flutter data storage: local storage vs cloud storage

Question

a question about local and remote storage of user data. Is there a best practices for the common situation where a user accesses data from an API and can favourite or otherwise personalise the data.

I have seen tutorials, e.g. a movie browsing app, where the use can make a list of favourite movies, where this personalised data is stored locally (e.g. in sqflite) and other tutorials where this data is stored remotely, eg. firebase. And firebase has an offline mode, so that data can be synced later. In that case, is it a common use case to set up local storage as well as cloud storage? Is there a common practice for this situation? Thanks for any insights.

Solution

This is not specifically a Flutter question, more of a general app development question. It's very common to have both local and cloud "storage" but I wouldn't think of it that way. If you're interacting with an API backend I wouldn't consider it as the cloud storage for your app. Instead look at it as a different component within your applications overall architecture. You API/Backend component, this way it's not apart of your app instead it's something your app interacts with.

I assume you know the purpose of your API. Returns your data you want to see, keeps track of user profile information and other sensitive information.

When it comes to local storage I'd say the most common scenarios for local storage is results caching and storing information that the API requires on every session to make the user experience a bit better. See some examples below for both:

• On instagram they store your "Feed watermark" which is a string value that is linked to a specific set of results so that when you open the app and request again they return that set of results, plus anything new - Local storage
• They also "store locally" (better referred to as caching) a small set of your feeds from your posts, a list of user profiles that has stories on them and your DM's for instant and offline access. This way when the app loads up it has something to show while performing the action to get the new information. - Caching
• They also store your login token, that never expires. - Local storage

tl;dr: Yes. If you need data on every session to use your API store that locally in a secure way and use that to interact with your "Cloud storage".

Comments

[user2342708]

Thank you for that answer and those are the considerations which would make being in control of and integration of both local and remote storage to be a necessity for any sophisticated app, I guess. For a simple movie browsing app, where you can save favourites but also share them so that others could see each other's favourites, it would be a matter of deciding on a balance between local and remote storage, I guess. But I haven't been able to find any tutorial on syncing e.g. sqflite etc local data with a remote database, e.g. firebase, or even to find an article discussing these scenarios..

[Filled Stacks]

@user2342708 the way you're thinking is wrong. If I had favourites I wouldn't store it locally. I'd just call a method on my.api/setFavourites?id=24 and I would indicate on my client immediately that it's favourited. If I wanted all the favourites for my account I would just create an api end point and call my.api/getFavourites?userId=9 . I wouldn't be syncing anything from local to the API. If the setFavourite http request fails then I'd either retry (a maximum of 2 times), then show a message saying it can't "like/favourite" the movie, like all the social medias.

[Filled Stacks]

@user2342708 if you want to infinitely try then I would store a list of id's using shared preferences (list<int>) if there's any Id's in that list I would call my API to update that ID, if the request succeeds I would remove it from the list and then do it for the rest until there's no Id's left on the disk to favourite. Then the API will have the list of favourites. redux_offline does this for you so no need to write it, but that's the idea behind it. Also this question will never be able to be answered to I don't think you'll get any more answers.

[user2342708]

Thanks again, this is very useful to me because it deals with the offline/online decisions, which seems to be a problem area, because of the syncing, caching issues. So I guess the purpose of sqflite in flutter apps is only if there is no network updating planned, and the app is for storing one user's data. Otherwise why use sqflite or other local database storage like objectbox? But if using only network/cloud/api storage, and when the network is not available, what is a good workflow for making sure data is not lost?

[Filled Stacks]

@user2342708 you seemed to have gotten a very complicated view of mobile apps in your head. It depends on what you mean by data being lost, this can only happen when downloading or uploading large files. In that case you can write every byte while downloading and keep track of it, have your endpoint be streamable so that you can resume from a certain point. In terms of data, if you request something and it doesn't show up, retry or show a dialog telling the user to try again later. If you're trying to update something on the API do the same with the addition of caching it locally for retries.

[user2342708]

I guess my real question is about offline/online data storage. Why use sqflite if every device is connected to the internet? Is there any point in saving data locally? Why not always use cloud storage e.g. firebase?

[Filled Stacks]

@user2342708 you would use sqflite if you want to cache data, for instance if you open instagram or facebook or any app. You see the things you were doing last while waiting for the new data to be fetched. If there was no local storage you would see a loading screen with no data every time you open a mobile app.You would also have to register again, login again, everytime you open the mobile app.Every single time. So instead of that, you store data locally.

[Filled Stacks]

@user2342708 Like the fact that you've registered with this device, your login token, and all the information you want to serve on start that was fetched during the previous session.

[user2342708]

I can't find any tutorial on this pattern, can you help?

[Filled Stacks]

@user2342708 it's not a pattern so can't point you in any direction. It's just a solution to a problem. The problem being, "The app shows a loading screen everytime it's opened." or "The user has to login every time the app is used". It's just a solution to that, it's not a pattern. It's just normal login or caching procedure.