I suppose if something is an "activity" it can be replaced with another component "activity" and thereby promising a certain amount of openness where it is applicable through intents etc..
On Wed, Dec 17, 2008 at 1:17 AM, Eric Chan <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
