This is a general sqlite question and specifically as implemented on Android.
Which offers the best peformance if a deletion on one table would require deletions on another? This can be accomplished three ways that I see:
To use a trigger
DELETE statements
A Transaction wrapping the DELETEs
Hope I've phrased it correctly, I can muck around in sql but I might not express myself properly.
The only real way to answer a question like this is to build a test case, and try it.
There are many things that can affect the execution time of a statement, and when you start adding things like triggers and transactions, the number of variables grows even more.
Write a simple test case, specifically for your application, and see which works faster for you.
Also, be wary of premature optimization.
Related
If I want to make a request from an Android device to a remote service, I can use AsyncTask, AsyncTaskLoader, Intent, etc to make the a request apart from the UI thread. It seems there are a lot of options, but I am confused how to choose among them. Could you explain when and which to use? Also, are there any other options besides the ones I have mentioned?
This is an extensively discussed question, since Android provides a long list of mechanisms capable to handle service calls asynchronously, besides the one you mentioned there's also:
IntentService
Native Threads
Now, the key point in your question is "When to use it" and here would be my answer:
In software the only golden rigid rule is the "It depends rule", there's no hard rules for anything in software development there's always different ways to approach a problem in software (i guess that's the reason of the word "soft" in it...) and that's exactly why it always depends, it depends on whatever you need and although one approach might be the most common way to do it like for example "AsyncTask" it doesn't mean at all that AsyncTaks is always the way to go, it always depends on the factors and needs that affect your functionality. There's plenty of things that nowdays get executed using AsyncTaks when maybe all you need could be just a regular common Native Thread.
The only way to be able to make a decision towards the most appropiate approach would be knowing ALL the features around a tool, like for example most people 90% of the time use AsyncTaks just to run doInbackGround on separate thread, but might not even need preExecute, publishProgress, postExecute, etc, and that's something a Regular Thread could do, just like this example there's features for every single object provided in order to do remote calls, however as i already mentioned several times, it all depends on what you need and what tool fits better your needs. Remember there's no hard coded rules for "How, When, and What" to use in software, IT ALL DEPENDS, and making good decisions in that "DEPENDS" makes the difference between good developers from excellent developers...
This is a list of things i usually take on count to implement either one way or another, this list do not apply for all the scenarios but might give you an idea.
AsyncTaks- I know is a good idea to make use of asynctaks when the functionality needs to be monitored, by monitored i mean, i need to keep track of progress during my job, like (download/task progress), because that's exactly what the AsyncTask was originally created for, it was created attached to "The Task Pattern", and if i don't need to make use of at least two methods for monitoring provided by AsyncTaks like onPreExecute,onProgressUpdate, onCancelled etc. I know there might be another way to implement it.
Native Java Threads - I know is good to make use of this tool when my task is not related to any view in android at all, and do not need to be monitored (example: removing/adding data from remote database, and the response might affect just persistence elements that will not be displayed like configuration preferences)
IntentService - When i want to do a one time task in a queueprocessor fashion way, but unliked a native thread, here i would like to have some application context in order to maybe bind an activity etc...
Regards!
is it true that a DBMS can optimize the access to a View by performing the query that defines the View only when the data that is backing the View is modified and not everytime I query the View itself?
EDIT
What about SQLite for Android?
Delamere,
The answer to your question depends largely on your implementation of the Views, the Database queries, and the underlying structure. In essence, the core issue is the nature of the data and how often it needs to be requeried.
In some of my published apps, I have data that only needs to be queried whenever the Window receives focus. In these cases, a simple manual refresh is called. These are often atomic queries meaning they are miniscule amounts of data. Using this method, I've bridged many apps and their data together into a cohesive almost instantaneous query.
In other cases, the data changes quite often but predictably. In these cases, it is counter-productive to reduce the number of queries, but it is also ineffectual to bind an observer.
Finally, there are several cases where the data will change irregularly and the amount of change is unpredictable. In these cases, the optimal solution is to utilize an Observer. This will make sure that only the queries that need to run are run. And the views will be updated as soon as the adapter is updated.
In reference to your question, the final scenario (I think) conveys what you are asking. In short, the answer is yes.... *but... * refer to the first two scenarios. To decide on the optimal solution for yourself, you need to have the answers to the following:
How much data are you querying at any given time?
How often will that data change?
Could it change while your app is running?
Once you have the answers to those questions, you may align your solution accordingly. Without more information, this is the extent of the guidance you will probably receive. I would also strongly advise that if you aren't familiar with basic database engineering concepts, that you familiarize yourself with the concepts of normalization, relational models, and indexing. A strong understanding of these can greatly improve the performance of your database, your app and the appropriate Views.
Hope this helps,
FuzzicalLogic
I'm developing an application for Android, and have tried to use ORMLite, but the performance seems to be really poor. Has anyone else experienced this?
Or am I doing something wrong?
EDIT
No I'm not doing any joins, and all queries are made with indexed keys as parameters. But the data set is resonably big, and there is quite many comparisions.
Haven't tried to do with pure SQLite...
I guess the best answer is that the performance of ORMLite is highly dependent on how you use it. If you could post some of the code samples as well as some of the performance numbers, we may be able to help more specifically.
If you are making a number of database operations at one time, you should consider using the Dao.callBatchTasks() method. Under Android, it starts a database transaction, calls the passed in Callable and after it returns, it commits the transaction. This is significantly faster if you are, for example, inserting a number of rows into the table.
See also: Why is the DAO method so slow in ORMLite?
EDIT
If your queries are taking a while then most likely the time is being spent in SQLite. You could try reducing some of the dataset or tuning the number of comparisons to see if things run faster so you can definitively determine that SQLite (and more likely just IO) is the culprit.
What is the best approach from a performance perspective to show a ListView with contacts and their phone numbers?
Use CursorAdapter with the contacts cursor and make the phone numbers query when bindView is invoked for each row
Copy all the contacts and phone numbers to an in-memory array in a background thread and then show them with an ArrayAdapter.
Other solutions?
In my opinion a mix solution should be better. Why this? Because you don't know or it's suppose that in most of contexts you cannot know about how and how many contacts your application will need to list. An also how many contacts are stored in the phone. If we know both answers, surely we can take the most approach solution.
So I suggest you to first bring a fix number of contacts using an in-memory array in a background thread, for example the first 20. Also if you consider that your app will perform more than one request to this service.. it will be awesome to use a sort of caching. The worst approach should be to call again and again the contacts service.
Then for a request for contact #21 you can bring next 20 and so on.
So you can use the advantages of both worlds, and minimize the disadvantages too. Always depends on the application and the context that we are talking about.
I think this would depend on three factors:
How many contacts are we talking about here?
How much time does it take to load each contact? (E.g. do you have a very complicated view that needs to be inflated or do you fetch contact images/etc that requires any network I/O?)
How much contacts are showing to the user at once?
Your solution one would fit most of the cases though the second solution offers some advantages as well:
Solution 1:
Advantage:
Delayed view inflation in a "view as you go" can perform well when it's fast enough to inflate the views without any noticeable UI glitches.
Disadvantage:
If your contacts associate with a lot of data and requires some complicate inflation, you might notice a delay.
Less flexible and extensible comparing to solution 2. As discussed below.
Solution 2:
Advantage:
You have control of all the steps, so you can easily simulate it just as easy as one, but adding things might be easier: searches through whole memory, custom sorting through the array, etc. they work better when you have everything queried to an array that's already there. Or if you want to do custom loading later, or adding some more data regarding the contacts that require some more processing (say network I/O), it might be slightly easier than cursor adapter.
Disadvantage:
Execution: this is not the text-book way to do it. making things more custom will need you to handle all the threads well and handle the initial appearance well. Make sure it scales.
So yea, depending on what exactly are you are working on, choose the appropriate one.
I think http://www.higherpass.com/Android/Tutorials/Working-With-Android-Contacts/ will be an option. Where you can find all of the facility you want...
I think CursorAdapter is the best solution.
Also make sure you watch this video http://www.youtube.com/watch?v=wDBM6wVEO70
It talks about optimizations that in my opinion are necessary to make your list scroll smoothly.
Executing multiple SQL statements without putting them into one transaction is a severe bottleneck (see e.g. http://www.sqlite.org/faq.html#q19). I haven't thoroughly checked how SQLite is configured on Android, but anecdotally I perceived dramatical performance increase within my on app when using transactions in more places.
Is it possible to detect instances where one forgets to use transactions using StrictMode? If not, could that be considered for a future release of StrictMode? It might be somewhat tricky to detect, but two different strategies could be, 1) non-select statements outside transaction, or 2) multiple non-select statements outside transaction executed within a short period of time.
Yeah, that sounds like a good thing to catch. I could imagine an API like:
StrictMode.catchWritesOutsideTransactionsOn(SQLiteDatabase db);
We've been considering other SQLite hooks into StrictMode (mostly around selects missing indexes and such), but this is a good idea too!