How should I store ~400 key-value pairs for my Android app?

Question

What would be the best way to store ~400 key-value pairs for an Android app? These values would be set on initial setup of the app and changed extremely infrequently after that. However they are used once per app use as a template to create a set of other objects which are then manipulated.

In the previous iteration of the app I stored these values in a separate sql table. I am now transitioning to using the room model and reworking a lot of the code, which part of that is evaluating previous decisions.

How the previous code worked was that I would import the ID and boolean value pair into a list of objects. The user when then add additional info to those objects and then I would re-store those objects data back into a separate, but related sql table.

Should I keep the values in the table? Would it be too much or inefficient to use SharedPreferences? Is there a better way that I am unaware of?

Here is the format of the two tables. The first is keeping track of which carts are currently in rotation whereas the second table is a daily historical record of each cart.

(cartID int NOT NULL PRIMARY KEY, 
in_rotation boolean NOT NULL) ");

database.execSQL("create table " + cartlistTable + " 
(checksheetID string NOT NULL, 
cartID int NOT NULL, 
in_rotation boolean NOT NULL, 
checked boolean default 0, 
overdue boolean default 0, 
maintenance boolean default 0, 
FOREIGN KEY(checksheetID) REFERENCES checksheet(checksheetID), 
FOREIGN KEY(cartID) REFERENCES carts(cartID))");

SharedPrefs is best place to store key-value pairs . and there is no limit for size ... — Kapta, May 29 '19 at 18:51
@dariushf Ok but with SharedPrefs being stored in memory when the app is running, what sort of guidelines/limitations should I be looking out for? Is there a point where storing the data in a different method is more efficient than using memory for basically a one-time transaction? I get that SharedPrefs would be an easy decision if the data was being changed semi-frequently (and the speed from no IO would be helpful) but I am just using it to populate a list once and then continuing with app functionality. — G-Schmu, May 29 '19 at 19:01
sharedPrefs is not in the memory , instead it's inside app storage directory. — Kapta, May 29 '19 at 19:24
SharedPreferences is a good way for an app to store primitive data in key-value pairs. It’s also pretty simple to work with. — sydney, May 29 '19 at 18:29

score 1 · Accepted Answer · edited May 29 '19 at 19:40

I would suggest you to keep away from shared preference if you are working with large amount of data, because the maximum amount of data that can be stored in shared Preference is 1428.51 kb.

Also shared preference is stored in xml file and it lacks the strong transaction support from SQlite or Room. Shared preferences loads all the data reads that entire XML file's contents into memory.

Comparing room and shared preferences, for information like 400 items, You can go with room.

How should I store ~400 key-value pairs for my Android app?

1 Answers1