Consider a table. For instance, for handling auth ...

# android

[bobtimm]

Consider a table. For instance, for handling auth sessions, we ended up using a table for storing a single entry. When the client then wanted to support multi user sign in, most of the work for storing that information was already handled.

[blakelee]

That is a good point!

[dave08]

With shared prefs, you could always just save a serialized json object per user I'd and have a users prefs file. If it takes more time to implement a feature that might not be necessary, why do it? Usually dbs are for searching and users only need to be retrieved by their I'd or username.... There's the KISS (keep it simple stupid) principle in programming.

[Paul Woitaschek]

It depends on how important the data is

[Paul Woitaschek]

When it's totally necessary to not lose the data on an upgrade, I use sql because migrations are way easier and better to test with room

[Paul Woitaschek]

It's pain using gson when you later need update your object representation. Handling the changes in the json string manually hurts.

[dave08]

Good point, but if the implementation is hidden like in MVP, as soon as requirements justify the extra work, migration can be done behind the scenes... The point is not to do extra work that might never be used and introduce complexity until it is really needed.. sometimes the choice is the wrong one and will be refactored anyways.

[Paul Woitaschek]

Yeah it always depends