Is SQL or file sharing available in the main theme of the Android user interface?

Question

I am trying to track Android best practices, so in debug mode, I turn on the following:

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violations StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all virtual machine violations 

Android is now yelling at me when I try to use any kind of file or SQL access in the main thread (UI). But I see so many recommendations for using file and / or SQL access in the main thread. For example, the main action is to load the default preference values ​​inside onCreate() if they are not already set:

 PreferenceManager.setDefaultValues(context, resId, readAgain); 

Unfortunately, this leads to file access the first time the application is run, because onCreate() is called in the user interface thread. The only way I can see is to start a separate thread --- which introduces a race condition with a different UI code that can read the settings and expect that the default values ​​will already be set.

Think about services like DownloadManager. (Actually, it’s so buggy that it’s useless in real life, but let it pretend that it works for a second.) If you queue the download, you get an event (in the main thread) informing you that the download is complete. To get information about this download (it gives you only the download identifier), you should request the DownloadManager --- which includes a cursor that gives you an error if strict policy is enabled.

So what is this story? Is it good to access cursors in the main thread? Or is it bad, and half of Android developers and Android book authors have forgotten about this?

Answer 1

The only way I see it is to start a separate thread --- which introduces a race condition with a different user interface code that can read the settings and expect that the default values ​​will already be set.

Then use AsyncTask by placing the setDefaultValues() call in doInBackground() and "another UI code that can read the settings" in onPostExecute() .

To get information about this download (it gives you only the download identifier), you should request DownloadManager --- which includes a cursor, which gives you an error if strict policy is enabled.

So request the DownloadManager in the background thread.

So what is this story? Is it good to access cursors in the main thread?

It depends on your definition of "fine."

On Android 1.x and most 2.x devices, the YAFFS2 file system is used, which basically serializes all disk access in all processes. The network effect is that, although your code may seem quite perfect separately, it sometimes seems to be slow in production due to other things happening in the background (for example, downloading a new email message).

Although this is a bit less of a problem in Android 3.x and higher (they switched to ext4), there is no doubt that flash I / O is still relatively slow - it will be slightly more predictably slow.

StrictMode intended to indicate where slowness can occur. It is up to you to determine which ones are benign and which are not. In an ideal world, you will cleanse them all; in an ideal world, I would have hair.

Or is it bad, and half of Android developers and Android book authors have forgotten about this?

It has always been a "bad thing."

I can’t speak for "half of the Android development team." I assume that at an early stage they expected developers to apply their existing development experience to detect sluggish behavior - this is not significantly different from performance problems on any other platform. Over time, they offered more templates for managing developers in a positive way (for example, in the Loader structure), in addition to changes at the system level (for example, YAFFS2-> ext4) to make this less problematic. In particular, they are trying to find places where Android introduces certain performance issues, such as a single-threaded interface.

Similarly, I cannot speak for all authors of Android books. Of course, I did not focus on performance issues in the early releases of my books, as I focused on Android features and functions. Over time, I added more tips in these areas. I also contributed the open source code related to these topics. In 2012, I will make huge changes to my books and create more open source projects to continue to address these issues. I suspect, given your tone, that I (and possibly others) are complete failures in your eyes in this regard, and you certainly welcome your opinion.