> > I'm not a fan of handling the various life cycle events for different > activities.
You better get used to this. It's a key aspect of Android. > I've not figured out yet if you absolutely must use different activities > for different views, or can you use a single activity and simply swap views > as needed? No, you don't HAVE to use different activities and as Sam mentions you can use a ViewFlipper. Personally, however, I would recommend using the ViewFlipper when you need a different way of looking at the same thing in the activity and not as a means of replacing multiple activities. > I ask this because it seems to me that at any point, the user may be in any > one of your activities.. and I hate the idea of having to implement the > pause/resume/create/start/destory methods for each and every activity. You don't have to implement EVERY SINGLE one of these, only the ones that make sense for you particular activity. > I am curious what developers do in this regard. Do they actually copy/paste > their code into each method for all their activities.. of course putting > activity specific stuff where appropriate? Personally, I don't copy and past any of those functions, I implement the ones I need when I need them. > Seems to me using a single activity as the main app lifecycle hook, and > simply swapping views would make it easier to manage life cycle events for > the app in one place. Not really. Unless you're doing something extremely trivial, I'm sure you will find that eventually managing the state of your one activity will get out of hand. If you do as you suggest and implement a single set of lifecycle methods you'll be doing a lot of checks in them all to determine what state you're in and what needs to be done in each. Saving and restoring your current state in particular will probably get way out of hand using this strategy. Perhaps I am lost on why it is necessary to have various activities.. Multiple activities make it easier to break your app apart into logical, functional units where each one does ONE thing (it's "activity") and allows you to focus on doing that one thing. Trying to force all of your functionality into one activity will, I assure you, grow into an unmaintainable mess as you continue to add more functionality to your one activity. Also, using multiple activities plays right into the default back-button behavior. If you use one activity to manage multiple views you will either have implement this logic yourself (overriding the back key to undo your actions) which adds even more complexity to your massive be-all Activity or ignore this behavior completely and allow your app to exit without going back through the sequence of views (which will confuse your users who will expect to be going back to a previous view when hitting the back button). > my main concern being duplication of the life cycle handling events > depending on where a user is within your app. I would recommend you focus on building reusable components that work with the Android platform and not against it. There should be minimal duplication in the strictest sense as each of your Activities will theoretically be quite different and have different needs as far as which methods need to be implemented and what happens in them. My $0.02. Hope that helps. ------------------------------------------------------------------------------------------------- TreKing - Chicago transit tracking app for Android-powered devices http://sites.google.com/site/rezmobileapps/treking
-- 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
