Left: Original complex layout with 8 views; Right: One single TextView.

How do we reduce the views in this menu? This menu is going to exist for the entire life time of the app (at this point of writing, even though they use a list view, the individual rows aren’t cleared every time the menu is closed). To start optimizing, let’s look at how the original menu layout was.

    <LinearLayout>

        <!-- left-most padding -->
        <View android:layout_width="10dp"/>

        <!-- icon -->
        <ImageView />

        <!-- menu item name -->
        <TextView />

        <!-- right Indicator -->
        <FrameLayout>

            <!-- tick -->
            <CheckBox />

            <!-- more indicator -->
            <ImageView />

        </FrameLayout>
        
        <!-- right-most padding -->
        <View android:layout_width="10dp"/>

    </LinearLayout>

The low hanging fruit here is to combine the ImageView for the icon with the TextView. That reduces one of the two views. The left and right most padding are interesting cases. The TextView by itself cannot have a standard margin. This would push the text more inside, if the icon or the right indicator is present, but will look right without them. But, that’s not the intended design. The parent LinearLayout can have a padding. However, this layout file actually had a <merge/> tag as the parent, as the layout could be inflated into any ViewGroup on demand. Now, since the left image is now made a compound drawable, the padding can be merged with the TextView. We are left with the right indicator (3 views) and an empty view for padding.

The interesting thing with compound drawables is that they support states. The state of the TextView is duplicated to the compound drawables too. If there is a way to combine the CheckBox and the ImageView as a single drawable, the entire right indicator could be made a compound drawable. How do we do that? The easiest way is to have custom states. A typical state list for the right indicator would look like:

    <selector>

        <!-- more indicator -->
        <item app:state_more="true"
              android:drawable="@drawable/more_indicator"/>

        <!-- checked state -->
        <item app:state_more="false"
              android:state_checkable="true"
              android:state_checked="true"
              android:drawable="@drawable/check_mark"/>

       <!-- unchecked state -->
       <item app:state_more="false"
             android:state_checkable="true"
             android:state_checked="false"
             android:drawable="@drawable/check_box"/>

       <!-- default state -->
       <item android:drawable="@android:color/transparent"/>

    </selector>

The right side of the TextView is shrunk to a single image with multiple states. This can be the android:drawableRight of the text. So, how many views do we have for the menu item?

    <TextView android:drawableLeft="@drawable/_assigned_by_code_"
              android:drawableRight="@drawable/_right_indicator_selector_"
              android:paddingLeft="10dp"
              android:paddingRight="10dp"/>

And that’s how we optimize Firefox on Android! One view at a time!

(i) Actual UI, (ii) Overdraw to start with, (iii) Actual reduction in overdraw, and (iv) Ideal condition

After understanding how overdraw is calculated, and how the problems can be mitigated, I started working on it. Basically there doesn’t seem to be a model that calculates what area of a view has to be repainted on the screen at any given time. In other words, Android doesn’t ask the view to paint only the region that is actually seen by the user. Instead the entire view is repainted if it is has its visibility as View.VISIBLE. To think in terms of windowing systems, a background application’s paint can be avoided when the foreground application occupies the entire screen. However, in case of Android, it paints both the hidden and visible views at every frame. By hidden the views are still View.VISIBLE, but not visible to the user. How do we solve this problem? To solve the problem, we need to see how complex the painting of a thumbnail in the screen was.

The actual thumbnail was the sixth layer drawn on the screen! The thumbnail had a text draw over it, and it by itself had a background which is usually hidden from the user. The about:home had a blue background, so did the Window. The tabs UI had a darker background drawn even though it was hidden, ummm, from the user’s eyes. There was also a SurfaceView, used for showing the HTML page, with a white background.

Android highly recommends using a background color for the Window. But why is it useful? 1. It makes the app feels like it loaded right when the user taps on the icon in the launcher, and 2. it works the same as a HTML background for the page. So, it’s good to have the window background and take the strain out of individual background in the app. For example, a white background for Facebook app’s window, instead of individual rows is better. But Firefox for Android has a different problem. We support themes starting version 19. If we had to set the image from the theme as the background of the window, then the about:home and url-bar over it wouldn’t have a background, but instead scroll over it. Also, hiding SurfaceView whenever about:home is shown will become a mess. But, having a background for Window and about:home is a clear overdraw! The way to solve this is to set a Window background at startup, and remove it after the UI is shown to the user. The app will be perceived as having launched faster, but the overdraw is removed for the lifetime of the app.

    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        if (hasFocus)
            getWindow().setBackgroundDrawable(null);
    }

That removes one layer out of the equation. Let’s take the case of tabs UI. When the app launches, it doesn’t open the tabs right away. The UI for tabs is hidden until the user hits the show-tabs button. This means that there is no point is having the UI with a state View.VISIBLE when the user does not even see it. The UI can be made View.VISIBLE right when the user taps on the tabs-button, and made View.INVISIBLE when it is hidden. As a matter of fact View.GONE could also be used. However, since there is a small animation involved, to know the height of the tabs UI, we had to use View.INVISIBLE. This ensures that the View is not drawn, but onLayout() is called to know the width, the height and the position of the View. A simple change in XML removes the next layer from the stack.

SurfaceView has a interesting property. The View wouldn’t be created and initialized if its not View.VISIBLE. Here comes the actual vs. ideal scenario in the first image. Ideally, if the same technique for Tabs UI is applied for the SurfaceView, the overdraw would be reduced by two times. However, since the code to handle it becomes messier, we avoided doing the same.

The last part in the stack involves the thumbnail. As mentioned earlier, thumbnail has an image of its own and a background. The background (30% white) is used in cases where a thumbnail image is not available. However, we keep drawing the background even when the image occupies the entire width and height of the ImageView. How about clearing the background if there is an image available? That would reduce one more layer!

    // somewhere in the code
    if (thumbnail == null) {
        thumbnailView.setImageBitmap(R.drawable.some_default_image);
        thumbnailView.setBackgroundColor(0x22FFFFFF);
    } else {
        thumbnailView.setImageBitmap(thumbnail);
        thumbnailView.setBackgroundColor(0x0);
    }

Though this might seem a silly optimization, this would benefit a lot of apps that requires loading images from a server. How do we deal with the TextView? As per the design, we wanted our TextView to be shown over the ImageView. Hence an overdraw couldn’t be avoided. This is what is seen in third screenshot. However, if we could move the TextView to be shown below the ImageView, the amount of overdraw on the TextView remains the same as the ImageView, as in the last screenshot. If we move the TextView down, wouldn’t it use a vertical LinearLayout instead of a RelativeLayout? Yes, it would! And wouldn’t the ImageView be enclosed in a RelativeLayout, that also has another ImageView for the small triangle on right corner? Maybe. And doesn’t this increase the number of views significantly? Of course yes!

    <!-- TextView over ImageView -->
    <RelativeLayout>
        <ImageView ..thumbnail.. />
        <ImageView ..triangle.. />
        <TextView/>
    </RelativeLayout>

    <!-- TextView below ImageView -->
    <LinearLayout ..vertical.. >
        <RelativeLayout>
            <ImageView ..thumbnail.. />
            <ImageView ..triangle.. />
        </RelativeLayout>
        <TextView />
    </LinarLayout>

There is a better way to handle this. A custom view can take care of drawing the triangle over the actual image bitmap when needed. This would involve just one View, but two draw operations. This is shown as the green overdraw only for the triangle in the last screenshot. However, if pin’s bitmap can be blended with the image and painted in one draw, the overdraw can be reduced further. It’s just the trade-off between two draws vs. blending images that would win there. A very small overdraw is better than a complex bitmap calculation usually.

So, finally, how many layers do we have in last screenshot? 1. about:home background, 2. thumbnail image. Just two layers! Hence the light blue region instead of bright red!

Basically Nexus 7 has a scaling factor of 1.33 (or is it 1.34?). Let’s take an image of size 50×50 px in mdpi scale. The same image will be of size 75×75 px for hdpi devices. Nexus 7 uses scales down this image to 67x67px. This would seem to look good if the image is flat with no shadows. However, Firefox for Android uses images with shadows to give an embossed feel over the textured background. A 2dp shadow is scaled to 3px on tvdpi, while a 4dp shadow is scaled to 5px. Basically a scale of 1.33 cannot yield a whole number like a scale of 1.5 (for any even number). And hence the rounded off scaled value can either be ceil or floor, causing the above visual artifacts.

So, isn’t there any solution? Not exactly! Like I mentioned, it’s hard to believe there is a problem with the scaling unless one watches it closely. If you compare the Nexus 4 and Nexus 7 side by side, the fuzziness is instantly noticeable all over the OS. The way default Android apps mitigate this is with the Holo theme. Since, in Holo theme all the icons are flat, with no shadows and gradients, the fuzziness is not that blatant. Does this enforce every app to follow Holo theme? That’s a big discussion in itself. However, that seems to mitigate the problem.

Is this the only problem? Unfortunately, no! Canvas uses a lot of float calculations. With the device having a scaling factor of 1.33, the chances of getting a whole number on float multiplications is very less. For example, there is a white line to the right of refresh button in the above image. In Firefox for Android, we use a cubic bezier path to create those curves. The width of the curve is 1.125 times the height of the view. Since the curve is in the ActionBar, the height is 48dp on portrait, 40dp on landscape and 56dp on tablets. Hence the width of the curve will be 45dp, 54dp and 63dp respectively. Except for a HDPI tablet, these always yield whole numbers. On a HDPI tablet, the value defaults to its ceil value. However on Nexus 7, the width will be 74 * 1.125 = 83.25. (Note: 74 is the Android’s approximation of 56 at 1.33 scale). Using this float directly to set control points at 75% and 25% will result in floating values with 4 decimal places. This would make Android to round off the number to it’s floor value, leading to 1px difference than the intended value.

Hence, a scale like 1.33 is not helpful for the app developers in any ways! If Angry Birds is fuzzy on your Nexus 7, now you why!

    <LinearLayout android:orientation="horizontal">
         <ImageView ... the icon ... />
         <TextView ... the text ... />
    </LinearLayout>

However, Android provides a way to add combine these views into a single view — a TextView. TextViews can optionally support Drawables in a view. They can be specified in XML or using Java methods. From the likes of it, based on the naming convention used, they wanted an approach to show borders like in HTML. However, they can be hacked to show much more than borders.

    <TextView android:text=" ... the text ... "
              android:drawableLeft="@drawable/_the_icon_"
              android:drawablePadding="_gap_to_icon"/>

The Drawable can be assigned to any direction, and more than one can be specified at a time. The distance between the drawable and the text is specified by the attribute android:drawablePadding. Unfortunately, the padding has to be the same on all sides. Also, this padding is different from the TextView’s padding. By default the image is shown at its actual size. What if the icon is huge and we don’t want it to be bigger than the text? Using Drawable’s setBounds(), we can set the size of the Canvas to use to render the Drawable. A drawable that is assigned as a compound drawable for a TextView should have its bounds set before being specified as one. The standard Android’s launcher uses this approach to show the icons with the name of the app. The menu items are also rendered in the same way. Though this doesn’t scale well for all purposes, for simpler cases, this reduces the views effectively.

Going through the changesets in the Android codebase, the only new change to the Drawables in three years was related to mutate(). However this couldn’t all of a sudden affect how a drawable is drawn. What could be the problem? As it turns out, LayerDrawable tries to get a ConstantState of the drawable in its constructor. Our implementation of a LightweightThemeDrawable relied on a BitmapDrawable for the same. And since BitmapDrawable doesn’t know that it’s draw() is going to be overriden, it is going to give it’s own ConstantState, which wouldn’t add translucency.

Now the visible solution in hand is to implement the ConstantState for the LightweightThemeDrawable. This drawable is going to be used for just one button. The bitmap is not going to be shared between the buttons as it is not a texture. Do we really need to maintain a constant state? What other option could save us here? Let’s look at how this drawable would be, if defined in XML.

<layer-list>

    <!-- The translucent drawable, with transparency applied by overriding draw() -->
    <item android:drawable="@drawable/_the_theme_image_"/>

    <!-- The texture beneath -->
    <item android:drawable="@drawable/_repeating_texture_bitmap_"/>

</layer-list>

Is there a way to combine these layers into one? When given a Canvas, we need to paint the texture once, and then a bitmap. Since we are creating a custom drawable for translucency, we can reuse the same to draw the texture too. The good news is that the translucency can be achieved in a even better way if we use Shaders. Shaders are more like Photoshop brushes. We could use a pattern and paint over the canvas in Photoshop using a brush. The same holds for Canvas in Android too.

A repeating shader for Bitmap is easy. We need to create a BitmapShader that holds the repeating bitmap to be drawn. The snippet below checks to see if the textureId specified is a texture in drawable-nodpi/ or a BitmapDrawable that already defines how to repeat the texture. In the first case, the texture is repeated in both directions. In the second case, the texture is repeated as specified in the drawable.

    public void setTexture(int textureId) {
        Shader.TileMode modeX = Shader.TileMode.REPEAT;
        Shader.TileMode modeY = Shader.TileMode.REPEAT;

        // The texture to be repeated.
        Bitmap texture = BitmapFactory.decodeResource(mResources, textureId);

        if (texture == null) {
            // Texture may be used inside a BitmapDrawable.
            Drawable drawable = mResources.getDrawable(textureId);
            if (drawable != null && drawable instanceof BitmapDrawable) {
                BitmapDrawable bitmapDrawable = (BitmapDrawable) drawable;
                texture = bitmapDrawable.getBitmap();
                modeX = bitmapDrawable.getTileModeX();
                modeY = bitmapDrawable.getTileModeY();
            }
        }

        // Set the shader for the texture paint.
        if (texture != null) {
            mTexturePaint = new Paint();
            mTexturePaint.setAntiAlias(true);
            mTexturePaint.setShader(new BitmapShader(texture, modeX, modeY));
        }
    }

As mentioned before, the translucency can be achieved in one go with Shaders. A ComposeShader takes two shaders and combines them using a PorterDuff-Mode. With the bitmap’s shader as the DST and the LinearGradient as the SRC, we can use a DST_IN mode to get the translucency effect.

    @Override
    protected void onBoundsChange(Rect bounds) {
        super.onBoundsChange(bounds);

        // A bitmap-shader to draw the bitmap.
        // mBitmap is usually passed as an argument for the constructor.
        // Clamp mode will repeat the last row of pixels.
        // Hence its better to have an endAlpha of 0 for the linear-gradient.
        BitmapShader bitmapShader = new BitmapShader(mBitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // A linear-gradient to specify the opacity of the bitmap.
        // mStartColor and mEndColor have just the alpha bits set to required value. E.g.: 0xAA000000.
        LinearGradient gradient = new LinearGradient(0, 0, 0, mBitmap.getHeight(), 
                                                     mStartColor, mEndColor, Shader.TileMode.CLAMP);

        // Make a combined shader -- a performance win.
        // The linear-gradient is the 'SRC' and the bitmap-shader is the 'DST'.
        // Drawing the DST in the SRC will provide the opacity.
        mPaint.setShader(new ComposeShader(bitmapShader, gradient, PorterDuff.Mode.DST_IN));
    }

We have a shader for the texture and a shader for the bitmap. All we need to do.. is paint them!

    @Override
    public void draw(Canvas canvas) {
        // Draw the texture.
        canvas.drawPaint(mTexturePaint);

        // Draw the bitmap.
        canvas.drawPaint(mPaint);
    }

And we have the solution! In fact, the base layer needn’t be a texture. We could just paint a color and paint the bitmap over it. Shaders can be used to do many other effects. What would setting up an alpha based shader, like RadialGradient, from transparency to black, and drawing it on a bitmap look like? A vignette effect! What would adding a red LinearGradient for a shader and using a MULTIPLY look like? A saturated sun-set effect! Have you started dreaming of implementing Instagram filters already? The greatest advantage over my previous post is that this is all drawn by Paint in one go. We don’t need offscreen bitmap processing to worry about handling opaque areas.

Note: Painting the Canvas twice could result in overdraw. This complex effect of painting over a texture wouldn’t be needed in most applications. In that case, a ComposeShader will result in a single time painting. In case you would want to combine the two shaders above, you could do that. It might work.

There are clearly two things that make it feel like the theme has changed from Holo Dark to a Light version — the ActionBar and the Menu. The good thing with menu is that it uses a ListView to show the items. Hence it gets re-created every time it is shown. Now a theme change during runtime will change the menu items for sure. A small theme change code will be like:

<!-- somewhere in themes.xml -->
<resources xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- light theme -->
    <style name="AppTheme" parent="@android:style/Theme.Holo.Light"/>

    <!-- dark theme -->
    <style name="AppTheme.Dark" parent="@android:style/Theme.Holo"/>

</resources>

And we could change the theme in Java as:

    // somewhere in the activity
    private void changeTheme(boolean isLight) {
        setTheme(isLight ? R.style.AppTheme : R.style.AppTheme_Dark);
    }

That solves the menu problem! How about ActionBar? This is where Pocket has a very clever approach. The ActionBar is clearly not a custom UI. Hence, a call like getActionBar().getCustomView() will return null. If we had such a view, we could easily change the background color, couldn’t we? In this case, ActionBar is fully owned by Android and we don’t have any control over it’s appearance, except that is defined in themes.xml. Also, we cannot re-inflate the ActionBar too — unless we plan to show a custom view.

Let’s take a step back. Where is the actual app content placed on phone? Based on the UI XML Snapshot (that’s so cool!), a typical app will have views like:

<!-- A bunch of FrameLayout as ancestors for core android ...and then -->
<!-- Window of the application -->
<FrameLayout>

    <!-- Content of the application -->
    <RelativeLayout>

        <!-- ActionBar owned by Android -->
        <LinearLayout />

        <!-- Actual content of the application defined in our layout.xml -->
        <LinearLayout or RelativeLayout or FrameLayout />

    </RelativeLayout>

</FrameLayout>

And we can get the Window of the application — which is a FrameLayout — and can set a background! So, if the views contained by it are translucent, the Window’s background will be seen. Choosing a mid-grey for the translucent layer and changing the background to be black or white could give magical effects.

Did we just have two color themes by just changing the Window background? Changing the window background color is pretty simple.

    // somewhere in the activity
    private void changeTheme(boolean isLight) {
        getWindow().setBackgroundDrawable(new ColorDrawable(isLight ? Color.WHITE : Color.BLACK));
    }

And that’s the magic behind a two-color ActionBar in Pocket. The icons are all translucent, making them feel like they change based on the Holo theme used. The text part is pretty easy. Inflating the views again is unnecessary. Adding a custom state can switch themes in a jiffy. Firefox for Android uses this technique to swiftly change color scheme between normal and private browsing modes. One good trick here is to make the children duplicate their parent state.

<!-- some layout file for the activity -->
<LinearLayout ...attributes...>
    <Button ...attributes...
            android:duplicateParentState="true"/>

    <TextView ...attributes...
              android:duplicateParentState="true"/>
</LinearLayout>

In the above layout, changing the custom state, say “state_light_theme_enabled”, of LinearLayout will propagate down to its children too. So a single call on the root level element can do wonders. And thereby, we can change themes — or make it feel like — within 250ms. This technique is not restricted for monochrome. This works with normal colors too.

Since that’s a big discussion by itself, let’s skip that and investigate if we can support fonts. There are few blogs explaining how one can add new fonts. The general idea here is to add the font to assets in project directory, and apply it to the individual views. Should we have to apply the Typeface individually to each element, after it is inflated? (Does this sound like loading a HTML page with default font, and changing the CSS to a custom font — which loads later?). A better approach would be to add a custom attribute, say font in XML, and use it to specify the path to the font. But font is a heavy resource and shared among many views (a flyweight pattern!). Hence, its better to cache the fonts and use them. So, a direct path to the font file wouldn’t work.

Coming from HTML background, the CSS has a font-family attribute that can be used to specify a font family for a group of classes or HTML elements. How could we use a similar concept in Android? In fact, Android supports such a property starting with JellyBean. However, this still doesn’t support user’s custom fonts. There are various styles of Roboto that can be used — like sans-serif, sans-serif-light or sans-serif-condensed. Let’s tie them all together to build a FontManager that can support a CSS like font-family, which effectively caches resources.

Digging into the Android SDK, I found out how Android specifies the list of fonts it supports. If you look into the file: _sdk-directory_/platforms/android-16/data/fonts/system_fonts.xml, you could see a similar XML like below. A family specifies a particular font-type. This has a list of names that it can respond to, specified in nameset and a list of files that specifies the different styles, specified in fileset. And, familyset is a parent tag, more like the resources tag.

<familyset>
    <family>
        <nameset>
            <name>sans-serif</name>
            <name>arial</name>
            <name>helvetica</name>
            <name>tahoma</name>
            <name>verdana</name>
        </nameset>
        <fileset>
            <file>Roboto-Regular.ttf</file>
            <file>Roboto-Bold.ttf</file>
            <file>Roboto-Italic.ttf</file>
            <file>Roboto-BoldItalic.ttf</file>
        </fileset>
    </family>
</familyset>

For the sake of easy understanding, lets create our parser based on this. Since any file in res/values/ expects tags only known to Android, we can add a file with these tags in a file, say fonts.xml in res/xml/ folder. I downloaded a couple of fonts from Google web fonts, added it to assets folder, and specified them in a XML like below. Here, Montaga has just one style — Regular, while OpenSans supports four different styles. Also, OpenSans could respond to “opensans”, “open-sans”, “sans” or “sans-serif” as font-family.

<?xml version="1.0" encoding="utf-8"?>
<familyset>
    
    <!--  Montaga -->
    <family>
        <nameset>
            <name>montaga</name>
        </nameset>
        <fileset>
            <file>fonts/Montaga-Regular.ttf</file>
        </fileset>
    </family>
    
    
    <!--  Open Sans -->
    <family>
        <nameset>
            <name>opensans</name>
            <name>open-sans</name>
            <name>sans</name>
            <name>sans-serif</name>
        </nameset>
        <fileset>
            <file>fonts/OpenSans-Regular.ttf</file>
            <file>fonts/OpenSans-Bold.ttf</file>
            <file>fonts/OpenSans-Italic.ttf</file>
            <file>fonts/OpenSans-BoldItalic.ttf</file>
        </fileset>
    </family>

</familyset>

Since we are adding a custom attribute, we need to create custom views. Also, fonts work as a combination of Typeface and the style (bold/italic/bold and italic/normal). We could use android:textStyle in our custom styleable attribute Fonts.

<resources>
    <declare-styleable name="Fonts">
        <!-- using android's -->
        <attr name="android:textStyle" />

        <!-- our custom attribute -->
        <attr name="fontFamily" format="string" />
    </declare-styleable>
</resources>

And the custom TextView will be like,

    public class FontView extends TextView {
        public FontView(Context context, AttributeSet attrs) {
            super(context, attrs);
		
            // Fonts work as a combination of particular family and the style. 
            TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.Fonts);
            String family = a.getString(R.styleable.Fonts_fontFamily);
            int style = a.getInt(R.styleable.Fonts_android_textStyle, -1);
            a.recycle();

            // Set the typeface based on the family and the style combination.
            setTypeface(FontManager.getInstance().get(family, style));
       }
    }

And the parser for the XML,

public class FontManager {
	
    //Making FontManager a singleton class
    private static class InstanceHolder {
        private static final FontManager INSTANCE = new FontManager();
    }

    public static FontManager getInstance() {
       return FontManager.InstanceHolder.INSTANCE;
    }
	
    private FontManager() { }
    
    // Different tags used in XML file.
    private static final String TAG_FAMILY = "family";
    private static final String TAG_NAMESET = "nameset";
    private static final String TAG_NAME = "name";
    private static final String TAG_FILESET = "fileset";
    private static final String TAG_FILE = "file";
	
    // Different styles supported.
    private static final String STYLE_BOLD = "-Bold.ttf";
    private static final String STYLE_ITALIC = "-Italic.ttf";
    private static final String STYLE_BOLDITALIC = "-BoldItalic.ttf";
	
    private class FontStyle {
        int style;
        Typeface font;
    }
	
    private class Font {
        // different font-family names that this Font will respond to.
        List<String> families;
		
        // different styles for this font.
        List<FontStyle> styles;
    }
	
	private List<Font> mFonts;

	//private boolean isFamilySet = false;
	private boolean isName = false;
	private boolean isFile = false;
	
	// Parse the resId and initialize the parser.
	public void initialize(Context context, int resId) {
		XmlResourceParser parser = null;
		try {
			parser = context.getResources().getXml(resId);
			mFonts = new ArrayList<Font>();

			String tag;
			int eventType = parser.getEventType();
			
			Font font = null;

			do {
				tag = parser.getName();

				switch (eventType) {
					case XmlPullParser.START_TAG:
						if (tag.equals(TAG_FAMILY)) {
							// one of the font-families.
							font = new Font();
						} else if (tag.equals(TAG_NAMESET)) {
							// a list of font-family names supported.
							font.families = new ArrayList<String>();
						} else if (tag.equals(TAG_NAME)) {
							isName = true;
						} else if (tag.equals(TAG_FILESET)) {
							// a list of files specifying the different styles.
							font.styles = new ArrayList<FontStyle>();
						} else if (tag.equals(TAG_FILE)) {
							isFile = true;
						}
						break;

					case XmlPullParser.END_TAG:
						if (tag.equals(TAG_FAMILY)) {
							// add it to the list.
							if (font != null) {
								mFonts.add(font);
								font = null;
							}
						} else if (tag.equals(TAG_NAME)) {
							isName = false;
						} else if (tag.equals(TAG_FILE)) {
							isFile = false;
						}
					break;
					
					case XmlPullParser.TEXT:
						String text = parser.getText();
						if (isName) {
							// value is a name, add it to list of family-names.
							if (font.families != null)
								font.families.add(text);
						} else if (isFile) {
							// value is a file, add it to the proper kind.
							FontStyle fontStyle = new FontStyle();
							fontStyle.font = Typeface.createFromAsset(context.getAssets(), text);
							
							if (text.endsWith(STYLE_BOLD))
								fontStyle.style = Typeface.BOLD;
							else if (text.endsWith(STYLE_ITALIC))
								fontStyle.style = Typeface.ITALIC;
							else if (text.endsWith(STYLE_BOLDITALIC))
								fontStyle.style = Typeface.BOLD_ITALIC;
							else
								fontStyle.style = Typeface.NORMAL;
							
							font.styles.add(fontStyle);
						}
					}

				eventType = parser.next();

			} while (eventType != XmlPullParser.END_DOCUMENT);

		} catch (XmlPullParserException e) {
			throw new InflateException("Error inflating font XML", e);
		} catch (IOException e) {
			throw new InflateException("Error inflating font XML", e);
		} finally {
			if (parser != null)
				parser.close();
		}
	}
	
	public Typeface get(String family, int style) {
		for (Font font: mFonts) {
			for (String familyName : font.families) {
				if (familyName.equals(family)) {
					// if no style in specified, return normal style.
					if (style == -1)
						style = Typeface.NORMAL;
					
					for (FontStyle fontStyle : font.styles) {
						if (fontStyle.style == style)
							return fontStyle.font;
					}
				}
			}
		}
			
	    return null;
	}
}

Now the activity should make sure to load the fonts, so that when the views are inflated, they know to get the font from the FontManager. The following piece of code needs to be added before setContentView() in onCreate().

    // Set up the font parser with the fonts.xml resource.
    FontManager.getInstance().initialize(this, R.xml.fonts);

With so much of plumbing what did we achieve? Quite a lot! Lets see what all this can do.

    <!-- In any layout, we could specify the fontFamily to the custom views.
         "sirius" is our custom namespace for our application -->

    <!-- Regular font -->
    <FontView style="@style/CustomFont"
              android:text="Montaga"
              sirius:fontFamily="montaga"/>
    
    <!-- fontFamily as opensans -->
    <FontView style="@style/CustomFont"
              android:text="OpenSans - Regular"
              sirius:fontFamily="opensans"/>

    <!-- textStyle is "italic" and family is "sans" -->
    <FontView style="@style/CustomFont"
              android:text="OpenSans - Italic"
              android:textStyle="italic"
              sirius:fontFamily="sans"/>

    <!-- The font family can be specified in the styles.xml -->
    <FontView style="@style/OpenSans.Bold" />


    <!-- In styles.xml, we can create hierarchies of styles with different fonts.
         Note that the attribute names are unbounded, as they are in our scope. -->
    <style name="OpenSans">
        <item name="fontFamily">opensans</item>
    </style>

    <style name="OpenSans.Bold">
        <item name="android:textStyle">bold</item>
    </style>

    <style name="OpenSans.Bold.Italic">
        <item name="android:textStyle">bold|italic</item>
    </style>

So, any view that can support custom fonts, can either specify it in its own attribute list, or as a part of it’s style. In fact, we could specify this attribute in themes.xml, and let our application use a default font! Did we just make it look like a HTML page? Oh wait! Did we just allow developers to develop applications with… Comic Sans MS?

Note: The fonts used here are for demonstration purposes only. I don’t own any right to ship it (as I don’t understand the big complex font licensing that Google talks about).

Let’s see how we can gradually fade-in an image. The reflected image in the screenshot has android:rotationX set to 180, and is a separate image.

The idea is to use a Shader with the Paint used for drawing on the Canvas. We want the image to be opaque on the top and transparent at the bottom. A LinearGradient from black to transparent could achieve this effect.

public class ReflectedImageView extends ImageView {
    private Paint mPaint;
    
    public ReflectedImageView(Context context, AttributeSet attrs) {
        super(context, attrs);

        // Setup the paint.
        mPaint = new Paint();
        mPaint.setAntiAlias(true);
        mPaint.setColor(0xFFFF0000);
        mPaint.setStrokeWidth(0.0f);
        
        // Destination (DST) is drawn by the parent, and should be retained.
        mPaint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.DST_IN));
    }
    
    @Override
    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
        super.onLayout(changed, left, top, right, bottom);
        
        // It's recommended not to create a Shader in the basic layout calls.
        // Linear gradient from Transparent to Black, from top to bottom.
        // Note: We rotated the image using a transformation.
        // Hence the colors will be opposite.
        LinearGradient gradient = new LinearGradient(0, 0, 0, bottom - top, 
                                                     0x0, 0xFF000000,
                                                     Shader.TileMode.CLAMP);
        
        // Set the gradient as the shader.
        mPaint.setShader(gradient);
    }

    @Override
    protected void onDraw(Canvas canvas) {
        // Save the canvas. All PorterDuff operations should be done in a offscreen bitmap.
        int count = canvas.saveLayer(0, 0, canvas.getWidth(), canvas.getHeight(), null,
                                     Canvas.MATRIX_SAVE_FLAG |
                                     Canvas.CLIP_SAVE_FLAG |
                                     Canvas.HAS_ALPHA_LAYER_SAVE_FLAG |
                                     Canvas.FULL_COLOR_LAYER_SAVE_FLAG |
                                     Canvas.CLIP_TO_LAYER_SAVE_FLAG);


        
        // Do a default draw.
        super.onDraw(canvas);
        
        // Draw the paint (that has a shader set), on top of the image
        // drawn by the parent (ImageView).
        // Note: This works only on ICS. For pre-ICS phones, create a bitmap and
        // draw on it, like mentioned in CanvasDelegate linked below.
        canvas.drawPaint(mPaint);
        
        // Restore the canvas.
        canvas.restoreToCount(count);
    }
}

That gives a nice glossy feel for the image. This method was earlier used in drawing the tabs button. To re-use the logic, Fennec uses a LightweightThemeDrawable, that uses a CanvasDelegate, which takes care of drawing on the canvas. Grab an aurora build today to give this a try!

Update: A better approach would be to use Shaders. This reduces the need for a offscreen bitmap.

But, could we reuse an existing state to convey the private browsing mode? This would not go well with the actual meaning of the predefined Android states. So, could we create a new state for private mode? Oh, yes!

We need a custom attribute that can be used in other XML files that describes the background. This is added in res/values/attrs.xml.

<resources>
    <declare-styleable name="PrivateBrowsing">
        <!-- name of the attribute that will be used in XML files -->
        <attr name="state_private_mode" format="boolean"/>
    </declare-styleable>
</resources>

We can now add this attribute to a StateListDrawable, that defines the background of the view. Let’s have it in some res/drawable/background.xml.

<!-- Note: The "state_private_mode" attribute is defined in our application's scope. Let's call it "sirius". -->
<selector xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:sirius="http://schemas.android.com/apk/res/com.sriramramani.just.another.app">

    <!-- private browsing mode -->
    <item sirius:state_private_mode="true" android:color="_some_dark_color_" />

    <!-- normal mode -->
    <item android:color="_some_light_color_"/>

</selector>

Now this background be specified in the layout XML just like any other drawable. This doesn’t end here. We’ve specified a way to add a custom attribute, and have used it in our background. Though the app will compile fine, Android doesn’t know when to apply this state. It’s the responsibility of the custom view to inform Android, that it’s state has changed and request it to show a new background. Is that hard? Let’s create a new custom button, PrivateModeButton, that’s a Button at heart but supports private browsing mode, by providing a method setPrivateMode().

public class PrivateModeButton extends Button {
    // (Combination of) States are usually specified as an array.
    // Our custom attribute will be generated as R.attr.state_private_mode.
    // Note: This is in our app's scope.
    private static final int[] STATE_PRIVATE_MODE = { R.attr.state_private_mode };

    // The view needs a way to know if it's in private mode or not.
    private boolean mIsPrivate = false;

    public PrivateModeButton(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    // Android calls this method to know the current drawable state of the view.
    // It starts with an "extraSpace" of 0 in View.java, and each inherited view adds its new state.
    // We add just one more state, hence, we create a new array of size "extraSpace + 1".
    @Override
    public int[] onCreateDrawableState(int extraSpace) {
        // Ask the parent to add its default states.
        final int[] drawableState = super.onCreateDrawableState(extraSpace + 1);

        // If we are private, add the state to array of states.
        // If not added, the value will be treated as false.
        // mergeDrawableStates() takes care of resolving the duplicates.
        if (mIsPrivate)
            mergeDrawableStates(drawableState, STATE_PRIVATE_MODE);

        // Return the new drawable state.
        return drawableState;
    }

    // We need a way for the Activity (or some other part of the code)
    // to enable private mode for the view.
    public void setPrivateMode(boolean isPrivate) {
        // If we flip the current state of private mode, record the value
        // and inform Android to refresh the drawable state.
        // This will in turn invalidate() the view.
        if (mIsPrivate != isPrivate) {
            mIsPrivate = isPrivate;
            refreshDrawableState();
        }
   }
}

Voila! We can now call myPinkButton.setPrivateMode(true); to show a black button instead. Facebook can have a LikeButton with a custom attribute state_liked, or Twitter can have a FavoriteButton that exposes setFavorite() which can add a small little star at the top right. From Java’s perspective, it’s a property of the view. From XML perspective, it’s just another state!

P.S.: Thanks to Wes (wesj) for pointing me out to try using custom states.

We wanted to show as much persona as we can, yet retain the affordance provided by the buttons. To achieve it, the gray or black texture of the buttons will have a translucent layer of the image, making the image flow smoothly between interactors. Also, the about:home reflects the background from the image by taking the dominant color from the image. The experience isn’t complete if the tabs menu and the awesomescreen are left behind. We’ve got that covered as well!

There are few more bits getting reading to join these bytes — like the text color in about:home and the url-bar transparency. But still, what are you waiting for? Try out a nightly build and help us improve the Firefox for Android to make it more personal for you!

P.S.: Just in case you wanted to get back to the default theme, hit Menu > Tools > Addons and disable the theme.