Just curious, why was the Activity inside TabActivity functionality introduced into the SDK, if it's such as bad idea?
This option not only seems like the main culprit of stock overflow errors in an Android app, but it adds significant complexity to the SDK, both API and implementation-wise. For example, even in the 2.1 SDK (not sure about 2.2), managed dialog states are not properly preserved when you have activities inside activities. That bug alone made me completely abandon managed dialogs. On Jun 21, 9:48 am, schwiz <[email protected]> wrote: > Thanks for the advice on the activities Mark I will definitely keep > that in mine unfortunately all of the activities need access to a > service and need to stand alone but you have given me some things to > think about maybe its time to start refactoring. The getParent thing > worked I actually thought of it whilst sitting in the movie theater > today and couldn't wait till I got home to try it :P BTW I saw two of > your books on the shelf at Barnes and Noble today :) > On Jun 20, 10:25 am, Mark Murphy <[email protected]> wrote: > > > > > On Sun, Jun 20, 2010 at 11:08 AM, schwiz <[email protected]> wrote: > > > thanks for the suggestions mark but my app is way to complicated to > > > keep all of my logic in one activity which is why I have it separated > > > into separate activities with the tabs. > > > Do not use Activity as simply a means of code organization. You waste > > RAM, increase the odds you will run into stack-overflow errors via > > your use of activities in tabs, and so forth. > > > > It was also an additional > > > requirement of my client to have some of the activities I made > > > separate like that so they can reuse them in other apps. > > > Just because some collection of code *can* be used as an Activity *in > > some cases* does not mean it has to *always be used as an Activity*. > > For example, you could use a custom View class, reused as a tab in one > > setting and as the main content view of an Activity in another > > setting. > > > > All I really > > > want to intercept is the menu button > > > I suspect that may be intercepted by the framework between TabActivity > > and your child Activities, because it is expecting to delegate that to > > the currently-active child Activity via the normal option menu > > methods. That is just a guess, though. > > > You could try intercepting the key in the child Activities. Then, if > > getParent() is not null, they know they are children in the > > TabActivity and can call some method on that TabActivity. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > _The Busy Coder's Guide to Android Development_ Version 3.1 > > Available!- Hide quoted text - > > - Show quoted text - -- 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
