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 -~----------~----~----~----~------~----~------~--~---
