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.
Related
I want to know if an android app of mine can be extended by third parties without me having to modify the base app for each extension, kind of what eclipse does with its plug-ins.
The base app would be something pretty simple, some kind of local data manager (CRUD operations). A given plug-in may, for example, do things with said data (different ways of displaying it, for instance) in additional activities/fragments.
From a little research around, I've discovered that if I were to be the developer of both base app and plug-ins, I could accomplish it by creating new apks non directly accessible for the user (Main/Launcher) and querying from the base app whether a given plug-in is installed on the device and, if so, show additional options on the UX. I can work with that, but I wondered if there was no other option to allow the third-party extension.
Searching for "extension points" doesn't seem to yield android results. Maybe it isn't possible?
A given plug-in may, for example, do things with said data (different ways of displaying it, for instance) in additional activities/fragments.
Step #1: Expose said data to third-party apps, such as via a ContentProvider.
Right now, you're already done, except for the part of "show additional options on the UX". For that:
Step #2: Document the <intent-filter> that third-party apps should have on any activities that they want to be launched from your app. This may involve custom actions and/or categories and/or MIME types.
Step #3: When your needs to "show additional options on the UX" (which I am interpreting as some sort of list or menu), use queryIntentActivities() on PackageManager to find all activities that implemented the <intent-filter> that you documented in Step #2, and include them in that list.
For your particular scenario, where it's simply a matter of storing and retrieving data from a base application, you can use the same approach as the Contacts application uses, which uses a Content Provider.
You can read more about Content Providers and how to implement them here: Content Providers | Android Developers
If you're instead looking at extending an installed application, you would have to predefine a dynamic set of classes to present the data, as well as a set of rules and a language / interface for the plug-ins to extend your applications functionality from within your own application.
You could also look into loading external .jar files into your application at runtime. It looks like others have been successful before
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.
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.
GOAL
Hi, I plan to include in all my aps a "credits" button that will display my logo, URL, etc.
PREFERRED SOLUTION
In order to be more effective I would like to have it as an independent app, so that if I later modify it, all the apps calling it would get updated to the same credits display, instead of modifying each of them.
ALTERNATIVES
*(a)* Of course the easy solution is to copy it within each of my apps and update manually each of them. I think this is not so effective when the number grows.
(b) Having a kind of external resource like a mobile adapted webpage which would always be called. I would only need to change it. But I open then the workfield out of android.
My first idea is to have to define it as an independent activity and get it called from each of the apps.
I have two related questions:
1. How do I ensure this "credits" activity gets installed with an application (is there a kind of dependency which can be defined?)
2. Is this a reasonable way of doing it within Android context?
Thanks.
PREFERRED SOLUTION In order to be more effective I would like to have it as an independent app, so that if I later modify it, all the apps calling it would get updated to the same credits display, instead of modifying each of them.
No user will download this, so do not bother writing it.
How do I ensure this "credits" activity gets installed with an application (is there a kind of dependency which can be defined?)
There is no way to accomplish this.
Is this a reasonable way of doing it within Android context?
No. As #bigstones suggests, use an Android library project.
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.