So let us look at some Design/Prototyping tools:

Sketch 3 (Bohemian Coding)

Sketch 3 is a Vector based design application. It’s easy to use, and has a low learning curve. Think of a user friendly mix of Photoshop and Illustrator
You have the possibility to use a ton of plugins to make the design experience even greater.
And using the template components for Material Design should make designing great applications fun.

Price: $99
Makes me happy because:

• Easy to use, no high learning curve
• Support plugins
• Many templates are available

Makes me sad because:

• Updates can break created designs
• So support for live viewing on an actual Android device

Illustrator (Adobe)

Adobe Illustrator is also a Vector based design application. It contains a lot of features for the skilled designer. But if you are a Illustrator newbie, you can be overwhelmed by all the possibilities and options available.
As with Sketch 3 they also have a template components for Material Design which you can use.

Price: €24.19 per month for just Illustrator (or €69.49 per month for entire Creative Cloud suite)
Makes me happy because:

• Focus on screen design
• Many templates are available

Makes me sad because:

• Learning curve is to high
• So expensive

Flinto

Flinto is designed as a tool for creating interactive prototypes based on PNG’s. Just link your PNG’s that you have created to screens and set transitions for that app-like feeling.

Price: €20 per month
Makes me happy because:

• Ease of use for prototyping
• Great transitions

Makes me sad because:

• You can only use it for prototyping
• Kind of pricey

Marvelapp

Marvelapp links your prototype with Dropbox to create an interactive prototype on your mobile device or desktop. No need to code or save PNG’s as images.
It’s easy to use, and can be used with different Vector based design applications. You can even export your prototype to a runnable APK.

Price: starts from €0 per month to €100 per month.
Makes me happy because:

• Ease of use for prototyping
• Great UI
• Exportable APK’s

Makes me sad because:

• No unlimited exportable APK’s

Keynotopia

If you know how to use Keynote or Powerpoint, you may want to use Keynotopia. Keynotopia is a library that contains UI components.
So you don’t need to know how to use a different design tool, just drag en drop your UI components to make your design.

Price: €49 if you are just interested in Android design.
Makes me happy because:

• No need to learn a new tool
• Free life time updates

Makes me sad because:

• UI components aren’t updated regularly
• Still no Android preview app available

Pen and paper

Last but not least, you can just you a pen and a piece of paper to do your design. It’s doesn’t need to be a paid app or service to start designing awesome designs.

Price: €1.
Makes me happy because:

• No limitations

Also available:
InVision, Proto.io, POP, UXPin, FieldTest

finally let me give you one advice, if you have no previous graphic design experience then I would suggest that you mastering the basics of graphic design first.
Once you are comfortable with the basics then you can start to look into designing with a specific tool.

So maybe I should share some techniques/tips on how to improve the UX.

1) Analyze

Do some analysis on your current (or future) UX design. As designer and/or developer we tend to think we know everything, but we don’t. Your application may be used differently than you might think.
Knowing how users are using or will use your application is valid information in making a good UX design, as the focus is, and always should be, the user.

• Do usability tests to discover problems or bottle-necks in your design. This can be done by actually sitting down with a user and observe his/her behavior while he/she is using your application or prototype.
• Use analyzing tools like Google analytics to find how user are using your application, so you know the user focus (or lack of) inside your application.
• Or just look around how people are using there device to know basic human-device interaction. A good example might be when you application is using the camera as feature. You’ve probably seen that “selfiesticks” are becoming more populair, so your application might be needing front-camera support as well.
• And finally have a look at user reviews in Google Play. They might supply you with vital information on how to make your users happy (and getting good ratings at the same time).

2) (Re)Think

It might be a good idea to have a second (or third) look at your current UX design and re-think.
Try to look for these bad UX omens:

• Additional texts to explain how it elements work. You can’t document your way out of confusing UX.
• Novel paradigms. Stick to known patterns, so users feel quickly at ease.
• FAQ section. The information presented to the user should be obvious and clear.
• “Pop-ups”, like a confirm dialog. Don’t block the UX. Don’t say that something is dangerous if you can’t fix the danger. Do support “undo”.
• Too much information. Keep it simple (is always the hardest to do).

So how can you test if your new UX is wel thought out you may ask, well:

• You might want to prototype your new UX design first in stead of rewriting your app. This is quick and easy to do and can test if your redesign has been improved.
• Try doing A/B testing so you can compare the new design against your current one. Testing eliminates guesswork and turns “I think” into “I know”.

3) Adapt

As described in the previous section it’s important to stick to known patterns, so the user can quickly become acquainted with your application features.
Adapting platform standards is the way to go. And Google has done a great job with the introduction of Material Design, by suppling us with well thought out UX design patterns.
Learn these pattern and apply them to your UX design.
One question I get asked a lot is when an application is adapting Material design will it still contain its uniqueness and will my branding survive. My answer is yes.

• The application or product icon.
• Use of colors.
• And the actual application itself, meaning your brand should be reflected in the application.

Let me explain this by giving you an example giving to me by Marie Schweiz about her redesign of the Top Gear application.
The succes of Top Gear (brand) is not the cars, but the three guys hosting it and the fun they have with cars. This should be reflected in the UX design, so make if playful.

4) Add

It might sounds strange, adding features to transform UX design, but it’s not. Let me be clear, I’m not talking about adding more content but adding features like feedback, value and user aid.
So you can add:

	Interaction feedback, which gives the user confidence that he/she is using the content correctly
	Error feedback, which warns the user and a possible solution. But be careful not to block the user while giving this type of feedback.
	Loading feedback, which gives the user options, should I wait or just continue. Again don’t block the user.
	Action aid, which gives the the user the option to “undo stupidity”

If you want to know more, you may want to visit:

• Google Material design introduction
• User testing explained, part 1
• User testing explained, part 2
• Android UI/UX website by Taylor Ling
• Android UI patterns website by Juhani Lehtimäki
• Udacity course: UX Design for Mobile Developers
• Google design Youtube channel

I really want to thank my friend and colleague Ali Derbane for reviewing this post

During Droidcon Italy Stephan Linzner from Google explained upcoming features in the Android Testing Support Library. Lets have a closer look at some:

Test Filtering

If you want to suppress a test to run on certain target Api levels, just add the @SdkSuppress annotation.

You can also filter tests to only run on a (physical) device by adding the @RequiresDevice annotation.

ActivityTestRule

Because ActivityInstrumentationTestCase2 will become deprecated you need to define a @Rule.

Rules allow very flexible addition or redefinition of the behavior of each test method in a test class

So in your test add a @Rule annotation, and create an ActivityTestRule for your Activity

Now create your ActivityTestRule

Espresso-Intents

Espresso-Intents is like Mockito but for Intent, basically hermetic inter-app testing.
To give you an example, lets say in your application when a user presses a “call” button, you want to know if the correct data will be send to the Intent.ACTION_CALL.

So first create an IntentsTestRule and then verify that the Intent was sent using Espresso-Intents

So now you know…

All code can be found in android-testing github:

• ActivityTestRule Sample
• IntentsBasicSample
• General Espresso Github samples by Google

Thanks Stephan Linzner for the resources. #HappyTesting

Introduction

Introduced at the GTAC in 2013, Espresso is designed to be used in environments where the developers write their own tests, and makes it possible to write concise, beautiful, and reliable Android UI tests quickly.
Espresso has several general components:

• The Espresso class offers the onView and onData methods which, alone, can be used for a good numbers of possible tests on a given interface.
• ViewMatchers contains a collection of objects that implements the interface Matcher <? super View>. Using this Class you can collect and check View elements. For example, getting a View element (Button) with text “7”.
• ViewActions contains a collection of viewAction objects to perform actions on a view. These actions are passed to the method ViewInteraction.perform and may contain multiple actions. For example, clicking on a View element (Button).
• ViewAssertions contains a collection of ViewAssertion to conduct checks on views.

To illustrate these components a test can look like this:

And the good news, as of last year Google has introduced a Testing Support Library containing Espresso. So lets start by implementing Espresso.

Define the test runner

To use Espresso we first need to define who is running the tests. Espresso uses a new runner named AndroidJUnitRunner. This runner, based on InstrumentationTestRunner and GoogleInstrumentationTestRunner, runs JUnit3 and JUnit4 tests against your Android application.

First add the dependencies to your build.gradle, assuming you have installed the Testing Support Library.

Then add the runner in your build.gradleandroid.defaultConfig configuration:

Writing the test

As you may know test classes must be in src\androidTest\com.example.package.tests, com.example.package being the package specified in the package attribute of the manifest element in the AndroidManifest file. 
Also each test class must extend the abstract class ActivityInstrumentationTestCase2 and supply the Test Activity as generic type that will be used by default for testing.
It must also be passed to the superclass via the super(). To make the Test Activity being called by the test framework, simply define a setup which calls the synchronous method getActivity().

As mentioned we want to check if ‘6’ x ‘7’ equals ‘42’.

You may have noticed, this example is using static imports. This is solely done to make the code more readable.

Other actions you want to use are:

• pressBack(); to simulate the use of the “back” button,
• isDisplayed(); to check if an element is being shown and
• scrollTo(); to scroll to an element.

Running the test

Now lets do the fun part, lets run the test. This can be done from the command line with he command line with gradle connectedAndroidTest or using Android Studio by:

1. Open Run menu | Edit Configurations
2. Add a new Android Tests configuration
3. Choose the module you are testing
4. Define our test runner: android.support.test.runner.AndroidJUnitRunner

So now you know a bit more about Espresso. If you want to know more, you may want to visit:

• Espresso website
• Github repo corresponding to this article
• General Espresso Github samples by Google

Updated (08-04) When running the tests with gradle you can just use gradle connectedAndroidTest

During the course of two days I gave two talks and one workshop. The workshop “Prototype your Mobile UX design” was intended to show participants how to prototype an Android application. 100 participants attended this 2 hour workshop, and I was really impressed by the skill level they presented.

Thank you all.

Beside your APK there are some additional artifacts you want/need to save, and you want gradle to do this. Most common ones are Javadoc, your source files and perhaps your proguard generated files like the mapping file.

I naturally wanted a Gradle task to handle this. So lets have a look as some tasks you may want to use.

Adding Javadoc archive tasks

The following will add tasks to generate Javadocs for each build type and assemble it into a jar archive .

When added to your build.gradle file, generate your Javadoc jar archive from the command line with gradle generateReleaseJavadocJar.

Adding Source archive tasks

The following will add tasks to assemble a jar archive containing the Java sources.

When added to your build.gradle file, generate your Sources jar archive from the command line with gradle generateReleaseSourcesJar.

Adding Proguard archive tasks

The following will add tasks to assemble a zip archive containing the generated proguard files.

When added to your build.gradle file, generate your Proguard zip archive from the command line with gradle generateReleaseProguardFilesJar.

The library is a unbundled static testing library for Android that containers all Android testing frameworks by Google. It will become a available through the Android Support repository and as open source in AOSP.

So what does it contain?

• AndroidJUnitRunner
  This Runner, based on android.test.InstrumentationTestRunner, runs JUnit3 and JUnit4 tests against an Android package (application). Let me give an example:
  @RunWith (JUnit4.class)
  public class MyJUnit4Test {
  {
    Droidcon mDroidconUK;
   
    @Before
    public void setUp() {
      mDroidconUK = new Droidcons.get(Droidcon.UK);
      mDroidconUK.open();
    }
  
    @Test
    public void checkPreconditions() {
      assertNotNull("mDroidconUK cannot be null", mDroidconUK);
    }
  
    @After
    public void tearDown() {
      mDroidconUK.close();
    }
  }

• Espresso
  Introduced at the GTAC in 2013, Espresso makes it possible to write concise, beautiful, and reliable Android UI tests quickly. Lets look at some examples:
  // Find view using a Matcher and type text using a ViewAction
  onView(withId(R.id.message_edit_text)).perform(typeText(TEXT_MESSAGE), closeSoftKeyboard());
  
  // Perform a click ViewAction
  onView(withId(R.id.send_button)).perform(click());
  
  // Verify using a ViewAssertion
  onView(withId(R.id.received_message_text_view)).check(matches(withText((TEXT_MESSAGE))));

• Intento
  Intento is like Mockito but for Intents. Basically a mock framework that allows you to create and configure mock objects. Let me give you an example:
  public void testDailerInput_typeNumberAndCall() {
   
    //Type phonenumber in dialer
    onView(withId(R.id.send_data_to_call_edit_text)).perform(scrollTo(), typeText("123-345-6789"), closeSoftKeyboard());
   
    // Click the call button
    onView(withId(R.id.send_to_call_button)).perform(scrollTo(), click());
   
    //Validate Intent has been send
    intended(allOf(
        hasAction(Intent.ACTION_CALL),
        toPackage("com.android.phone"),
        hasData(allOf(hasSchemaSpecificPart("tel", "123-345-6789")))),
        times(1));
  }

In conclusion: Testing with Android is finally becoming a more prominent part of Android Development cycle with the introduction of the Android Testing Support Library

During the course of three days I gave a talk about prototyping your mobile application, and I gave a workshop about mobile UX design. Also I had the chance to explain Google Glass (being a Glass Explorer) to all visitors and Greek politicians.

Τα λέμε την επόμενη φορά