It can be said that the bottom navigation bar in android applications is very common. For example, Sina Weibo, WeChat, etc. are all designed in this way. The first reaction of everyone in this application is to use TabActivity. Today I will share how to use ActivityGroup instead. TabActivity, and the advantages of such use.
ActivityGroup is a very good API provided by Google, and TabActivity is the only subclass of ActivityGroup.
Advantages of ActivityGroup
First of all, let's talk about the excellence of ActivityGroup and its necessity. It provides a possibility for developers. This possibility does not present Activity as the top element of the screen (Context), but embeds it in ActivityGroup. This is a great leap. It subdivides the scene (Context). ActivityGroup is a main scene, and users can switch between desired sub scenes through the navigation buttons. If you use the Weibo function, it is a rather grand scene, with sub-scenes such as watching the latest broadcast information, posting your own Weibo, and modifying information. The user can switch to the desired sub-scene by pressing the button, and this sub-scene is still Activities in the main scene. Let a main scene have multiple logic processing modules, the main scene is no longer responsible for the sub-scene logic, the main scene is only responsible for the logic of switching scenes, that is, each activity (sub-scene) has a logic processing module, and an ActivityGroup has multiple activities , But does not interfere with the logic of Activity, which undoubtedly subdivides and modularizes the logic code. ActivityGroup and the functions to be implemented by the Activity it will be embedded can be completed with only one Activity, you can imagine, when you put an ActivityGroup and the logic code of the Activity it owns in an Activity, then this Activity will How many lines of code you have is very inconvenient for maintenance.
Shortcomings of TabActivity
Let’s talk about the shortcomings of TabActivity. First of all, TabActivity’s own unique view is hardly used (that is, the ugly tab button form), and most of the features used by developers are almost inherited from ActivityGroup. There is also the mandatory dependency of TabActivity. Its layout file must use TabHost as the root tag, and the id must be "@android:id/tabhost", there must be a TabWidget tag, and its id must be "@android:id/ tabs", and the View container that loads the Activity, the id must be @android:id/tabcontent. I don't feel very comfortable just to enforce dependencies. And after android3.0, it has been suggested to use Fragment instead of TabActivity. It's just that in order to be compatible with versions before 3.0, Fragment has not been popularized by developers.
Let's take a look at the main page architecture implemented by ActivityGroup after the reconstruction of the food library:
MainActivityGroup.java
public class MainActivityGroup extends ActivityGroup implements
OnCheckedChangeListener {
private static final String RECORD = "record";
private static final String CATEGORY = "category";
private static final String MORE = "more";
private ActivityGroupManager manager = null;
private FrameLayout container = null;
private RadioGroup radioGroup;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.test_main);
initView();
}
private void initView() {
radioGroup = (RadioGroup) findViewById(R.id.main_radio);
radioGroup.setOnCheckedChangeListener(this);
manager = new ActivityGroupManager();
container = (FrameLayout) findViewById(R.id.container);
manager.setContainer(container);
switchActivity(ActivityGroupManager.RECORD_ACTIVITY_VIEW, RECORD, RecordActivity.class);
}
@Override
public void onCheckedChanged(RadioGroup group, int checkedId) {
switch (checkedId) {
case R.id.record_button:
switchActivity(ActivityGroupManager.RECORD_ACTIVITY_VIEW, RECORD, RecordActivity.class);
break;
case R.id.category_button:
switchActivity(ActivityGroupManager.CATEGORY_ACTIVITY_VIEW, CATEGORY, CategoryActivity.class);
break;
case R.id.more_button:
switchActivity(ActivityGroupManager.MORE_AVTIVITY_VIEW, MORE, MoreActivity.class);
break;
default:
break;
}
}
private View getActivityView(String activityName, Class<?> activityClass) {
return getLocalActivityManager().startActivity(activityName,
new Intent(MainActivityGroup.this, activityClass))
.getDecorView();
}
private void switchActivity(int num, String activityName, Class<?> activityClass) {
manager.showContainer(num, getActivityView(activityName, activityClass));
}
}It can be seen that there is basically no logic code in the "main scene" MainActivityGroup, only the logic for switching each "sub-scene", and the switching of the sub-scene is managed by an ActivityGroupManager class, which again plays the role of code separation.
ActivityGroupManager.java
public class ActivityGroupManager {
private static final String TAG = "frag_manager";
public static final int RECORD_ACTIVITY_VIEW = 0;
public static final int CATEGORY_ACTIVITY_VIEW = 1;
public static final int MORE_AVTIVITY_VIEW = 2;
private HashMap<Integer, View> hashMap;
private ViewGroup container;
public ActivityGroupManager() {
hashMap = new HashMap<Integer, View>();
}
public void setContainer(ViewGroup container) {
this.container = container;
}
public void showContainer(int num, View view) {
if (!hashMap.containsKey(num)) {
hashMap.put(num, view);
container.addView(view);
}
for (Iterator<Integer> iter = hashMap.keySet().iterator(); iter.hasNext();) {
Object key = iter.next();
View v = hashMap.get(key);
v.setVisibility(View.INVISIBLE);
}
view.setVisibility(View.VISIBLE);
}
}It is worth mentioning that the showContainer () method in the ActivityGroupManager class is not like online practices:
container.removeAllViews();
container.addView(view);This approach seems to have simpler code logic, but this will cause the loaded View to be removed every time you switch the "sub-scene". On the one hand, the performance is lacking, and the other is the state of the "sub-scene". Can't remember. The current approach solves the above problems.
Okay, then there is the code of each "Activity". The logic of each "Subscenario" is independent, so there is no code here.
One more thing to mention here is the implementation of the bottom navigation bar. Since Android does not have a pre-defined component like iOS, you can only define a layout yourself. Here I use RadioGroup to achieve the bottom navigation bar effect similar to WeChat. , The following is the layout code, just include it directly in other places where it is used.
<?xml version="1.0" encoding="utf-8"?>
<RadioGroup xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/main_radio"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_gravity="bottom|center"
android:layout_marginBottom="-20dp"
android:gravity="center"
android:orientation="horizontal"
android:padding="0dp" >
<RadioButton
android:id="@+id/record_button"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:layout_weight="1.0"
android:background="@null"
android:button="@null"
android:checked="true"
android:drawableTop="@drawable/main_tab_record_selector"
android:gravity="center"
android:tag="record" />
<RadioButton
android:id="@+id/category_button"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_weight="1.0"
android:background="@null"
android:button="@null"
android:drawableTop="@drawable/main_tab_category_selector"
android:gravity="center_horizontal"
android:tag="category" />
<RadioButton
android:id="@+id/more_button"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_weight="1.0"
android:background="@null"
android:button="@null"
android:drawableTop="@drawable/main_tab_more_selector"
android:gravity="center_horizontal"
android:tag="more" />
</RadioGroup>