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.
@SkinnyGeek1010: Thanks for answering! In fact, I was using your listeners that I happened to find somewhere in a github repository just recently. 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.
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 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.
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).
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?