Your app can open doors: Host Card Emulation

Your app can open doors or make payments or do other cool stuff. Host Card Emulation (HCE) is a technology that emulates a payment or access card on a mobile device using an app. Many Android devices that offer Near Field Communication (NFC) functionality already support NFC card emulation.

A card could be emulated by a separate chip in the device, called a Secure Element (SE). Android 4.4 introduces an additional method of card emulation that does not necessarily involve a Secure Element, called host based card emulation. This allows any Android application to emulate a card and talk directly to the NFC reader.

Using Host Card Emulation you can, for example, pay, travel or check into a hotel, but you need an phone running on Android 4.4 or above.

Any app on an Android 4.4 (or above) device can emulate an NFC smart card, letting users tap to initiate transactions with an app of their choice. Apps can also act as readers for HCE cards and other NFC-based transactions.

Playing with NFC tags is fun, but HCE is even more fun...

Get started

To get started with HCE for Android you can download the card emulator and the card reader examples from GitHub (Or you can use the New, Import sample option from the File menu within Android Studio -for OSX- for that). I have installed the emulator app on an Samsung Note 3. On a second device, a Nexus 5 to be precise, I have installed the card reader app.

After enabling NFC on both devices I am able to read the 'loyality card' that exists on the Note 3 device with the reader app on the Nexus 5 using NFC. That does work great, however I have not been able to do the same with a Samsung Galaxy S4 Mini (emulator app) and the Nexus 5 (reader app). For some reason, that I have not figured out yet, the examples do not work with the combination of these (and perhaps a few other) devices.

For a Windows 10 example you might want to check this link.

Secure element

A Secure Element (SE) securely stores card data and does some cryptographic processing.

During a payment transaction it emulates a card to authorize a transaction. The Secure Element could either be embedded in the phone or embedded in the SIM card.

Pay

Google wallet & Android Pay

Android Pay or Google wallet do not (yet) use a device based Secure Element. It uses Host card emulation (HCE) instead. The card emulation and the Secure Element are separated into different areas. It can also be implemented with a Secure Element chip, but this is not yet required.

Android Pay works for KitKat users and higher (Android 4.4+)

Samsung Pay

Samsung Pay works only for a small number of Samsung devices. It is built into Samsung’s Galaxy S6, S6 Edge, Note 5, and S6 Edge+. Samsung Pay uses (embedded) secure elements (and it supports HCE).

Since it uses both NFC and magnetic secure transmission (MST) to transmit payment information the service probably will work on more POS as is the case for Android Pay.

Apple Pay

Apple Pay uses a device based Secure Element and does not use HCE. It uses the Secure Element chip on the iPhone as part of the token-generation process and also to store fingerprint data.

I have not seen Apple Pay in action yet. I guess the most nearby opportunity will be in London, where you can use Apple Pay to travel by bus, tram, railway or underground.

Apple Pay works on iOS 8 and above. The functionality is available on the iPhone 6 and iPhone 6+ only.

Windows 10 & NFC HCE

Microsoft supports HCE NFC payments in Windows 10 (mobile). You can check out the Windows 10 HCE Tap to Pay demo on YouTube.

Conclusion

HCE is interesting technology and available for Android & Windows. Apple is doing things differently and, as it seems to be, in a better and a more secure way.

Since both Android and iOS do have their own audience, Android Pay and Apple Pay could perfectly exist next to each other. And then there is Samsung Pay, which probably will become a huge competitor for Android Pay.

And what about us, developers? Well, we have some new challenges and things to figure out...

Further reading

• 1. Android card emulation example on GitHub
• 2. Android card reader example on GitHub
• 3. NFC + HCE Your phone in an interactive world (YouTube)
• 4. Write an NFC HCE app with Windows 10 for mobile
• 5. Apple pay, an attempt to demistify
• 6. Android pay, Google wallet & Samsung pay
• 7. Mobile wallets, Apple Pay vs Samsung Pay vs Android Pay
• 8. Why Samsung Pay is way better than Apple Pay and Android Pay

ADB Plugin for Android Studio

Android Studio comes with many interesting plugins. Under the Plugins section of the Preferences dialog in Android Studio (for OSX) you can find some of them and you can browse for additional ones using the Browse repositories button.

On the Android Studio Plugin Repository page (or on GitHub) you will find all available plugins. Recently I have found a nice plugin for Android Studio (and Intellij IDEA) that could help you to speed up your daily Android development.

ADB Not Responding - Wait More or Kill adb or Restart

Does the line above looks familiar? To restart the ADB I always used the command prompt for that. Using this plugin created by Philippe Breault we could perform this and other tasks from within Android Studio.

In addition to restarting the ADB it can also clear the app data, uninstall an app or just kill it. After installing ADB Idea appears under the Tools, Android menu but as Philip suggests on GitHub you can use the Ctrl + Shift + A (For Windows Ctrl + Alt + Shift + A ) short cut.

Short cut for all

By the way, you can also use the Cmd + Shift + A short cut and type adb to look up adb commands or use this short cut to look up any command.

Conclusion

Well, what else can I say about it? It is a nice little tool. Thank you Philippe Breault for that !

Further reading...

• 1.Android Studio plugin repository
• 2.ADB Idea on GitHub

Android & Retrofit 2.0

Retrofit is a well known and very popular networking library. It is an open source library created by Square and it is widely used by Android developers because it performs great and is easy to implement.

Retrofit 2.0 introducing new features, such as cancelling a request or using a pattern that fits both synchrone and asynchrone requests. Also it does no longer depend on just Gson.

Now you need to add a converter as a separate dependency, which gives you more flexibility if you want to convert a response into an object. You can use the Gson converter but you can also choose another converter to support a different data format, such as Xml. Or you can create your own converter if you want to.

Retrofit dependencies

Here is a small demo project that consumes data from Wipmania using RetroFit 2.0. WipMania is a service that determines the location based on your IP address.

1. Create a new project in Android Studio and add the dependencies for RetroFit in the build.gradle file in the app folder. The dependency section will look like shown below.

compile 'com.squareup.retrofit:retrofit:2.0.0-beta1'  
compile 'com.squareup.okhttp:okhttp:2.4.0'  
compile 'com.squareup.retrofit:converter-gson:2.0.0-beta1'

2. Define the API endpoint in an interface called IRepository

import retrofit.Call;
import retrofit.http.GET;

public interface IRepository {

    @GET("json")
    Call demoCall();
}

3. Create a new class, name it Result and add some of the fields being returned by the WipMania service.

public class Result {

        public String latitude;
        public String longitude;
        public Address address;

        public class Address{
            public String continent;
            public String country;
        }
}

4. Create a method testRetrofit in your MainActivity. Within this method setup Retrofit and call the method from the interface we have created. The API returns data in a JSON format. The GsonConverterFactory will convert that data into a Result object.

If the call succeeds we will display some of the properties of the returned data in a toast or if it fails we will display an error.

import retrofit.Call;
import retrofit.Callback;
import retrofit.GsonConverterFactory;
import retrofit.Response;
import retrofit.Retrofit;

...

public static final String BASE_URL = "http://api.wipmania.com/";

private void testRetroFit(){

   Retrofit retrofit = new Retrofit.Builder().
        baseUrl(BASE_URL).
        addConverterFactory(GsonConverterFactory.create()).
         build();

   IRepository repository = retrofit.create(IRepository.class);

   Call call = repository.demoCall();
   call.enqueue(new Callback() {
       @Override
       public void onResponse(Response response, 
         Retrofit retrofit) {
          displaySuccess(response.body());
       }

       @Override
       public void onFailure(Throwable t) {
          displayError();
       }
   });
}

private void displaySuccess(Result result){
    Toast.makeText(this,"lat="+result.latitude+
      " lng="+result.longitude+ 
       " continent="+result.address.continent+"   
        country="+result.address.country, 
         Toast.LENGTH_LONG).show();
}

private void displayError(){
    Toast.makeText(this,"something went wrong", 
        Toast.LENGTH_LONG).show();
}

5. Call the testRetroFit method from somewhere in your app, for example in the onStart method. Do not forget to add the internet permission to your AndroidManifest file. Finally run your app.

<uses-permission android:name="android.permission.INTERNET"/>

Cancel a transaction

6. What if the user initiates a request but changes his mind? Previously Retrofit had not a straight way to cancel an ongoing transaction but that is no longer an issue. Just call the cancel method on the Call object.

call.cancel()

Conclusion

So far it seems Retrofit 2.0 is a really great improvement and I have just seen the beta version. Also there some other interesting features to investigate...

Further reading...

• 1. Retrofit
• 2. Retrofit on GitHub
• 3. WipMania

Mobile Behaviour Driven Development: Cucumber and Calabash

Before you will release your app to the Play Store or App Store it needs to be tested. And while we can do that manually it would be better to do that in an automated way.

Android Studio support unit testing and so does xCode. However we also have to run UI tests. Google has released the Espresso framework for this purpose. And there is Xcode 7, which also has introduced UI testing features.

But what is a smart thing to do if we want to test the same functionality for both Android and iOS? Cucumber could be the answer to that question.

Cucumber & Calabash

Cucumber is a tool that runs automated acceptance tests written in a Behaviour-Driven Development style. It describes how software should behave in plain text.

Features are being described in a feature file, like in the example shown here.

 Scenario: Login
  Given I am on the Login Screen
  Then I touch the "Email" input field
  Then I use the keyboard and type "hello@world.nl"
  Then I touch the "Password" input field
  Then I use the keyboard and type "verysecretpassword"
  Then I touch "LOG IN"
  Then I should see "Hello world"

This is not just documentation. It can be used for automated UI tests as well.

Features are being described in a domain specific language. They describe the behaviour of software without much implementation details. So these tests can also be written by the non developing members in your team.

Calabash & some glue

Calabash is a framework that you can use for running Cucumber tests on Android and iOS apps. The framework has been created by the guys from Xamarin, which makes sense I guess, since Xamarin is a cross mobile platform solution.

There is some glue code required to actually run Cucumber tests using feature files. This glue needs to be defined in step definitions and Cucumber typically lets you write these step definitions in the Ruby language. The glue is platform specific but the feature file is not so theoretically it can be used for both the Android and the iOS version of your app.

Another cool thing about Calabash is that it allows you to run automated tests in the cloud, for example by using the services of TestDroid or the Xamarin Test Cloud.

Conclusion

Seeing Cucumber tests in action is great but it may take a while before you have setup all the things you need for it.

Behaviour Driven Development sure is an interesting approach. Using Cucumber and Calabash we can create mobile UI and acceptance tests for both Android and iOS.

The downside is that in particular Calabash does not seem to be very mature yet. The tests run slow and it takes a considerable amount of time to define them. Also the mixture of Gherkin feature files, Ruby glue and Java/Objective-C/Swift code feels weird.

On the other hand the Calabash framework is still in beta so it probably is just a matter of time before mobile behaviour driven development becomes widely adopted.

Further reading...

• 1. Behaviour Driven development
• 2. Cucumber
• 3. Gherkin
• 4. Calabash
• 5. Calabash for Android on GitHub
• 6. Calabash for iOS on GitHub
• 7. The state of iOS testing in 2015
• 8. Calabash & TestDroid