lol, I always argue with my mates about use activity or multiple layout views. We follow this, if menu changes with screen changes, use the activity, else employ multiple layout views
2008/12/17 Dianne Hackborn <[email protected]> > We are just arguing semantics here. Yes, there are times when it makes > sense to start a new activity and times when it makes sense to change the UI > in an existing one. I'm not going to give you The Rule for when these times > are. That is part of designing your UI, keeping in mind the basic activity > model where they stack on top of each other and the user presses back to > return to the previous. If that is not how you want flow to happen between > parts of your UI (and you don't need to allow external applications to > directly launch these parts of it), then it may well make perfect sense to > do a set of things within one activity. > > As Romain said, we called the class Activity and not Screen for good > reason, which I was very involved in arguing about at the time the API names > were being settled. :) > > > On Tue, Dec 16, 2008 at 12:57 PM, loty <[email protected]> wrote: > >> >> Cool - I guess we were arguing on the same side of things. :) >> I definitely saw this in API docs somewhere and Diane just repeated it >> too that general rule of thumb should be new Activity for new screen >> and I just think that as a general rule of thumb you probably don't >> want to have new Activity for each new screen. It sounds like one of >> these rules that is meant to be broken... >> >> On Dec 16, 3:17 pm, Romain Guy <[email protected]> wrote: >> > We never said every screen has to be an Activity (that's why it's >> > called Activity and not Screen :)). Calendar is a good example of >> > this, when you switch between the Day view to the Week view, you >> > remain in the same activity for instance. >> > >> > Again, it is perfectly sound to flip views inside one Activity, if it >> > makes sense in the user's workflow. Similarly, it is perfectly sound >> > to use several Activities, if it makes sense in the user's workflow. >> > >> > The Calendar app is again a good example of when not to use >> > Activities. The Activity is viewing your agenda, but you can view it >> > in different ways (day, week, month, etc.) and those become simply >> > states of the activity. >> > >> > >> > >> > On Tue, Dec 16, 2008 at 9:04 PM, loty <[email protected]> wrote: >> > >> > > 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >> 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 >> > >> >> > [email protected] >> > >> > >> >> > 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 >> > >> > [email protected] >> > >> > >> > 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 >> > >> [email protected] >> > >> > >> 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 >> > [email protected] >> > >> > 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 > [email protected] > > > 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. > > > > > -- Best Regards Eric Chan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
