Getting started with the new build system is relatively easy. To get started you’ll need to make sure you have both Maven and Gradle installed.

Install Homebrew

If you’re working on OS X you can make your life a whole lot easier by installing Homebrew. If you don’t already have it installed, you can install it by running the following command from your terminal:

    $ ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Install Maven

    $ brew install maven

Install Gradle

As of May, 2013, the new Android build system only supports Gradle versions 1.3/1.4. This means it won’t work with the latest version of Gradle. You’ll have to follow the instructions at gradle.org/installation to install a prior version of Gradle. Otherwise you could simply install the latest version using Homebrew.

    $ brew install gradle

You can verify you have the correct version of Gradle installed using the following command:

    $ gradle -v

You should see output that looks something like this:

 
    ------------------------------------------------------------
    Gradle 1.3
    ------------------------------------------------------------
 
    Gradle build time: Tuesday, November 20, 2012 11:37:38 AM UTC
    Groovy: 1.8.6
    Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
    Ivy: 2.2.0
    JVM: 1.6.0_45 (Apple Inc. 20.45-b01-451)
    OS: Mac OS X 10.8.3 x86_64

Add a build.gradle to your project

Add the following build.gradle file to the root of your Android project:

Build your project

You should now be able to build your project using the following command:

    $ gradle clean installDebug

As of today, the two most common screen resolutions in the 7-inch category are 1280x800 - WXGA and 1024x600 - WSVGA. Higher-end tablets like the Nexus 7 have a 1280x800 resolution and thus a higher pixel density. Lower-end tablets like the Samsung Galaxy Tab use a 1024x600 resolution and have a lower pixel density.

The Nexus 7 has a pixel density of around 213ppi and technically falls into the unique tvdpi density bucket, but for all intents and purposes you can consider it an hdpi device. Lower-end devices with a 1024x600 resolution have a pixel density of approximately 170ppi and will typically use mdpi assets. I don’t know of any 7-inch devices with an xhdpi pixel density, but I’m sure we’ll see some hit the market soon.

Regardless of the resolution, all 7-inch Android devices fall into the 600dp category. That is, they have a width of 600 density-independent pixels when in portrait orientation. We can use this width to provide alternative resources for these devices.

For starters, if you want to specify a custom layout for 7-inch devices you can simply add a new res/layout-sw600dp directory. Any layouts in this directory will be applied to devices that have a “smallest-width” of “600dp”.

If you don’t want to provide a completely different layout, but want to bump up the size of all your elements slightly you can use the res/values-sw600dp directory. Any resources provided here like dimens.xml or styles.xml will take precedence on devices like the Nexus 7. This way you can have a single layout file that references dimensions or styles that are dynamic based on the device size.

Finally, you might want to provide alternative drawable resources for 7-inch tablets. You can combine the sw600dp resource qualifier with a density qualifier to provide alternative drawables:

• res/drawable-sw600dp-mdpi
• res/drawable-sw600dp-hdpi
• res/drawable-sw600dp-xhdpi

As you can see we’ve simply added the sw600dp qualifier to our typical drawable directories. These resources will be applied to devices of the correct screen density, but only if they are 7-inch tablets or larger.

All of these techniques are also applicable to targeting 10-inch tablets. Simply replace the 600dp width qualifier with 720dp in the case of 10-inch devices.

Further reading

• Android Developers – Supporting Multiple Screens
• Dianne Hackborn on the Nexus 7

There are several posts on Stack Overflow that recommend accomplishing this by leveraging the Action Bar’s custom view feature, or by getting a reference to the title TextView. These solutions are adequate but can lead to infuriating edge cases. We can do better.

You might have come across the TypefaceSpan class, which allows you to style a section of text in a TextView with a monospace or serif font. This is almost what we want to do, but we need to be able to provide our own Typeface instance.

Here’s what a custom TypefaceSpan might look like in use:

    SpannableString s = new SpannableString("My Title");
    s.setSpan(new TypefaceSpan(this, "MyTypeface"), 0, s.length(),
            Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
 
    // Update the action bar title with the TypefaceSpan instance
    ActionBar actionBar = getActionBar();
    actionBar.setTitle(s);

Notice that we simply create a SpannableString with our desired Action Bar title. We then create a new instance of our custom TypefaceSpan providing it with our Activity context and the typeface name as arguments (so it can load the typeface from our application’s assets directory). The span is set on the entire length of the title (... 0, s.length(), ...). Finally, we pass in the Spannable.SPAN_EXCLUSIVE_EXCLUSIVE flag, which simply indicates that the span should be removed if all of the spanned text is deleted. Here’s what the result might look like:

But what does the custom TypefaceSpan implementation look like? Well, it’s surprisingly simple. I’ve created an example you can use in your own apps. You can get it at gist.github.com/twaddington/b91341ea5615698b53b8. Simply copy this class into your application and use it like I’ve indicated above. You can even subclass the custom TypefaceSpan to add additional styles like colors or text shadows.

Fonts Shown

• Lost Type Co-op: Bender
• Lost Type Co-op: Cubano
• Hoefler & Frere-Jones: Gotham

The solution is to write a custom TextView implementation with support for defining custom attributes.

The first thing you should do is create the file attrs.xml in your project’s res/values directory. Save the following XML to your new file:

<?xml version="1.0" encoding="utf-8"?>
<resources>
 
    <declare-styleable name="TypefaceTextView">
        <attr name="typeface" format="string" />
    </declare-styleable>
 
</resources>

This XML simply defines the custom attribute typeface for the not yet existing class TypefaceTextView. It also notes that the attribute value should be parsed as a string.

You can now create the new class TypefaceTextView.java using the following source code:

You can see that the class simply looks for the custom typeface attribute and attempts to load the named font from your application’s assets/fonts directory at runtime. The class implements a static LruCache to avoid unnecessary hits to disk for fonts that were previously loaded. Note that if you’re targeting API levels prior to 12 the LruCache is only available using the Android support library.

Assuming you have the font file GothamBold-Family.otf in your project’s assets/fonts directory, then you can use the custom TypefaceTextView class in your layouts like so:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:simple="http://schemas.android.com/apk/res/com.simple"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >
 
    <com.simple.widget.TypefaceTextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Hello, Gotham!"
        simple:typeface="GothamBold" />
 
</LinearLayout>

If you have another font you wish to use, simply update the value of the simple:typeface attribute of your view. In this way you can use the same class to display a variety of custom typefaces in your Android application.

The ListView eschews the typical full-width layout in lieu of a padded layout with white margins on either side. These gutters allow for a persistent fast-scroll bar. Because of the extra white space provided by the gutters, the persistent scroll bar does not obscure the most important information, your contacts. It also provides a convenient way to quickly scrub through a long list of people (most of whom you never talk to anymore).

It was not immediately clear to me how they accomplished this layout. I was still puzzled even after reading through the source of the Contacts application.

Finally, after a great deal of thought and experimentation, I believe I’ve stumbled on the solution, and it’s really quite elegant.

Essentially, the key is the view’s setScrollBarStyle(int style) method. The default style appears to be SCROLLBARS_INSIDE_OVERLAY, which overlays the scroll bar on top of your list items without affecting the layout. This means that adding padding to the list view element will nudge the scroll bar in with the rest of your list content.

However, changing the scroll bar style to SCROLLBARS_OUTSIDE_OVERLAY places the scroll bar at the edge of the ListView, outside of your padding! This means that you can easily add padding to the list view element itself and the scroll bar will stay exactly where you want it.

In practice this can be done with very little effort:

    /** Style the <code>ListView</code> with a persistent scroll bar. */
    @TargetApi(11)
    private void setPersistentScrollBar() {
        ListView lv = getListView();
        lv.setFastScrollEnabled(true);
        lv.setFastScrollAlwaysVisible(true);
        lv.setScrollBarStyle(View.SCROLLBARS_OUTSIDE_OVERLAY);
 
        Resources r = getResources();
        int leftPadding = r.getDimensionPixelSize(
                R.dimen.list_view_padding_left);
        int rightPadding = r.getDimensionPixelSize(
                R.dimen.list_view_padding_right);
 
        // Add left and right padding to the ListView to accommodate the
        // persistent scroll bar.
        lv.setPadding(leftPadding, 0, rightPadding, 0);
    }

Dropping the setPersistentScrollBar() method into your ListActivity or ListFragment and invoking it in your onCreate(Bundle savedInstanceState) or onActivityCreated(Bundle savedInstanceState) (respectively) method should prove sufficient.

The only slightly tricky part is correctly padding the list view. In the example above, we’re specifying the padding in our code. However, you could easily do the same in your XML layout. For the example above to work properly, you’ll need to create a dimens.xml resource in your project’s res/xml directory that contains the following XML:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <dimen name="list_view_padding_left">16dp</dimen>
    <dimen name="list_view_padding_right">32dp</dimen>
</resources>

Finally, if you’re wondering how the pinned list headers work in the Contacts application, you should look over the PinnedHeaderListDemoActivity.java example in the Contact application source.

Happy coding!

!!! Unable to convert unknown Java object class 'org.json.JSONObject$1' to Js value !!!

It took me a long time to track down the cause of this error, but essentially the issue is in the JNI layer, which passes native Java objects to the Javascript layer does not know how to handle a JSONObject.NULL value. The Titanium wrapper object KrollDict attempts to convert all non-native Java objects into native ones. JSONObject becomes a simple Map, JSONArray becomes an ArrayList and so on. However, the constructor fails to account for instances of the JSONObject.NULL object, which is not a simple primitive.

An easy work around would be to ensure the JSON objects that you’re passing around never have any true JSON null values in them. You can replace them with empty strings, or simply remove the key from the object altogether. This is ultimately the fix we went with. However, a simple two-line patch should solve this issue in the core Titanium code:

From 57868ea5b822468563d4a1be2adb901cce383f11 Mon Sep 17 00:00:00 2001
From: Tristan Waddington <tristan.waddington@gmail.com>
Date: Mon, 4 Jun 2012 14:24:15 -0700
Subject: [PATCH] Update the 'fromJSON' method of 'KrollDict' to map the
 'JSONObject.NULL' Object to a real Java null
 representation.
 
---
 android/titanium/src/java/org/appcelerator/kroll/KrollDict.java |    2 ++
 1 file changed, 2 insertions(+)
 
diff --git a/android/titanium/src/java/org/appcelerator/kroll/KrollDict.java b/android/titanium/src/java/org/appcelerator/kroll/KrollDict.java
index da29217..96017d6 100644
--- a/android/titanium/src/java/org/appcelerator/kroll/KrollDict.java
+++ b/android/titanium/src/java/org/appcelerator/kroll/KrollDict.java
@@ -56,6 +56,8 @@ public static Object fromJSON(Object value) {
 					values[i] = fromJSON(array.get(i));
 				}
 				return values;
+			} else if (value == JSONObject.NULL) {
+				return null;
 			}
 		} catch (JSONException e) {
 			Log.e(TAG, "Error parsing JSON", e);
-- 
1.7.10

I submitted a pull request to the titanium_mobile repository on GitHub, but all contributors are required to sign a Contributor License Agreement (CLA). Not a big deal, but I don’t expect to ever submit another patch to this project, so I’m not inclined to spend a day getting their dev environment bootstrapped and sign my life away for a two-line bug fix (yes, I wrote a passive-aggressive blog post instead).

Unfortunately, they don’t even seem interested in accepting the patch as a simple bug report so someone else can fix it:

If you’re trying to build a platform that’s meant to be developer focused, willful disinterest is not the best response. If you’re curious, here’s the raw patch file and the full exception:

When I got back my friends asked me what sessions they should watch. Really the answer is all of them, as they were mostly fantastic. However, I’ve attempted to subjectively compile the best sessions in the list below:

Keynote

• Keynote Day 1
• Keynote Day 2
• Behind the Scenes: Glass Demo Day 2

Android

• What’s New in Android?
• What’s New in Android Developers’ Tools
• Doing More With Less: Being a Good Android Citizen **
• Making Good Apps Great: More Advanced Topics for Expert Android Developers **
• Multi-Versioning Android User Interfaces
• Navigation in Android
• So You’ve Read the Design Guide; Now What?
• Google Cloud Messaging

Google Maps

• What’s New in Google Maps?
• Maps For Good
• Best Practices for Maps API Developers

Web

• Putting the App Back into Web App – Web Programming with Dart
• How to Build Apps that Love Each Other with Web Intents
• Google Compute Engine — Technical Details

Accessibility

• Making Android Apps Accessible
• Advancing Accessibility for the Web
• Developing for a Global Audience: Tools for Localization and Internationalization

Finally, here is a list of all the recorded sessions from Google I/O 2012.

Delete triggers fire when rows are removed due to a REPLACE conflict resolution. This feature is only enabled when recursive triggers are enabled.

This was causing us some grief in one of our Android projects where we were using a virtual table for full-text search. Whenever we updated the products table we had a trigger fire to update the virtual-table. However, when we did a REPLACE into the product table a duplicate entry would be entered into the virtual table. We resolved this issue by turning on recursive triggers.

You can enable recursive triggers by running the following SQL query:

PRAGMA recursive_triggers='ON'

You can easily use the SQLiteDatabase.execSQL method if you’re doing this on Android.

$ cd /path/to/project
 
# Initialize the submodule 
$ git submodule add https://github.com/JakeWharton/ActionBarSherlock
 
# Commit your changes
$ git commit -am "Added ActionBarSherlock submodule."
 
# Ignore local changes in the submodule directory
$ git status --ignore-submodules=dirty

To ignore changes to the submodule directory (in case permission or other changes are required) you can add the following to your .gitmodules file:

[submodule "ActionBarSherlock"]
	path = ActionBarSherlock
	url = https://github.com/JakeWharton/ActionBarSherlock
        ignore = dirty

Once you have a running EC2 instance you’ll need to modify the instance’s security group to open up ports 22, 80 and 443.

The first thing I did was update the EC2 timezone to our local timezone:

$ sudo ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

Install any version control systems you might like to use:

$ sudo apt-get install git

Then pretty much just follow the installation instructions from the Jenkins Wiki. I’ve copied the actual steps here for posterity.

Installing Jenkins:

$ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
$ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
$ sudo aptitude update
 
# Note this will install the openjdk dependencies automatically!
$ sudo aptitude install jenkins

Setting up an Apache Proxy for port 80 -> 8080:

$ sudo aptitude install apache2
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2enmod vhost_alias
$ sudo a2dissite default
$ touch /etc/apache2/sites-available/jenkins

Use your favorite editor to update /etc/apache2/sites-available/jenkins with the following virtual host configuration:

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	ServerName ci.company.com
	ServerAlias ci
	ProxyRequests Off
	<Proxy *>
		Order deny,allow
		Allow from all
	</Proxy>
	ProxyPreserveHost on
	ProxyPass / http://localhost:8080/
</VirtualHost>

Enable the new jenkins virtual host and restart apache:

$ sudo a2ensite jenkins
$ sudo apache2ctl restart

Jenkins should now be live and accessible from port 80! Now you can begin configuring Jenkins to your liking. I’ll follow-up with a post highlighting our Jenkins configuration. For now, here are the plugins we’ve chosen to install:

• Green Balls
• Post build task
• Instant Messaging Plugin
• IRC Plugin
• Rake plugin
• Git Plugin
• Github Plugin
• GitHub API Plugin
• Github OAuth Plugin