Design Concerns

Issues

1. SQLite latency was a big problem in the prototype. (The whole list was saved to the SQLite db upon leaving the screen. This results is long latency when switching screens. I need to rewrite it to use atomic db operations: when individual items are added, deleted, or changed, the db is updated immediately.
2. Each item must store its index in each of two contexts: stockOrder and shopOrder. These will be used to position each element in the respective array lists. [TODO: check latency on this]
3. Add a button to the make-a-list screen for testing: Will load my ~70 items from a fixed "raw" .csv spreadsheet hardcoded in the app.

Questions

1. To support multiple lists:
   • Should I just add a database key for the list name, and use a cursor to only get those that have that key? How does this affect db latency?
   • Or should I have a separate table for each list? One table that maps strings to tables, then one table for each list?
2. What’s the latency penalty for accessing the items out of order in the DB?
3. Should the DB adapter be a singleton class, that is, since there’s only 1 database, all Activities share it?
4. Need to persist the list of store names from one run to another (use array of Strings in SharedPreferences). Since shared prefs only store primitives, and not lists, should I store a single string with funky delimiter characters (e.g., ` and tabs)
5. There are no help screens. Should there be one, so I can give instructions like, "Press an item to edit it, long press to delete it"?