Cordova app (Android) not reloading after hot code push with deployed app

blouze · January 13, 2016, 12:22pm

Hi,

my app is hosted on scalingo.io

When building the app with:

meteor build --server http://mylocaldevmachine:3000

where mylocaldevmachine:3000 points to my dev server, HCP works great, and I can see the mobile client getting new code.

When deploying to scalingo, and building like so:

meteor build --server http://mydomainpoitingatscalingohost

the app works just fine (browser and Cordova), shows the latest version of the UI and communicate with server as expected. If I push new code, browser clients get updated, not so much for Cordova ones…

I’m aware there have been many issues regarding HCP posted on this forum, and that development is active on this particular subject (thanks @martijnwalraven), but I have not found one where it stopped working after deployment, or the requirements for setting it up correctly on my particular hosting (I’ve contacted them already, they’re awesome and very reactive, but unfortunately they could not give me an answer).

ROOT_URL is set correctly on target host.
I use --mobile-settings option to build the app.

Does someone know how I can troubleshoot this?

martijnwalraven · January 13, 2016, 1:00pm

I suspect the issue is that ROOT_URL has not been set correctly on the server. Could you check the value of __meteor_runtime_config__ in the generated index.html?

blouze · January 13, 2016, 1:15pm

Hey @martijnwalraven.

From .meteor/local/cordova-build/www/application/index.html :

__meteor_runtime_config__ = JSON.parse(decodeURIComponent("%7B%22meteorRelease%22%3A%22METEOR%401.2.1%22%2C%22ROOT_URL%22%3A%22http%3A%2F%2Fapp.shredd.io%2F%22%2C%22ROOT_URL_PATH_PREFIX%22%3A%22%22%2C%22DDP_DEFAULT_CONNECTION_URL%22%3A%22http%3A%2F%2Fapp.shredd.io%22%2C%22autoupdateVersionCordova%22%3A%228bd56ee340585a6f3ccf9bab5b3aaced104087b3%22%2C%22appId%22%3A%221yb4n7j1dgujxeg48ddu%22%7D"));

which gives me:

{"meteorRelease":"METEOR@1.2.1","ROOT_URL":"http://app.shredd.io/","ROOT_URL_PATH_PREFIX":"","DDP_DEFAULT_CONNECTION_URL":"http://app.shredd.io","autoupdateVersionCordova":"8bd56ee340585a6f3ccf9bab5b3aaced104087b3","appId":"1yb4n7j1dgujxeg48ddu"}

So I guess it’s set alright. Could it be the value gets overwritten once deployed?

martijnwalraven · January 13, 2016, 1:20pm

Yes, you should check the value you get from your server. If I look at http://app.shredd.io/, I get (leaving out some values):

ROOT_URL: "http://app.shredd.io" ROOT_URL_PATH_PREFIX: "" autoupdateVersion: "48e95924831ba7f35016d6b508d0c2500d0e0a85" autoupdateVersionCordova: "none" autoupdateVersionRefreshable: "e19b8a7d9e540cdeb93977f8f19588b74187fd85" meteorRelease: "METEOR@1.2.1"

So it seems that although the ROOT_URL has been set correctly, it is somehow not serving the Cordova version. Did you remove the mobile platforms from your app by any chance?

blouze · January 13, 2016, 1:34pm

That’s interesting.

meteor list-platforms
outputs android, browser and server. So nope

martijnwalraven · January 13, 2016, 1:39pm

Hmmm, I wonder what could be going on here. Is that the meteor list-platforms output on the server? How are you running Meteor?

blouze · January 13, 2016, 2:11pm

This is the output on my local dev machine. I could not run it on the server (command not found).

I’m using iron-cli to scaffold my app and run the local server (I don’t think it’s relevant, it’s basically passing the build and run commands along to meteor), so the meteor app has it’s own folder /app.

Details about deploying meteor on scalingo can be found here :

Like explained here, app folder needs to be specified setting PROJECT_DIR in host environment.

Basically,I just push my local branch, the container gets restarted, and I can see the expected behaviour in a browser tab, updated with new code.

I can’t tell when or why __meteor_runtime_config__.autoupdateVersionCordova gets overwritten.

martijnwalraven · January 13, 2016, 2:27pm

I’m not familiar with the scalingo setup, but it seems they use demeteorizer. Could it be that they somehow do not build the web.cordova architecture?

soulou · January 13, 2016, 3:00pm

Hi @blouze, hi @martijnwalraven

I’m Scalingo’s CTO,maybe I’ll be able to give you a little more insight about our build process. Currently, we do not build to the ‘android’ and ‘ios’ targets. Once built, the programs directory looks like the following:

bundle/programs $ ls
server	web.browser

It makes no sens for us to build the ios and android targets as we’re only hosting the web part of the application. Does the ‘server’ target needs the ‘android’ target to be enabled to allow hot code push?

Regards,

– Leo

martijnwalraven · January 13, 2016, 3:13pm

Hi @soulou, thanks for looking into this. The server target indeed needs to build the web.cordova architecture to be able to serve updated code to mobile clients.

I’m not sure about your workflow, but the easiest solution is probably to leave the ios and/or android targets in as part of the projects and use meteor build as usual.

If you want to dive in more into what is going on, see:

github.com

meteor/meteor/blob/devel/tools/project-context.js#L1133-L1140


};


_.extend(exports.PackageMapFile.prototype, {
_readFile: function () {
  var self = this;


  var fileInfo = watch.readAndWatchFileWithHash(self.watchSet, self.filename);
  var contents = fileInfo.contents;

soulou · January 13, 2016, 3:37pm

Actually, letting ios and android does not work for us, building the ios target requires a Mac OS environment to build this target and building the ‘android’ target requires a full Android SDK which is not available in our nodejs/meteor building environment.

For us the ideal solution would be to build the web.cordova architecture without building the full android application. (it has no sense for us to build an Android application on our web hosting platform )

Have you any idea of the feasability of this?

Thanks !

martijnwalraven · January 13, 2016, 3:56pm

Hmmm, I’m not sure what the best way to deal with this would be. I’ll ask around and get back to you!

blouze · January 20, 2016, 12:23pm

Hey @martijnwalraven.

I was wondering if you had some new information on the requirements for building for the web.cordova architecture without the hassle of hosting SDKs and system environments.

Cheers.

martijnwalraven · January 20, 2016, 2:20pm

We’ve been talking about it internally, and we agree we need to find a solution for this. One option we discussed would be to allow adding a cordova-server-only platform. Another option might be to add a --server-only option to meteor build.

martijnwalraven · March 2, 2016, 9:20am

@blouze @soulou: In 1.3-beta.12, I’ve added a --server-only option to meteor build that doesn’t require the mobile SDKs to be installed on the build machine, but that will still build web.cordova when ios or android platforms have been added to the project.

soulou · March 2, 2016, 9:51am

Hi @martijnwalraven

Great, thanks for adding this to the build chain, it will be very useful for us

blouze · April 3, 2016, 3:32pm

Hey @martijnwalraven!
As a meteor-head, I want to thank you all at MDG for your hard work to bring us 1.3

I just upgraded my mobile app to find out if it would solve my previous problem.

I am able to get the HCP working with a published Cordova app built with --server option set on a locally running instance (I had to build the app first, and then run meteor with a target specified as pointed out here).

After deploying the app in production, I can see the same behaviour as before, web client gets refreshed, no cigar for Cordova.

Values for ROOT_URL is set alright in runtime config, I even get a value for autoupdateVersionCordova.

Pls, halp.

martijnwalraven · April 3, 2016, 3:46pm

Are both the app and your server on Meteor 1.3?

Can you check if the asset manifest is served at /__cordova/manifest.json on your production server?

Any error messages either in logcat or with Chrome remote debugging?

blouze · April 4, 2016, 10:01am

I forgot to mention __cordova/manifest.json gets served.

BUT, opening logcat (thx for the tip) got me:

Error: Skipping downloading new version because the Cordova platform version or plugin versions have changed and are potentially incompatible

cordova --version gives 6.1.0

Trying to update incriminated plugins… Getting back at you after that.

blouze · April 13, 2016, 2:50pm

Nope, still no luck with my issue

I tried removing every single cordova plugins (including crosswalk), I still get the same error.