Each Activity carries a lot of baggage like state management, etc which is not always applicable. I started my first Android app like a good boy from the Notepad example and very soon had a spaghetti of Activities. It got to the point that I had to click Back button 6 or 7 times to get back to my main screen - clearly an awful design (mostly mine maybe with some guilt spilling to Android team as well). I redone my app with just 2 Activities and view flipping and couldn't be happier. Activity is NOT a new screen - activity is as the name suggests an 'Activity'. User has to clearly start doing something different for it to be justifiably new activity. At least this is my view on things.
On Dec 16, 2:14 pm, Romain Guy <romain...@google.com> wrote: > Thanks Dianne, I should have been clearer: it is indeed perfectly fine > to switch between Views, there are good reasons to do so. But > replacing the Activity model is not a good one. > > One thing is certain, it is wrong to think that it would be an > optimization. Like I said, it will only slow down your application's > startup time, use more memory, slow down layout and drawing, etc. > > As for relying on the system to kill other apps, it's not a good > approach either. You are simply causing a disservice to the user for > absolutely no good reason. > > Please instead explain why you don't want to use the Activity model so > we can either explain it better or improve it. > > > > On Tue, Dec 16, 2008 at 8:02 PM, Dianne Hackborn <hack...@android.com> wrote: > > There is nothing intrinsically right or wrong with either approach. It is > > just as wrong to say that you shouldn't use the activity model for your UI, > > as it is to say that you should never switch between multiple views in the > > same activity. > > > For the issue Romain is addressing, I would agree that it is generally wrong > > to decide that you don't want to deal with multiple activities even though > > you want your application to have the same behavior as if it did, but just > > don't want to deal with them. All you'll end up doing is making any > > application that tries to behave consistently with others, but doesn't > > quite. > > > Also if you go off into the woods with your own UI management inside of a > > single activity, you are going to lose a lot of the things the framework > > does for you: you will need to do your own state saving and restoring for > > whatever additional stuff you have in your UI so that the user will > > correctly return to it, do your own handling of back, and decide when to > > reset back to the root state and when not. > > > So there are certainly situations where it makes sense to switch between > > views in an activity: heck, there is sample code for this such as in the tab > > demos. A good general rule of thumb is that if the user is navigating to > > what they perceive to be a new screen, it should be expressed as an > > activity, and if they are switching between related views in the same screen > > is can often make sense to do that all in one activity. > > > On Tue, Dec 16, 2008 at 9:50 AM, loty <lev.pert...@gmail.com> wrote: > > >> I'm actually on the same page with Mark. To me Android's history > >> mechanism is more of a hassle than a benefit especially if you use > >> view=activity anathema. Personally I found that views inflating is not > >> that slow at all. I didn't measure memory footprint of my applications > >> but Hey, let Android swap some other application out if my app needs > >> more RAM :) At least I won't have to bother with endless activities > >> nightmare. > >> Perhaps I should look into FrameLayout more closely. > > >> On Dec 16, 12:14 pm, Romain Guy <romain...@google.com> wrote: > >> > Such an approach would be very inefficient for several reasons. First > >> > of all it requires to inflate many resources that won't be needed > >> > right away, which will slow down your application startup time. It > >> > will also increase memory usage. Then you will defeat the history > >> > mechanism built in Android, thus forcing you to implement the back > >> > yourself, and everything it entails. It's a lot more work for you, and > >> > you will probably end up having a user experience that feels like > >> > other Android apps but not quite. > > >> > What performance issue are you trying to solve? > > >> > On Tue, Dec 16, 2008 at 6:01 PM, Mark <mark.nuetzm...@gmail.com> wrote: > > >> > > Would there be an advantage of using multiple Activity classes each > >> > > with their own primary layout as opposed to creating multiple layout > >> > > views and stacking them into FrameLayout? One of the things I > >> > > currently do in my WM development that has worked very well in terms > >> > > of performance is to create multiple layers for a form and then show > >> > > or hide the layers based on what the user is doing. I could see using > >> > > the FrameLayout class to stack multiple other layouts that would > >> > > provide the same capabilities. This would allow me to use a single > >> > > Activity to wrap what I need rather than creating multiple Activities. > > >> > > thanks, > >> > > Mark > > >> > -- > >> > Romain Guy > >> > Android framework engineer > >> > romain...@android.com > > >> > Note: please don't send private questions to me, as I don't have time > >> > to provide private support. All such questions should be posted on > >> > public forums, where I and others can see and answer them > > > -- > > 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. All such questions should be posted on public > > forums, where I and others can see and answer them. > > -- > Romain Guy > Android framework engineer > romain...@android.com > > Note: please don't send private questions to me, as I don't have time > to provide private support. 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 -~----------~----~----~----~------~----~------~--~---
