Charles Harley

Getting Xcode static libraries to work

Sun, 03 Mar 2013 00:00:00 +0000

Getting Xcode static library dependencies to work is way harder than it should be! This weekend I setup a new Xcode OS X workspace with 2 child projects. One project was the app and the other a static library used by the app. Setting the static library as a dependency of the app project took ages. Part of the reason was my lack of knowledge but Xcode should really give a bit more help.

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.

Using AndroVM

Mon, 14 Jan 2013 00:00:00 +0000

Update: the team behind AndroVM have released Genymotion. It greatly simplifies the downloading of device images and automatically connects them to adb.

AndroVM is a novel alternative to the Android emulator with Android running in a virtual machine (VM) using VirtualBox. It works quite well and for some requirements can be significantly faster than the Android emulator.

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:

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”.
Execute ‘adb connect '
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 the VM to adb.

UIButton in UITableViewCell has no highlight state

Tue, 08 Jan 2013 00:00:00 +0000

I recently created a custom UITableViewCell with a UIButton as a subview. Pretty standard except that the highlight state of the button was only activated if you held your finger on the button for more than some fraction of a second. The solution is quite straight forward but is subtle enough to justify a quick blog post.

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 = 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];
}

Custom drawable states in Android

Thu, 07 Jun 2012 00:00:00 +0100

A state list drawable is a really useful Android resource for displaying different drawables for a view depending on the state of that view. e.g. we can define a state list drawable for the background of a button that defines a colour for both pressed and unpressed states. The button takes care of switching between the two drawables depending on the state.

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!

View example application on Github

Tiny Stopwatch for Android

Tue, 08 May 2012 00:00:00 +0100

Today I released my first personal Android app into the Google Play Store. It is a stopwatch app that supports multiple stopwatches and is designed to work across phones and tablets. It is also built from the ground up to fit in with the new design paradigms used in the latest versions of Android such as the action bar. I also just wanted a better looking stopwatch app.

Android screen utility class

Fri, 27 Apr 2012 00:00:00 +0100

There are a few common operations I infrequently perform related to the Android screen:

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:

Views saving instance state in Android

Sat, 03 Mar 2012 00:00:00 +0000

The activity lifecycle is central to Android development. Although it is quite well defined, it does take a bit of getting used to. One aspect new developers perhaps struggle with is that rotating the device will by default destroy and recreate the activity.

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!

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 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.

View example application on Github

Android vs iOS development presentation

Thu, 09 Feb 2012 00:00:00 +0000

My colleague, Nick Street, and I gave an ‘Android vs iOS Development’ presentation for Edinburgh Student TechMeetup on behalf of Kotikan. We only had about 25 minutes so didn’t go into too much depth. Was good fun and worth a watch just to find out who wins.

Book review: Application Security for the Android Platform

Tue, 03 Jan 2012 00:00:00 +0000

Just finished reading ‘Application Security for the Android Platform: Processes, Permissions, and Other Safeguards’ by Jeff Six.

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.

Disabling Android TextView suggestions

Wed, 07 Dec 2011 00:00:00 +0000

Android TextViews provide suggestions to the user as they type. Although the user can disable this feature in the system settings there are cases where the developer wants to always have suggestions disabled for certain TextViews.

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)