That makes complete sense. I appreciate the advice. Mark
On Dec 16, 1: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 -~----------~----~----~----~------~----~------~--~---
