UI framework modifications in Android 1.6

Posted on


Android 1.6 introduces quite a few enhancements and bug fixes within the UI framework. At this time, I might like to focus on three two enhancements specifically.

Optimized drawing

The UI toolkit launched in Android 1.6 is conscious of which views are opaque and might use this data to keep away from drawing views that the consumer won’t be able to see. Earlier than Android 1.6, the UI toolkit would typically carry out pointless operations by drawing a window background when it was obscured by a full-screen opaque view. A workaround was obtainable to keep away from this, however the method was restricted and required work in your half. With Android 1.6, the UI toolkit determines whether or not a view is opaque by merely querying the opacity of the background drawable. If you understand that your view goes to be opaque however that data doesn’t rely upon the background drawable, you’ll be able to merely override the tactic known as isOpaque():

@Override
public boolean isOpaque() {
return true;
}

The worth returned by isOpaque() doesn’t must be fixed and might change at any time. For example, the implementation of ListView in Android 1.6 signifies {that a} record is opaque solely when the consumer is scrolling it.

Up to date: Our apologies—we spoke to quickly about isOpaque(). It is going to be obtainable in a future replace to the Android platform.

Extra versatile, extra sturdy RelativeLayout

RelativeLayout is probably the most versatile structure supplied by the Android UI toolkit and will be efficiently used to cut back the variety of views created by your purposes. This structure used to endure from varied bugs and limitations, typically making it troublesome to make use of with out having some data of its implementation. To make your life simpler, Android 1.6 comes with a revamped RelativeLayout. This new implementation not solely fixes all recognized bugs in RelativeLayout (tell us while you discover new ones) but additionally addresses its main limitation: the truth that views needed to be declared in a selected order. Contemplate the next XML structure:

<?xml model="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="64dip"
android:padding="6dip">

<TextView
android:id="@+id/band"
android:layout_width="fill_parent"
android:layout_height="26dip"

android:layout_below="@+id/observe"
android:layout_alignLeft="@id/observe"
android:layout_alignParentBottom="true"

android:gravity="prime"
android:textual content="The Airborne Poisonous Occasion" />

<TextView
android:id="@id/observe"
android:layout_marginLeft="6dip"
android:layout_width="fill_parent"
android:layout_height="26dip"

android:layout_toRightOf="@+id/paintings"

android:textAppearance="?android:attr/textAppearanceMedium"
android:gravity="backside"
android:textual content="Someday Round Midnight" />

<ImageView
android:id="@id/paintings"
android:layout_width="56dip"
android:layout_height="56dip"
android:layout_gravity="center_vertical"

android:src="http://officialandroidcenter.blogspot.com/2009/10/@drawable/paintings" />

</RelativeLayout>

This code builds a quite simple structure—a picture on the left with two traces of textual content stacked vertically. This XML structure is completely tremendous and accommodates no errors. Sadly, Android 1.5’s RelativeLayout is incapable of rendering it accurately, as proven within the screenshot under.

The issue is that this structure makes use of ahead references. For example, the “band” TextView is positioned under the “observe” TextView however “observe” is asserted after “band” and, in Android 1.5, RelativeLayout doesn’t know find out how to deal with this case. Now take a look at the very same structure operating on Android 1.6:

As you’ll be able to see Android 1.6 is now higher in a position to deal with ahead reference. The consequence on display is precisely what you’ll anticipate when writing the structure.

Simpler click on listeners

Establishing a click on listener on a button is quite common process, however it requires fairly a little bit of boilerplate code:

findViewById(R.id.myButton).setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
// Do stuff
}
});

One option to cut back the quantity of boilerplate is to share a single click on listener between a number of buttons. Whereas this method reduces the variety of courses, it nonetheless requires a good quantity of code and it nonetheless requires giving every button an id in your XML structure file:

View.OnClickListener handler = View.OnClickListener() {
public void onClick(View v) {
swap (v.getId()) {
case R.id.myButton: // doStuff
break;
case R.id.myOtherButton: // doStuff
break;
}
}
}

findViewById(R.id.myButton).setOnClickListener(handler);
findViewById(R.id.myOtherButton).setOnClickListener(handler);

With Android 1.6, none of that is essential. All it’s a must to do is declare a public technique in your Exercise to deal with the press (the tactic should have one View argument):

class MyActivity extends Exercise {
public void myClickHandler(View goal) {
// Do stuff
}
}

After which reference this technique out of your XML structure:

<Button android:onClick="myClickHandler" />

This new characteristic reduces each the quantity of Java and XML it’s a must to write, leaving you extra time to focus on your utility.

The Android workforce is dedicated to serving to you write purposes within the best and most effective manner attainable. We hope you discover these enhancements helpful and we’re excited to see your purposes on Android Market.





oflapps.xyz

Leave a Reply

Your email address will not be published. Required fields are marked *