Cordova "Lite" Build which skips the local server & simply loads a remote URL

[DanielDornhardt]

Hi,

tl;dr:

Create a cordova-lite - build for people wo don't need or want an offline mode with anything too fancy.

Make the cordova build create a lighter shell wrapper & load the external app URL instead of downloading the app to the local server.

We would actually be willing to sponsor somebody competent to have a look at this & maybe work with us to develop a prototype. Get in touch if you're interested. (Is there a good place to put code sponsorships like this with any chance of it taking off?)

/tl;dr

The cordova webapp-package sometimes creates issues for of us when implementing certain behaviours & also because of the kind of hard to control the update cycle between the built apps from the app stores and the "soft" HCP version served by the meteor server.

Maybe it'd be simpler for us to just have the cordova app load the current app from our app URL and to have a simple hook / callback / page to handle the offline case (we can actually already do that once the app has been loaded using the Meteor.connection.status() reactive functions).

So there is a value for an initial version of the app being available, if only for us to be able to show the "not connected" status! :D But maybe there could be a workaround for that. Either with a default - configurable Page and/or mini-app or some other mechanism...

(I am actually not that well versed in the PWA space, but the PWA / Progressive Web App Approach using a worker to load & update ressources might be something to look at there too).

Of course the devil's in the details and there might be some things which I haven't considered, but that's always the case.

The build complications, the wrestling with the HCP & planning and syncronizing updates across a device population of a certain size + the server makes the whole deployment process harder for us than it needs to be.

Of course it'd be great if crowd favourites like Meteor.isCordova could be implemented as well.

One issue are the existing meteor packages which might rely on a) Meteor.isCordova and/or b) other "advanced" Meteor Cordova Features.

That would be something to look at & take into account of course.

But basically, this "simpler" wrapper would allow us to deploy more often and with less headaches.

---

So, what do you think? Good Idea? Stupid? Interesting? Valuable?

What did I miss / didn't think off? What else does the Meteor Cordova Webapp mechanism provide I might have forgotten about? Which other issues would need to be to be addressed?

Could this be done in a package? What kind of patching would there be needed in the Meteor Core?

Or maybe we can create a separate, simpler "Meteor-Cordova" - Wrapper - Project which could be used to wrap a meteor project, but doesn't use the full meteor build system? (The problems I see here are existing meteor packages not able to access the Meteor.isCordova - flag / code not being included from the package.js - api.addFiles('...', 'cordova') ) - sections. Some things to chew on.

Thanks and best

Daniel

[StorytellerCZ]

I like this idea in general and would prefer it over implementing an independent "Meteor-Cordova" - Wrapper.

[filipenevola]

Hey @DanielDornhardt, I understand from where your idea is coming from but I would like to dig a little bit in the problem here.

It seems to me that you are having a few issues with current Meteor/Cordova integration and also HCP after your app is live on stores and as a way to solve your problems you are thinking about a new way to deliver the app code to your native app.

It seems to be a good idea but I believe you would lose a lot of benefits and in the end you would need to write a bunch of workarounds (like an offline mode) that will end up in a very similar solution (and maybe the same problems).

Could you be more specific about your issues with the current integration and HCP?

For example, did you already check this package https://github.com/quavedev/reloader ? I wrote it last year in order to give the developer more flexibility handling HCP updates.

Maybe enhancing the current solutions we could have a better final result instead of trying to create a new solution.

[DanielDornhardt]

Hello @filipenevola ! Thanks for getting back to me.

I'm still struggling to get all of this together.

I think the main issue for us is that we can't be sure that the client and the server versions are in sync properly.

One issue that there's inherently an interval where we don't know whether the customers have the updated App yet or not. As the delivery through the App Stores isn't immediate & it takes some time for all clients to update. The update takes some time to appear in the stores of different people anyhow, and some people have set their phones to update at night / with wifi only / but then their on airplane mode at night / yadda yadda. So some people may be on the most recent build, some might be on an older build.

Also, a "trust issue" for Code which should be shipped via HCP: If there's a problem on a clients device with the HCP, in general the new version gets blacklisted and the device won't try to update to that version anymore, even though the update might go through eventually.

This is - as far as I know - impossible to fix from the client / JS code in any way. Is that correct? Or can we trigger a retry and/or send us a notification if the update failed & then try to make the clients reload later if anything goes wrong?

Basically the only way to force a retry is to uninstall and reinstall (maybe just clear the app cache, but not sure if that exists for iOS?). Then the app will try to load the newest version again.

Or alternatively we could try and push a new version to the App Store, which in Apples case takes probably at least a day or so.

IF IT DOESN'T, OUR CUSTOMER IS STUCK WITH AN OLDER VERSION.
That wouldn't happen if the app would just reload from the server as the browser builds do.

This leads us to the problem that we have to do the following song & dance:

1. Make sure the latest version of the App works with the latest server version. That should be a given. That's just our regular Software Development.

But then, additionally:

2. Make sure that the newest server build works with the previous app Release (Methods + Publications signatures must be backwards-compatible). Because of people stuck with a hanging HCP or until the update has been delivered through the app store. So we need to keep copies of the previous staging builds to be able to test that against our current staging server.

3. Make sure that the previous version of the server code still works with the latest version of the app code because of the Apple (and maybe sometimes Android?) testers which will try and open the app when checking it. So we have to check whether the new live build will work with the current / previous live server build which is of course still online until both android + apple apps have passed their stores.

4. After both Apps have completed the store review, we put them online manually & update the live server (which takes some minutes actually so it's not a precise thing).

5. Don't forget to make backups of the current staging app build so we can check Step 3. again for the next release.

6. After a few days we can display a message to everybody whose Cordova App hasn't yet been updated through the OS mechanism that they need to update themselves or they can't use the app anymore. To make sure that they update the app.

This is basically the process we currently have to take care of all eventualities, which is a huge headache of course.

Is there a better system out there? Are we missing something obvious to make this easier?

---

Also, about https://github.com/quavedev/reloader : That's nice, but we're a bit shy about asking / informing the users to update, as we don't want the apple testers to see such a message. So we'd have to be careful when to release new versions because we suspect apple not being happy about their update mechanisms being subverted. So we prefer the sneaky approach currently.

Also, if the HCP would get stuck & would blacklist the version on a phone, that wouldn't help us either I think.

Thank you for listening :) I feel better already :P

[renanccastro]

I had to deal a lot with things like this, but I don't think the proposed solution works unless we force a refresh as we do on hcp (if you don't, you would still have old clients accessing server-side things), and this would lead us on having a way to inform an update and other things that come with this. What if the client doesn't have a reliable connection at the time? You would be in the same scenario unless the user forcefully closes your app.

There is also a need to prevent new code from running at an outdated Cordova plugin base, with a missing native interface, for example, so we will always have to be careful when updating JS code.

This is a tough issue, but I actually believe that a better HCP system, or at least a more customizable one, can be a solution to it. Like in your proposed scenario, don't you think that it would be the same thing in a wrapped URL? How can we solve it?

The "fallback" build code that we store in the device, actually helps in all these cases ;) What if we could specify breaking versions inside our HCP? quave/reloader also helps in this, but we might need a integrated solution in the core.