Question about Setup / can our requirements be solved with this package?

[DanielDornhardt]

Hello,

we're developing a cool modern meteor-cordova-app (of course, why would we be here otherwise? :) ) and we're fine-tuning the startup experience at the moment.

What we'd like to have the app behave like in the end is this:

• First launch and any launch after more than 10 minutes of being in the background or not running: Show the splashscreen (so far, so good!) and do the update while the splashscreen is still showing - don't let the user start with a stale version if possible.
• After launch: don't restart the app if the user switched away from the app for less than eg. 10 minutes.

Note: All this is mainly tested on an LG G2 Android Device using the crosswalk package at the moment.

An example for the issue we're running into at the moment:

• The user starts the app and sees a login screen
• a release is detected / being loaded in the background
• The user enters his username
• The user might switch to another app to go read his password or something similar
• The user comes back - and the app reloads. He needs to re-enter his username too.

We could mitigate the missing username in this case by storing the content in a more permanent spot, but this is just an example. At any point in the app the user could switch to another app and switch back a few seconds later.

I thought that this would actually be solved by the default Reloader config: I interpreted (wished? it to be:) ) it as follows:

Reloader.configure({
    check: 'everyStart', // Yes, that's cool, but only on "real" starts or after idleCutoff seconds?
    checkTimer: 3000,  //3 seconds  // don't know what this is?
    idleCutoff: 1000 * 60 * 10  //10 minutes  // only restart the app after more than 10 minutes have passed since the user navigated away from it
});

The behaviour we're observing at the moment (using the default options at the moment):

• The app starts the first time. If an update is available, it won't be loaded immediately, the splashscreen will be hidden and the app will start running, but not with the latest version (Reloader.updateAvailable.get() will return true )
• Going to the homescreen for a few seconds and returning will trigger a reload (splashscreen, reload of app)

Is there a way to get it to work as we'd like it to using the configuration options provided?

Also, maybe some more explanation of what "checkTimer" and "idleCutoff" are doing (or should be doing? It doesn't really seem to wait for 10 minutes for me for the refresh when not in the app) would be helpful. If you can guide me to a better understanding, I'll gladly update the docs for you.

[jamielob]

Hi @DanielDornhardt -

Looks like two separate things are happening.

1) App starting the first time - Can you try increasing checkTimer to 10000 and letting me know if you then get the latest version on first start? checkTimer is how long we wait to see if there is an update available from the server. In future versions of Meteor we will have an API to instantly check if something is available or not, but until then we need to wait to see if a new code bundle is downloaded. If 10 seconds works for you, try reducing it a little.

2) The other piece (losing the username) is a scenario that I hadn't thought of and one that should definitely be catered for. Currently, if an app update is downloaded in the background and we have it ready, the app updates as soon as it can do it without any interference to the user (resume/start). Let me think about the best way to add this.

Let me know when you've tried increasing the checkTimer.

[jamielob]

@DanielDornhardt - I've added a configuration option called refresh that should allow for your scenario. There are two different things that can be configured with hot code push and this package:

1) When we make additional checks for new code - controlled by the check option 2) When we refresh to code that has already been downloaded - controlled by the refresh option`

For example:

Reloader.configure({
    check: 'firstStart', // Only make an additonal check the first time the app ever starts
    checkTimer: 5000,  //Wait 5 seconds to see if new code is available on first start
    refresh: 'start' // Only refresh to already downloaded code on a start and not a resume
});

This will make sure the first time your app is run it is up to date, will download new versions of code while the app is being used, and then only update when the app is next started.

[DanielDornhardt]

Hi @jamielob , thanks for the update + the explanation! That's awesome! :D

One more thing I'd like to understand, if you'd be so kind as to explain:

So - the "checkTimer" is meant to be a timer of additional time waited until the Splashscreen is released to see whether Meteor finished downloading an update?

So we have to choose whether we want to wait longer (in case of eg. bad connection speeds) until we release the splashscreen on every start or whether we want a faster startup experience, is that right?

Because you can only detect the hot code push after meteor has finished downloading it, is that it?

Thanks and best wishes

Daniel

[jamielob]

@DanielDornhardt - Absolutely correct! And if it doesn't finish downloading until after the checkTimer has finished, it will simply be applied at the point you specify with the refresh option.

[DanielDornhardt]

Hello Jamie,

a little bit of follow-up here:

First and foremost, thank you again for your help and your answers.

And then: I think I have the source of our woes, and turns out - it's actually independent of the reload-on-resume / reloader - packages... :/

The thing is, we're using crosswalk for our android apps and that leads to Android deciding rather quickly that it'd like to garbage collect the precious RAM we're using, killing off the app soon after a task switch, with nothing left to go back to except for a new App launch.

I thought that might be tangentially of interest to you, because this package is about reloading, in a way, and these Reloads are not by you, but people might still report about them or be confused why the nice settings they configured (eg. "idleCutoff") don't seem to be respected when really the app gets started afresh almost every time the user leaves them.

Actually that's kind of a real problem for meteor apps I start thinking now, because the reload always takes some time with Meteor Apps anyway, and if we add another few seconds for something like Reloader - it quickly could become rather painful to build something the user would like to go back and forth to for some reason or another.

Anyways, here are the links to an Issue on the Meteor issue Tracker and a Meteor Forum Post I did:

Meteor Issue Forum Post

[jamielob]

Hi @DanielDornhardt - Makes sense. The best option for you at this moment will be to use the following options:

Reloader.configure({
    check: 'firstStart', // Only make an additional check the first time the app ever starts
    checkTimer: 5000,  // Wait 5 seconds to see if new code is available on first start
    refresh: 'start' // Only refresh to already downloaded code on a start and not a resume
});

This will make sure the first time your app is run it is up to date, will download new versions of code while the app is being used, and then only update when the app is next started. This should result in zero delays for you.

[jamielob]

I'm going to leave this open until you've had a chance to check the above config.