I am building an android app that will ask user what they want to see. Based on that I will provide gifs, images and texts(one lines) based on time duration they choose. This would be an offline app.
I am confused about how I should proceed with storing large amount of gifs(1000), images(1000), and texts( sentences or words). After storing I would want to run them in some kind of time duration loop so that those they have seen won't be repeated.
In my opinion images, gifs or otherwise are just resources and should be stored as such. Text can be stored in another appropriate resource file.
What I'd recommend is then ensuring you have a database that provides names and links to the resources.
When the user provides you with a keyword, query your database to get a list of items that need to be provided. Your query can be used to change the order etc...
Your code should then cycle through the query response, retrieving and displaying the items as appropriate.
Remember, if you are displaying images to a user you may also need to consider screen resolution and thus may require the same image at different resolution. Equally you may wish to consider localising the text to support different languages.
Hope this helps.
(By the way, I'd recommend putting a rough plan together based on the above approach, breaking it down to ensure you know 'HOW' to do it. After you know how/what, then search to see if a library exists that allows you to do what you want to do in a simpler method. Search to see if there's a better method for handling the resources etc... the first step is always getting AN approach and then evaluating to see if it's the best approach for your needs/requirements.)
Related
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.
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.
I have been storing option lists for my Android app in a cloud table. For example, categories like "historical fiction","biography","science fiction", etc. I see the following pros and cons:
Pro:
I can make changes to the list without sending an app update to Google Play
Not normalized - I can use the text in my other data tables instead of a reference ID
Con:
App needs to take time to download from the web each time (or at least check for changes)
English only
I believe the "proper" way to do this is the use the XML resource files. But I need to make sure the selection references correctly with my data. That is, my app needs to understand that "Poetry" and "PoesÃa" are the same thing.
Is the correct thing to do:
Forget about it since I'll never get to the point where I'm translating my app anyway
Use a string-array and use the index (0...x) to know what the selection is
Use a 2-dimensional string-array with a reference ID in the first column and the text in the second?
If you are handling the category list online, then why not handle the translations online as well. Here is what I would suggest:
In your application options, have a list of supported languages (each in their native translation). These language options should be stored on whatever server application is handling your web requests. Each language is associated with an integer ID that the user does not see, but is stored in the app.
Whenever you issue a web request to get a list of options, include the language id in the message. This will allow you to know what language the user has picked and can use a 2D array or some other structure to handle the conversion to and from the chosen language.
I'm not sure if this helps at all, since I don't know exactly what you are making or how you are designing it, but from the given description, this is an easy and effective course of action.
Yep I know its easy to fetch n it simplify code n even for localization. But I just wanna know because in android declaration of too much objects is not advisable, And im not too sure if arrays in resource is like dat in code (i.e in terms of object). That is why Im asking which is the best practice in android as we all know that each language as its own do n dont for effective output
I think the comments point to the answer that there is no real answer. What is the "best" depends on what you're trying to do.
Loading a fix array of strings from resources will be fast and negligably increase the size of the apk. However, as far as I know, a resource is fixed. You cannot add/remove entires to your XML resource file on the fly. You generally see fixed XML resouces when you know the values will not change, like with a ContextMenu where you know the options you will be offering will always be the same. In that situation, there is no need to set the values programatically (although you can if you want to).
Declaring the Array programatically is more flexible, i.e. it can be modified dynamically, but had other limitations. For example, it is not necessarily universally accessable like your resources file. I'd use the Array declared in you Java code if what you're doing is a dynamic function, e.g. generating a user selected list or grouping data on the fly.
As for speed someone who knows more may be able to elaborate but, unless the data size is extremely large, I cannot imagine that there would be huge performance differences for a basic string array in either form.
You just need to balance you're needs vs. the cost/benefit of each possiblity.
There are few questions related to this topic on stackoverflow, But I didn't get the proper answer. I have some doubts on performance of flat files, Is it better to use flat files instead of SQLite ? Can anybody have performance statistics ? Or example of proper way to code flat file in android.
Aside from performance benefits, here's a simple list of advantages of using SQLite rather than flat file:
You can query items as you wish -- don't need to load all of them and select which ones you need.
Deleting records is a much less painful process. No rewriting of whole files into wherever.
Updating a record is as easy as removing or creating one.
Have you ever tried doing cross-referencing lookups on a flat file? Not worth it.
To summarize, it's every advantage a Database has over a text file.
It depends on your requirement.
If your storage data size is structured-bulky in size then i suggest you for SQLite. On the other hand if the data size is just a single or few lines then flat file is best option.
What makes difference between them is, SQLite stores data in structured format, so it will be easier to find a record from multiple set of records which is very tedious process in case of flat file.
However when if you are storing blob kind of data then it is suggested to use combination of both, SQLite and file system both. i.e. store the image/sound/video data as file format and store their path in SQLite.
Also visit this accessing performance.
SQlite definitely way better in terms of performance and this gets even more important as the size of your data increases.
I've been working on a flutter app where I needed to display a filtered list of items dynamically based on typed text. I initially used a json file to store data and would read and store relevant values into a list, then filter this list as the user types.
This worked just fine with a few items so I thought I was fine until I tested with a real dataset which contained over 150,000 items. Trying to filter a list this large as a user types crashed the app. I moved to a database solution and all my problems were solved. Instant filtering and no more crashes