thanks mark. my answer is what you'd expect. i thought it would make the app most modular. your approach would have been better. in retrospect, the use case for "tabs as activities" is probably only to allow someone to quickly stick an existing, stand alone activity in a tab. for some reason inflater is never intuitive to me.
to get around this i ended up moving the initialization code out of onCreate(), adding a listener for tab change, and sending a message to initialize the activities separately. another problem with the "tabs as activities" approach is that in general i have quite a lot of code dedicated to communciation between the tab activity and the tabs' activities. On Sun, Oct 4, 2009 at 5:48 AM, Mark Murphy <[email protected]> wrote: > Frankly, I have yet to figure out what that sex appeal is of putting > activities in tabs. AFAICT, it results in more fragile code. If you need > the same things to be in a tab *and* in a separate activity, reuse the > inflation and view logic between a standalone activity and just using the > View for a tab's contents. All the tabs-as-activities code seems to do is > launch the activity, then rip the root view out of that activity and put > it in the tab. > > So, if you really want control over what happens when, I'd skip the > tabs-as-activities approach, and just put ordinary views in the tabs. > > But, that's just me. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com > Android App Developer Books: http://commonsware.com/books.html > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Beginners" 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-beginners?hl=en -~----------~----~----~----~------~----~------~--~---
