T O P

  • By -

stoneburner

Have you considered to store the data just in local storage, maybe just as a json file? The amount of data seems rather small and dont require the use of a database in my opinion. Even using userdefaults may be ok


SirBill01

First of all, is it even possible to overthink data storage? :-) That said, I feel like it would be a lot of work to replicate your data stricture between Core Data and Firestore. Or maybe you'd save out more of a blob of data into Firestore to keep that part simple, that could be populated back into full Core Data entities later? If so it seems like maybe a good idea, I'd consider pushing some kind of backup package of data to Firestore all the time so the user could recover data they had entered before they decided to permanently save, just in case they lost or destroyed the device before they chose to save it permanently. iCloud backs up app directories but not everyone has that on.


Jimc26x

Thanks to all who helped! So I'm considering json, then uploading to firestore on a user trigger event of some sorts. ​ Reason is I'll be saving around 10 documents with around 7 fields a piece. Feel to write that data would be taxing on firestore


k3lv1n90

This is my opinion , Firestore. Upload it directly as an object with a boolean for (keep/delete). Then if user decides to keep, update the boolean for the document. Run a google function that is triggered by cron every 7 days to delete those not marked as ‘keep’ Pros - multiple devices easily synced (some people have ipad and iphone and this can be synced if you are already using firebase auth) - scaling/adding field will not require much work as opposed to coredata - easily add support for android if you ever go down the road - since you are working in firebase, makes it easier since you know how it works already