Just to reiterate what TreKing says: you *could* build your app using just a ViewFlipper, but I think you're kicking against the platform if you try to avoid multiple Activities, and you may wind up reinventing a lot of Activity features -- especially as your app gets more complex than what you started out with.
To me (coming from Qt S60 development where you have a main.cpp, and classes such as QMainWindow or QWidget) the Activity/Service/Intent/ Content Provider framework feels like a natural fit for mobile development. Mobile apps are more different from desktop or web apps than I initially thought! Sam On Jan 18, 6:35 am, TreKing <treking...@gmail.com> wrote: > > 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 > deviceshttp://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 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
