Cordova app breaks on wake-up

I am testing my Meteor app on an iPad 3. It works fine if I run it once and work with it.

But if I send the app in the background, work with other apps like YouTube and wake my app up again after a while, it happens that the app is completely broken afterwards. Sometimes, I can still navigate it to some extent, and also the DDP connection seems to be working, but a lot of pages just do not show up as they should.

If I connect it to the Safari inspector, I see a whole bunch of Blaze-internal methods throwing errors. It looks like many of my template files have not been loaded, so Blaze does not find them.

It also happens that the app does not even startup anymore. It is stuck on the loading screen. If I then look into inspector, I see messages like that the variable “Meteor” is not defined.

I know these problems pretty well from hot-code reloads, which tend to break apps. But I am now experiencing these things even if no code changes have happened since I put the app in the background. So it seems to happen if an app has to re-start from scratch because it has been discarded by iOS to free up memory.

Any ideas how to tackle these problems?

In the ‘old way’ of doing Cordova with Meteor I had to listen for the device ‘background’ event and disconnect the meteor connection. On the ‘wake’ event I would then manually re-connect Meteor.

However, I would imagine this is one of the things the Cordova integration would handle right?

At any rate to try this just Meteor.disconnect() before you close the app and manually Meteor.reconnect() when you open it.

@waldgeist Is it totally broken or does it work again after you’ve “killed” the app?

@SkinnyGeek1010: Thanks for answering! In fact, I was using your listeners that I happened to find somewhere in a github repository just recently. :slight_smile: I was very happy to find this stuff, since I needed a way to react on wakeups, e.g. to set the user’s online status. I removed the disconnects / reconnects today to see if this changes things, and in fact, the app behaves better now. Maybe this was it? I don’t know, I have to do some more tests.

1 Like

IIRC, I had to re-install it.

But a “lost” connection shouldn’t destroy the whole app, making it unrecoverable. I also had the situation that my iOS app wasn’t working anymore without any HCP (that happened only 2-3x). Do you have the “safe-reload” plugin from Percolate installed? @martijnwalraven is this issue known?

I can’t remember the specifics but a few years ago it would totally freeze up the app when the socket died only on the divice though). It kind of sounds like this is a different issue though

There are known problems with hot code push, but I haven’t heard of the app going to the background causing missing files. Whatever is going on here, hopefully the new plugin will solve this too!


I was not aware of the “safe-reload” plugin. Thanks a million for pointing me to this package, I will definitely try it!

Since I removed the auto-disconnect and re-connect on sleep and wakeup, I did not experience this issue any more. Hopefully, it is resolved by this measure. Although I do not understand why this should not work. On the contrary, I thought that @SkinnyGeeks1010 code would be a good idea, since the app does consumed less resources this way.

Yes, I really want this new plugin! These HCR issues are a pure nightmare. Thanks for working on it. Can’t wait until it’s finally there…

BTW: One thing I forgot: When I looked at the Safari logs, I also noticed that there were some entries saying that the WebSocket connection was closed before data could be retrieved. I can’t remember the exact message text, but it showed up quite frequently. Maybe this is related to the issue?

Does it still auto connect/disconnect? I thought I removed that after the meteor iteration came about. At any rate it prob. needs to be deprecated, not sure if keeping the state of the device in session keys is a good idea (stale data).

You removed it in two of four callbacks, it’s noted in the Readme:

I’m not using the session keys either, but the events themselves came in handy.

BTW: It’s a bit strange that Cordova does not namespace these events. :-/

I tried out my app today morning, after letting it sleep over night. And it worked! So I guess the problem was really related to the disconnect / reconnect thing. (Not 100% sure because I also applied the safe-reload package in the meantime.) Maybe it’s a good idea to deprecate this package (or only let the session variables in it for those who need it). And just as a side-note: I read in the Cordova docs today that the events “online” and “offline” are only fired if the plugin cordova-plugin-network-information is present. Doesn’t seem to be the case in standard Meteor. Maybe you’d like to include this plugin as a dependency?

1 Like

Just added a deprecation notice, thanks!