You suggestion (of which I was aware) only handles some of the issues. I was including your technique under the heading of "downloading a separate .apk".
However, in the current world, it's a valuable technique, and I should have covered its limitations a bit more explicitly. Let's say I have a paid core app. Let's say you have an extension for my app. The user downloads your app, and pays for it. Then, a day later, he gets around to trying it. Now your app takes him back to the marketplace. More money? No. You didn't tell me that, that's not right! (Maybe you DID tell him; maybe you didn't have room to explain it well enough -- and it ate into the space needed to explain YOUR app). So now he uninstalls your app. And can't get his money back, and leaves all sorts of negative comments. So now you're both screwed. This is a problem even for free apps. If the transaction gets split up, it won't be successful a lot of the time. Users will be annoyed. There's not space in the market descriptions to explain what's going on at time of download. By the time they actually download, there can be version skew. Later, he uninstalls the service app, not realizing it's needed. Now your app breaks. Let's say you start a service on bootup or some other broadcast intent. Just when do you report that your app is broken? Sure, the fix is to re-download the service app, but the only time it's really reasonable to do that is on launching an activity. And providing .apks for download that don't actually have a launcher icon, or that don't actually provide any user functionality, presents its own set of problems. Your approach primarily is a way of easing the user into the manual step. I see the very existence of that manual step at that point in the process as being a major problem. I've only encountered your technique being used once. It actually rather startled me -- I've encountered quite a number of cases where it SHOULD be used. This argues that the mere existence of your technique isn't sufficient to solve the problem. The problem is, it requires too much of the programmer, to discover and implement. This is really something that should be a documented part of the SDK, in whatever form it takes. This would help ensure a consistent user experience and more consistent implementation. Even if it's just your technique, adopting it as part of the SDK would help. But as I outlined above, it's an inadequate workaround. On Apr 17, 4:16 am, Mark Murphy <[email protected]> wrote: > Bob Kerns wrote: > > If I have a service used by > > several applications, I currently have to supply it in every > > application, and arrange to negotiate just which one actually provides > > the service. > > That's not the only option -- see below. > > > The alternative, of a separate APK is prohibitive because it depends > > on the user seeing the dependency, understanding what to do about it, > > and taking action. > > Those three steps can be handled by the application that has the dependency. > > If your application requires other capabilities: > > -- use PackageManager to see if the required component is there > > -- if not, pop up a dialog saying that you need to download/install the > dependency before you can continue (or before certain features are enabled) > > -- start up the relevant Market Uri, or download and kick off the > installation yourself, depending on how the component is distributed > > > However, if we could declare in our manifest that a package *requires* > > package, and the Market handled this, most of our problems would be > > solved. > > It would certainly solve all of the above problems, and related ones > (e.g., uninstalling no-longer-needed applications once whatever depended > on them is uninstalled, warning a user if they try to uninstall > something that somebody else depends upon). I suspect it will introduce > new and exciting problems, but that remains to be seen. > > FWIW, I suggested this about a year ago and the notion was squashed. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android Training...At Your Office:http://commonsware.com/training > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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
