Thanks for the additional feedback.
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
Thanks for the additional feedback.
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
On Fri, Jan 16, 2009 at 2:43 AM, whitemice markbr...@zedray.co.uk wrote:
provider
android:name=test.TheirContentProvider
android:authorities=myComponentNamespace.theirApplicaitonNamespace
meta-data android:name=type android:value=myComponentNamespace/
/provider
The meta data name
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
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
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
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
Thanks everyone for the replies:
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
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
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
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
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
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
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
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
15 matches
Mail list logo
