The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
IMHO, content providers are solutions in search of worthwhile problems.
ReplyDeleteThere certainly are worthwhile problems, particularly for cross-process data publishing. For example, you need to use a content provider to supply search suggestions to a Quick Search Box.
However, for internal use within an application, I am still skeptical. The benefits (e.g., the single threading that Robert mentions) IMHO are outweighed by the costs (e.g., reduced flexibility compared to SQLite and rawQuery()).
One of these days, I expect that the cartoon light bulb will shine over my head, as I finally figure out what the core Android team was thinking with respect to content providers. That certainly has happened for other areas of Android. At the moment though, the thought balloon over my head is filled with question marks, not light bulbs.
If you do implement a content provider, bear in mind that they are accessible by other applications by default. You need to include android:exported="false" in the <provider> element to make them private to your app.
Using a content provider will give you a more modular design, and make your life easier if you at some point in future would like to reach the data from other applications.
ReplyDeleteIf you are certain that the data will only ever be needed from one application, you might as well operate directly on the database.
There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.