Add mobile storage standards documentation#21
Conversation
Document guidelines for using SQLite DB versus Shared Preferences in mobile storage.
OrangeAndGreen
left a comment
OrangeAndGreen
left a comment
There was a problem hiding this comment.
This all looks good to me. I'm a bit curious about whether this means variables like the upcoming emailOfferCount and lastEmailOfferDate would make more sense as SharedPrefs, but since the other email-related fields are stored with the user's DB object it feels like they make sense living together?
Maybe worth a little additional guidance on things like tracking "offers", other examples in the past have been things like:
- Prompt user to verify secondary phone number (after 5 days)
- Re-show received payment card some time after the user chooses to hide it
A separate thought: Is it reasonable to say that pretty much any data the server stores in its DB and sends to mobile should also live in mobile's DB?
| **If data is state → Shared Preferences** | ||
| **If data is records → SQLite** |
There was a problem hiding this comment.
Small nit: in the rich diff this all shows on a single line. Can we either add a line break here or turn this into a bulleted list
Clarified definitions and best practices for mobile storage standards, including specific examples of user state and data types.
yeah, that's what I was trying to refer to with "UI State", added a generalised example in this commit, does that make it more clear ? |
4 participants
Document guidelines for using SQLite DB versus Shared Preferences in mobile storage.
Changeset Category
This PR is streamlined for review in the following category