Ik ben van plan een web applicatie uit te breiden met een mobiele app die offline beschikbaar moet zijn. De web app maakt momenteel gebruik van een REST API die op zijn beurt MySQL achter de schermen gebruikt. Het grootste deel van de gegevens kan vanuit de MySQL database naar de mobiele database gekopieerd worden (master-slave). Een klein deel van de gegevens moet zowel op de website als mobiel door de gebruikers aangemaakt en bewerkt kunnen worden en moet dus gesynchroniseerd worden.
Bij het uitwerken van deze mobiele app heb ik een aantal vragen:
1.Welke embedded database lijkt het best geschikt voor mijn vereisten? SQLite ziet er het meest voor de hand liggend uit en hier heb ik reeds ervaring mee. Met Realm of PouchDB heb ik geen ervaring.
2. Wat de synchronisatie van de mobiele database naar de REST API/MySQL betreft; wat lijkt hier de beste strategie? Omdat ik graag de simpliciteit van master-slave behoud, dacht ik aan een soort van offline queue op mobiel die de updates naar de REST API stuurt. Indien de timestamp van de update groter is dan die binnen de MySQL database, dan wordt deze toegepast.
3. Als gegevens veranderen in de MySQL database, dan moeten deze ook op de mobiele clients aangepast worden. Elke table/resource van een created/modified timestamp voorzien, lijkt me een mogelijke oplossing, zodat de mobiele app naar aanpassingen kan pollen vanaf een bepaald tijdstip.
4. Verdergaand op 3, lijkt het me niet aan te raden de offline database met alle gegevens te embedden bij de installatie van de app. Als er nieuwe data beschikbaar is op de REST API, betekent dit dat de mobiele app telkens na installatie gesynchroniseerd moet worden. Na verloop van tijd kan dit er voor zorgen dat de hoeveelheid data die gesynchroniseerd moet worden te groot wordt, en dat het beter is een nieuwe versie van de app met de nieuwe database beschikbaar te maken.
Ik zou liever enkel de app updaten, als er effectief code veranderd is, en de meest recente database gewoonweg na installatie downloaden. Is het mogelijk om tijdens het installatieproces van de app (iOS/Android) deze database on-the-fly te downloaden? Ik wil niet dat de gebruiker na de installatie van de app zonder database komt te zitten.
Bij het uitwerken van deze mobiele app heb ik een aantal vragen:
1.Welke embedded database lijkt het best geschikt voor mijn vereisten? SQLite ziet er het meest voor de hand liggend uit en hier heb ik reeds ervaring mee. Met Realm of PouchDB heb ik geen ervaring.
2. Wat de synchronisatie van de mobiele database naar de REST API/MySQL betreft; wat lijkt hier de beste strategie? Omdat ik graag de simpliciteit van master-slave behoud, dacht ik aan een soort van offline queue op mobiel die de updates naar de REST API stuurt. Indien de timestamp van de update groter is dan die binnen de MySQL database, dan wordt deze toegepast.
3. Als gegevens veranderen in de MySQL database, dan moeten deze ook op de mobiele clients aangepast worden. Elke table/resource van een created/modified timestamp voorzien, lijkt me een mogelijke oplossing, zodat de mobiele app naar aanpassingen kan pollen vanaf een bepaald tijdstip.
4. Verdergaand op 3, lijkt het me niet aan te raden de offline database met alle gegevens te embedden bij de installatie van de app. Als er nieuwe data beschikbaar is op de REST API, betekent dit dat de mobiele app telkens na installatie gesynchroniseerd moet worden. Na verloop van tijd kan dit er voor zorgen dat de hoeveelheid data die gesynchroniseerd moet worden te groot wordt, en dat het beter is een nieuwe versie van de app met de nieuwe database beschikbaar te maken.
Ik zou liever enkel de app updaten, als er effectief code veranderd is, en de meest recente database gewoonweg na installatie downloaden. Is het mogelijk om tijdens het installatieproces van de app (iOS/Android) deze database on-the-fly te downloaden? Ik wil niet dat de gebruiker na de installatie van de app zonder database komt te zitten.
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
:strip_icc():strip_exif()/u/86599/crop681cb5088171b_cropped.jpg?f=community)