Is it a good idea to save user generated values in a .xml file in the res values folder?
The values look like "Aircraft", "Type", "Note" in one row. Is it even possible to save Values there while runtime and is it possible to save there a multi-part value?
I just want to know, what's the most recommended way to save a three part value, to show it in a Table (table layout).
First of all android .apk file is read only so you can't store values in /res directory at runtime..
You an store these values in Shared Preferences, Xml file and then it in internal storage or sdcard and in SQLite database..
Now you have a multi-part values, and you want to display it as a table layout format, So I think SQLite database is useful for it..
Now choice is yours..
If your amount of data is small, you can consider using SharedPreferences.
Else, the prefered way to store persistent data is using a SQLite database I think.
You can't save values to res folder at run time. you can store those data in Shared Preference or in SQLite database or
Related
So the question is what is the best way to save long text (20000+ chars) in realtime database based app. There is a way to save images as links. Maybe there is a way to save text like that?
You can save large text contents in database as Character Large Objects (CLOBS) or or Binary Large Objects (BLOBS).
It depends what database you're using. You can also simply just save them as files and only store the metadata in the database. You can save the file to your servers file system or a more preferable method of using a cloud file storage.
http://www.dba-oracle.com/t_insert_clob_table_column.htm#targetText=Store%20the%20CLOB%20inside%20the,way%20to%20bulk%20load%20data.
https://learn.microsoft.com/en-us/sql/relational-databases/blob/compare-options-for-storing-blobs-sql-server?view=sql-server-ver15
I want to store a list of 1000 lines which i will write to an array when activity starts. No queries. Just need to rewrite the entire list on some condition and always display the entire list. As SQLite is also only a file , i was wondering what performace benefits does writing a file to storage have over it , if any.
Basically what cases should we use file over SQLite? I know a case - when the data cannot be written in form of table. but if its possible to write data in a table (like a single list) which will then be saved to an array then is file still better.
There are two couple of things both Files system and SQLite introduced in android for storage techniques we can say about each as follows
Files:When you want to store a bunch of data in your application in serialized object format you can store it in to file and save to disc,once after you can deserialize and retrieve data what you want it from
SQLite: It we can use accordingly along with file system but as it have tables we can consider this approach for populating listviews withe limited content(metadata)
For example :You are storing an Object class in to file it might be have large data in it as its not possible/not good an approach to store in db(SQLite) we can store metadata(such as file name what we are storing in file system).
Hence with metadata we can populate listview with SQLite db,and once list is populated with file names we can retrieve respective file from the local storage.
And we have a CursorAdapter in android which will helpful to create a listview with cursor reference.
For your question its bit memory consumption to populate a listview from the file system as there are too many files in storage.More over if it is SQLite data base as we have cursor reference with query we can populate listview using CursonAdapter
I am working with web service using soap parser. I need to retrieve the values from the web service and store it in local. I have lot of string values in it.
My question is, how and where to store all the string values in my application.
Like, this sort of storage normally we use raw folder.
Thanks in advance
Have a look # Android Data Storage
Raw and Asset folders are Read-Only. You cant modify the contents inside, though you can read it only.
In your case, either you should use SQLite database or SharedPreference to save your data. Another technique would be saving your data in a file created inside sd-card, but then you should evaluate the feasibility.
In my project I have to manage large quantity of static text data(ie no modification, deletion or addition of data, only for displaying and it is based users need). To implement this I have two solutions.
Saving entire text data in to database, to do this I have to keep an xml file that containing text data into asset folder, and during the onCreate of database I have to fetch each text data from file and insert into database.
Saving text data into several xml file in asset, and keep the xml file name into database.
In both case I have to keep database because I want to store some flag element for each text data according to users needs. My question is which is the best method from above? or Is there any other best method?
I think the second option is preferable and better, because in First you have to store all xml files in asset or any other directory then you copy the whole data of those xml files into database (Time consuming) and fill the database with that xml data. (Large size of database probably searching and getting data also time consuming) .
And in your second option you have to just store file name in database. (So no worry of large size database file and you only open that file which is needed so data fetching also easily. your application size is also less)
I think you should create a read only database using Sqlite browser and put in assert folder and when your application execute for the first time the entire database will be copied from assert folder to the Android root database folder .
Here is link to do this ..
http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
Which is favourable, efficient and faster? storing information in xml format and retrieving it or storing information in a db on android?
and also, in terms of portability, xml could be stored as an asset...can the same be done with db? do db come in as default package in all phones.
application involves dealing with over 1000 records of data.
A SQLite DB will be faster when it entails large amounts of data - it will find what you want much faster.
For small amounts of data a KML file will have a much smaller overhead than the DB, but isnt very useful for dynamic data.
If the data needs to be updated or added to, you would have to store the file in a writable location if you want to continue using the xml file.
For around 1000+ entries I would be looking to use a SQLite DB - you could do one of two things here - precompile a DB for your application, then place the DB file into the asset folder, then on first run check if the DB file exists - if not move the file from the asset forlder to the DB folder (see note below).
Alternatively you could store the entries in a KML file in the asset folder, then on first run use a parser to write each entry from the kml file into a DB.
Getting files from the KML or a CSV file would take a while to process depending on the number of entries. I have an app which will get data from a csv file on the SDCard, and load it into a DB, as a test around 7,000 entries took about 35 seconds on a desire.
Also I think the raw and asset folder has a size limit of around 1mb.
Take a look at this link, it shows a very useful way of moving a large DB on first run of the application:
Database Populating Solution
You can't use assets/raw folders as writable resources. They're readonly.
So basically you have 2 options:
Store data to DB (SQLite)
Store data in preferences - in fact XML file stored somewhere/smth like
/data/data/[your package]/shared_prefs
My personal choice: if data size is more than 100 records - use DB, if less preferences.
My choice is
I use DB for structured data. When there is certain need in searching through data set by some fields or sorting by different fields. Use DB when there is additional logic is required.
I use "shared prefferences" files when there is only need in persistence of data. No additional logic, only key value pairs.