CODEWITHSUNDEEP
androidcomponentsmanifestsharing
karla
karla

Reputation: 4606

How does sharing application components happen in android?

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!

Upvotes: 0

Views: 913

Answers (1)

CommonsWare
CommonsWare

Reputation: 1007554

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.

Upvotes: 1

Related Questions