On Tue, May 29, 2012 at 6:38 PM, Jason Teagle <teagle.ja...@gmail.com> wrote: > (To the OP) > > I may be missing something here, but why do you use a cached reference to > package B's context?
A is the actual application, B is a data disk, expansion or whatever you call it. A needs to be able to access files in B just as its own, through an appropriate Context. > I believe you said that trying to grab the context after B has been > uninstalled fails, as expected - so why not use this as a test to see > whether A should be allowed to go ahead and use those assets? Why not try > and grab B's context afresh each time you want to access the files, and > avoid trying to do so if the grab fails? You could do that but why would you? Polling seems wasteful if you can get an interrupt when the important event (package B's uninstall) happens. I don't see what polling would buy you over just subscribing to Intent.ACTION_PACKAGE_REMOVED. > Presumably if A is already using those assets while B is being uninstalled, > you wouldn't want the code to just die - package A should at least be > allowed to finish what it was doing; and if it is hogging those assets for a > long period of time... that sounds like an area that could do with a little > reconsideration as well. I'm afraid you lost me here. The idea was, if it were guaranteed the package B stays intact as long as A holds its Context, A wouldn't be forced to handle the uninstall whenever it comes and could wait for a more suitable and safe moment to flush B's resources and drop its Context. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
