Hi,
I am planning to build a mobile application which will work in offline with auto data sync( while online). Please guide me the correct solution for this approach.
- Meteor + GroundDB
- Meteor + PouchDB + CouchDB
Thanks in Advance,
Sathish
Hi,
I am planning to build a mobile application which will work in offline with auto data sync( while online). Please guide me the correct solution for this approach.
Thanks in Advance,
Sathish
No one replied… Can you please help me out on this?
Share me design /architecture / sample code for Offline data auto sync Client(s) to server and server to client(s).
If we dont have anything, just share your ideas,let me start write coding and post.
CC top users… @abernix, @gothicmage, @jamiter,@mokaid, @robfallows, @babrahams, @knana, @tomsp, @sashko, @diaconutheodor
Check this -
Thanks for your quick reply. Let me check this.
Did you get a chance to check it? Do let me know your findings.
The “magical offline capabilities” don’t survive a restart of the app though, for that you’ll need ground:db. ground:db doesn’t have any feature to automatically push local changes to the server on reconnect though, you’ll probably have to figure out that part yourself.
Hi Eveyone, I found this post which is working perfectly in online and offline along with auto sync.
http://rafaelquintanilha.com/offline-app-with-meteor-and-cordova/
i have tried very basic testing and working fine. But need to do more testing with different datatype collections.
Have anybody tried this already? Is this advisable one?
And also, want to know grounddb will work with Angular 2?
Thanks for sharing. I’ll also go through this.
not exactly pouchdb+couchdb but it’s close. also uses react native which you might be possibly using.
other than that just look into db replication
Don’t know should I have asked this or not, but in case you are done, would you mind sharing which way you choosed?
Regards,
Smith
https://viamichelin.onl/
https://googleearth.onl/
I won’t share my complete solution, but I will give some pointers as to the different aspects and pitfalls, they may not all be relevant to you though. It would be interesting to hear the “skeleton” of others approaches too.
If you want to support offline mode that persists restart, in cordova AND on the browser, you need all of the following
Most of our approach is built around minimal changes to the UI code by instead patching anything the UI code could use (insert/update/remove/find/findOne/call/apply/subscribe)
We wrap our main collections with a bespoke class that listens for insert/update/remove calls and if online passes them through as normal, if offline stores them in a list and calls the equivalent method on a grounddb
collection. Similarly, we intercept find/findOne calls and use a grounddb
collection if we’re offline.
We patch subscribe
to check if we’re offline, and if we are return a “handle like object” which immediately involkes the callbacks
We patch Meteor.call
to check if we’re offline and look at a grounddb
collection of saved method call results.
We utilise a service worker and a static list of URLs required to take offline (e.g., image assets) combined with a scrape of the current HTML for any <script>
or <link>
tags (to ensure we have the latest CSS and JS.
We use the same service worker to cache dynamic assets the user has requested, e.g., uploaded videos and images.
In cordova we use cordova-plugin-httpd
cordova-plugin-background-download
cordova-plugin-file
and cordova.plugins.diagnostic
for webserving (exclusively for video assets), background download, file storage and permissions requests respectively.
When the user opens the app and has no connection, we check if they’ve logged in before and taken content offline (e.g., they have a local copy of their user) in which case we force the login method to return true, and rerun the real login when they connect to the server.
We also force a disconnect - in our situation we want all users to be offline if they can. We dont want a flaky connection toggling them between live data and cached data, so we wait 10 seconds on login to try for a connection, then we stop trying. We actually spin up a secondary connection in the background to detect when a connection may be available, and prompt the user to see if they want to reconnect.
Thats all I can remember from our solution