Anyway, for the good of the people here are 2 blog posts I found helpful. I was using Xcode 4.6.

http://blog.stevex.net/2012/04/static-libraries-in-xcode – I found this the most useful for setting up the dependency, however steps 10 to 16 weren’t needed for Xcode 4.6. Probably because Apple fixed a bug.

http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4 – The instructions for setting up a dependency didn’t quite work for some reason. However, the section on creating a static library is useful.

Installing and setting up is as simple as installing VirtualBox and importing the Android VirtualBox images available here.

To debug and install your apps using adb:

1. Get the IP address of the VM from the AndroVM Config app running in the VM. If the app doesn’t show an IP address make sure you’ve created a host only network in the VirtualBox preferences and configured the VM to use that host only adapter as “Adapter 1″.
2. Execute ‘adb connect <IP address>’
3. From this point the standard adb commands (such as ‘adb install’) should work.

AndroVM is still in it’s infancy and as such does have a few bigger limitations:

• Only Android 4.1 images are available.
• The available screen resolutions are limited but can be easily selected using the AndroVM Config app running in the VM.

On the plus side, the team behind AndroVM have promised configuration management software to make it easier to create and run different Android configurations. Additionally the software will also automatically connect adb with the VM.

Table view cells are displayed using a UITableView which is a subclass of UIScrollView and as such inherits the ability to scroll. A scroll view intercepts touch events and has a short delay to check if the touch event is part of a scroll gesture. If it isn’t then the touch event is passed onto the corresponding view. That explains the delay in the button highlight state.

We can remove the delay by setting UIScrollView.delaysContentTouches to NO. A side effect of this change is that scroll gestures cannot start from the buttons. Depending on how big your buttons are this might not be ideal. The work around for this is to override the (BOOL)touchesShouldCancelInContentView:(UIView *)view method in your UITableView subclass like so:

- (BOOL)touchesShouldCancelInContentView:(UIView *)view {
    // Because we set delaysContentTouches = NO, we return YES for UIButtons 
    // so that scrolling works correctly when the scroll gesture 
    // starts in the UIButtons.
    if ([view isKindOfClass:[UIButton class]]) {
        return YES;
    }

    return [super touchesShouldCancelInContentView:view];
}

You can make state list drawables even more useful by defining custom states.

This is a screenshot of a hypothetical email client, notice the difference between read and unread messages.

The recommended implementation for a screen like this would be to use a ListView. In this example, each item in the list is a RelativeLayout containing an ImageView and a TextView. When displaying each item you could manually switch between the two images used and set the background colour accordingly. However, by defining a custom state you can make it simpler and easier to maintain.

Step 1: declare the custom state attribute

The custom state is declared in the ‘attrs.xml’ file in the application’s ‘res/values’ directory.

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <declare-styleable name="MessageState">
        <attr name="state_message_unread" format="boolean"/>
    </declare-styleable>

</resources>

Step 2: use the custom state in the state list drawables

In the message list example there are two state list drawables.

One for the list item background:

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:example="http://schemas.android.com/apk/res/com.charlesharley.example.android.customdrawablestates"
          >

    <!--
    We make the pressed and focused selector items transparent so the ListView's own selector states show through.
    -->

    <item android:state_pressed="true"
          android:drawable="@android:color/transparent"
          />

    <item android:state_focused="true"
          android:drawable="@android:color/transparent"
          />

    <item example:state_message_unread="true"
          android:drawable="@color/message_list_item_background_unread"
          />

</selector>

And one for the message status icon:

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:example="http://schemas.android.com/apk/res/com.charlesharley.example.android.customdrawablestates"
          android:constantSize="true"
          >

    <item example:state_message_unread="true"
          android:drawable="@drawable/message_read_status_unread"
          />

    <item android:drawable="@drawable/message_read_status_read" />

</selector>

To use the custom state all you need to do is declare a new XML namespace using your application’s package name and prefix the custom state attribute with the new namespace.

Step 3: update the view’s drawable state to include the custom state

Each view provides a number of existing states that can be used by its drawables where applicable, e.g. a CheckBox has a checked state. By overriding View.onCreateDrawableState() a custom view can inject its own states, which are then made available to the view’s drawables.

In the message list example, the relative layout that contains the image view and the text view is a custom implementation that maintains an unread state, which when set, updates the view’s drawable states resulting in the different look for read and unread messages.

public class MessageListItemView extends RelativeLayout {

    private static final int[] STATE_MESSAGE_UNREAD = {R.attr.state_message_unread};

    private boolean messageUnread;

    // Constructors, view loading etc...

    @Override
    protected int[] onCreateDrawableState(int extraSpace) {
        // If the message is unread then we merge our custom message unread state into
        // the existing drawable state before returning it.
        if (messageUnread) {
            // We are going to add 1 extra state.
            final int[] drawableState = super.onCreateDrawableState(extraSpace + 1);

            mergeDrawableStates(drawableState, STATE_MESSAGE_UNREAD);

            return drawableState;
        } else {
            return super.onCreateDrawableState(extraSpace);
        }
    }

    public void setMessageUnread(boolean messageUnread) {
        if (this.messageUnread != messageUnread) {
            this.messageUnread = messageUnread;

            // Refresh the drawable state so that it includes the message unread
            // state if required.
            refreshDrawableState();
        }
    }

}

What about the message status image view? Good question! Because the image view is a child of our custom view we tell it to duplicate its parent state using View.setDuplicateParentStateEnabled(). Any state in the parent is passed down to the children including custom states. Brilliant!

The example Android application used for this tutorial is hosted here on Github.

Check it out here: https://play.google.com/store/apps/details?id=com.tinystopwatch.android

• Converting a pixels value to the corresponding density independent pixels (DIP) value and vice versa
• Getting the screen dimensions
• Checking what orientation the device is in
• Getting the screen size (small, normal, large, extra-large)

They’re not difficult but it is annoying having to remember exactly how they’re done so I created a utility class to make it a bit easier. Here it is:

A well behaved activity will restore its state after a rotation so the user can continue using the application with no lose of state. e.g. EditText widgets should restore the text they contained when the device was rotated and a long running operation should resume without restarting.

There are a few topics to understand to achieve this effectively but one that I’d like to talk about is views saving and restoring their instance state. In most cases saving state is actually very simple but when creating compound views a couple extra steps are required. Compound views combine multiple views into a single convenient reusable view, e.g. the NumberPicker.

Saving individual views

For individual views, saving instance state is as simple as defining a unique ID for each view that you want to save its state. The activity will take care of the rest!

Note: IDs only need to be unique within the activity where they are used.

How saving instance state works

The instance state of each view within an activity is saved in shared persisted data with the state for each view referenced using the view’s ID. Hence why the IDs need to be unique.

To save state the activity traverses the layout hierarchy and for each view it encounters it calls View.saveHierarchyState() which in turn calls View.dispatchSaveInstanceState(). If the view has an ID this method calls View.onSaveInstanceState(), which saves its state to a Parcelable object and returns it. View.dispatchSaveInstanceState() then takes the Parcelable and saves it to the shared persisted data using the ID of the view.

Restoring state is a very similar process with the activity traversing the layout hierarchy and for each view it calls View.restoreHierarchyState() which in turn calls View.dispatchRestoreInstanceState(). If the view has an ID this method retrieves the corresponding Parcelable from the shared persisted data and passes it through to View.onRestoreInstanceState(), which then restores the view’s state.

ViewGroup, which extends View, modifies the process slightly to pass the call to View.dispatchSaveInstanceState() onto its child views.

Simple really!

Saving compound views

Saving instance state for compound views works in the same way as individual views but does require a little extra work when creating them to ensure that if an activity contains more than one instance of the same compound view, its state is correctly saved.

Compound views contain one or more child views and if an activity contains multiple instances of the same compound view then the IDs of the child views are no longer unique. To resolve this issue, the compound view class needs to take on the responsibility of saving and restoring the state of its child views.

To make it easier to understand I’ve created an example project that defines a compound view that correctly saves and restores the state of its child views. The project is hosted here on Github. The project contains various files to make the application work but if you want to skip to the important bit take a look at the LockCombinationPicker class. It contains 4 overridden methods that ensure the state of the child views are correctly saved and restored.

@Override
protected Parcelable onSaveInstanceState() {
    Parcelable superState = super.onSaveInstanceState();
    return new SavedState(superState, numberPicker1.getValue(), numberPicker2.getValue(), numberPicker3.getValue());
}

@Override
protected void onRestoreInstanceState(Parcelable state) {
    SavedState savedState = (SavedState) state;
    super.onRestoreInstanceState(savedState.getSuperState());

    numberPicker1.setValue(savedState.getNumber1());
    numberPicker2.setValue(savedState.getNumber2());
    numberPicker3.setValue(savedState.getNumber3());
}

@Override
protected void dispatchSaveInstanceState(SparseArray container) {
    super.dispatchFreezeSelfOnly(container);
}

@Override
protected void dispatchRestoreInstanceState(SparseArray container) {
    super.dispatchThawSelfOnly(container);
}

LockCombinationPicker saves and restores the state of its children by overriding View.onSaveInstanceState() and View.onRestoreInstanceState() much as you would expect. In addition to this we need to ensure the compound view’s children aren’t then called to save their state as well. We do this by overriding View.dispatchSaveInstanceState() and View.dispatchRestoreInstanceState() and calling ViewGroup.dispatchFreezeSelfOnly() and ViewGroup.dispatchThawSelfOnly() respectively. These methods ensure that View.onSaveInstanceState() and View.onRestoreInstanceState() are called on the compound view class and not on the child views.

And that is it! To then save and restore the state of the compound view(s) within an activity just give it a unique ID.

Android v iOS App Development from Kotikan on Vimeo.

The book is essentially a high level introduction to application security when programming for the Android platform but does go into sufficient depth to give you a decent understanding. It covers the following key topics:

• Risk assessment
• Android permissions system
• Storing data securely
• Securing server communication

Having studied computer science at university the last two key topics were familiar but it is amazing how much you forget! By far the most useful chapters were on the Android permissions systems. I don’t have sufficient knowledge on application security to properly review the book (hence why I bought it). However, at just under 100 pages it is a good introduction to the topic and very easy to read.

To achieve this, the documentation indicates that you should use:

XML:

<TextView android:inputType="textNoSuggestions" />

Java:

TextView.setInputType(InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS)

Annoyingly some HTC devices ignore this option and so a common approach has been instead to use:

XML:

<TextView android:inputType="textVisiblePassword" />

Java:

TextView.setInputType(InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD)

Although this does work, it will restrict the keyboard language on some HTC devices to English. A better approach, that appears to work across all devices, is:

XML:

<TextView android:inputType="textFilter" />

Java:

TextView.setInputType(InputType.TYPE_TEXT_VARIATION_FILTER)