> What is "GetPackageContext" in your code? Is that just a typo and should be > "getPackageContext"?
Well, now don't I feel sheepish! It was indeed a typo, and the ever so helpful editor created a GetPackageContext for me and returned null. Sorry about wasting your time. As for your other suggestion about using a broadcast to get the data, that does seem like a good idea. In fact, the widget itself uses a broadcast intent when the user click on it to get the next set of data to display. I assume that I could send that broadcast to my main app just as easily as it does to the Widget app. Thanks for the help and suggestions. On Jan 16, 5:57 pm, Dianne Hackborn <[email protected]> wrote: > On Sun, Jan 16, 2011 at 5:19 PM, John Gaby <[email protected]> wrote: > > The following is the routine that I wrote to test the function. The > > call to manager.getPackageInfo works, but the call to > > GetPackageContents returns null. > > What is "GetPackageContext" in your code? Is that just a typo and should be > "getPackageContext"? > > > I actually tend to agree, but I really hate to force the user to > > install the app to internal memory (there is a fair amount of > > content). The feedback I have gotten so far from the users that I > > have asked is that they would rather see a separate app than loose the > > ability to install on the SD card. Is there ANY other way to deal > > with this? > > Well for transferring data between apps, I will say the same thing I already > have: I would very much recommend using a receiver, service, or content > provider. Don't use shared user IDs. Your widget could just for example > send a broadcast to your app when it needs to populate data. As a bonus, > your main app could be the one in charge of the data and send a broadcast to > the widget app when it has changed to give it the new data. I think you'll > find this a much cleaner solution than trying to directly access data files. > > At any rate, offering your users a small add-on app that they can optionally > download to provide a widget is probably not too bad I guess. Heck you > could turn it into an advantage and make it paid so it is an additional > feature they can purchase for your app. ;) > > But I do think you should architect it so that the interaction between these > pieces is through app components, not data. It will result in a much > cleaner and more maintainable design. > > -- > 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
