Droidcon Boston 2018 Conference Report

Workshop: Hands on Android Things

Kaan Mamikoglu, Mobile Software Engineer, MyDrive Solutions

James Coggan, Senior Mobile Engineer, MyDrive Solutions

Pascal How, Mobile Software Engineer, MyDrive Solutions

Of the 6 workshops at Droidcon Boston 2018, I was able to attend the one on Android Things, the IoT version of Android.

The workshop setup attendees with an NXP i.MX7D kit. We flashed Android Things onto the board. The board was attached to a breadboard with a temperature sensor and LEDs. The workshop walked us through creating an app for the device that communcates with Firebase and that, using DialogFlow and Google Assistant, allows you to ask “Hey Google, what’s the temperature at home?”

The workshop was hands-on, and consisted of opening the workshop apps in Android Studio and running through the following steps:

• Connecting board to WiFi using an adb command.
• Setup Firebase in Android Studio and your project, with Realtime Database support
• Open the Firebase console and enable anonymous login
• Setup Firebase on the common module
• Create a HomeInformation data class with light, temperature and button
• Observe changes to HomeInformation in the database using LiveData
• Setup Firebase on the Things device
• Setup Firebase on the mobile app

You can find more info on the workshop at James’s GitHub.

Day 2

Keynote: Design + Develop + Test

Kelly Shuster, Android Developer, GDE, Ibotta

The second day keynote by Kelly Shuster was about communication between designers, developers, and testers. She pointed out that we often get in weeds as software engineers, solving problems. We need to remember other things in order to build a successful product that people will actually use. It’s a responsibility to get good at effective cross-team communication. Kelly gave a great example of what happens when cross-team communication is missing from when she was a child actor in the Secret Garden and everyone forgot their lines in one scene. A painful experience but a lifelong memory.

Kelly explained the typical flow of app development: design mocks -> development begins -> development finalized. Often have another step with “developer questions”. A big problem is that you start to have a lot of these conversations, and much of the conversation is boilerplate. What if we could remove these boilerplate conversations? She came across a blog post about removing barriers from your life, and thought: what are the barriers to effective communication?

For barriers with designers, Kelly listed a number of tools that can help. Zeplin, which can give you details like sizes, fonts, and font sizes. A designer uploads a Sketch file to Zeplin, which parses out all the details. Another tool is a style guide with the design team, which serves as “boilerplate code completion” for the design world. A good design style guide has a color palette with common names, zero state and loading state designs, and button states. These things cover 80% of boilerplate design discussions right in the style guide.

Kelly then discussed how SVGs can help minimize back and forth with designers, and how a designer she worked with once offered to use Android Studio to learn how to work best with Vector Asset Studio. Conversely, as developers, Kelly pointed out that we often say a lot of negative things to designers. We should instead think about what can we do for them: be a relentless advocate for your designer’s vision (within reason).

Kelly discussed some surveys she’d done, one question being “if I could do one thing to make my product better it would be…” Most answers boiled down to “spend more time testing”. Even from designers and QA. Kelly talked about testing from two perspectives: pre-development and post-development. For pre-development, she suggested tools such as Usability Hub for user testing of designs, and Marvel, which takes pictures of paper designs and turns them into a clickable prototype.

“Post”-develoment testing is really post-design unit testing and integration testing. Kelly gave an anecdote about wanting to learn a song on piano for 5 years and not doing so until committing to practicing 5 minutes a day, and then compared it to how to get good at testing: write at least one test a week. You’ll be able to write tests fast within a few months.

Kelly finished up with results from another survey question: “the hardest part of working with developers is…” The consistent answer: their lack of smoke testing. Kelly gave great advice such as using “Day of the Week” emulators to test across API levels. She’s found many UI bugs by doing this.

fun() Talk

Nate Ebel, Android Developer, Udacity

Nate’s talk was all about exploring Kotlin functions. He pointed out that Kotlin loves functions. You can see it in docs and examples. The standard library is full of functions, including higher-order and extension functions. Functions in Kotlin are flexible and convenient. As Android developers, they give us the freedom to re-imagine how to build apps.

Nate dove into parameter and type freedom. Kotlin allows default parameter values, used when an argument is omitted. They give you overloads without the verbosity of writing them, and documents sensible defaults. For Java interop, you can use @JvmOverloads, which tells the compiler to generate the overloads for you.

You can also use named arguments in Kotlin. Without names, parameter meaning can be confusing without looking at source. Named arguments make it easer to understand. You can also switch the order when using named arguments. There are some limitations, for example, once named, all subsequent arguments must be named.

You can use variable number of arguments using vararg. They are treated as an Array of type T. You can use any number when calling, and they typically but not always will be the last parameter. They do not have to be last if using named arguments or if the last parameter is a function. You can use the spread operator * to pass existing arrays into vararg.

Nate described Kotlin return types. If there is no return value, the default is Unit. You append the return type to the function signature with a : if there is a non-Unit return value. Single-expression functions can infer return type.

Nate then discussed Generic functions, and how much of the standard library is built on generics. You add a generic type after the fun keyword.

Nate then explored how and when to create functions. He discussed top-level functions and how to rename files using @file:JvmName. He gave examples of member functions on a class or object, local functions which are functions inside functions, and companion object functions. He described function variations, such as infix functions, extension functions, and higher-order functions.

Nate finished up by re-imagining Android via the power of Kotlin functions. We can use fewer helper classes and less boilerplate. We can pass logic around for a try-catch block. We have libraries like Anko and Android KTX. We have DSLs like the Kotlin Gradle DSL.