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:
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
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
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.
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.
Related
I am currently learning android programming and creating an app that will store some integers representing user choices (values inserted several times a day, must be displayed in the results activity) and steps data collected Google Fit HISTORY Android APIs, also displayed in the results activity. I am looking for the most efficient way to store this data. I know that it might be possible to insert the custom data types in the GOOGLE fit database. However, I am not sure if it is a good idea if the app mostly works offline, and it needs to immediately represent only a small set of results, for example, the values inserted in the last 2 weeks, with step counts. On the other hand, I am not sure if it is ok to have two databases storing the data.
My apologies if the question sounds a bit too amateur, I am doing my best to find an optimal solution in terms of performance.
Thank you for your answers.
So, to give you my opinion and answer (mainly opinion)
Android has 3 ways (mainly) for storing data:
Files
Online database/API
Local database
for this specific scenario you have listed, wanting the data to be available offline, you should probably be looking at using Room: https://developer.android.com/training/data-storage/room, as it supports storing primitive types without having to write any type converters, you can store models and custom data as well, it uses very basic SQL (because it's a wrapper for the older Sqlite database methods) and is part of android (not an external 3rd party library). Room also requires most operations to be done off of threads, instead of main threads and this will improve your performance as well (also has support for livedata/rxjava to observe straight onto any changes as they happen)
However, as I told this user here:
Should i store one arrayList per file or should i store all my arrayList in the same file?
When starting out, don't worry about the best way for doing something, instead, try something out and learn from it, worrying about the best solution now is rather pointless, either way, happy learning and coding :P
I am developing a notepad app which can store simple text files and checklists. Currently I maintain a separate file (say info.txt) that maintains information about whether a given file is a simple text file or a checklist and based on that I render my UI (for either listing all files or opening a file) to show that file in my app. However I am not very happy with this approach because is slow and does not appear to scale well.
Is there a better way to add "metadata" (e.g. if it is a simple text or cheklist, tags, etc) about a file in android?
Any help will be greatly appreciated
There are several ways of storing persistent data in Android.
The way you are currently doing it is through the device storage, and you are quite right it would probably not scale well in addition to being directly accessible to the user meaning they could edit or delete your metadata.
Using SharedPreferences would be one way of storing the metadata which has the advantage of being completely hidden from the user, as well as being relatively easy to set up. The main disadvantages I can see are that it may not scale well if a user has a large number of files, and it is much more difficult to retrieve files with certain criteria, a certain tag for instance, as you mention in the comments.
The best way to store data that will scale well, be persistent, and let you run queries on the data would be an on device SQLite database. SQLite will usually have more overhead in terms of setup time, but is far more robust and featured than any of the other options besides perhaps network based storage, which based on the information you have given is probably not something you are interested in. Based on your problem the SQLite database is probably the way to go and has the bonus of being expandable in case you ever decide to add more information, or even store the files in the SQLite database.
There are many similar questions about this issue but I have clear points about my question to ask you.
I am new at Android development and before only I developed small applications which store small sized data. For example country List, calendar, birthday reminder etc. I stored my small data in single XML file and I parsed it with easy methods. This was enough for me. But for my Mobile Application Development Course I took a project which will store huge static data.
Specifications of my project will like these:
There are about 200 entities.
Each entity has about 20 sub categories which they stored in text format.
Each sub category has about 30-sub categories which they stored again in text format.
Also for each parent entity I will have 2-3 image
If I calculate simply, I have to store 200 X 20 X 30 = 120.000 static data for my application and data does not change. This is only install and use application. Online data interaction is not necessary. (If there are some changes for data I will relase major updates in long periods of time.)
My question is about storing method.
Which way should I choose? SQLite or XML parsing? For your answer can you explain advantages / disadvantages for your choice?
Interesting project, although not necessarily realistic.
To manage a large amount of "static" data, you'll want a database. XML parsing forces you to store the data in memory, which means that you have to read it into memory on a regular basis. Remember that you can't count the in-memory data being around when the user goes to your app; Android may have destroyed your app previously.
On the other hand, you can use an SQLite database on disk directly from your app. It's persistent, even if your app goes away. You'll have to load the database once, when you install the app.
Consider wrapping your SQLite database in a content provider. This will, among other things, allow you to do asynchronous queries using a CursorLoader.
I am writing an app that contains a list of items with their information. When the users open the app, they would see the list, and when they select a particular item, they would get all the information about that item.
Right now my approach is I store the data in a multidimensional array in the java source file. When I push a new update, I might add new items in the java source file (so the array gets bigger). I wonder if this is the best approach. I tried looking up relevant information about array and database on the Internet, but I can't seem to find the information I need. Any advice for me?
Also, if in the future, I create a function for users to add their own items to the list, what's the impact?
If the user should be able to update it, if you should be able to update it dynamically (for instance update from internet), then the database is a must.
If that data is static and won't change unless you update the app, you can store it in the code or better, in a file (you can store in JSON format for ease of reading & parsing)
If use array, the newly added items by the user will be gone when the app restarts.
You can use a SQLite database stored directly on your phone (sd card for example).
An analysis of the storage options and what they're commonly used for can be found here. Personally I suggest SQLite database.
The database is good for permanent data, but realize it can create a bottleneck if writing to disk is not really necessary.
I am in the middle of refactoring an App to no longer use SQLite. I was inserting large amounts(10,000-100,000) of new rows at once, and it looked like it was going to take an hour based on my log feedback of the status. When I keep it in memory, it all loaded in about 5 seconds.
I want to write an android app that basically shows titles of songs in a list view, and by selecting one song in the list, the lyrics of that sing are shown in a textview. In a second step there would be maybe a translation of the lyrics for every song.
So far nothing too complicated, but since I'm completely new to android programming, I wonder what's the best approach to store the data (i.e. the song titles/lyrics). I thought about a single (xml?)-file for each song where the filename is the title and the file contains the lyrics. I think that would make it easy to add new songs. where would such files be stored typically? /res/xml?
Or would another approach be more suitable? database storage? content provider?
I would use a database and a content provider since it becomes very trivial to bind the content to ListViews using the Loader API.
According to the documentation about Data Storage, you have several options.
But the storage strategy that seems to meet your needs is an SQLite Database.
You can make use of SQLiteOpenHelper and ContentProvider to get it working.
It will require quite an amount of work and understanding to implement it but it's worth the effort :
Esier than other solutions to manipulate data once it stored.
A lot of android component are designed to work with databases cursors.
Easy to add new data and structures as your application evolves.
You will learn a lot about how develop android apps "the right way".
If i were you i would avoid :
SharedPreferences because this is not suited for list of data as there isn't any "id mechanism". On the other hand it is pretty easy to use for small settings.
Internal Storage because it is difficult to manipulate the data once it is stored. Also it is not the recommended way to store that type of data.