Android now. I started to feel that android is still too young. The system itself is not mature enough, and there are even fewer documents. There is a dark trap everywhere in the android journey. It falls into the trap and is half-dead, and can only be crawled by yourself.
Think
Most of the work is focused on defining a set of contentprovider and upper-layer display controls. A contentprovider provides very limited external interfaces,
It is very effort-consuming to characterize the semantics of these things (the standard is the same behavior as the system contentprovider. At least I fell several heads. To reduce the number of subsequent departments
I tried to remove several stumbling blocks and fill out several traps. I hope they will be helpful.
In contentprovider, the most important thing is query operations. Query Root
A qualified cursor is returned. This may result in the following situations: 1. the query is successful, including several correct results; 2. the query fails and no matching results; 3.
Input error, triggering an exception; 4.
The results cannot be queried, but it cannot be determined whether the input is incorrect or the query fails. The first case is what we need most. Of course, it needs to be properly maintained, and the last case should not appear in most applications (but in
* _ #) In my application, and the second and third are more common.
After my tests, the system's contentprovider maintains such semantics: if this is the case 2, the returned
Normal cursor, and its count is 0, which is equivalent to empty
Cursor; if it is case 3, if no exception is thrown, null cursor is returned. This is clearly understandable, but since there is no official documentation
It is often misused. For example, in some cases, if the query fails with null, an exception is thrown to describe the incorrect input.
Empty
Cursor, if it is maintained by databasecursor, there will naturally be dB for you to maintain, but if the returned arraylistcursor, mergecursor or its
The custom cursor needs to be maintained by itself. Arraylistcursor can use new arraylistcursor (columns,
New arraylist. Columns must not be null. Mergecursor cannot start with new
Mergecursor (new cursor [[] {}) is created by using new mergecursor (New
Cursor [] {aemptycurcursor ...). Custom cursor must also provide empty generation
Cursor method.
If contentprovider is understood as a separate module, it is advantageous to return Ms through null instead of exception.
. All exceptions are eaten at the exit of the module. Although sufficient information cannot be provided (all exception information is written to the log), the upper layer may be easier to use. But in Android, I have no idea
This is obvious. As the upper-layer function of contentprovider, listactivity. managedquery,
Listview. setlistadapter, etc., cannot process a null cursor at all. This triggers an exception in listview. Even more speechless, when you
After setting a null cursor as a manage. It does not immediately throw an exception, but does not handle null in the case of an onfreeze or another lifecycle function.
Cursor throws an exception. This makes it impossible for you to catch the exception locally. In other words, the managecursor of listactivity is simply an unusable function. You must use getcontext (). Query () to obtain the cursor, and then determine whether the cursor is null. bind it to startmanagingcursor. This is far less unified and convenient than handling error paths directly with exceptions.
Of course, some things cannot be changed and can only be adapted. For custom cursor,
Contentprovider, the most important thing is to return empty without human error input.
Cursor instead of null. As for the use of null response or exception response, I personally think it is better to synchronize with the system. Although it is awkward, at least the unification is not easy to be ambiguous.
In addition, contentprovider has a lot of detailed semantics. For example, the returned cursor needs to bind a URI to automatically respond to updates. Custom updates must support operation semantics such as deleterow. In short, we need better documents or more experience documents so that we can better climb the shoulders of giants.
PS: The top-layer listview is even more traps. First, the cursor bound to the listview must have a _ id item. Otherwise, an exception is thrown. If you have developed. net,
This can be thought of, but it should be stated in the document. In addition, if you do not bind a data source to listview, you must not add
Attribute. For example, Android: Height = "wrap_content" will throw an exception during onmeasure.
