On Sun, Aug 29, 2010 at 5:17 PM, Bob Kerns <[email protected]> wrote: > There is no reasonable way, that does not impose an unacceptable > burden on users, to distribute an app that makes use of third party > functionality like this that should live in its own .apk. >
How is bump's functionality as a separate .apk an unacceptable burden? It does mean the user would need to install a separate app if they want to use that functionality... but it should be very easy for the original app to explain it needs this (when they want to use the functionality), clearly associates that functionality with the bump developer (who btw gets some nice branding there), and also allows bump to upgrade their client code without having to get all of their app authors to update each app. > And even if there were -- it does not solve the problem -- it just > associates it with the third-party app. And that's bad, actually. It > gives the user the option of not including that app, which makes > things MORE complex for the user, and opens up the possibility of > leading to broken situations. > It also introduces the equivalent of DLL hell. Please tell me you > don't want to go there! > We have been avoiding standard general shared library support partly because we don't want to have DLL hell. (Also because the security implications are nasty.) However, when you implement things as separate .apks, I think this is much less an issue. If you aren't doing something extremely loosely coupled like intent protocols, I think the interaction you will have between the two pieces of code will by nature be much less tightly bound than with shared libraries. It just doesn't lend itself to a large surface area API with a lot of subtleties in interaction. It's more like client/server interaction like APIs published by Facebook and other web services. (A corollary is that this approach is not going to work for every case where you use shared libraries... but what I have been observing is that in a lot of the cases where some third party is providing a piece of functionality that is not core to the app using it, this can work quite nicely.) > I really do think that optional permissions, which are requested IN > THE CONTEXT OF THE NEED are very much the way to go. They are simpler > for users to understand. This is how Apple does it, and while it does > have its drawbacks, it is far less mysterious. > I'm curious, what is this example of how Apple does it? Yes there is the location thing, which as I've said is probably an exception that should have per-app control for the user. What else? Having apps ask you to enter your password to log in as admin in MacOS X? > But the current situation is not where we want to be! > The current approach is I believe a strong improvement over what has gone before. Things can always be improved more. The question is how that should be done, and what are all of the repercussions (especially unintended ones) that fall out from it. -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. 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 [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
