how to make a complex tabbed app with views

2018-06-02 23:10:02

First question on Stack Overflow, apologies if it is not well formed.

I am developing a relatively complex tabbed app, and already had the basics set up before coming across information that ActivityGroup and TabActivity are deprecated, and the preferred model is to use views.

I have had no trouble using views, this is a question about architecture rather than syntax (which is why I haven't posted any code). Specifically, how should I go about restructuring the app to use views instead of Intent launched Activities.

The app has five tabs; two hold a single layout, no problem there. The other three tabs are running an ActivityGroup with 2-5 different Activities (ie a tab running an activity for settings, where clicking each view starts a new Activity dealing that particular setting, pressing the back button returns you to the broader settings activity/view). If I were to keep each Tab as a TabActivity, it would still be fairly easy to change those internal transitions to views as opposed to separate Activities.

The main question is using ONLY views, no TabActivity/Activity group at all. The vast majority of the research I've done has been discussion about whether to use Activities or Views, or about specific syntax. I haven't been able to gather a clear idea of how to actually MAKE the transition to views across the whole application.

If I were to do so, wouldn't the entire app now be running in a single Activity - the one hosting the tabbed layout?

If (1) is true, how to manage this? Despite ActivityGroup being deprecated, all of the Android documentation still seems to state that it is preferred to use separate Activities for separate aspects of functionality--which makes sense. Did the Android development team simply decide that the costs to the stack and the device made the TabActivity implementation ineffective?

If the application is running in a single Activity that manages different views for each tab (and then different views WITHIN a tab when necessary), should I have one single enormous onClick method to handle all clicks from any clickable view, handling input based on which view is active? Or should I register and de-register all of my Listeners programatically?

With a single Activity, won't any click listener or any broadcast receiver be running all of the time, consuming resources even when unnecessary?

With a single Activity, the back button would exit the entire app from any point in its functionality. If I am using views, won't I have to consistently override onBackPressed() and carefully manage the app behavior to force it to behave "like an Android app?"

AM I THINKING ABOUT THIS COMPLETELY WRONG? It's possible that I am unintentionally attempting to recreate ActivityGroup and TabActivity functionality using views instead, when I should be taking an entirely different design approach to using tabs and Views.

When the people at Google say we shouldn't use activities as tabs anymore, and Mr. Mark Murphy so emphatically agrees, I'm inclined to believe. I simply haven't been able to research-up a way to switch without resorting to recreating a lot of Activity functionality by hand (which would probably include a variety of dirty hacks).

Appreciation in advance for anyone willing to tackle such a vague and overwritten topic.

Using Fragments is the new standard for performing tabbed style ui components, I think you must have just overlooked them because they are the missing piece to all your above questions. Good luck.

Don't forget that using the compatibility library brings Fragment support all the way back to 1.6.

And here is an easy Google recommended tutorial on using Fragments within a TabHost.

About 3) Split your app in as many Activities as you have different parts of the app. Today I'd even go for Fragements that can be easier composed to different layouts when you eg make the app for Phone and Tablet. Most of the time, you can just set up the onClick listeners in the respective xml layout definition files like this:

<ImageButton
    android:id="@+id/new_tweet_back_button"
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:layout_gravity="left"
    android:onClick="done"
    android:src="@drawable/back_button"
    android:layout_below="@id/CharCount"
        />

Here the android:onClick attribute points to a method that implements the handler. You don't need to de-register anything.

And instead of Tabs I'd go for the ViewPager which makes imo a much more natural experience with just swapping views by swiping left and right (see eg G+ app or market app)

As a final answer to my own question:

Using fragments in tabs DID solve all of the above issue.

So, instead of an Activity defining tabs containing other Activities, I have one large FragmentActivity that sets up and switches the views of the various fragments. The click methods defined in the XML for each tab view belong to the FragmentActivity, and I opted to have each onClick call a corresponding method in the appropriate fragment (passing a context if necessary) so the code for manipulating each view programatically can stay in the appropriate class.

THIS IS FOR A PHONE USING THE COMPATIBILITY PACKAGE, not a tablet or Honeycomb, so I can't speak for those unfortunately.

This solution seems to have worked well for me. I recommend anyone looking at the same issue to check out:

thepsuedocoder blog post: http://thepseudocoder.wordpress.com/2011/10/04/android-tabs-the-fragment-way/

Android documentation on Fragments: http://developer.android.com/guide/topics/fundamentals/fragments.html

The API demo "Fragment Tabs" http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/index.html#Fragment

链接地址: http://www.djcxy.com/p/10392.html

上一篇: ORACLE函数MONTHS的模拟

下一篇: 如何制作带有视图的复杂标签式应用