I’m using the deploy plugin and checking on two different channels.
- Before the user logs in, I’m checking for updates on the production channel
- After the user logs in, I’m checking on a user specific channel
The reason I do this is the code for 1. needs to be super stable so that in case of a bug in 2, we can still rescue users with a deploy to the production channel.
My question is: if you’ve checked on the production channel and a new update is available, then downloaded and the app restarts, how does it know if the update on the user specific channel should be downloaded? Does it check snapshots by timestamp or something like that?
This doesn’t answer my question. It talks about binary versioning, not how the deploy plugin decides when a new snapshot is available
Sorry, upon rereading I actually understood what you are trying to do.
I am not 100% sure Channels were supposed to be used that way, so it could actually be that this case of “I installed a snapshot from Channel A, now I changed to Channel B - How do I decide if this snapshot from B should be applied or not?”
From looking at the actual code of the plugin we can now that all the necessary information is transmitted to the server at least:
But that of course doesn’t tell us what happens there, as the decision if the snapshot should be applied seems to happen all there. The app later only evaluates what the server returned:
So you will have to try it or ask someone at Ionic. Quickest way is probably to open a support ticket at https://ionic.zendesk.com/hc/en-us/requests/new?ticket_form_id=632068 (from https://ionicframework.com/support)
Thanks, this is actually useful info. I’m hoping that it figures it out on the server side by timestamping the snapshots and just telling you a new one is available if its timestamp is later than the installed snapshot on the device. I’m going to test this out and hope it works. Hopefully it doesn’t get me in to some infinite loop and drain our deploy quota! 
I just tested it and it does look like it goes into an infinite loop. Damn
So jumping between two channels all the time?
Will this work? If there is a bug in Channel 2 that breaks the application, this will also break your option to update from Channel 1 - so no way to rescue. Or did I misunderstand?
Hi Sujan, the very first thing that happens in the app is that it checks the production channel for updates. If we didn’t check the production channel first and there were any bugs prior to using the Deploy service, then a buggy push to the cloud would brick the app and it couldn’t be fixed.
However, the problem with checking the production channel as the very first step is that we don’t know who the user is yet (they haven’t logged in). We also want to be able to let the user log in, then check if they’re a “beta” user who should get a special release of the app to test new features. That way we can do controlled releases of new versions of the app.
But if you do the check on separate channels you then get into an infinite loop. I contacted Ionic support and they wrote this:
"I’ve chatted with one of our developers about this, and it sounds like you could potentially accomplish what you’re looking for, but it might take some creativity.
Essentially, Deploy’s channels weren’t conceived with the intention of an individual device switching from one channel’s updates to another. The app knows if a new update is available by checking the designated channel for an active deploy, then checking that deploy’s version number against the installed version on the device. However, the version number is the same, regardless of channel, so that might cause some issues with the way you’re trying to build this. "
I figured out a work around. Basically I first check on the production channel. Then when the user logs in and is marked as a “beta” user, I check for updates on the beta channel. I then write the channel name to localStorage. WHen the app starts again, it checks if there’s a channel in localStorage and if there is it uses that instead of the production channel. This at least removes the infinite loop. Not ideal (ideal would be for the server to only tell you there was an update based on timestamp) but it works
1 Like