He interviewed co-founder and CTO Ben Medlock because he wanted to find out more about the “geek behind SwiftKey”.

Watch his Google Hangout with Ben and CMO Joe Braidwood here:

Scoble, Rackspace’s Startup Liaison Officer and a familiar face on the tech scene around the world, said he’d only been using his Android smartphone a day but was already 40% faster at typing thanks to SwiftKey.

Where do you stand on Android versus iOS? Join the debate in the comments or on the SwiftKey Facebook page.

The post Scoble: SwiftKey No 1 reason I switched to Android appeared first on SwiftKey.

Today we played host to Jouko Kaasila and Henri Kivelä from Bitbar, who came to talk to us about automated cloud-based testing for Android.

Michele Sama (second from right), SwiftKey’s Test Architect, will tell us a little about what they talked about.

Software testing is a critical activity for any software company. From a purely commercial perspective bugs and slow performance are the main reasons for which users stop using a piece of software. From a managerial perspective the cost, in terms of development time, of detecting and fixing bugs increases exponentially the longer a bug exists in the code.

The combination of continuous integration and automated testing is one of the most powerful instruments which quality engineers have to improve the quality of their software during any stage of development.

Developing for mobile platforms such Android proposes an additional challenge to traditional continuous integration systems: the variety of devices on which your software must work. It may sound obvious but even if your tests pass on an emulator your application may still have problems with certain devices. Such problems are known as “integration issues” and are detected by the so called “integration tests”.

Here at SwiftKey we support 7 versions of Android, on at least 10 different screen sizes with over 50 languages. To test all of those combinations we would have to run our integration tests on 7 * 10 * 50 = 3,500 configurations. This would be eventually possible by using, for instance, Jenkins and by running our tests on a matrix of configurations using the Android emulator.

Should we run our tests 3,500 times?

The answer is probably not. First, not all of those combinations exist, which means that in case of errors you will need to exclude false positives. Second, a configured emulator is still an emulator and it will not detect device-related integration faults. Third, when a single test fails then you will have 3,500 failures!

How should we run our integration tests then?

That is simple. You should run them on all the devices that you support. How much will it cost you? How difficult would it be to maintain them? Well… a lot.

The people at BitBar think they have the answer.

The idea behind Testdroid is simple. They own a cloud of devices, including more than 150 different models, and they let you run your tests on those devices using their web frontend. You can then configure a set of “must work” devices (including the most popular devices) and you run your tests on those at every commit using a Jenkins plugin.

The next step is to test the integration with more of the market devices to see which ones your application supports. Once again we can create two cluster of phones, one with all the “fully supported” devices and one with the “not fully supported” ones. You can then, daily or weekly or every now and then, check which devices you support and make sure that all the tests pass in those ones that are fully supported. On each test run Testdroid also collects CPU and memory usage of your execution, making it possible for quality engineers to check for performance issues or memory leaks. You can also select the language with which to configure your devices before the execution.

The latest addition to the tools available in Testdroid cloud is the Android app crawler. In a similar way in which a web crawler browses a web site, the app crawler explores your application view by view and generates a graph representation of each view, including a screenshot for each device. Being able to obtain screenshots from all the devices under test without manually clicking through is very useful.

One thing that scares me as a quality engineer is the adoption of new tools and library. Before adopting one I always need to write down what I call the “adoption risk analysis”. I absolutely do not want to be forced to ask the team to rewrite all the tests because we have to change a testing tool. With Testdroid this is absolutely not an issue. Testdroid runs (and generates) normal Android instrumentation tests which means that there are no adoption (and no leave) costs.

To thank Jouko and Henri for their visit, after all they came all the way from Finland to give us a talk, we decided to show them a preview of few new tools which we have developed internally.

Keith is a pre-build configuration tool which uses a set of Python scripts to change the Android resource files for a specific build. Keith lets you define products (targets) and modifiers (rules) and lets you apply modifiers to each product.

SlimChimp is a Java extension of MonkeyRunner inspired by ChimpChat which lets you install and control Android applications exploring the elements on the screen of the device. With SlimChimp not only we can install and enable SwiftKey as a keyboard during our tests but we can also test it on third party applications of which we do not have the source code.

Chauffeur is an Android testing support tool which avoids code duplication in your test setUp and tearDown method by configuring and restoring your test environment for you.

You will probably hear more about these tools in near future.

You can find out more about Bitbar and what they do at http://testdroid.com/.

The post Bitbar – Automated cloud-based testing for Android appeared first on SwiftKey.

Today, at DroidCon UK 2011, I presented the TouchType way of dealing with configuring Android APKs. We’ve come up with a clean framework to generate different APKs from a single source tree according to given feature requirements. (Our system is a bit clever than the slides suggest, but it gives you a good basis to start from.)

Download the presentation slides here

My question to you is this: If we open-sourced our framework for APK configuration would you find it beneficial?

Chetan.

The post Building APKs with different features from a single source appeared first on SwiftKey.

• Video of the talk
• TDD on Android slides
• Sample code

If you have ideas of how we can improve testing on Android, please get in touch! You never know… we might just hire you!

The post Test-Driven Development on Android using native Scala Mocking and Dependency Injection appeared first on SwiftKey.

Do you think you fit the bill? If so, check out our job description here. No recruiters please.

Cheers!

Joe

The post Are you a super web dev? appeared first on SwiftKey.

The code of the application described here is checked into GitHub.

Given that we can’t mock PowerManager directly, instead we’re going to create an interface that we can mock:

public interface PowerControl
{
    void disablePowerOff();
    void enablePowerOff();
}

Together with an implementation which will be used in production code:

public class PowerControlImpl implements PowerControl
{
    public PowerControlImpl(Context context) {
        PowerManager powerManager = (PowerManager)
            context.getSystemService(Context.POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(
            PowerManager.FULL_WAKE_LOCK, "PowerControl");
    }

    public void disablePowerOff() {
        wakeLock.acquire();
    }

    public void enablePowerOff() {
        wakeLock.release();
    }

    private PowerManager.WakeLock wakeLock;
}

We won’t be able to test this implementation, but hopefully it’s so simple that (as Hoare puts it) it obviously contains no deficiencies (as opposed to contains no obvious deficiencies).

But we do now have something that we can mock, so we can test that the code that calls it does so correctly.

The first challenge we’re going to have to overcome is how to inject a PowerControl implementation (the real one or the mock) into the code under test. We could use a dependency injection framework like RoboGuice, but for the purposes of this article I’m going to keep things simple and use a custom Application class which implements a getPowerControl method:

public class PowerControlApplication extends Application
{
    public void onCreate() {
        powerControl = new PowerControlImpl(this);
    }

    public PowerControl getPowerControl() {
        return powerControl;
    }

    protected PowerControl powerControl;
}

Our activity calls this during onCreate:

public class PowerActivity extends Activity
{
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        PowerControlApplication app =
            (PowerControlApplication)getApplication();
        powerControl = app.getPowerControl();
    }

    public void startImportant(View button) {
        powerControl.disablePowerOff();
    }

    public void stopImportant(View button) {
        powerControl.enablePowerOff();
    }

    private PowerControl powerControl;
}

We can now write a test to verify that startImportant calls disablePowerOff:

class PowerActivityTest
  extends ActivityUnitTestCase[PowerActivity](classOf[PowerActivity])
  with MockFactory {

  val startIntent = new Intent(Intent.ACTION_MAIN)

  def testStartImportant {
    val mockPowerControl = mock[PowerControl]
    val application = new PowerControlApplication {
      powerControl = mockPowerControl
    }
    setApplication(application)
    startActivity(startIntent, null, null)

    withExpectations {
      mockPowerControl expects 'disablePowerOff once

      getActivity.startImportant(null)
    }
  }
}

Our test first creates a mock PowerControl object:

    val mockPowerControl = mock[PowerControl]

And then creates an application object that returns this mock instead of a “real” PowerControl instance:

    val application = new PowerControlApplication {
      powerControl = mockPowerControl
    }

We tell Android’s test framework to use this application object by calling setApplication:

    setApplication(application)

Finally, we set our expectation (that disablePowerOff is called once) and call startImportant:

    mockPowerControl expects 'disablePowerOff once

    getActivity.startImportant(null)

The post Mock objects on Android with Borachio: Part 3 appeared first on SwiftKey.

But there’s a wrinkle. Android is the most test-hostile environment I’ve ever had the misfortune to find myself working in. I wonder sometimes if its designers deliberately designed it to make testing as difficult as they possibly could. It can be done, and I’ll show how in part 3, but if you’ll forgive me a digression, in this article I’m going to try the simple, “obvious” solution and demonstrate why it doesn’t work.

I’m going to try to write a simple test of an application that uses Android’s PowerManager service. PowerManager allows us to control when the device switches on or off. If we’re about to start some critical operation that must complete without the device switching off, we can obtain a WakeLock, which is what this sample app does.

The code is checked into GitHub. Here’s the code that we want to test:

package com.paulbutcher.powercontrol;

import android.app.Activity;
import android.os.Bundle;
import android.os.PowerManager;
import android.view.View;

public class PowerControl extends Activity
{
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }

    public void startImportant(View button) {
        PowerManager powerManager =
            (PowerManager)getSystemService(POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(
            PowerManager.FULL_WAKE_LOCK, "PowerControl");
        wakeLock.acquire();
    }

    public void stopImportant(View button) {
        wakeLock.release();
    }

    private PowerManager.WakeLock wakeLock;
}

Let’s try to write a test that verifies that startImportant calls PowerManager.newWakeLock. Our first task is going to be working out how to inject a mock PowerManager into the code under test.

That code obtains its PowerManager instance by calling Context.getSystemService. Happily, Android provides MockContext and ActivityUnitTestCase.setActivityContext, so we should be all set.

Before we get carried away, let’s just verify that we can get a test using a MockContext to run at all:

  def testAttempt1 {
    val mockContext = new MockContext;
    setActivityContext(mockContext)
    startActivity(startIntent, null, null)
  }

Let’s see what happens when we run that:

Failure in testAttempt1:
junit.framework.AssertionFailedError
  at android.test.ActivityUnitTestCase.startActivity(ActivityUnitTestCase.java:148)

Hmm—apparently this isn’t going to be as easy as we hoped.

The problem is that startActivity calls our MockContext. Specifically it calls getSystemService("layout_inflater") which fails because MockContext‘s methods are non-functional and throw UnsupportedOperationException.

It turns out that what Android means by “mock” isn’t what the rest of the world means. As Martin Fowler says in Mocks Aren’t Stubs, mocks are:

objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Never mind—there is another way. Android’s ContextWrapper allows us to wrap an existing context, only changing those bits of functionality we’re interested in for the purposes of our test:

  def testAttempt2 {
    val testContext =
        new ContextWrapper(getInstrumentation.getTargetContext);
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

That works, so now we just need to modify it to return a mock PowerManager when getSystemService is called:

  def testAttempt3 {
    val mockPowerManager = mock[PowerManager]
    val testContext =
      new ContextWrapper(getInstrumentation.getTargetContext) {
        override def getSystemService(name: String) = name match {
          case "power" => mockPowerManager
          case _ => super.getSystemService(name)
        }
      }
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

Which looks great, right up until we run it:

Error in testAttempt3:
java.lang.IllegalArgumentException: android.os.PowerManager is not an interface

Borachio, in common with most other mocking frameworks, can only mock interfaces, and PowerManager is a class, not an interface. There are mocking frameworks that can mock classes, for example PowerMock, but they rely on code generation, which Android’s Dalvik VM doesn’t (yet) support. So that’s not going to be any help

There’s one final thing we can try. As well as mocking interfaces, Borachio can also mock functions. So we can derive from PowerManager and just mock the single method we’re interested in like this:

  def testAttempt4 {
    val mockNewWakeLock =
      mockFunction[Int, String, PowerManager#WakeLock]
    val mockPowerManager = new PowerManager {
      override def newWakeLock(flags: Int, tag: String) =
        mockNewWakeLock(flags, tag)
    }
    val testContext =
      new ContextWrapper(getInstrumentation.getTargetContext) {
        override def getSystemService(name: String) = name match {
          case "power" => mockPowerManager
          case _ => super.getSystemService(name)
        }
      }
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

But, when we compile this, we get:

PowerControlTest.scala:53: error: constructor PowerManager cannot be accessed in anonymous class $anon
    val mockPowerManager = new PowerManager {
                               ^

PowerManager‘s constructor is private

And at this point, we’re out of easy options. We can’t play the same trick with PowerManager as we played with Context, as there’s no PowerManagerWrapper or similar.

We’re not beaten yet—I’ll show how to get around this problem in part 3 of this series. Small wonder, however, that most of the Android code I’ve seen has virtually no tests!

The post Mock objects on Android with Borachio: Part 2 appeared first on SwiftKey.

One of my biggest frustrations with writing code for Android has been the fact that none of the current Java mocking frameworks work on Android’s Dalvik VM. I recently released Borachio a native Scala mocking framework which does work on Android.

Because Borachio is written in Scala, you’ll need to write your tests in Scala. But it can be used to test code written in Java.

This post demonstrates how to get basic mocking working. Things get more complicated when you try to mock bits of Android itself, but I’ll cover that in a subsequent article.

This is an Android version of the example in Martin Fowler’s article Mocks Aren’t Stubs. The code is checked into GitHub here. You’ll need to have the Android SDK and Scala 2.8 installed to run this code.

We’re going to build a (very) simple ordering system. Orders will succeed if there’s enough inventory in our warehouse and fail if not. Let’s start by creating a very simple little Android application for us to test:

1. Create a new project with:

   android create project -p WarehouseManager -t android-8
       -p warehousemanager -k com.example.warehousemanager
       -a WarehouseManager

2. The core abstraction is a warehouse, represented by a Warehouseinterface:

   package com.example.warehousemanager;
   
   public interface Warehouse {
       boolean hasInventory(String product, int quantity);
       void remove(String product, int quantity);
   }

3. And here’s a very simple concrete implementation of Warehouse:

   package com.example.warehousemanager;
   
   import java.util.HashMap;
   
   public class RealWarehouse implements Warehouse {
       public RealWarehouse() {
           products = new HashMap();
           products.put("Talisker", 5);
           products.put("Lagavulin", 2);
       }
   
       public boolean hasInventory(String product, int quantity) {
           return inStock(product) >= quantity;
       }
   
       public void remove(String product, int quantity) {
           products.put(product, inStock(product) - quantity);
       }
   
       private int inStock(String product) {
           Integer quantity = products.get(product);
           return quantity == null ? 0 : quantity;
       }
   
       private HashMap products;
   }

4. We remove things from the warehouse by placing an Order:

   package com.example.warehousemanager;
   
   public class Order {
   
       public Order(String product, int quantity) {
           this.product = product;
           this.quantity = quantity;
       }
   
       public void fill(Warehouse warehouse) {
           if (warehouse.hasInventory(product, quantity)) {
               warehouse.remove(product, quantity);
               filled = true;
           }
       }
   
       public boolean isFilled() {
           return filled;
       }
   
       private boolean filled = false;
       private String product;
       private int quantity;
   }

5. We’ll need a UI to allow us to make orders, so modify main.xmlto look like this:

6. And finally, here’s the implementation of WarehouseManager:

   package com.example.warehousemanager;
   
   import android.app.Activity;
   import android.os.Bundle;
   import android.view.View;
   import android.widget.EditText;
   import android.widget.Toast;
   
   public class WarehouseManager extends Activity
   {
       /** Called when the activity is first created. */
       @Override
       public void onCreate(Bundle savedInstanceState)
       {
           super.onCreate(savedInstanceState);
           setContentView(R.layout.main);
   
           productEditText = (EditText)findViewById(R.id.product);
           quantityEditText = (EditText)findViewById(R.id.quantity);
       }
   
       public void placeOrder(View view) {
           String product = productEditText.getText().toString();
           int quantity = Integer.parseInt(quantityEditText.getText().toString());
           Order order = new Order(product, quantity);
           order.fill(warehouse);
   
           String message = order.isFilled() ? "Success" : "Failure";
           Toast toast = Toast.makeText(this, message, Toast.LENGTH_SHORT);
           toast.show();
       }
   
       private Warehouse warehouse = new RealWarehouse();
   
       private EditText productEditText;
       private EditText quantityEditText;
   }

You should now have a little Android application that can be compiled and installed with ant install. Here’s what it looks like:

So, now that we’ve got something to test, let’s create a test project to test it:

1. Create a test project with:

   android create test-project -p test -m .. -n WarehouseManagerTest

   Next, we’ll convert this to a Scala project, as described here.

2. Add scala.dir and proguard.dir to local.properties. Here’s what I added to mine (you’ll need to change the paths to match your local installation):

   scala.dir=/opt/local/share/scala-2.8
   proguard.dir=/Users/paul/android-sdk-mac_86/tools/proguard/

3. Copy build-scala.xml into the root of the test project and add the following to build.xml:

4. Delete the proguard.cfg file and copy the configs directory into the test project. Add the following to the bottom of both default-debug.cfg and default-release.cfg(to ensure that ProGuard doesn’t discard our test classes:

   -keep public class * implements junit.framework.Test { public void test*(); }

5. Copy the Borachio JAR to the libs directory.
6. Finally, we can write our tests, which create mock instances of the Warehouseinterface:

   package com.example.warehousemanager;
   
   import junit.framework.TestCase
   import com.borachio.junit3.MockFactory
   
   class OrderTest extends TestCase with MockFactory {
   
     def testInStock() {
       withExpectations {
         val mockWarehouse = mock[Warehouse]
         inSequence {
           mockWarehouse expects 'hasInventory withArguments ("Talisker", 50) returning true once;
           mockWarehouse expects 'remove withArguments ("Talisker", 50) once
         }
   
         val order = new Order("Talisker", 50)
         order.fill(mockWarehouse)
   
         assert(order.isFilled)
       }
     }
   
     def testOutOfStock() {
       withExpectations {
         val mockWarehouse = mock[Warehouse]
         mockWarehouse expects 'hasInventory returns false once
   
         val order = new Order("Talisker", 50)
         order.fill(mockWarehouse)
   
         assert(!order.isFilled)
       }
     }
   }

7. Run the tests with:

   ant run-tests

In part 2, we’ll look at some of the challenges of mocking Android components.

The post Mock objects on Android with Borachio: Part 1 appeared first on SwiftKey.

We’re going to start off with a series of articles on Android development (originally published here).

In Testing a library project the Android documentation says:

There are two recommended ways of setting up testing on code and resources in a library project:

• You can set up a test project that instruments an application project that depends on the library project. You can then add tests to the project for library-specific features.
• You can set up a set up a standard application project that depends on the library and put the instrumentation in that project. This lets you create a self-contained project that contains both the tests/instrumentations and the code to test.

How to achieve the first of these is pretty obvious, but the second (to me, at least) rather less so. I wasn’t able to find an example, so I thought that I’d post how I managed to get it working.

Although it does work, I’m not 100% happy with it, and there may well be a nicer way to achieve this (see the end of this post for a discussion about my concerns). I would be very grateful for any suggestions for improvements.

Note, we don’t build with Eclipse (partly because we’ve found its reliability leaves a lot to be desired, but mainly because we need a command line build in order to be able to integrate with the rest of our build system and continuous integration server). So all of the following uses the Android command line tools.

The steps

1. Create a new library project as follows:

   android create lib-project -n ExampleLib -t android-8
   -p examplelib -k com.example.lib

2. In that project, create src/com/example/lib/Widget.javacontaining:

   package com.example.lib;
   
   public class Widget {
       public String getColour() {
           return "blue";
       }
   
       public String getDisposition() {
           return "awesome";
       }
   }

3. In the examplelibdirectory, create a test project with:

   android create test-project -m .. -p test -n ExampleTest

4. Edit the AndroidManifest.xmlin the test project and change the line:

   android:targetPackage="com.example.lib"

   to:

   android:targetPackage="com.example.lib.tests"

5. Delete the following line from the build.propertiesin the test project:

   tested.project.dir=..

   and add the following:

   android.library.reference.1=..

6. Delete the src/com/example/lib/ACTIVITY_ENTRY_NAMETest.java file.
7. Create src/com/example/lib/WidgetTest.javacontaining:

   package com.example.lib;
   
   import junit.framework.TestCase;
   
   public class WidgetTest extends TestCase {
   
       private Widget widget;
   
       @Override
       protected void setUp() {
           widget = new Widget();
       }
   
       public void testColour() {
           assertEquals("blue", widget.getColour());
       }
   
       public void testDisposition() {
           assertEquals("awesome", widget.getDisposition());
       }
   }

8. Start an emulator and install with ant install.
9. Run the tests with:

   adb shell am instrument
   -w com.example.lib.tests/android.test.InstrumentationTestRunner

Reservations

It’s clear from the above that the Android tools (the command line tools, at least—perhaps the Eclipse plugin is better?) don’t really fully support this way of working. Not least the fact that they assume that we’re always testing an activity in another application (hence the strangely named ACTIVITY_ENTRY_NAMETest.java file).

1. In step 4, we changed the targetPackage. This is necessary because if we leave it as com.example.lib, Android will try to launch an application with that package name, which doesn’t exist. However, it’s something of a lie to suggest that the targetPackage is com.example.lib.tests
2. In a normal Android test project, we can run the tests by typing:

   ant run-tests

   We have to run the tests explicitly with adb, however, because in step 5, we deleted the tested.project.dir line. If we don’t, the ant build system will try to rebuild the library project (and library projects can’t be build independently).

   An alternative to the solution presented above is to set tested.project.dir to the current directory (.). This enables ant run-tests, but at the expense of building the project twice.

So, it all works, but it’s a bit messy. Suggestions for improvements very welcome!

The post Android library project with tests, step by step appeared first on SwiftKey.

At last month’s DroidCon Android conference in London, I pitched our app at the AppCircus competition and we won. This officially marks the first ‘best app’ award won by SwiftKey and is great news! In my pitch for the app, I explained a bit about our big plans for SwiftKey, and why we’re so excited about the technology behind it. I thought I’d share my thoughts with you.

But first, let me introduce myself. I’m Ben Medlock, TouchType’s Chief Technical Officer. I co-founded the company just over two years ago with Jon Reynolds, our CEO. Together, we set out with the simple goal of making text entry on handheld devices easier and more intuitive.

By using intelligent technology, we were confident we could find a better way to get the thoughts out of your head and on to your phone. Since then, we have gathered a team of exceptional people to help us make that happen, and my job is to ensure our products remain at the cutting edge of innovation in handheld communication.

Getting electronic devices to do intelligent things with human languages is no simple task. In the past, it took teams of programmers and linguists years to build rudimentary systems for performing basic language tasks and these systems were usually frail and unreliable. Recently, people started to wonder if rather than telling a computer exactly what to do, they could build programs that would learn for themselves when shown the right sort of data. We call this “machine learning.”

It turns out that machine learning is a pretty good way to deal with the complexities of human language… the only problem is you need fast computers and LOTS of data. SwiftKey sometimes feels like it’s reading your mind because it’s already read words written by millions of other people, gleaned from a variety of sources including the World Wide Web. Of course, it also learns from your own writing as you use it.

In the next few months, we’ll be making it easier to tailor SwiftKey to the type of look and feel that you want. We also have some great ideas for making the suggestion buttons easier to use, and we’ll be introducing even more advanced correction mechanisms that don’t just work out when you hit the wrong keys, but also recognize when you miss a letter or spell a word the wrong way.

We are really proud of what we’ve achieved so far, but this is just the beginning of our plans to enhance communication on handhelds. We’re working on new techniques that put our machine learning and artificial intelligence expertise to powerful effect, and will make even the technology in SwiftKey feel like yesterday’s news. Our vision is to design software that really feels like it’s working with you to make writing fun, creative and as fast as you can think.

Happy typing!

Ben

Chief Technical Officer, TouchType

The post The clever stuff behind SwiftKey’s success appeared first on SwiftKey.