I have a static table around 100 000 records. How should I use realm so that it can save my time? As I know I can put my static table (in case of sqlite) directly in assets and can access it's data.
Is there any way to put static data (rows), so that I can save my time to manually enter the data?
I already used realm's
realm.createAllFromJson("myfile")
But for this I have to put myfile in assets folder, and I guess it will need double the disk space.
There are two restrictions why this is impossible now.
Any sqlite database is stored inside a particular path:
'//data/data//databases/'
To get access to any database you have to use a path
You can only get data from assets (or raw) in order to copy to somewhere. This is not possible to manipulate with SQLite without namely 'file' data.
That's why you have to copy data from app resourses into filesystem. Imho, this is ugly but I had not found another solution.
Android default API (Realm uses it) use only the files stored in 'databases' folder.
Related
I have some entities which I hold in SQLite DB.
Some of these entities will have image as well, as I read, SQLite DB can return up to 2MB per cursor, so storing the images in the DB isn't an option.
So I guess we are left with internal storage and self managing.
Are there any support libraries for managing these images ?
Is there a recommended design for this ?
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I used the solution that you mentioned here:
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I created a folder in my Android project and used ids that will never change. Knowing the folder and the id, which I retrieve from the DB, I am able to get the image. I used the android SQLite asset helper library for the solution.
I used such an approach for this little app: MTBcat. You can find an example here: http://www.6020peaks.com/2015/03/how-to-ship-an-android-app-with-preloaded-data/
You should store all of images on the internal storage. There is a post about that with piece of code, which could be helpful for you:
Capturing and Saving an image in Android with different names and then retrieving it by any of those names?
EDIT:
I mean external storange not internal
Have some sequence to generate unique ids (maybe just store current value as property), and store the id only in the database. Name the image file by id and store the file somewhere in the file system. If you delete the record, remove the file and do not reuse the id.
Generate own ids, independent from what the database is doing. Then they will not be affected by backup/restore or things the like.
I think storing an image which size is more than 2M in sqlite is not good for reading or whiting,maybe you can compress your image before you store it.
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.
Basically, I'm trying to store some data (~300 rows, ~10 columns) for an android app. This data will not be changed by the app, just used in calculations and stuff.
However, everything I've found online (example) talks about using a database that is created at runtime. I do not want this, the data will be the same every time the app is run.
So is there a way of using a databse like this? (Or any other way of storing data in a table-like fashion?)
Generate the SQLite database as part of your build and keep it in your app's raw resources. Since all you need is the file's path and name to open it, you can still read it fine. Your open helper will still go through onCreate() the first time unless you include the table Android uses for its own bookkeeping, but that should be okay.
Make sure you only open it for reading, and you should be good to go.
Put your custom file in the assets folder under the project root.
To get a inputstream from the file, just do:
context.getAssets().open(file);
In this way you can store your static data in conma separated or any model you want.
If you want the data constantly changing, you can create a temporary file in the SDCard, by accessing and creating a new file under some path at:
Environment.getExternalStorageDirectory()
How about storing this data in raw file under Assets or Res/raw folder. You can either dump this data on the fly in Database or read it and process it [which may be costly]. Dynamic handling may be costly, test it and compare performance.
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.