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
Related
My goal is to collect health and family related data through interview some patients. So I'll provide every information about every view or question in database. like view type (radio button,edit text ,spinner...), data type (text or number), data length, whether it has any media (image, audio, video) regarding this question. Questions might have a dependency (visibility or value) on other question. I have tried so far and what I got that for small number of questions its okay. But when its about 100 or 150 or more questions, performance is not good. Since I am running lots of sql query and refreshing view manually. I mean on event (onSelect, onChange, onChecked.....) I am saving data to db, changing other question's visibility, value. So far lots of requirement have been added to my app. Can you suggest me about coding structure , library so that I can improve the performance? What are the things that should be used in this app? I have attached some pictures so that you can get a idea.
View Demo https://i.stack.imgur.com/ZCGuz.png
Dependency https://i.stack.imgur.com/j2nzj.png
Required field validation https://i.stack.imgur.com/tFuOH.png
You could use Google Firebase services. There are some huge advantages compared to sql especially with app development. It's optimized for many queries and therefore it's speed is impressive. You can just a Firebase account and use it(Although with limited resources). I would really that you add the firebase library to your project. Also with sensible health and personal data should stay private and as far as I know there are literally always security issues with Apache2 or nginx or php or mysql/mariadb so just do it the easy more reliable and more secure way. I hope I helped you out. :)
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.
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.
I am going through a bit of a design dilemma, I have been targeting Android 2.3.3 and have a custom implementation of a ContentProvider. I then have a class of static methods to abstract the Content provider - providing me with objects representing each entity (row) based upon my query. For a while I was very comfortable with working like this, until I started wanting to use the whole collection in a number of places, for performing "hit tests" and drawing to the screen. I then had the headache of keeping my object representations up to date, and at this point have decided I need to step back and reconsider where to take this.
As I say, I am presently using 2.3.3, and realise that in 3.0 CursorLoader overcomes a lot of the problems I have encountered. I still need to support smart phones though, so unless there will be a backport I cannot do this.
As an interim solution I started to register notifyChange listeners so that I can rebuild a collection with my original query, but this strikes me as very CPU intensive and potentially slow. I haven't yet decided whether I should roll back from using my static facade and instead use the now obsolete managedQuery call from Activity.
I therefore have two questions:
1) Is there a preferrable way to avoid the issues with working against a collection based around a contentProvider?
2) Have you any advice on working with raw cursors in an activity? Should I be making objects out of them or working with the cursor as-is? I certainly feel they should be in an AsynTask while performing the query, but after that can I use them anywhere?
Ok, well I came to a decision and it works reliably.
1) Is there a preferable way to avoid
the issues with working against a
collection based around a
ContentProvider?
I have decided that the approach I took was correct; In my situation it is preferred to make a cache rather than maintain a cursor (managed or not) to the ContentProvider; this allows me to reuse methods and reduce the amount of code that requires testing. NotifyChange listeners are important until working on 3.0+ and that means I should guarantee the NotifyChange is called - another argument for centralising all of this code, so that it indeed triggers the changes when expected.
2) Have you any advice on working with
raw cursors in an activity? Should I
be making objects out of them or
working with the cursor as-is? I
certainly feel they should be in an
AsyncTask while performing the query,
but after that can I use them
anywhere?
In my use case I have decided it is a matter of thinking about what it is I am planning to create - avoid unnecessary work, with respect to returning unnecessary rows & fields and potentially creating unnecessary objects. If I am looking to create a map of entry names and entry IDs then I shouldn't be getting all of the other fields too. Abstracting from the collection is good but it must be lightweight and take in to account how the data is used - whether it is a one-off or may be used repeatedly. It is important that it is written for performance rather than completeness.