Diane (Hackborn), you posted the following: Since activities are the things that interact with the user, they are the only things that can directly show UI. The Application class exists because my arms were twisted into making it. There is nothing actually all that useful about it, as far as I am concerned. ;)
We have several proxy interfaces where we make calls to backend services -- I thought a specialized extension of Application would be useful to hold these proxies as well as a client interface where we make the call, to reduce the number of objects being created and cutting down on Garbage Collection. A singleton if you will. Is this an erroneous assumption? I also was using the Application as a location to fire off a thread to load globally accessible data needed by the application -- should I move these into an Activity and store the data in the sqllite? It seems like a lot more work to store them in a database if I'm just going to query them the next time the app pulls them down. I plan to write a mechanism to sync the data to local sqllite in the future, I'm just short on time. I'm currently running into a problem where I'm getting an NPE back from a subsequent activity where this data is not found--even though I saw it being loaded in my Application subclass and stored there. Weird. Brian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
