Content providers don't provide a database, or anything else for that matter. They are an Android component that offers the following features:
- cross-application access, so that one data store can serve multiple applications. The framework handles data transfers and procedure calls across processes. - Flexible resource identification based on URIs. - Implementation hiding - a provider can manage its data however it wants, but it must offer its data as one or more data sets. - Each data set is *accessed* like a single SQL table of rows and columns, regardless of the underlying structure of the data. Basically, you don't get automatically get a database when you create a ContentProvider, and in fact you have to implement the underlying data structure yourself. Providers are there so that applications can offer an unattended source of data to other apps. The provider is always available, and Android starts it up automatically when an app tries to access it. A newer reason for providers is copy and paste: if you want to copy and paste complex data structures, binary data, or file streams, you have to use a content provider. There are also some convenience methods in the content provider framework for managing synchronization. This is useful if you want to allow updates both from Android apps and from the Internet. For a list of restaurants with street addresses, latitude and longitude, and pictures, a database is *probably* the best idea. Over time, it will be the easiest to manage. The alternatives are storing it in a text file (containing pointers to the image files), but that only works for a small set of data that you don't update a lot. If you want this data available to all applications on the phone, you really have to use a content provider. Otherwise, your own SQLite database will be easier to handle, even if you're doing internet updates. I think SQL and SQLite are easier than people think. They get complicated if you try to decompose them to canonical form, but you can always get your code working first and then do that later, since the decomposition and joining are done with SQL, not with Java. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
