Hey folks, as always, thank you for the great work on Expo.
I have a few questions regarding the Util.addNewVersionListenerExperimental API (link) if anyone could please provide some more color.
Does anyone have a working example of this?
My implementation is as follows, based off of the documentation & this gist. I am currently on v23.0.0 :
import React from 'react'
import { Util } from 'expo'
import { connect } from 'react-redux'
class App extends React.Component {
...
componentWillMount() {
Util.addNewVersionListenerExperimental(() => {
this.props.dispatch({type: 'SHOW_TOAST', payload: "App update available, reloading in 5
seconds..." })
setTimeout(() => Util.reload(), 5000)
})
}
...
}
export default connect()(App)
I have yet to see this toast notification fire, so I’m not entirely sure that I’m implementing this correctly. I also do not believe that Util.reload() is firing, since Android users still need to close & reopen the app 2x to get the OTA update.
Does Util.addNewVersionListenerExperimental only look for an update when the app is first loaded? Or can an event containing the new manifest of the project come in when a user has the app open / reopens the app from the background?
Hi @pcooney10 thank you for the detailed explanation. It looks like you’re using it pretty much right so not sure what could be breaking. Could you maybe try moving that into the constructor? @esamelson is working on this API now and we should have some improvements within the next few SDK versions.
To answer question #2, Util.addNewVersionListenerExperimental does indeed only look for updates when the app is first loaded. It’s not “listening” to the server all the time for updates, but is actually listening for a native event that can only fire when the app is loaded. Check out https://forums.expo.dev/t/when-does-the-add-new-version-listener-actually-check-for-updates/4785/2 for more information.
FWIW, your code looks a lot like mine, so I would expect it to fire when the app is loaded for the first time after publishing an update. Also, heads up that there’s no guarantee that this event will fire at any particular time after the app loads (just sometime), so if you auto-reload in response to the event, the user could potentially lose work-in-progress.
A few other caveats on the update process in Android:
If you publish a new APK to the Play Store, some of your users will get the new JS bundle immediately on first run after the update. So this could theoretically work for ensuring users get a critical update ASAP. Unfortunately, this only works for Android users running 7.0 or higher. <= 6.0 users will still see the old JS the first time running the app after a Play Store update. I’m guessing this is not by design, but it’s unclear if or when it’ll be fixed. See this open issue: https://github.com/expo/expo/issues/1122#issue-282671789
Calling Util.reload() may cause problems if your app displays images uploaded by other users. If your app uses an API that downloads images secured with a session cookie (or anything else in an HTTP header, like a JWT), then your app will stop downloading images after Util.reload() is called (it will fix itself once the app is manually force-closed and started again). See this open issue: https://github.com/expo/expo/issues/370#issue-243064615.
After making some updates, namely moving the declaration to the constructor & removing the listener when unmounting, I observed the Util.addNewVersionListenerExperimental callback firing once in about 5 or 6 attempts when new bundles were available. I got a white screen that was hanging, and had to manually restart the app.
I am still only on v23.0.0, and am tabling my efforts on this for the time being. Will test more & report back when I update to v25.0.0.