Google I/O 2016 developer talks

Last May 18th to 20th was the Google I/O 2016. The Google I/O is an annual conference for developers. Besides the usual marketing numbers, the keynote is often used to announce new products and services Google is planned to launch later this year. This year Google announced Google Home, a new messenger app Allo, a video calling app Duo and more. Besides these announcements, there are also a lot of interesting talks where Google developers tell us about how to use new, improved and existing APIs. A lot of those talks are available on Youtube. Below is a list of talks that I watched and found interesting enough to share.

The talk below is about using the right APIs to prevent your app to slow down the users phone or to drain the battery.

The talk below is about changes that were introduced in Android Marshmallow and Android N and other good practices to keep in mind to secure data in your app.

The talk below is about the new Awareness API. There are already numerous APIs that can detect the users’ activity, geofencing, whether the headphones are plugged in and more. Combining these APIs can be difficult, especially in terms of efficiency. The Awareness API efficiently combines the aforementioned APIs.

The talk below is a deep dive into the RecyclerView.

The final talk I would like to share is a deep dive into Fragments.

Advertisements

Droidcon London 2015: Microservices

droidcon London 2015-1

Near the end of two days of Droidcon, Duana Stanley of SoundCloud shared how SoundCloud migrated from a monolithic architecture for their public API to microservices. This talk was interesting because currently, we are working on a public API which currently has a monolithic architecture. This talk triggered me to read more into microservices. Martin Fowler and James Lewis wrote an interesting and elaborate blog post on this subject.

The idea of microservices is that you have a suite of separate services which communicate with each other. An advantage of this, is that it is possible to deploy multiple instances of a microservice that is heavily being used. For instance, if you have an account service with which you can login. And a service to get a list of street names. The street name service would probably be used more often than the account service. So you would deploy three street name services and one account service.

The use of microservices an interesting alternative for the monolithic architecture. The biggest question I currently have, is when should you transition to microservices? What is your opinion?

 

skills matter-droidcon London 2015
Video Skills Matter – Droidcon London 2015

 

Google I/O Dag 2

google io 2015 - android-m-1

Dag 2 van de Google I/O 2015 stond vooral in het teken van technologie, waarbij er dieper werd ingegaan op de nieuwe Android M developer preview.
Android M developer preview bevat een aantal interessante nieuwe features voor de Android ontwikkelaar, waaronder:

  • Fingerprint API
  • Nieuwe Android Studio
  • UI Databinding
  • Nieuw Permission model
  • Material Design support library

Laten we wat dieper ingaan op deze nieuwe features.
Continue reading

Android Testing Support Library announced

During the Droidcon UK 2014, Stephan Linzner of Google announced the upcoming Android Testing Support Library. This means Google is (finally) taking testing Android apps seriously.

IMG_20141031_163015

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

Droidcon UK: Android 5 (Lollipop) is a major improvement on 4.4

IMG_3762

This year there was significant involvement from the Google Android team at Droidcon UK.

  • Chet Haase presented an overview of the changes in Android 5
  • Nick Butcher and Chris Banes discussed the new design (Material Design)
  • Narayan Kamath discussed coding for the new ART runtime engine which will replace Dalvik.

Of the numerous changes and improvements to Andoid 5, Material Design and ART Runtime will have the biggest impact on both new and existing apps.

Material Design promises a consistent UI on all form factors
The main changes to the Android Lollipop design are:

  • Tangible surfaces. Android 4.4 had a flat design. Material design is meant to look like pieces of paper placed on top of each other with a certain degree of depth. Where iOS 7 did away with skeumorphism, Material Design has brought it back a little.
  • Bold, beautiful, aesthetic. Shadows for the UI elements because they have depth. Android now provides a set of easy to use methods to customize the look and feel using tints.
  • Meaningful motion. The UI has better transitions and animations. 
  • Adaptive design. The card based layout system is intended to make designing for phones, phablets and tablets a natural continuum. In theory you make one design for all form factors.

Bottom line: The new design is better, but will require existing apps to be recoded in order to utilize it.

ART Runtime: your code will be interpreted differently
Android is coded in java, which was designed to be platform independent. Therefore the java compiler (javac) makes no assumptions about the processor or hardware on a device. This leads to slow code, especially on constrained devices such as smartphones. The solution for Android was to add an extra compilation process which takes the output of the javac compiler and optimizes it for smartphone processors. This is called post-compilation and Androids first postcompiler was called Dalvik. With Android 4.4 Google introduced the ART postcompiler as an alternative, and in Android 5, Dalvik will not be available. ART has many performance improvements, but there are a few incompatibilities which can cause existing apps to break.

Bottom line: ART is better than the current Runtime Engine, but you will have to regression-test existing apps to make sure they don’t break.

Many interesting talks at Droidcon UK

There were many other interesting talks during the rest of the conference. Here are a couple of highlights, this blog post will be updated later in the week…

Nick Butcher and Chris Banes: Material Design and implementation

IMG_3766

Taylor Ling: The Importance of Feedback in User Interface Design

IMG_3770

Richard Woolley: Creating the Internet of Things with Bluetooth Smart

Bluetooth smart device numbers are growing exponentially, with 2.5 Billion (2500000000) devices shipped in 2013. Read more…

Stephan Linzner: What’s new with Android Testing

Finally Stephan Linzner announced the Read more…

IoT based on Bluetooth LE has rapid growth

At Droidcon UK 2014, Martin Woolley of the Bluetooth Special Interest group discussed Android 5 improvements for Bluetooth Low Energy and how to use Bluetooth Smart based Internet of Things (IoT) devices from Android smartphones. Below are some key takeaways of Martins session.

IMG_3780

Regular Bluetooth has been around for over a decade and was intended for streaming audio. Bluetooth headphones and carkits use regular Bluetooth to communicate with your smartphone. Because of the large amount of data involved in streaming audio, Bluetooth connections use quite a lot of power which is a problem on battery powered devices. 

However there is a whole range of devices that only require a small amount of data to be transmitted. Heart rate monitors, GPS trackers, smart light bulbs and temperature sensors are but a few of the Internet of Things (IoT) devices that are proliferating at the moment. This is where Bluetooth Low Energy.comes in. Bluetooth Low Energy (also called Bluetooth Smart) has a much lower transmission frequency which vastly improves the power consumption involved. A regular Bluetooth connection will deplete a smartphone battery in a few hours, but on a Bluetooth Low Energy a smartphone battery will last for months or years. And the same applies to the devices your smartphone connects to. This is why Bluetooth Low Energy is seen as a key enabler of the Internet of Things (IoT). Apple uses a subset of Bluetooth Low Energy to implement its iBeacon protocol. 

Bluetooth communication consists broadly of five steps:

  1. Discover a device. A client (your smartphone) looks for devices that are broadcasting their existence. The broadcasting devices are said to be in “discoverable mode”.
  2. Connect
  3. Explore what you can do with the device. This is called service discovery. The Bluetooth has a protocol for finding out which commands you can send to a device and which data you can retrieve from it.
  4. Interact with a device. This is two-directional. The device can be queried (i.e. tell me what the temperature is) or the device can notify you – heart rate and gps sensors do the latter.
  5. Disconnect

The good

Bluetooth LE works on many devices that are available right now for consumers. You can build products and applications that consumers can buy and use.

The bad

Manufacturers of Bluetooth devices are free to decide what names and values they use for attributes and services. Two different heart rate monitors may have different service and attribute names for the same things. There is no central place to find device characteristics so you have to code this for each and every device type you want to use. (edit: since this article bluetooth.org has introduced a registry of services and attributes. It will be interesting to see if this registry gains support from device vendors).

The Ugly

Implementations of the Bluetooth stack on smartphones do not get the care they deserve by smartphone manufacturers. Some API’s are buggy and will drop connections, mishandle errors and require restarting the phone to re-enable Bluetooth operations.

Bluetooth Low energy facts

  • Bluetooth LE works well in radio saturated environments because it can hop to different frequencies up to 1600 times a second
  • Native smartphone support on 96% of current smartphones
  • Developer friendly: API available on most smartphone platforms
  • Growing rapidly. 1 Billion devices shipped in 2012, 2,5 Billion in 2013, 30 Billion sales expected in 2030

* Note: Apple, iBeacon and Bluetooth are registered trademarks.

The Hitchhiker’s Guide to Android functional testing

Android™ development and testing go hand in hand. When it comes to automated functional testing there are plenty of frameworks out there. At this years DroidconNL (23 – 25 November) Wiebe Elsinga & Ali Derbane will take the audience on a journey into several testing frameworks to use for Android functional testing.

Wiebe ElsingaAli Derbane

During their interactive session Wiebe and Ali will be presenting a fine selection that could help you decide what to use in your next project. Some of the frameworks they will talk about are Robotium, Robolectric, UIAutomator, Calabash, Selendroid and Espresso. And since DroidconNL is a developer conference there will be code as well!