I’m building an Android app and I’m trying to find a way to store data on the user’s device. It’s not much data (think game highscores and number of challenges completed), so it could well be stored as {key: String} pairs.
I find it difficult to google myself to an answer, I think that SQLite might be an option, but I’m not sure if a database would be overkill for this little data.
I’m totally clueless about how mobile apps handle local storage, so it’d be great if someone would be able to point me at a direction or just throw some tech terms at me to research further. I’ve no knowledge in either Java or Kotlin, so anything supported by React Native or Expo would be awesome.
Mobile/native apps have access to the devices filesystem:
I’d start here:
If your using a framework like React Native, I’d check their docs such as here:
I’ve already looked into AsyncStorage and if I’m not completely mistaken, it uses the global storage, not the internal app-specific one, so I don’t think that’s what I’m looking for, but thanks anyway.
AsyncStorage is probably what you want, it’s specific to the app.
Re what mobile uses (and what AsyncStorage makes use of) – SQLite [assuming heavily customised] for lots of iOS (and lots of OSX), used to be same for Android but newer versions use RocksDB afaik. So yes, you could bundle a version of SQLite specifically for your app, it’s unlikely to be too hard as it’s a tiny completely standalone thing that works everywhere (although it’s native so it’ll inevitably probably not work or need some huge amount of faffing around to do or come with huge caveats). But then you’re just replicating what’s already built into the device anyway so 
.
If it’s stuff that needs to be secure, SecureStore gives access to the cryptographically secured storage (keychain on iOS & whatever Android uses), but that’s unlikely that apply here (just really for passwords and stuff).
You could use flat files if you don’t need fast write access: if you just want occasional slow writes and can just load the file and read it at startup then can use the file storage (this is what a load of games will do, for example Football Manager and similar, load a flat file database that doesn’t need much in the way of writes, and when a write is done you’ll get the “saving…” popup for a while). Probably doesn’t apply here, v slow, but it would be easy.
1 Like
I thought AsyncStorage is the equivalent of the browser’s local storage, and can therefore be cleared by anyone. I’m not sure if I find it awesome that I have to trust that no other apps clear the whole storage and delete “my” user’s data.
Using a text file was my initial idea, because it’s most suited. It’s little data, it only needs to load when the app starts, while the app is running I keep stuff in state, and when the app is closed I save the progress.
You mean this, right? FileSystem - Expo Documentation
It is the closest equivalent, but it’s app specific – if you go to settings and clear app data it’ll clear it, for example – but another app shouldn’t technically be able to touch it. If it’s for a small amount of data that doesn’t need to be secured then it’s the best option
But flat file is fine and probably the simplest (almost certainly in terms of debugging and testing it works I guess), & yep the file module was what I was thinking about. It’s much less secure even than async storage because if you’ve got another app that can save files you could go into the filesystem and just overwrite yours, but it’s v easy
I think this means that theoretically any app can clear the storage?
It’s probably safe to trust that no developer would use that method, but you know. I mean you never know.
At some point I won’t get around using databases in combination with mobile (if only for a private project) but for now I’ll look into both AsyncStorage and directly manipulating a text file and see what works out best.
Ah, that’s not very well written. So what it means is that it’s going to wipe everything in async storage for the app including things set by libraries your app uses: a load of things use async storage under the hood, very likely some of dependencies of your app, so blowing away the storage is going to wipe anything they’ve stored as well, possibly causing the app to behave badly.
From a security perspective, you can’t have an app touch another app without explicit system permissions, one app can’t just generally just arbitrarily dig into another one (Android is slightly weaker w/r/t than iOS, but not far off)
Alright I thought AsyncStorage was some public pool like the browser’s local storage, where one tab can wipe out the storage of another tab. And that you’d have to use some sort of app-internal storage if you want to keep it encapsulated. Glad that’s cleared up, I was puzzled as to why all googling pointed to AsyncStorage when it seemed to be such a stupid choice.
