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.
Related
I need to have a Graph(or some equivalent data structure) in memory which should hold a set of IDS(numbers) and the requirement would be that the graph(or some datastructure) might have about 10000 nodes.The scenario is explained below. Should I choose any API or my own custom implementation.Please consider memory and speed (Please feel free to tell me any suggestions.)
Eg:
I would get all the leaf nodes at every instance. ie
In the figure below I would need only 6,7,8.
If the program removes 6 from the graph then the output would be 4,5,7,8
Sorry to stress it again.Please consider memory and speed as it should run on android.
Thanks
You might also want to have a look at the following post: Is there a Directed Acyclic Graph (DAG) data type in Java, and should I use it?
What you want is a DAG (Directed Acyclig Graph) library.
What API implementation are you considering? I can't think of any Java collection that suits your needs.
If you just implement your own, you can keep track of the leaves as you build and modify the tree, so whenever you need to get the leaves, you already have a list of them. If you use a a HashSet to keep track of the leaves, I think you should be able to do all tree operations without incurring an extra time-complexity hit because of the HashSet.
Of course, you'll be using extra memory, but it's up to you to determine if that will be an issue. I'd say that even with 10k possible leaves and running on android, it should not be of any concern.
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
Are there any advantages of Loaders over Async task? Also, how to make loaders compatible for phones with Android froyo.
Edit:
The primary problem here is that I'm not using the native DB(SqlLite). Using the DB on development server. Obviously, I can't use CursorLoader any more. AsyncTaskLoader has no examples at all. If any, please do link.
Is it a better idea to load the data required onto the local DB and then query it using CursorLoader?
Yes, Loaders are more advantageous than AsyncTask as they take care of a lot of things that AsyncTask falls short of, miserably.
Screen Orientation changes are difficult in AsyncTask. I used to have such a problem, till I used an Activity Control class, which I used to retain while configuration changed. I can give you some code if you want to know how. The app used to crash, though, when you changed the orientation multiples times even before the entire data loaded. The secret here is not load a lot of data with your first thread and and finish your threading tasks as soon as possible. Even if it happens in the background, Android has a shabby way of dealing with threads. You never know when one of your tasks would be killed.
Even if you use a AsyncTaskLoader, makes sure that you use an Activity manager. This will help you in getting more control over the activites and AsyncTask.
Yes, it is compatible in all the old version of Android. You need to include the support library(Most of the times, this is included by default but its always nice to double check.)
For one, loaders are easier to code (they're almost built-in in Fragments).
Loaders (specifically CursorLoader) also handles your cursor for you (like the deprecated manageQuery).
Check out this link to read on how to use Loaders pre-Honeycomb.
There simpler to implement and take care of a lot of the life cycle management which previously had to be done "by hand" with AsyncTasks. See the answer to this question for further detail.
With regards to using them with Froyo, they're available via the compatibility library.
It seems no one is talking about the disadvantages of loaders! I'm currently working on a system that runs other services in the background.
What I have noticed is that as soon as a screen with a loader is resumed. The cursor used by the loader locks up the DB.
It may not be open to most people but getDatabaseWriter from sqlite is actually a synchronized method and hence the cursor used by the loader is never closed until the loader is reset or terminated thus locking up access to the DB.
I cannot recommend using a loader under these circumstances nor can I advice using a loader when your result set consists of less than 100 items which are static and never seem to change.
Another advantage with loaders is that they handle screen turn event gracefully whereas asynctask can give you trouble.
Biggest diff:
CursorLoader will update your UI's content as soon as its related ContentProvider changes its content(say through a Service), while AsyncTask will only update your UI when you tell it.
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 just read a pretty interesting article on how android (and i assume other OSs) work when low on memory. How is this done theoretically? Is it similar to Java's object serialization?
In a word: yes.
In a few more words, sort of. You have to handle more of it manually than personally I'd like. Essentially, all Android provides for you is a hash to shove a few serializable objects, referenced by strings, that is guaranteed to be safe across application shutdowns. So, whenever something happens that you'd like to preserve across a shutdown of your application, you are responsible for updating this saved state hash (and letting Android know that you've done so). This includes things like half-finished text entry in form fields. That means you have a lot to listen to.
Android will then call a particular hook in your Activity that handles restoring state to the Activity when it recycles your application and you need to do so. This doesn't happen for all recycles — there are various states of being/existence for your application.
The screwy part is that because you're expected to do this sort of tedious work anyway, Android gets lazy and implements things like screen rotation as a full recycle of your application.
I'm making it sound worse than it really is once you get used to it; it's really not a bad way of solving the problem in the confines of Java and mobile computing.
Of course, this is a response regarding Android. Other (desktop) OS's rely on Virtual Memory and Paging to deal with memory constraints.