Develop Reference

Best way to store dynamic data?

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.

Best way to use AutoCompleteTextView with medium sized dataset of strings

If I want to use an AutoCompleteTextView as a search function to generate a list of strings (let's say about 1000-3000 strings) based on the text the user has currently inputted, would it be better to be loading these strings from an external database or having them stored in the internal SQLite database and loading the strings from there?
Is the amount of strings I plan on storing too big (each string will be about 10-20 characters long, they are constants and will never change) to be used in the SQLite database? How much would this slow down and/or bulk up my app? Should I just use the external database? Would the loading times be fast as the user is typing in a string?
I'm asking because if I can avoid using an external database I would prefer that since I wouldn't have to worry about the number of users accessing the database, maintaining it, and security issues.

would it be better to be loading these strings from an external database or having them stored in the internal SQLite database and loading the strings from there?
Depends on what you mean by 'better'. If you store them in a local database then the performance should be better, I recommend using indexes in this case. At the same time, this solution will require more memory although I think 3000 strings should be okay if they are just one-word strings.
Is the amount of strings I plan on storing too big to be used in the SQLite database?
Depends on what are those strings. If they are not too long then I think it should be fine. If each string contains a lot of text then I think this might cause problems while searching through them via SQL queries.
How much would this slow down and/or bulk up my app?
It shouldn't be noticeable, you can actually create a test for that, shouldn't take a lot of effort. Depends on your use case.
Should I just use the external database?
If those strings are like constants and they are not going to change, you can consider storing them in a local database, this should improve the performance versus the network-loading solution.
Would the loading times be fast as the user is typing in a string?
You can load the first set of data when they 'stop' typing. See my answer to similar question here: Best Practices for Handling Search
Once you load the list of data you can use this local cache for further searching, it should be fast enough so that user doesn't notice any delay.

Store large amounts of texts for Android app

I'm developing an Android app in which users will be able to write/save/modify potentially large pieces of text. I believe the amount of words will range from 10-1000. In the worst-case scenario, users will write a new piece of text everyday.
What is the best way to store these kinds of text data, holding in account the ability to easily modify saved pieces of text?

Store the data either as a file or in an sqlite database, if possible segment those pieces as separate records/files. For the loading part - there won't be any trouble of dealing with 1000 word within RAM, for example, if you load it inside a TextView. The limit to the size of text you allocate to your TextView is basically the amount of memory that you have.
I suggest testing your text editing view with ridiculously long texts at the end and if you see any issue (sluggish, runs out of memory etc), than you would have to take care of segmenting the document on your own. Hope this helps.

Best option Use sqlite database if you want to store data by day or by time. So, you can easily manage all your data.(if you looking for storage capacity then you can also manage your database in SDCARD(take backup in SDCARD, or create DB in SDCARD...etc.))
2nd Option store Data directly in SDCARD external storage(readable to user(He/She can Delete your data)).
you can use Encryption & Decryption in above both way.

Android data storage choice for a few fixed amount of entries, sqlite or sharedpreferences?

I wanna make an app kind of like Google keep, which has these features:
Storing the names, content, background color of every notes and photos (not including to-do lists, it's a little complicated), using TextView for notes, Custom View (TextView + ImageView) for photos;
Entries could change position with each other by drag and drop;
It could only save 10 entries at most. If there exists opening entry position, The app will fill the position with placeholder, and display all the 10 position in one screen (no scrollbar).
In my opinion, both method have some shortcomings for this situation:
Sharedpreferences: the amount of data is too much and kind of complex;
Sqlite: the data entries are limited. Besides, I think TableLayout is more suitable than GridView cus I want them display in one screen without scrollbar.
Then which data storage method should I choose, sqlite or sharedpreferences? Thanks for your help.

SharedPreferences is not suitable. As you note, it is not meant for that amount and complexity of data. As the name implies, it is meant for storing a users' preferences, not their data.
Note that SQLite support BLOB type that can be used for storing images, etc.
But you aren't limited to those two options. The third option would be to store your data in a file, in any format you choose, e.g. you could serialize your Java objects into a file. Since you will be dealing with a limited amount of data you don't necessarily need the capabilities of SQLite.
But on the whole, I think that SQLite is your best option. It is better then SharedPreferences for reasons given above, and better then the 3rd option because it is built into Android and is widely used.

Choosing Best Storage Type in Android

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.