Hi all,
The download of new hot code push bundles is delaying my initial data download when my Cordova app opens, resulting in a bad experience for my users.
Is there any way I can delay the check for updates until after my data has downloaded?
The relevant code seems to be at
But I don’t see a way for me to delay the check without modifying the source.
Thanks,
Graeme
I used to use this package to control how my users get updates: mdg:reload-on-resume - Packosphere
Now that I am more focused on PWA, I use a solution found here, discussed a couple of weeks back:
import { Reload } from 'meteor/reload'
Reload._onMigrate(retry => {
store.dispatch(toggleShowNewVersion(true)) // I use this state to show the user a prompt with a button to reload the new version.
return [false]
})
I am not sure if this would work in the context of Cordova.
Quave Reloader package offers a lot of options to control when to replace the bundle.
There is a full example with React on how to expose this to users as well.
Check it out here quave:reloader
@filipenevola @paulishca I think you guys have misunderstood.
I’m looking to control when the update is DOWNLOADED, not when it’s deployed.
The downloading of the update bundle competes with the downloading of initial collection data, which delays the start of my app. I’m pushing updates quite regularly, so this happens almost every time a user opens the app.
I’d like to be able to manually trigger the check that downloads the bundle update, but I can’t see how to do that.
(I am actually using quave:reloader to control when it update is deployed and it works well)
When there’s an update to download also, the app takes 36s to startup and load data.
Without the update, it takes 20s
Hmm sorry.
You could control manually your version but by default this is defined by app and not by client.
Do you want to control by client to defer the load for each one, right?
I think this would require some changes in Meteor core packages but this is totally doable.
Right now Meteor sends this in the first connection but you could start to send the current version of the client in the first connection but ignore any differences and then after a few seconds ask for changes again.
If you need help with this please let me know, maybe we could review this code from the core together in a call so I can point you a few places where you have to change stuff. Feel free to email me (filipe@quave.dev) as I check my email more often than here 
20sec is at least 15 sec more than it should take
Tx @filipenevola, I was afraid it was going to require core changes 
Do you know if I would still be able to use the Git push-to-deploy with Galaxy if I’ve made core changes?
Thanks for the offer to help, I’ll take a look at the code myself first to see if I can make sense of it and then get in touch.
Sure, you can run core packages making a copy in your own project and you should also submit a PR enabling this option for all 
But both options will work fine with Galaxy P2D.
I managed to find a way to do this without modifying the Meteor source. The autoupdate package subscribes to “meteor_autoupdate_clientVersions” from a Meteor.startup() callback, so I was able to intercept and defer it until after all my data is loaded:
if (Meteor.isCordova && Meteor.userId()) {
console.log("User logged in, deferring update check to after data load");
Autoupdate._retrySubscription_original = Autoupdate._retrySubscription
Autoupdate._retrySubscription = () => {
console.log("Intercepted update check on startup, deferring");
allDataReadyPromise.then(() => {
console.log("Running deferred update check");
Autoupdate._retrySubscription_original();
});
};
}
Thanks for your help @filipenevola
Smart! 
Nice job!
It sounds like you’re facing a challenge with the hot code push in your Cordova app affecting the initial data download experience for your users. While the Meteor package you’re using seems to automatically check for updates on startup, modifying the source code might not be the best approach, especially for maintainability.
One alternative could be to use a custom event or flag that gets set once your initial data download is complete. You could then use this event or flag to trigger the hot code push update check. This way, you can ensure that the update check only happens after your data has been successfully downloaded, improving the user experience.
Here’s a simplified example:
let isDataDownloaded = false;
// Your data download logic here
function downloadData() {
// ... download data
isDataDownloaded = true;
// Trigger update check if data is downloaded
if (isDataDownloaded) {
newVersionAvailable();
}
}
Meteor.startup(() => {
// Delay autoupdate until data is downloaded
if (isDataDownloaded) {
WebAppLocalServer.onNewVersionReady(() => {
if (Package.reload) {
Package.reload.Reload._reload();
}
});
Autoupdate._retrySubscription();
}
});
function newVersionAvailable() {
WebAppLocalServer.checkForUpdates();
}
This is just a conceptual example and would need to be adapted to fit into your specific app architecture. As an app development company in Miami, we often face similar challenges and find that a custom approach like this can offer a more tailored solution.