[android-developers] Re: Recommended uses of a class extending android.app.Application
I store my application config data in preferences: http://developer.android.com/guide/topics/data/data-storage.html#pref And have a singleton class to read and write (aka wrap) them. That way it is also maintained even if the application is killed. On Sep 11, 8:21 pm, Tom Gibara m...@tomgibara.com wrote: I hesitate to raise a word against any of Dianne's advice (ever) - and it clearly depends on the nature of your application. But what I find with my code is that most of the global state I want to keep depends on a Context. For example, anything that loads resources, or anything that needs to generate user readable messages. As a consequence I end up with a number of 'helper' classes that hold a reference to a context so that they can do their work. I find that the Application instance is the obvious context for these helpers. Furthermore, a specialization of the Application class seems the natural place for application code to access these objects, since the Application can instantiate them with itself (eagerly in onCreate or lazily behind accessors). Tom 2009/9/11 Dianne Hackborn hack...@android.com On Fri, Sep 11, 2009 at 8:10 AM, Mark Murphy mmur...@commonsware.comwrote: The four main options I have used are: 1. Custom application class, like you are proposing 2. Static data (e.g., singleton class instance holding your configuration) 3. A service 4. Shared preferences Best is somewhat subjective -- I certainly do not have a definitive always use X recommendation. There isn't a best, it's very much dependent on what semantics you want -- shared preferences will remain after the process is gone, a service's state is tied to the process but tells the system to try to keep the process around, and Application and static data are tied directly to the lifetime of the process and allow the system to remove them without guilt when the process isn't in active use. (So Application and static are redundant, and static data lets you better modularize your code instead of stuffing everything in to Application, which is why I recommend statics.) -- Dianne Hackborn Android framework engineer hack...@android.com 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 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 -~--~~~~--~~--~--~---
[android-developers] Re: Recommended uses of a class extending android.app.Application
Android Development wrote: The docs here: http://developer.android.com/reference/android/app/Application.html say that, if the application needs to maintain global state, it should do it here. On the other hand, Ms. Hackborn has indicated that she thinks the Application object is not that useful and has recommended simple static data members as an alternative. Suppose, i need to load some configurable data from a config file (to be used later at runtime by my application's various components). This data will be valid throughout the application's lifecycle (until it dies). So, is it the best approach to extend this class and override the onCreate ( ) method to load config data from a data source ? The four main options I have used are: 1. Custom application class, like you are proposing 2. Static data (e.g., singleton class instance holding your configuration) 3. A service 4. Shared preferences Best is somewhat subjective -- I certainly do not have a definitive always use X recommendation. If it is a simple configuration file, I'd be inclined to go with the static singleton class instance if the configuration is not user-managed, SharedPreferences otherwise. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Need help for your Android OSS project? http://wiki.andmob.org/hado --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Recommended uses of a class extending android.app.Application
I think it's more accurate to say *you may choose* to maintain global state by extending Application. It's my preferred approach, though it's important to to instantiate global state lazily wherever it's sensible to do so. I describe my default approach here: http://blog.tomgibara.com/post/126377651/global-application-state-in-android 2009/9/11 Android Development indodr...@gmail.com Hello, The docs here: http://developer.android.com/reference/android/app/Application.html say that, if the application needs to maintain global state, it should do it here. Suppose, i need to load some configurable data from a config file (to be used later at runtime by my application's various components). This data will be valid throughout the application's lifecycle (until it dies). So, is it the best approach to extend this class and override the onCreate ( ) method to load config data from a data source ? Thanks in advance.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Recommended uses of a class extending android.app.Application
Thanks for the replies. The data is hidden from the human user and is totally consumed by the application. Its a small file..some 4-5 attributes only. I am also somewhat inclined towards using a static singleton option. On Fri, Sep 11, 2009 at 8:43 PM, Tom Gibara m...@tomgibara.com wrote: I think it's more accurate to say *you may choose* to maintain global state by extending Application. It's my preferred approach, though it's important to to instantiate global state lazily wherever it's sensible to do so. I describe my default approach here: http://blog.tomgibara.com/post/126377651/global-application-state-in-android 2009/9/11 Android Development indodr...@gmail.com Hello, The docs here: http://developer.android.com/reference/android/app/Application.html say that, if the application needs to maintain global state, it should do it here. Suppose, i need to load some configurable data from a config file (to be used later at runtime by my application's various components). This data will be valid throughout the application's lifecycle (until it dies). So, is it the best approach to extend this class and override the onCreate ( ) method to load config data from a data source ? Thanks in advance.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Recommended uses of a class extending android.app.Application
On Fri, Sep 11, 2009 at 8:10 AM, Mark Murphy mmur...@commonsware.comwrote: The four main options I have used are: 1. Custom application class, like you are proposing 2. Static data (e.g., singleton class instance holding your configuration) 3. A service 4. Shared preferences Best is somewhat subjective -- I certainly do not have a definitive always use X recommendation. There isn't a best, it's very much dependent on what semantics you want -- shared preferences will remain after the process is gone, a service's state is tied to the process but tells the system to try to keep the process around, and Application and static data are tied directly to the lifetime of the process and allow the system to remove them without guilt when the process isn't in active use. (So Application and static are redundant, and static data lets you better modularize your code instead of stuffing everything in to Application, which is why I recommend statics.) -- Dianne Hackborn Android framework engineer hack...@android.com 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 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 -~--~~~~--~~--~--~---
[android-developers] Re: Recommended uses of a class extending android.app.Application
I hesitate to raise a word against any of Dianne's advice (ever) - and it clearly depends on the nature of your application. But what I find with my code is that most of the global state I want to keep depends on a Context. For example, anything that loads resources, or anything that needs to generate user readable messages. As a consequence I end up with a number of 'helper' classes that hold a reference to a context so that they can do their work. I find that the Application instance is the obvious context for these helpers. Furthermore, a specialization of the Application class seems the natural place for application code to access these objects, since the Application can instantiate them with itself (eagerly in onCreate or lazily behind accessors). Tom 2009/9/11 Dianne Hackborn hack...@android.com On Fri, Sep 11, 2009 at 8:10 AM, Mark Murphy mmur...@commonsware.comwrote: The four main options I have used are: 1. Custom application class, like you are proposing 2. Static data (e.g., singleton class instance holding your configuration) 3. A service 4. Shared preferences Best is somewhat subjective -- I certainly do not have a definitive always use X recommendation. There isn't a best, it's very much dependent on what semantics you want -- shared preferences will remain after the process is gone, a service's state is tied to the process but tells the system to try to keep the process around, and Application and static data are tied directly to the lifetime of the process and allow the system to remove them without guilt when the process isn't in active use. (So Application and static are redundant, and static data lets you better modularize your code instead of stuffing everything in to Application, which is why I recommend statics.) -- Dianne Hackborn Android framework engineer hack...@android.com 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 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 -~--~~~~--~~--~--~---
