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.
> >
> > Peliwww.openintents.org
> >
> > On Jan 15, 2:05 pm, whitemice <markbr...@zedray.co.uk> wrote:
> >
> > > Solution
> > > The simplest solution (not using intents) is to instruct each user of
> > > my component to define a new content provider:
> >
> > > content://myComponentNamespace.theirApplicaitonNamespace
> >
> > > Android lets me search through all available content providers, which
> > > can be string matched to my own component namespace.
> >
> > > context.getPackageManager().queryContentProviders(null, 0, 0);
> >
> > > 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.
> >
> > > <provider
> > > android:name="test.TheirContentProvider"
> >
> > >
> android:authorities="test.service.TestContentProvider.TestAndroidContentProvider"
> > > />
> >
> > > 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.
> >
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
