meteor-ios How can a SQLite PersistentStore be set and allow offline use (if possible at all)?

Hey Martijn,

I'd like to make my app usable without a connection, is this possible? If positive, how can I configure it? I noticed I'm not getting access to the todo list if I'm offline.

Thanks!

Jun 08 '15 00:06 agusguerra10

Right now, there is no true offline support. Once the subscribed data has been loaded it will survive a temporary loss of connection though. You can continue to query the in memory database and updates will be performed locally (through the latency compensation mechanism). Once the connection is restored the performed updates will be sent to the server and you will receive a change notification if any of the subscribed data changed.

Jun 08 '15 05:06 martijnwalraven

Cool, thanks!

Jun 08 '15 19:06 agusguerra10

Hey Martijn, back again :)

Do you have any plans to add offline support? Or is it not a priority right now?

Thanks!

Jun 24 '15 20:06 agusguerra10

True offline support is not a priority right now. Doing this right will likely require changes to the DDP protocol.

Jun 24 '15 20:06 martijnwalraven

@martijnwalraven can you provide more details about "changes to the DDP" ?

Thanks

Jun 24 '15 20:06 yury

Well, there is no session resumption in DDP right now, meaning opening a new connection will always send all the data you're subscribed to over the wire. Some form of conflict resolution for updates may also be required, depending on the offline usage scenario.

Jun 24 '15 20:06 martijnwalraven

I think to get closer to this you could add a second persistence coordinator to the meter object context, saving data to sqlite once the app gets terminated. Then i suppose you could check on application launch if there is connectivity. If connectivity is missing and sqlite holds data you get a persisted cached version. Once meteor successfully connected to the meteor app, whipe sqlite cache and let meteor-ios do the caching. Basically you would prevent modifying any data during that "offline launched" state. After that i suppose the next step is use a child context. during save: if meteor cache is not empty just merge straightaway. If meteor cache is empty, add the changes to a stack. As soon as meteor connected, pulled down the data and sqlite got whiped, use your own sync nsoperation to handle conflicts the way you want it. Precondition would be to somehow store meteor server-side id's the sqlite persisted representation. What do you think? It is a bloody workaround and it's not the "way you should do it" but could provide a quick solution to the common offline case as long as we don't have the needed information from ddp to incrementally patch the sqlite store.

Jun 28 '15 11:06 pozylon

Let's back it so anybody might prioritize this ;) https://www.bountysource.com/teams/meteor-ios/issues

Jun 28 '15 12:06 pozylon

I think this is the holy grail for any ios developer, a reactive backend connector to coredata with support for offline data manipulation and @martijnwalraven you're so damn close to accomplish that with this beautiful api! :+1:

Jun 28 '15 12:06 pozylon

Thanks for the encouragement :) You're right there may be ways to support offline usage without making changes to DDP. I think the first step would have to be to make clear what use cases we're talking about, because different scenarios may require different solutions. You describe adding a read only cache with all subscribed data, but developers may want control over what data gets persisted. Parse for example has a more explicit mechanism than the one you describe, where you 'pin' objects to a local datastore to make them available offline: http://blog.parse.com/learn/parse-local-datastore-for-ios/

Supporting offline changes is likely to be more difficult, because you'd probably want to add some kind of conflict resolution to avoid situations where a person working offline for a while would overwrite changes made in the meantime by others when connecting.

Jun 28 '15 17:06 martijnwalraven

Hi there, i think having a read-only offline cache would be a major step forward with a flag on the model to cache it locally. i like the idea of pinning. i would not try to solve offline changing in the core of meteor-ios in the first place, like you said, conflict resolution is always a manual thing.

but maybe we need to come up with a concept on how to incorporate offline changes with meteor-ios. i will face this challenge in a few weeks.

Jul 03 '15 09:07 pozylon

Hi, I'm evaluating meteor-ios for use in my next project. How long is a temporary loss of connection? Suppose the app opens, downloads data via DDP, and then is closed. If it's re-opened later, will data be cached in CoreData? Or will the app no longer have access to any data from the server?

Jul 18 '15 18:07 andrewash

Data is only stored in memory and will be lost if the app exits. Note that closing the app is not necessarily the same as exiting. It may remain in the background for a short while (the OS decides how long, currently seems to be 180 seconds) and if it becomes active again within that time the data will still be there.

Also, if the app is active while the connection is lost, it will keep the data in memory and try reconnecting.

Jul 20 '15 04:07 martijnwalraven

Thanks you Martijn. That makes it very clear for me. I was hoping to get away with using meteor-ios, but I'll need offline support for this particular project. I may use a REST API on top of Meteor instead…

Thanks for your help!

Jul 20 '15 07:07 andrewash

+1 for offline caching... I am facing this issue as well.