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

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

“And, is the application still works?” or “Is the application broken?”, these are questions that developers should be able to answer if a code change has been made or an improvement has been added. This is no different when developing an Android application. Also, the use of TDD (Test Driven Development), in which first the test is written, after which the code follows, is good practice. Automated functional testing has become part of software development. Using Selenium and Fitnesse for testing Java application, combined with Jenkins has become avery day pratice to most Java developers. So you would expect that this would differ during the development of Android app. Unfortunately this is not (yet) the case. Because of the relatively rapid growth of Android, these testing methods aren’t yet mature enough.

Lets look at four testing framework that can be used during Android app development:

 
The Android application that is being tested is a simple calculator. The common test scenario we will be implementing is testing if ‘1’ + ‘3’ gives a result of ‘4’.

UIAutomator

The Google test framework UIAutomator makes it possible to write simple Java (and JUnit) functional tests. The framework is not tied to the application that needs to be tested, but also has access to the Android platform itself.
This makes it possible to adjust your Android emulator or physical phone settings while running your test(s). This means that you can test the behavior of the test application if, for example, the internet connection is being switched off.

Unfortunately there is little documentation available. Also the framework only supports Android 4.1 or higher.
In short:

• Fully control device
• Code written in Java
• Extends JUnit framework
• Easy to read
• Only for Android 4.1 and higher
• Little documentation available

Robolectric

The Java-based testing framework Robolectric is the best of the tested frameworks in terms of performance. This is because it is not running on a device or on the Android emulator, but uses his own visual UI simulator. As a result, the delaying factor of starting an emulator or installing the app on a device has no influence on running the test(s). This makes Robolectric a good choice for TDD.

Because Robolectric uses a non-visual UI simulator its not possible to test a problem which only occurs on say a Samsung device.
In short:

• Does not require emulator or device
• Code written in Java
• Extends JUnit framework
• Fastest in terms of performance
• Does not run on actual device

Robotium

The idea behind Robotium is that a functional test should description what the user sees and can do. This framework is a good choice if you are just “black box” testing your application. Besides extensive documentation, there are some well described examples available and the API is easy to use.

In short:

• APIs are easy to use
• Tests are text-based
• Good for “black box” testing

Calabash-Android

Like Robotium, the functional tests described in Calabash Android is written as “What you see you test”. The only difference is that the tests are not written in Java, but in Cucumber (a text-based structure). This makes it possible that tests can be written/used by non developers. A drawback, because test(s) aren’t written in Java, is that “debugging” a failing test is not possible.

In short:

• Well documented
• Test(s) can be writen/used bij non developers
• What you see, you test
• ‘Debuggen’ of tests isn’t possible

Conclusion

Functional testing of Android applications is possible. Which test framework you want to use, dependents on the what you want to do with it. To choice with one fits best, ask yourself who is going to make the tests, what needs to be tested and/or on which device the tests are running on.In any cast, there is enough choice to start writing functional tests.

Source code can be found here

Without a doubt, the simplest method to protect an app is to enable the obfuscation in ProGuard. This freely available tool is already built into the Android toolkit.

Obfuscation

By default, compiled bytecode still contains a lot of debugging information: source file names, line numbers, field names, method names, argument names, variable names, etc. This information makes it straightforward to decompile the bytecode and reverse-engineer entire apps. Sometimes, this is not desirable. Obfuscators, such as ProGuard, can remove the debugging information and replace all names by meaningless character sequences, making it much harder to reverse-engineer the code. It further compacts the code as a bonus. The app remains functionally equivalent, except for the class names, method names, and line numbers given in exception stack traces.

Shrinking

Java source code (.java files) is typically compiled to bytecode (.class files). Bytecode is more compact than Java source code, but it may still contain a lot of unused code, especially if it includes program libraries. Shrinking programs such as ProGuard can analyze bytecode and remove unused classes, fields, and methods. The app remains functionally equivalent, including the information given in exception stack traces.

For a realistic example, take the following code:

The code as shown above is a typical scenario during development. You create code like this to help debug and test your code. Before releasing the final product, though, you set Config.LOGD to false, so it doesn’t execute. The problem is, this code is still in your application. It makes it bigger, and may cause potential security issues by including code which should never be seen by a snooping hacker.

Shrinking the code solves this problem beautifully. The code is completely removed from the final product, leaving the final package safer and smaller.

Optimizing

Apart from removing unused classes, fields, and methods in the shrinking step, ProGuard can also perform optimizations at the bytecode level, inside and across methods.

Proguard

So let’s have a look at the proguard.cfg file. I recommend you open up the sample code, as I will be highlighting the key parts on this page.

Basic template

Fragments

Serializables

Removing Logging

Methods

Now that we have added all our Proguard settings, we need to run Proguard during the build fase. I will use Maven to illustrate this.

Within your pom.xml the android-maven-plugin should be defined. To this definition add the proguard setting like:

All that is left is to run Maven with

To check if the app has been obfuscated, install the apk on you Android device and when you run it, you shouldn’t see any logging in logcat.

To autostart an Android application there are a couple of steps you need to take. However before you do this you should consider this:

Background service awareness

When manually or even automatically starting an application, users will see something being started.
If you (auto)start a background service it won’t be visible to the user. Users might not be aware of the fact that a service was started. Keep this in mind when using a service.

Battery life

As we know by now people might not be aware that your automatically started background service is running. Keep the battery life of the phone in mind when performing tasks in the background.

To create a battery aware service use these things in moderation:

• Getting a GPS or network location
• Connecting to your network and sending/receiving data
• Read/write files (IO)
• Intensive tasks

Let’s autostart our service

First of all we need to make sure your application is allowed to receive and handle the broadcast that tells the application that your phone was booted.
To be able to receive the broadcast you should add this permission as a child of the <manifest> element to your Android Manifest: