Droidcon Boston 2018 Conference Report

There are many awesome Android conferences that occur throughout the year. The Droidcon series of conferences are some of my favorites. The high quality of the presentations is consistently impressive, and for those that can’t be there in person, the conference videos are posted online soon after the events.

Droidcons occur throughout the year in Berlin, San Francisco, New York, and many other cities. In April 2017, Droidcon Boston held it’s first annual conference. I’ve had the opportunity to attend both Droidcon Boston 2017 and this year’s event, which was held just these past two days March 26-27, 2018.

This year’s Droidcon Boston was packed with attendees and excitement. Most of the sessions I attended were using Kotlin in their code examples. There were talks that were architecture focused, some doing deep dives into tools like ProGuard and Gradle, and others discussing newer technologies such as ARCore, TensorFlow, and coroutines.

In this article, I’ll give you highlights and summaries of the sessions I was able to attend. There were many other conflicting sessions and workshops I wanted to attend that aren’t included in this report, but luckily we should be able to check them all out online soon.

We’ll update this post with a link to the conference videos once they’re available.

Day 1

Community Addiction: The 2nd Edition

The conference was kicked off with an introduction by organizers Giorgio Natili, Software Development Manager at Amazon, Eliza Camberogiannis, Android Developer at Pixplicity, and Garima Jain, Senior Android Engineer at Fueled. They call themselves the EGG team, Eliza, Garima, Giorgio! :]

The introduction detailed the conference info: 2 tracks with 25 talks and 6 workshops, lightning talks at lunchtime, and a Facebook happy hour followed by the official party.

The organizers discussed the following principles of the conference: good people; diversity; cool stuff including Kotlin, Gradle, and ML; respect; trust; love; integrity; and, being together.

Giorgio ended the introduction with a quote:

Keynote: Tips for Library Development from a Startup Developer

Lisa Wray, Android Developer, GDE, Present

Lisa’s talk was all about the why, when, and how of writing libraries. It was her “Boston edition” and presented in the style of XKCD. :]

Lisa started off with a great question: why write open-source libraries for free on the Internet? She made the case that writing libraries not only benefits the community, but is really in your own self-interest, and proved the point with a cool self-interest Venn diagram. She explained that writing a library is like joining a startup, just without all the money, but that you can benefit in unexpected ways. You often get community input-other people writing code for you for free. Sometimes you write a library out of bare necessity, or sometimes just to learn something new in a sandbox.

The next question then becomes: so you want to write a library, how do you go about doing so? Lisa explained that you want to start small in accordance with Parkinsons Law of work expanding to fill all available time. Try to focus first on a single use case. Try not to use the word “and” when explaining what the library does. Using the library should be just a couple lines of code, just add a Gradle dependency and a dead simple example.

Lisa wrapped up her session with a great list of principles to follow as you develop and release the library. Be your own user and dogfood your library, because if it’s not good enough for you, it’s not good enough for others. Be honest about the library scope and size. Use semantic versioning, and use alpha and beta releases to get feedback. Don’t advertise your library all over the place, e.g. in Stack Overflow answers; let users find it on their own. Be sure to include sufficient testing and continuous integration, which will greatly help you know whether to accept pull requests when you receive them.

Lisa wrapped up her session with some things to watch out for. Determine ownership for the work you do building a library while employed at big, medium, and small companies. Be ready to get some competition. And also realize that you’re library may eventually get deprecated by the Android SDK taking over the features.

I really loved Lisa’s last few points. She pointed out that no library is too small. Writing them is a great way to practice your craft. Look inside your app for boilerplate code, utilities or extensions. The community will thank you for a well-focused library.

Pragmatic Gradle for Your Multi-Module Projects

Clive Lee, Android Developer, Ovia Health

Gradle is the powerful build tool we use to make Android apps, but not everyone has mastered all it’s intracacies, especially for multi-module products. Clive’s talked aimed at giving you pragmatic tips to help get you to Gradle mastery.

Clive started by defining some terminology, like the root project and it’s build.gradle file and dependency coordinates. He then explained that you need to keep Gradle code clean because, well, it’s code. He also discussed why you may want to use multiple modules, because you can then use the tools to enforce dependencies and clean architecture layers. You also end up with faster builds thanks to compilation avoidance and caching. And loading multi-module projects into Android Studio is getting faster.

Next, Clive walked through his set of tips. The first were about using parallel execution and caching, via adding org.grade.parallel=true and org.grade.caching=true to your gradle.properties file. He recommends the android-cache-fix-gradle-plugin tool. He pointed out that the project must be modularized for parallel Gradle execution to occur.

When using multiple modules, you don’t want dependency version numbers in multiple places. You need a better way. Clive discussed techniques progressing from putting the version numbers in the project-level build.gradle, to putting the entire dependency coordinate in the project-level build.gradle, to using a separate versions.gradle file, and finally, using a Java file to hold the coordinates, which gives you both code navigation and completion for the dependencies. Clive also mentioned using the Kotlin-Gradle DSL and that you can also store other constants like your minSdkVersion using these various techniques.

Clive then walked through how to get organized with your gradle files. Put build.gradle files in a directory. Use settings.gradle to add the name of the directory, and you can then access it easily in the Android Studio Project panel. Another great help is to rename each module’s build.gradle file to correspond to the module name, since it makes navigating and searching easier. You need to set buildFileName on the rootProject subProjects. It’s well worth 5 minutes of time. You can use a bash script for renaming, and be sure to do the renaming for any new modules you add to the project.

The end of the talk discussed pitfalls you may run into. Avoid using a “core” module for common dependencies, since it enlarges the surface between modules. The result is slower builds. Use a shared Gradle file instead. Also, proceed with caution when using nested modules, which, while they may make navigating easier, lead to a slower reload when switching branches. Also, they do not show up in the Project panel in Android Studio.