I am writing a component that makes certain functionality available to
any application running on an Android device (e.g. an advertising
service, stock ticker cache, Snowball server, etc).
This functionality is useful for application developers, but not
interesting to actual users i.e. my component should be included as
part of a new application, but not require the end user to explicitly
install the additional component themselves.
I expect that over time multiple applications installed on the phone
will want to communicate with my component. As each new application
will have a different certificate, I want to communicate between
applications using an Android Content Provider. To save resources on
the device (networking, caching, etc) only one instance of my
component should be appointed to handle all queries.
This works well as Android only registers the first Content Provider
for a given URI and then ignores the rest (throwing an “WARN/
PackageManager: Skipping provider name xxxx name already used” error
each time a new one is installed).
However if the registered Content Provider is uninstalled, it will
immediately break all the other applications that rely on it, even
though other instances of the component still exist.
Questions:
- Does anyone have any suggestions on how to better handle this
situation?
- If I could reregister Content Providers I could handle situations
like this, and upgrade components when newer versions are installed.
Perhaps the Android OS could also handle this situation better, by
tracking Content Provider naming collisions?
- Should I be looking at other communication methods to solve this
issue?
Just to clarify, the attribute “android:multiprocess” in the
“provider” tag seems to have a behaviour that is not relevant to this
problem, i.e. it prevents multiple instances of the same Content
Provider from existing, rather than affecting multiple Content
Providers trying to use the same namespace.
As far as naming issues, this is why you should use an authority in a
namespace/domain you own, so that there will not be naming collisions.
For the possibility of your provider not being there, whether or not it was
ever there originally, any client app that is relying on a component that is
not part of the base platform needs to deal with the error cases if that
component does not exist.
> I am writing a component that makes certain functionality available to
> any application running on an Android device (e.g. an advertising
> service, stock ticker cache, Snowball server, etc).
> This functionality is useful for application developers, but not
> interesting to actual users i.e. my component should be included as
> part of a new application, but not require the end user to explicitly
> install the additional component themselves.
> I expect that over time multiple applications installed on the phone
> will want to communicate with my component. As each new application
> will have a different certificate, I want to communicate between
> applications using an Android Content Provider. To save resources on
> the device (networking, caching, etc) only one instance of my
> component should be appointed to handle all queries.
> This works well as Android only registers the first Content Provider
> for a given URI and then ignores the rest (throwing an "WARN/
> PackageManager: Skipping provider name xxxx name already used" error
> each time a new one is installed).
> However if the registered Content Provider is uninstalled, it will
> immediately break all the other applications that rely on it, even
> though other instances of the component still exist.
> Questions:
> - Does anyone have any suggestions on how to better handle this
> situation?
> - If I could reregister Content Providers I could handle situations
> like this, and upgrade components when newer versions are installed.
> Perhaps the Android OS could also handle this situation better, by
> tracking Content Provider naming collisions?
> - Should I be looking at other communication methods to solve this
> issue?
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
Hm, I think you end up with unnecessary code duplication if you
include your component / content provider in every application.
I think it would be better if every application that wants to use your
component shows a small dialog "You need to install the following
component..." with a button that brings you to the download page of
the Market for your component. There are various ways when to show
this dialog box (catch the ActivityNotFoundException if you try to
launch an activity of your component, or use the PackageManager to
check if a desired component exists to handle the request).
At OpenIntents we try to resolve dependencies as late as possible -
i.e. not at installation time, but the first time the user actually
wants to use a particular feature (they may never use it in which case
there is no need to install it).
I think in the long run Market should have better tools for resolving
compulsory dependencies automatically, but for the moment I think this
is a good compromise for developers and end users.
> I am writing a component that makes certain functionality available to
> any application running on an Android device (e.g. an advertising
> service, stock ticker cache, Snowball server, etc).
> This functionality is useful for application developers, but not
> interesting to actual users i.e. my component should be included as
> part of a new application, but not require the end user to explicitly
> install the additional component themselves.
> I expect that over time multiple applications installed on the phone
> will want to communicate with my component. As each new application
> will have a different certificate, I want to communicate between
> applications using an Android Content Provider. To save resources on
> the device (networking, caching, etc) only one instance of my
> component should be appointed to handle all queries.
> This works well as Android only registers the first Content Provider
> for a given URI and then ignores the rest (throwing an “WARN/
> PackageManager: Skipping provider name xxxx name already used” error
> each time a new one is installed).
> However if the registered Content Provider is uninstalled, it will
> immediately break all the other applications that rely on it, even
> though other instances of the component still exist.
> Questions:
> - Does anyone have any suggestions on how to better handle this
> situation?
> - If I could reregister Content Providers I could handle situations
> like this, and upgrade components when newer versions are installed.
> Perhaps the Android OS could also handle this situation better, by
> tracking Content Provider naming collisions?
> - Should I be looking at other communication methods to solve this
> issue?
Oh wait if what is being talked about is having the same content provider in
multiple applications, that is completely the wrong approach. For a given
authority there must be one and only one content provider implementation,
living in a single specific .apk.
On Thu, Jan 8, 2009 at 11:03 AM, Peli <peli0...@googlemail.com> wrote:
> Hm, I think you end up with unnecessary code duplication if you
> include your component / content provider in every application.
> I think it would be better if every application that wants to use your
> component shows a small dialog "You need to install the following
> component..." with a button that brings you to the download page of
> the Market for your component. There are various ways when to show
> this dialog box (catch the ActivityNotFoundException if you try to
> launch an activity of your component, or use the PackageManager to
> check if a desired component exists to handle the request).
> At OpenIntents we try to resolve dependencies as late as possible -
> i.e. not at installation time, but the first time the user actually
> wants to use a particular feature (they may never use it in which case
> there is no need to install it).
> I think in the long run Market should have better tools for resolving
> compulsory dependencies automatically, but for the moment I think this
> is a good compromise for developers and end users.
> On Jan 8, 4:18 pm, whitemice <markbr...@zedray.co.uk> wrote:
> > I've blogged this question with pictures here:http://tinyurl.com/9hwdva
> > I am writing a component that makes certain functionality available to
> > any application running on an Android device (e.g. an advertising
> > service, stock ticker cache, Snowball server, etc).
> > This functionality is useful for application developers, but not
> > interesting to actual users i.e. my component should be included as
> > part of a new application, but not require the end user to explicitly
> > install the additional component themselves.
> > I expect that over time multiple applications installed on the phone
> > will want to communicate with my component. As each new application
> > will have a different certificate, I want to communicate between
> > applications using an Android Content Provider. To save resources on
> > the device (networking, caching, etc) only one instance of my
> > component should be appointed to handle all queries.
> > This works well as Android only registers the first Content Provider
> > for a given URI and then ignores the rest (throwing an "WARN/
> > PackageManager: Skipping provider name xxxx name already used" error
> > each time a new one is installed).
> > However if the registered Content Provider is uninstalled, it will
> > immediately break all the other applications that rely on it, even
> > though other instances of the component still exist.
> > Questions:
> > - Does anyone have any suggestions on how to better handle this
> > situation?
> > - If I could reregister Content Providers I could handle situations
> > like this, and upgrade components when newer versions are installed.
> > Perhaps the Android OS could also handle this situation better, by
> > tracking Content Provider naming collisions?
> > - Should I be looking at other communication methods to solve this
> > issue?
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
Just to clarify: I am writing an advertising server component at the
moment, but other projects that I have in the pipeline essentially
have the same requirement.
>>Dianne Hackborn - As far as naming issues, this is why you should use an authority in a
namespace/domain you own, so that there will not be naming
collisions.<<
My application sits in its own namespace. I am only having conflicts
with different copies of the same Content Provider Component being
installed with different applications.
>>Dianne Hackborn - …any client app that is relying on a component that is not part of the base platform needs to deal with the error cases if that component does not exist.<<
If the component is not there, then the application would show an
error on start and normally refuse to run. Result: Bad user
experience.
>>Peli - Hm, I think you end up with unnecessary code duplication if you include your component / content provider in every application.<<
This isn’t an issue, as my component is delivered as a small Java
class included with the main application. When activated, the
component inflates in size as it downloads content over the internet.
My goal is to manage this process by having only one component
activated regardless of how many applications are installed on the
device.
>>Peli - I think it would be better if every application that wants to use your component shows a small dialog "You need to install the following component..." with a button that brings you to the download page of the Market for your component...<<
Catching a missing component is easy enough. It’s just that what you
describe adds up to a bad user experience:
- No user will download a 3rd party advertising server (or any non-
core functionality) just to run a game.
- Installation is already a convoluted process and should only take
place once. Additional APK installations require more downloading,
application permission settings, button pressing, confusion, etc.
- No client of mine will accept a solution that asks the user to jump
through any additional hoops (e.g. even the Android Developer
Challenge only permitted a single executable).
>>Peli - At OpenIntents we try to resolve dependencies as late as possible - i.e. not at installation time, but the first time the user actually wants to use a particular feature (they may never use it in which case there is no need to install it).<<
This doesn’t work for me as ad funded Applications generally require
my component to be available on startup.
>>Peli - I think in the long run Market should have better tools for resolving compulsory dependencies automatically, but for the moment I think this is a good compromise for developers and end users.<<
I agree that this needs to be improved, as there is currently no
support for components (downloading, versioning, upgrading, etc) in
Android or on the Android Market. Hence I am trying to get around
this issue by “managing” a Content Provider.
>>Dianne Hackborn - Oh wait if what is being talked about is having the same content provider in multiple applications, that is completely the wrong approach. For a given authority there must be one and only one content provider implementation, living in a single specific .apk.<<
This is how it’s done at the moment, i.e. Android will log a warning
(and do nothing) every time an application tries to register a Content
Provider URI that’s already in use. This means that subsequent
applications will be broken (and need to be reinstalled) if the
original Content Provider is ever uninstalled. I don’t seem to be
able to reregister a missing Content Provider URI at runtime.
>>Muthu Ramadoss - AFAIK, a Content Provider is tied up to a unique Authority. If you want to support multiple URI's you do so accordingly by providing different URI paths using the same authority.<<
I explored this approach initially, but it still has the following
problem:
Over time, I release a number of versions of my component that other
developers subsequently integrate into their own applications. My
component uses the following URI conventions:
content://mynamespace.mycomponentnamespace.version1/
content://mynamespace.mycomponentnamespace.version2/
content://mynamespace.mycomponentnamespace.version3/
Android allows me to search and interrogate each URI to check the
status of each Content Provider (allowing me to version my
component). This is fine until v3 of my component becomes really
popular and a user installs five games on their phone, each with the
same component trying to register the same URI.
The user then gets bored of the first game and uninstalls it, thereby
breaking all the other games that rely on the Content Provider that it
contains. As URIs are set at install time, none of the other games
will work until the user reinstalls an existing game or downloads a
new one - This is a terrible user experience.
Indeed, for an advertising server, it makes more sense to include that
in every application separately, for the reasons you mentioned.
I could suggest the following:
Obviously it is easier to work with multiple instances of the same
intent through the PackageManager than it is to work with multiple
instances of the same ContentProvider.
The point is, you don't have to use a single ContentProvider at all,
at least not directly.
Have each application have its own content provider in their own
namespace (e.g. in the namespace of the client, so there is never a
name collision), and handle all the synchronization through intents.
For example there could be a broadcast intent
SEND_ACTIVE_CONTENT_PROVIDER_URI that you send to all installed
applications that can receive this.
The one application that has maintains the currently active content
provider answers with a broadcast intent, and in the extra it contains
the uri of the ContentProvider in use (e.g. content://com.some_client.whitemice.ads/).
So all other applications can access that content provider
subsequently.
If no other application replies with an active content provider for 5
seconds (or 900 ms or whatever), then the current application can
create the master content provider in its own namespace and
subsequently answer to the SEND_ACTIVE_CONTENT_PROVIDER_URI with its
own content provider uri (e.g. content://com.another_client.whitemice.ads/).
(to add version information, include this in an extra
CONTENT_PROVIDER_VERSION, so only applications answer that have an
active content provider with the correct version).
So there is never a collision of content provider name spaces, but
only one of the content providers is active (and filled with
information) at a time, and all applications can access that one
content provider.
> Just to clarify: I am writing an advertising server component at the
> moment, but other projects that I have in the pipeline essentially
> have the same requirement.
> >>Dianne Hackborn - As far as naming issues, this is why you should use an authority in a
> namespace/domain you own, so that there will not be naming
> collisions.<<
> My application sits in its own namespace. I am only having conflicts
> with different copies of the same Content Provider Component being
> installed with different applications.
> >>Dianne Hackborn - …any client app that is relying on a component that is not part of the base platform needs to deal with the error cases if that component does not exist.<<
> If the component is not there, then the application would show an
> error on start and normally refuse to run. Result: Bad user
> experience.
> >>Peli - Hm, I think you end up with unnecessary code duplication if you include your component / content provider in every application.<<
> This isn’t an issue, as my component is delivered as a small Java
> class included with the main application. When activated, the
> component inflates in size as it downloads content over the internet.
> My goal is to manage this process by having only one component
> activated regardless of how many applications are installed on the
> device.
> >>Peli - I think it would be better if every application that wants to use your component shows a small dialog "You need to install the following component..." with a button that brings you to the download page of the Market for your component...<<
> Catching a missing component is easy enough. It’s just that what you
> describe adds up to a bad user experience:
> - No user will download a 3rd party advertising server (or any non-
> core functionality) just to run a game.
> - Installation is already a convoluted process and should only take
> place once. Additional APK installations require more downloading,
> application permission settings, button pressing, confusion, etc.
> - No client of mine will accept a solution that asks the user to jump
> through any additional hoops (e.g. even the Android Developer
> Challenge only permitted a single executable).
> >>Peli - At OpenIntents we try to resolve dependencies as late as possible - i.e. not at installation time, but the first time the user actually wants to use a particular feature (they may never use it in which case there is no need to install it).<<
> This doesn’t work for me as ad funded Applications generally require
> my component to be available on startup.
> >>Peli - I think in the long run Market should have better tools for resolving compulsory dependencies automatically, but for the moment I think this is a good compromise for developers and end users.<<
> I agree that this needs to be improved, as there is currently no
> support for components (downloading, versioning, upgrading, etc) in
> Android or on the Android Market. Hence I am trying to get around
> this issue by “managing” a Content Provider.
> >>Dianne Hackborn - Oh wait if what is being talked about is having the same content provider in multiple applications, that is completely the wrong approach. For a given authority there must be one and only one content provider implementation, living in a single specific .apk.<<
> This is how it’s done at the moment, i.e. Android will log a warning
> (and do nothing) every time an application tries to register a Content
> Provider URI that’s already in use. This means that subsequent
> applications will be broken (and need to be reinstalled) if the
> original Content Provider is ever uninstalled. I don’t seem to be
> able to reregister a missing Content Provider URI at runtime.
> >>Muthu Ramadoss - AFAIK, a Content Provider is tied up to a unique Authority. If you want to support multiple URI's you do so accordingly by providing different URI paths using the same authority.<<
> I explored this approach initially, but it still has the following
> problem:
> Over time, I release a number of versions of my component that other
> developers subsequently integrate into their own applications. My
> component uses the following URI conventions:
> content://mynamespace.mycomponentnamespace.version1/
> content://mynamespace.mycomponentnamespace.version2/
> content://mynamespace.mycomponentnamespace.version3/
> Android allows me to search and interrogate each URI to check the
> status of each Content Provider (allowing me to version my
> component). This is fine until v3 of my component becomes really
> popular and a user installs five games on their phone, each with the
> same component trying to register the same URI.
> The user then gets bored of the first game and uninstalls it, thereby
> breaking all the other games that rely on the Content Provider that it
> contains. As URIs are set at install time, none of the other games
> will work until the user reinstalls an existing game or downloads a
> new one - This is a terrible user experience.
whitemice wrote: > My application sits in its own namespace. I am only having conflicts > with different copies of the same Content Provider Component being > installed with different applications.
Don't use a ContentProvider.
> This isn’t an issue, as my component is delivered as a small Java > class included with the main application. When activated, the > component inflates in size as it downloads content over the internet. > My goal is to manage this process by having only one component > activated regardless of how many applications are installed on the > device.
Since the content in question is going on /sdcard (right? right?!?), solve the problem by managing the space, not managing the components. Since you already require each application to have your own code anyway, just use a regular Java class to access the /sdcard data store and dump the ContentProvider interface.
> I agree that this needs to be improved, as there is currently no > support for components (downloading, versioning, upgrading, etc) in > Android or on the Android Market.
> Since the content in question is going on /sdcard (right? right?!?),
Ad images and banners should be placed on the SD card, but private
data for accounting (number of times an ad had been shown, click-
through-rate, last ad shown, etc.) could be stored in a content
provider, and it makes sense to share this content provider among
several applications installed (e.g. so that the end user is not
presented the same ad in every application they launch).
>>Peli - Indeed, for an advertising server, it makes more sense to include that in every application separately, for the reasons you mentioned. I could suggest the following…and all applications can access that one content provider. Would this sound like a suitable solution?<<
I didn’t think of just doing the synchronisation using intents (as
they support a one-to-many relationship between components). I’ll do
a proof of concept on Monday to see if this works. It’ll be a bit of
a hassle for the guy who has to incorporate this into their
application, but it will do until Android is improved to support
components. ;-)
Thank you kindly!!
>>Mark Murphy - Since the content in question is going on /sdcard (right? right?!?), solve the problem by managing the space, not managing the components. Since you already require each application to have your own code anyway, just use a regular Java class to access the /sdcard data store and dump the ContentProvider interface.<<
>>Peli - Ad images and banners should be placed on the SD card, but private data for accounting (number of times an ad had been shown, click- through-rate, last ad shown, etc.) could be stored in a content provider, and it makes sense to share this content provider among several applications installed (e.g. so that the end user is not presented the same ad in every application they launch).<<
While Mark Murphy’s solution could be made to work, communicating
outside of the OS would be quite ugly in terms of the security and the
hardware assumptions which would need to be made. I also expect the
security regime and file permissions to morph somewhat over the next
couple of Android releases, potentially breaking my OS bypass hack.
I’ll put this idea down as a plan B, thanks anyway!!
I think I have enough ideas to get this to work now, and will post my
results to the thread and blog early next week.
If I find more than one valid Content Provider I can then pass around
Synchronisation information (validity, compatibility, version, status,
etc) using any of the ContentProvider class methods (I used getType
()).
The only problem with this approach is that the application developer
who imports my component (as a JAR) will have to define their own
custom Content Provider. This is done by extending the
MyComponentContentProvider class (from my JAR) and defining a
CONTENT_URI variable.
package test;
import com.whitemice.MyComponentContentProvider;
public class TheirContentProvider extends MyComponentContentProvider {
public static final Uri CONTENT_URI =
Uri.parse( "content://
myComponentNamespace.theirApplicaitonNamespace");
}
As well as adding the custom provider to the Android manifest.
Without the custom Content Provider configuration, Android will behave
strangely and sometimes call a different .APK file if it has a class
in it with the same name.
As this is a work time project, I will have to check if I can release
the synchronisation code as a working example. If I do it will appear
on my blog here:
http://tinyurl.com/9hwdva
> I can then pass around
> Synchronisation information (validity, compatibility, version, status,
> etc) using any of the ContentProvider class methods (I used getType
> ()).
Probably you should not mis-use getType(), even if all
ContentProviders act in your own name space. The reason is that other
applications (maybe a universal backup application?) may peek all
content providers and call getType() if they are interested in what
kind of content your content providers provide.
Probably it is safer to use query() on different URI paths, as this
can return whatever you define it to return - within your name space.
> If I find more than one valid Content Provider I can then pass around
> Synchronisation information (validity, compatibility, version, status,
> etc) using any of the ContentProvider class methods (I used getType
> ()).
> The only problem with this approach is that the application developer
> who imports my component (as a JAR) will have to define their own
> custom Content Provider. This is done by extending the
> MyComponentContentProvider class (from my JAR) and defining a
> CONTENT_URI variable.
> package test;
> import com.whitemice.MyComponentContentProvider;
> public class TheirContentProvider extends MyComponentContentProvider {
> public static final Uri CONTENT_URI =
> Uri.parse( "content://
> myComponentNamespace.theirApplicaitonNamespace");
> }
> As well as adding the custom provider to the Android manifest.
> Without the custom Content Provider configuration, Android will behave
> strangely and sometimes call a different .APK file if it has a class
> in it with the same name.
> As this is a work time project, I will have to check if I can release
> the synchronisation code as a working example. If I do it will appear
> on my blog here:http://tinyurl.com/9hwdva
> Regards
> Mark
> P.S. Thanks again everyone for your suggestions.
I assume, getType() is also called by the system whenever it wants to
resolve an intent that contains the data (so that it can look up the
Manifest file for the appropriate intent filter that contains that
MIME type).
So I guess if the argument of getType(..) is not a content URI that
you use in intents, then probably your "trick" is safe after all :-)
I don't know whether some Android folks know of other caveats that one
may like to take into consideration?
Peli
On Jan 15, 3:55 pm, Peli <peli0...@googlemail.com> wrote:
> > I can then pass around
> > Synchronisation information (validity, compatibility, version, status,
> > etc) using any of the ContentProvider class methods (I used getType
> > ()).
> Probably you should not mis-use getType(), even if all
> ContentProviders act in your own name space. The reason is that other
> applications (maybe a universal backup application?) may peek all
> content providers and call getType() if they are interested in what
> kind of content your content providers provide.
> Probably it is safer to use query() on different URI paths, as this
> can return whatever you define it to return - within your name space.
> > If I find more than one valid Content Provider I can then pass around
> > Synchronisation information (validity, compatibility, version, status,
> > etc) using any of the ContentProvider class methods (I used getType
> > ()).
> > The only problem with this approach is that the application developer
> > who imports my component (as a JAR) will have to define their own
> > custom Content Provider. This is done by extending the
> > MyComponentContentProvider class (from my JAR) and defining a
> > CONTENT_URI variable.
> > package test;
> > import com.whitemice.MyComponentContentProvider;
> > public class TheirContentProvider extends MyComponentContentProvider {
> > public static final Uri CONTENT_URI =
> > Uri.parse( "content://
> > myComponentNamespace.theirApplicaitonNamespace");
> > }
> > As well as adding the custom provider to the Android manifest.
> > Without the custom Content Provider configuration, Android will behave
> > strangely and sometimes call a different .APK file if it has a class
> > in it with the same name.
> > As this is a work time project, I will have to check if I can release
> > the synchronisation code as a working example. If I do it will appear
> > on my blog here:http://tinyurl.com/9hwdva
> > Regards
> > Mark
> > P.S. Thanks again everyone for your suggestions.
Generally I would recommend against hacky solutions that redefine the
semantics of very well-defined calls. It would be much better to just
define a standard structure of the content provider where this information
can be found be regular queries.
Along those same lines, looking for your own special text in the authority
to identify content providers you are going to work with is also kind-of
screwy. Typically how we do this is attach meta-data to the component that
whoever is interested in identifying specifically tagged components looks
for. Look at the way input method service components are discovered in
Cupcake as an example.
Also, have you thought about security at all? What kind of information is
stored on the content provider? Who can access it?
On Thu, Jan 15, 2009 at 8:36 AM, Peli <peli0...@googlemail.com> wrote:
> Hm...
> I assume, getType() is also called by the system whenever it wants to
> resolve an intent that contains the data (so that it can look up the
> Manifest file for the appropriate intent filter that contains that
> MIME type).
> So I guess if the argument of getType(..) is not a content URI that
> you use in intents, then probably your "trick" is safe after all :-)
> I don't know whether some Android folks know of other caveats that one
> may like to take into consideration?
> Peli
> On Jan 15, 3:55 pm, Peli <peli0...@googlemail.com> wrote:
> > Nice solution.
> > However, one point of critique:
> > > I can then pass around
> > > Synchronisation information (validity, compatibility, version, status,
> > > etc) using any of the ContentProvider class methods (I used getType
> > > ()).
> > Probably you should not mis-use getType(), even if all
> > ContentProviders act in your own name space. The reason is that other
> > applications (maybe a universal backup application?) may peek all
> > content providers and call getType() if they are interested in what
> > kind of content your content providers provide.
> > Probably it is safer to use query() on different URI paths, as this
> > can return whatever you define it to return - within your name space.
> > > If I find more than one valid Content Provider I can then pass around
> > > Synchronisation information (validity, compatibility, version, status,
> > > etc) using any of the ContentProvider class methods (I used getType
> > > ()).
> > > The only problem with this approach is that the application developer
> > > who imports my component (as a JAR) will have to define their own
> > > custom Content Provider. This is done by extending the
> > > MyComponentContentProvider class (from my JAR) and defining a
> > > CONTENT_URI variable.
> > > package test;
> > > import com.whitemice.MyComponentContentProvider;
> > > public class TheirContentProvider extends MyComponentContentProvider {
> > > public static final Uri CONTENT_URI =
> > > Uri.parse( "content://
> > > myComponentNamespace.theirApplicaitonNamespace");
> > > }
> > > As well as adding the custom provider to the Android manifest.
> > > Without the custom Content Provider configuration, Android will behave
> > > strangely and sometimes call a different .APK file if it has a class
> > > in it with the same name.
> > > As this is a work time project, I will have to check if I can release
> > > the synchronisation code as a working example. If I do it will appear
> > > on my blog here:http://tinyurl.com/9hwdva
> > > Regards
> > > Mark
> > > P.S. Thanks again everyone for your suggestions.
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
>>Peli - Probably you should not mis-use getType()…<<
I originally choose getType() for simplicity (URI in -> String out),
but I will now use query() instead. However, as my application is not
compatible with any other software (i.e. my data exchange has no MIME
type), I would be interested if anyone could provide a concrete
example of where an inappropriate getType() response might cause
problems.
Also, for simplicity I am not using intents.
>>Dianne Hackborn - ...Along those same lines, looking for your own special text in the authority to identify content providers you are going to work with is also kind-of screwy. Typically how we do this is attach meta-data to the component that whoever is interested in identifying specifically tagged components looks for. Look at the way input method service components are discovered in Cupcake as an example. <<
Here is a small component discovery rewrite, now using meta-data to
mark valid Content Providers:
####Java Code####
List<ProviderInfo> pis = androidContext.getPackageManager
().queryContentProviders(null, 0, PackageManager.GET_META_DATA);
...
for(ProviderInfo pi:pis) {
Bundle md = pi.metaData;
if (md != null &&
md.getString("type") != null &&
md.getString("type").equals("myComponentNamespace")) {
//Congratulations you have now found a valid Content Provider
//Note: keep looking as you might find more
}
}
The upside of this is that the application developer can now deploy my
Content Provider using any URI namespace they choose. However, I will
still recommend the previous naming scheme to prevent damaging naming
conflicts.
>>Dianne Hackborn - …Also, have you thought about security at all? What kind of information is stored on the content provider? Who can access it?<<
As I understand it, any cross application Content Provider on Android
needs to implement its own (i.e. roll-your-own) security solution when
handling incoming requests.
My current application (an advertising server) treats this as an open/
free to use API, with risk scenarios being managed mainly on the
server side.
My next application (component for peer-to-peer data sharing) will
require a custom Android Permission for sending data. This is similar
to the “android.permission.INTERNET” permission whereby the user still
gets a say as to whether the application can send data off the phone.
I am not yet confident enough in the security capabilities of Android
and/or my knowledge of them, to implement an application that handles
confidential data.
> The upside of this is that the application developer can now deploy my > Content Provider using any URI namespace they choose. However, I will > still recommend the previous naming scheme to prevent damaging naming > conflicts.
They should give their provider an authority that is in their own domain, as you are supposed to when writing your own providers. There is no need to change the convention here.
> >>Dianne Hackborn - …Also, have you thought about security at all? What > kind of information is stored on the content provider? Who can access it?<< > As I understand it, any cross application Content Provider on Android > needs to implement its own (i.e. roll-your-own) security solution when > handling incoming requests.
Usually they rely on the standard permission mechanism, though you can do more complicated stuff if you want.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
>>The meta data name is a global namespace to all applications, so you must
qualify it…<<
That’s how I understood it. “myComponentNamespace” is a shortened
camel case to represent a full application namespace. I renamed all
my code to anonymize our client and make my point easier to follow.
For example, my provider authority of
“myComponentNamespace.theirApplicaitonNamespace” is something like
“com.myclientscompany.example.projectname.platform.component.com.thirdparty company.applicationname”.
Thanks for pointing at the actual documentation, as it was sort of
buried.
>>Usually they rely on the standard permission mechanism, though you can do more complicated stuff if you want.<<
The standard permission mechanism is great for protecting the user
from bad applications, but not helpful for protecting an application
from a bad user. I will have to look at this in more detail when I
find myself implementing something that needs to be secure.
|
