1

I am developing a launcher for Android and need some advice on designing my persistent storage system.

I wish for people to be able to create different categories for their apps (e.g Media, Utilities, Social). Users must be able to choose the order of their apps and apps can appear in more than one category. Users can update the order of the apps and order should persist on restart. I would also like to keep track of how often apps are launched so that I can have an automatic 'most used' category.

I have had 2 approaches but neither seem ideal:

  1. Save the list of apps to a file (JSON or other), taking note of the package name and position in the list. When required bring this file in and sort by order

  2. Save the list in an SQLlite database, either:

    • Have a table for each category. Columns would be package_name and list_position
    • Have a single table, with a column for each category, which stores the position of that app in that category (or null if not present). When a new category is created, a new column is added (not supported in Room).

Option 1 I feel would be tricky to keep dynamic and unsure of efficiency, so I prefer option 2 because its's simple to update and automatically Order By, however it may be overkill to use a DB for this.

Any advice or other possible solutions would be great! Thanks

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115
FrazorLazer
  • 59
  • 1
  • 4

2 Answers2

1

I'd go for a database approach. I think storing data in a file is perhaps a good choice for small applications where the data don't grow and you flush changes max once before the application is destroyed.

If you want to avoid the boilerplate code of SQLite, then consider Room. Alternatively, you may want to have a look at Realm which is an alternative to SQLite.

Georgios
  • 4,764
  • 35
  • 48
  • Thanks George, given that Room (which I would like to utilise) doesn't support adding columns to existing databases, do you think I am stuck with using a table for each category? – FrazorLazer Jul 03 '18 at 15:08
  • I'm not sure I fully understand why you need to have one table for each category. Wouldn't it be sufficient if you had one table with columns "package_name" and "list_position" where the first one would also be the primary key? – Georgios Jul 03 '18 at 15:26
  • I'd like to allow the user to create their own categories, so columns could be "package_name", "listposition_media", listposition_social" for example. Then if the user wishes to create a new category utilities they would need add a column listposition_utilities dynamically. – FrazorLazer Jul 03 '18 at 19:37
  • Could you share how would your Java/Kotlin models look? For example, will you have a Category class or would a HashMap represent your data better? – Georgios Jul 04 '18 at 12:08
  • I haven't yet defined what my models will be for sure as I think they would be affected by which method I use here. A closer look at Realm, as you suggested, and I feel it may be the best way forward. For example Category extends RealmObject { categoryName: String, position: Int } and AppListItem extends RealmObject() { appTitle : String, package: String, categories : RealmList } – FrazorLazer Jul 05 '18 at 20:49
  • With such models it can also be easily solved with SQL and 2 tables. Table Category(name [primary key], position) contains a list of all categories. Table AppItem(appTitle [primary key], package, categoryNames [list of foreign keys]) contains a list of all appItems and each row has a list of foreign keys which correspond to entries in the Category table. When a user creates a new category, you'll add a new row in the category table and update the categoryNames column(s) of the appItem table. This is a scaleable and easy to maintain approach. Wouldn't it solve your problem? – Georgios Jul 05 '18 at 21:14
0

If your function is limited then a file based approach works, your approach depends on basis of features you want to have like

-->add i.e (append) specific index or you resorting or shuffling of data is needed.

-->consuming the data i.e If accessing the data in ordered fashion or filtering on multiple features.

Storing data in a file is generally preferred for a small collection of key-values like android Sharedpref itself. Depending on the functionalities your launcher has the file system gets complex and slower accessing and modification in which case it(file) won't be the best way to store the list of apps (& other info if needed) in a file.

Building a database would help overcome all the complex for future functions like different sorting and other features.

abhishek kasana
  • 1,462
  • 12
  • 14