Core data in Android - android

i have an iphone application that use core data for searching ,and in similar application in andoird am using sqlite ,so my performance is lower than iphone , is there anything similar to core data in Android ?.Also can i get any performance advantage by using ORM (am searching in table contain records 7000+)

For readers who are looking for a Core Data replacement in Android, I suggest an ORM tool like greenDAO. It allows you work with Java objects and uses SQLite as its storage back end.

If simply searching a static db, you can get away with using this very safely:
yourSqliteDb.execSQL("PRAGMA synchronous = OFF");
If it is a live/production database of constantly changing things I would recommend against this for corruption reasons. But it increases speeds quite dramatically.

Related

Sqlite on Android - is it stable to use and does it work fast?

I'm asking for a piece of advice. Currently, we are developing android client for out service. Service produces like a lot of dynamic information, and it must be stored on users phone so it can be accessed without connection to the net. On iOS client we achieved this using restKit. On android I found that there is no tool like restKit. So there are 2 options - use sqlite db or cache last json response. I want to use sqlite db, but our android developer sad that it's not stable and slow. Is he right? What practice is better?
The second question is that I found a sqlite editor app, which allows to edit sqlite databases on phone. Is there any way to avoid this?
You can use SQLite because SQLite is capable of being extremely fast. If you are seeing speeds slower than other DB systems such as MySQL or PostGres, then you are not utilizing SQLite to its full potential. Optimizing for speed appears to be the second priority of D. Richard Hipp, the author and maintainer of SQLite. The first is data integrity and verifiability.
The first thing you should know is that most of the time spent by SQLite (and most other DB systems) is on disk access, which is slow compared to memory operations. So the key to optimizing SQLite is to minimize the amount of disk access required. This requires some understanding of when SQLite is accessing information on disk, and why. Because operating systems generally cache open disk files in memory, a carefully tuned use of SQLite can approach the speed of a pure in-memory database.
If you are new to optimization, you must know that the only reliable way to optimize for speed is to measure where time is being spent. Unless you are already familiar with doing this for SQLite, you will often guess wrong. Use quantitative tests on representative examples whenever possible. Unfortunately, reproducibly measuring performance on an application that does disk access isn't trivial.
However it is difficult to use cache no doubt cache is fast but its not for large data and data cannot stored on cache for long time. So if you want that user will use your app offline then you should place your data on SQLite in an optimized way.
Hope this will help you.
No according to experience SQLite is the most reliable database to use in android device itself. It doesn't have separate server process and it directly read/right to single disk file.
This link will provide more information

Alternative To SQLite Asset Helper Library

I'll begin with explaining how I stumbled upon SQLite Asset Helper library. I am trying to build a small android application which is basically shows the meaning of words. And to do so I intend to keep everything offline (no dependence of internet connectivity). Now, as far as I can think of, there are 2 ways of achieving that:
1. Using String array, which I believe will be a tedious task and a memory hog.
2. By providing a pre-populated database, using which I can easily establish relations between words and their meanings and do more (searching, sorting, etc).
Now, the problem I am facing is supplying a pre-populated database (or words and meanings) with the app itself. And for doing that I came across SQLite Asset Helper which does the job.
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android. Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)? Is it acceptable method? Any other better alternative up for suggestion would be great!
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android
It works on the latest iterations of Android.
Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)?
You are welcome to roll your own implementation. I do not know what you would gain by this.
Is it acceptable method?
I am not aware of anything better.

Speed issues using H2 database with OrmLite on Android

i am coding an android app which needs a database. I won't use sqlite because i want a pure java core without any dependencies to androids library. To simplify the database access i'm using ORMLite.
So i've just compared the ORMLite android examples
HelloAndroid and HelloAndroidH2.
I've reduced the functionality of both examples to read operations.
The test tables(2 colums, primary_key;value) contains 2 datasets.
The Result:
SQLite: results appears immediately
H2: needs about two seconds to load results.
Where is the mistake or is it correct? Does h2 really need such a long time to load two small Datasets? Any other experiences?
Opening an H2 database using the default options is relatively slow on Android, as documented. There are a few ways to improve that, most of them are documented in the Android section of H2:
FILE_LOCK=FS (to use native file locking; saves at least 20 ms)
PAGE_SIZE=1024 (using a smaller page size seems to improve performance here)
CACHE_SIZE=8192 (to avoid using too much heap memory for the cache)
Also quite important is using an empty user name and password. If you don't, then the password is hashed, which is relatively slow on Android.
But in any case I think you will not be able to get the same opening speed as SQLite in the near future, sorry.

Best Database design option for Android application with huge data

I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.

How do databases on smartphones run?

Im trying to write an article on how databases in modern day smart phones(Android,Symbian,iOS,BlackBerry) operate, however couldn't find any material on the internet, despite searching quite a bit. Any pointers in the form of links or input would be appreciated.
they all use SQLite.
Simply put, it's a serverless SQL database. Or in other words, a C library that takes SQL commands and returns results as read from (or written on) the data stored in a single file.
It's really compact code and works great when you don't need heavy concurrency.

Categories

Resources