I'm reading the official documentation from android's content providers and I've seen this:
Decide if you need a content provider.
You need to build a content
provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other
apps.
You want to provide custom search suggestions using the search
framework.
You don't need a provider to use an SQLite database if the
use is entirely within your own application.
I'm developing an app that syncs data on background when the position changes through an IntentService.
What I've seen is that with ContentProvider you could observe when data changes which I really want without user noticing it. It changes in IntentService and MainActivity observes this changes and when it's notificated, layout content change
Is it a great idea to use a ContentProvider although they don't even mention this?
Thanks
Personally, I have been using ContentProviders in all my projects for the last year and a half. They provide good, database independent, data abstraction to access your data. They are very flexible, I even had a play project where one URI pointed to a SharedPreference while all others where for accessing database tables. ContentProviders also allow you to use already built framework infrastructure such as CursorLoaders, for example. Implementing your own from interfaces and abstract classes is not that hard, but it may be time consuming and error prone, being able to just leverage work that's already been tried and tested is a great advantage.
By the way, I remember the same exact question on a post in google+ about 2 weeks ago where Cyril Mottier gave a very good answer. You can read it here.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So far I've made dozens of apps which use database. I did not go too deep into database logic and how to structure it, but made it as simple as possible and by the rules.
For example, my database logic usually consists of one database class which extends SQLiteOpenHelper. Then I make CRUD methods for each table. Each time I have to deal with a database, I make a special AsyncTask and within it deal with the database. And this is it.
Talking to some developers, I was told that my logic structure should be more complex, more OOP. I tried finding samples on the net but they all were directed towards explaining how to deal with the database. I even reviewed some open source projects but they had the logic similar to mine.
Can you help me? How should I make database logic more OOP? I guess they mentioned that I should be able to reuse this logic in the future, changing only the lowest part which deals with a specific database and its tables.
This is a slightly subjective question, so here's a subjective answer. There is not one correct way to do it imho, I can only speak about how I personally like to work (the big project version, for small projects there's another story). For you or your team it might be different.
For the reference, I work mostly agile, e.g. requirements can change. APIs within the code can change (and do that quite often). This - of course - influences what I consider as useful and what I consider as not useful for my personal work.
Also, I like to work without big frameworks, whereever possible. That's why there is no framework in the model explained below.
I divide database work into three parts to work with: (quite some similatities with the MVC pattern)
The actual database backend (which can execute SQL). Can contain own code for cross-platform work.
The storage class(es), that takes care of storing application-specific information. Each piece of information can be read and set from storage classes, (example: interface AddressBook provides access to elements of the type interface Contact, which have getters and setters for some stuff. The implementation translates that to a single table in the backend).
The application code, which performs actual work and is splitted up further depending on the application (example: stuff providing an address book GUI, etc.).
Why do I split that way? Well, one reason is the ease to switch to a new storage or database backend. If I discover that there could be more preformance when restructuring tables so that new requirements can be met, I update the storage classes. That way I do not have to touch any application logic (example: adding a 1:n table for email addresses to the address book. The new table and its relations do not affect any code within the application, it can recive a list of email addresses from a contact, and add or remove them with ease).
One other reason is that the application code is easy to read (as it consists of, well, application code), while storage code is also easy to read (as it only takes care of storing, caching and similar stuff).
The third reason is that in the case I wish to add another storage mechanism (for example when switching to a platform with a built-in database backend or when adding optional web services) - I can use all OOP mechanisms on the three layers; multiple storages for example can coexist within the same application, so that the user could choose between storing data locally (storage with database backend) or in the cloud.
I hope this answer gave you a little insight of some possibilities with OOP in database-related parts of your application. Again, this is not the one correct way to do it, just one I found working quite well.
Try ORMLite
Object Relational Mapping Lite (ORM Lite) provides some lightweight functionality for persisting Java objects to SQL databases while avoiding the complexity and overhead of more standard ORM packages. It supports a number of SQL databases using JDBC and also supports Sqlite with native calls to Android OS database APIs.
http://ormlite.com/sqlite_java_android_orm.shtml
http://sourabhsaldi.blogspot.in/2012/10/ormlite-tutorial.html
I want to develop an application that supports plugins and that provides data to these plugins. It seems to me that the correct way to implement this plugin-archtitecture on Android would be one apk for the main app and one apk per plugin.
But as the main app and every plugin are in different apks I can't easily pass (data) objects from the one to the other, the applications run in different processes and even if they run in one process (which can be achieved) they have different classloaders and this doesn't work. Currently I see two promising approaches for getting data from my main app to my plugins:
Declaring the main app as a ContentProvider. This seems to me to be the intended approach because it does exactly what I want to achieve: providing content/data to another process.
Making my data objects Parcelable and pushing them around with AIDL or - if I do not need multithreading - with the Messenger-approach. In my opinion, this approach seems to be easier because I can use an ORM-library which cares about the Database in the background. I never used ContentProviders before but at a first look at it I thought that using a ContentProvider is a bit like building SQL-Queries by hand (please tell me if I'm wrong), and I would like to avoid that work!
Now I would like to know if I missed any pros or cons and if there are notable performance differences between these two approaches. And which solution would you prefer and why would you do so?
Thanks in advance! Any replies are appreciated!
Content provider is just way to share data (that are stored in different ways [database, files and so on]) between applications. If you want just share data between application it is the best way to do this.
However, if you want services to perform some tasks with data (for instance, sum several values provided by you) it's better to have a remote service.
In general case, application - plugin interaction is more similar to a remote service. In this case the main application exposes a remote service (an API of this application) that can be used by plugins to perform some actions.
I am making a dictionary kind of an app which uses SQLite. I have a single table that keeps the pair of foreign words and their translations. I want to sync this table with a particular spreadsheet in Google Docs.
I ve found this awesome library to retrieve and manipulate GoogleSpreadsheets, so at least I am covered for that. But I donT feel comfortable about the sync. Now,
Can I use a SyncAdapter to do this sync between my SQLite and a GoogleSpreadsheet? If yes, how would I go about it? Would I retrieve and manipulate the rows of the spreadsheet in the onPerformSync or smth?
What could be the other alternatives for such a scenario? Should I maybe use a normal service to do the check when the user requests it (in the main activity, for example) ?
On the Google I/O vids (particularly on Android REST client apps ) they seem pretty persuasive for using the SyncAdapter but I am not sure if it could help me without an actual REST service.
Thanks in advance..
One good reason to use the Android SyncAdapter, ContentProvider and SyncManager is that you will benefit from the Google system knowledge that is useful for preserving battery life and other resources. Some of this content is in the video you link to. For example, exponential back-off logic to prevent wasteful attempts at synchronizing.
There is some good info about battery life preservation by conserving cell radio power in today's Google I/O 2012 talk "Making Good Apps Great: More Advanced Topics for Expert Android Developers." While not mentioned explicitly, I think that the SyncManager is likely to have the battery conserving properties that are mentioned in this video.
Based on my reading (not actually implementing anything) of the APIs and other resources such as the com.example.android.samplesync package, it seems that the pattern is flexible enough to adapt to your program needs.
The team I'm working with has implemented custom sync for our android app but I can tell you we didn't consider this option because we were committed to writing as much logic as possible to run with the WebView. I wouldn't necessarily recommend that, but that's beyond the scope here.
I am creating an Android app that will get data from the Internet. Eventually I will want to change the app to get similar data from a different (yet to be determined) Internet location. Then even later, yet another location. I'd like to avoid changing my app to account for different Internet locations because that would be difficult to maintain.
There's probably a lot of options, but after some research it seems like a Content Provider may do what I want. It looks like Content Providers were designed to expose data across application boundaries. This is okay, but I don't care that the Content Provider is in a different app from my main app. No other app would be interested in my Content Provider's data, so crossing application boundaries isn't helpful in this case.
Is a Content Provider a good way to approach the problem?
Is there another option I'm not considering?
If a Content Provider is a good solution, how would I go about packaging both the app and the Content Provider(s) into a single .apk file?
Can this be done inside Eclipse or do I need to use the command line tools?
Content provider is a good solution for your problem.
You just have to declare your content provider in your manifest and it's build with your apk. If you don't declare your Content provider as publi, only your app can access to your data.
A good lib/sample for beginning with content Providers is data droid http://datadroid.foxykeep.com/ It will do all the stuff for you.
If you are using the data directly in a ListView for example, it might be beneficial to create a content provider.
You could also opt for a different abstraction within your app, for example a new class that abstracts out the different sources. I don't really see the argument for using a content provider just to make your app more maintainable.
You might even argue that a content provider adds more complexity while you are not using most of it's features.
If you do go for a content provider you can add it to your main app as a component by declaring it in AndroidManifest.nl just fine and you can develop and package the app in Eclipse like you would normally.
my android application is handling a large database of bus passage time and we would like to allow others application to be able to display certains bus passage time. We would like to use a content provider to do that. Most example seems to be about using an SQL database, but... we use some custom text file. I was wondering what would be the best way to do that. I was thinking I could use a Content Provider and implement the Cursor interface on a custom object that I would manually fill with my text data. Would this be possible ? Anyone have a better idea (excluding changing to SQL lite of course) ?
Thanks in advance.
Would this be possible ?
Sure. ConetntProvider is, in effect, a facade, not dictating all that much about the internal implementation.
The key will be documentation. If you are not using SQLite as a data store, you most likely will not be supporting full WHERE clauses for query() and such. Hence, you need to make sure that whatever you do support for WHERE clauses, available columns, and the like, you document it well, so developers integrating with your content provider know how to do it. Otherwise, they may make faulty assumptions.