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. Would this sound like a suitable solution? Peli www.openintents.org www.openintents.biz On Jan 9, 10:54 am, whitemice <[email protected]> wrote: > 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 > > 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. > > Regards > Mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
