This year marked the 9th anniversary of AndroidTO, the largest Android developer conference in Canada. The organizers of GDG Toronto and Symbility Intersect put on a full-day lineup of fifteen 30-minute talks in the MaRS Discovery District.
There weren't a lot of sponsors at the tables outside the auditorium, but two community groups, GDG Toronto Android, and Android Pub Night, gave away stickers. Lunchtime was handled via Ritual, with attendees receiving a credit to go purchase a meal from a local restaurant. As in previous years, there was a live DJ helping with speaker intro/outro!
I was honoured to be accepted as a speaker during the morning half. Here's a summary of the talks I attended:
Mallika Potter (@mallikaandroid) discussed how making apps accessible is a largely untapped area, despite its very large market. She emphasized that accessibility is not just beneficial for people with chronic conditions, or who are born with disabilities, because anyone can sustain a temporary impairment that requires accommodation.
One of the key points she made was that notifications and cues should have more than one sensory component. For example, a visual status bar notification should be accompanied by an auditory signal (and vice versa: avoid sound-only notifications, and provide a visual cue also). Another example is ensuring that videos contain captions.
Making changes incrementally and focusing on low-hanging fruit is important, because even small improvements can make your app usable for those that were previously unable to. Some quick fixes include using TalkBack to check for navigation issues, changing text size and density to look for clipping and crowding problems, and adding descriptions to UI controls.
Auditing Your APKs Like a Black Hat Hacker
Kristina Balaam (@chmodxx_) provided a whirlwind tour of how to think about security in Android apps, from the perspective of a malicious actor. She covered reverse engineering, attack surfaces, and best practices in app development.
Many of the tools of the app security trade are not used by everyday app developers. These include Apktool, a tool that can disassemble compiled APK resources (like string and image resources, manifest files, and more); dex2jar; smali (an assembler/disassembler for the Dalvik executable format); and JD (a Java bytecode decompiler and analyzer). In addition to these low-level tools, Kristina mentioned drozer, a security testing framework to identify vulnerabilities in apps and devices, and a playground app called Diva, to get practise in hacking.
In listening to her describe a lot of the security problems that befell major app developers over the years, I got the feeling that it's really hard to get security right. Operating systems like Android get a host of new features every year, and keeping up with best practices is never-ending. Do watch her presentation to learn more about how other companies got it wrong, and the things you should start doing to get it right.
How the Command-Line Can Give You Superpowers
Over the last few years, I have encountered a lot of developers who only know Android Studio, and rarely spend any time in the command-line. Having grown up with Commodore BASIC, DOS, and Linux, the command-line is second nature to me. This summer, I decided to put together a talk focusing on how CLI tools can be helpful to Android developers.
This talk is in its 3rd or 4th iteration, as I've given versions of it several times this year, refining and updating it each time.
Dynamic App Modules
Alex Saveau (@SUPERCILEX) gave us a deep dive into Google's new app serving model, Dynamic Delivery, and the associated App Bundle upload format. The subtitle of his presentation was "Building for Billions", and is apropos because the goal of dynamic delivery is to allow users to download optimized APKs containing only the code and resources they need. No more one-size-fits-all distribution!
We learned about how app bundles are an evolution of split APK support, but takes it further by allowing the Play Store to automatically extract configuration-specific resources (e.g. screen density, CPU architecture, etc.) and feature-specific components into individual APKs, then sign and build them for you. We also learned about how apps need to be organized into base and feature modules, and how to handle older devices that don't support dynamic delivery.
Applying Rx Best Practices To Your Architecture
Benoît Quenaudon (@oldergod) gave a talk describing how to implement a Model-View-Intent architecture using RxJava. He has written about managing state with Rx before, and has given a talk at Droidcon NYC on this subject as well.
This is a pretty advanced talk, adopting an architectural pattern that isn't easy to wrap your head around, implemented using a library that has an even steeper learning curve. His main points were to avoid side effects so that functions are pure and easy to test, and to maintain a single unidirectional stream of events.
If you are new to MVI and RxJava, there are many other resources out there to learn the basic concepts from (my favourites are this series on MVI by Hannes Dorfmann, and this free ebook on Rx by Matt Dupree). If you're looking for complete examples, you'll find Benoît's port of the Android Architecture TODO example in this repository very useful, as well as this one by my colleague Etienne.
Adventures of an Android Developer in iOS Land
Yun Cheng (@yuncheng13) does double-duty as an iOS and Android developer. In learning Android, she observed some differences in the tooling and language, and shared them with us in her talk.
Her first set of grievances were around Xcode, Apple's IDE. From its shortcomings with navigation and refactoring, to its poor autocomplete implementation, Yun could not think of any benefits of Xcode over Android Studio. Despite having alternative IDEs for writing Swift code (including JetBrains' AppCode), writing GUIs still requires Xcode to generate the machine-readable XML layouts. Speaking of Swift, she shared that it was nicer to use than Objective-C, especially with the latter's block syntax. (But perhaps closures are just as confusing?)
Testing is one area where Android developers take mocking for granted. However, Swift does not allow reflection. Despite having fewer hardware and OS versions to test on, iOS developers still struggle with code signing and TestFlight. Android developers have it much easier: build an APK, give it out.
Building Conversational Experiences with Actions on Google
There's a lot of "tech" that goes into the Assistant: NLP, AI, speech processing and synthesis. Being able to leverage all of that, and developing your own experience from a template in just a few hours is pretty magical. However, it's a pretty different mindset: you need to consider that people talking to the Assistant expect a real-time response, and may be having other chats at the same time. Conversation design involves thinking about all of these things so that interaction is natural and intuitive to users. And, since some connected devices have screens, existing visual UI/UX principles also need to be considered.
As Amazon did with Alexa, Google is encouraging developers to try writing Actions by offering incentives (Cloud credits and a T-shirt) if you publish before the end of July 2019.
Machine Learning: Life After the Tutorial
Kyri Paterson spoke about machine learning, data quality, and some of the mistakes companies have made when adding artificial intelligence to their products. She pointed out that ML algorithms are only as good as the data they are trained on, and that practitioners should be aware of pitfalls such as mislabelled data, feature scaling, correcting for bias in data sets using techniques like SMOTE, and data sanitization.
From the prejudice in Amazon's AI recruiting tool to the racist utterances of Microsoft's Tay chatbot to the implications of police wearing facial recognition glasses, there are many examples of imperfect technology powered by AI in our world today. Understanding what ML can and cannot do, and knowing that algorithms (and not just humans) can be biased, must be part of what data scientists consider nowadays.
Poor Programming Patterns and How to Avoid Them
Alice Yuan (@Names_Alice) gave several examples of code smells and poor programming in apps that she's worked on, and outlined solutions for them. A nice touch was her own hand-drawn illustrations on many of the slides.
The first issue she discussed was the classic inheritance vs composition design principle. A poor choice makes adding new features difficult, and leads to duplication of logic. Another poor choice was choosing an event bus over the observer pattern, as the former does not enforce that a listener is around when an event occurs. On Android, there are many choices available to implement observers and listeners (including LiveData and RxJava).
Alice also pointed out data consistency issues when attempting to cache values inside fragments, putting model-dependent logic in view layers. Her suggested solution was to use the repository pattern, a central source-of-truth for models. Note that the Jetpack guide to app architecture demonstrates a repository. Finally, she also chastised anyone not writing unit tests for their app. In her case, it was tightly coupled, poorly designed code that made it hard to test. By separating concerns, and using a good architecture pattern, she was able to improve understandability, promote code reusability, and ensure her code was testable.
Flutter: In Real Life, For Real People
Two of the organizers of AndroidTO, Mark Reale (@markreale) and Jeff Corcoran, closed the conference with an amusing talk about their journey of learning Flutter. Mark was convinced to starting learning Google's latest mobile SDK after listening to a podcast, but quickly learned that Google's own tutorials needed a lot of polishing.
Having two major mobile platforms to develop for means double the cost and effort for companies wanting apps on iOS and Android. Flutter is the latest attempt to solve the problem of building apps for two platforms from a single codebase. Mark and Jeff have hosted Flutter Study Jams in the past, relying on the educational resources that Google and Udacity provide. They quickly found that many of the materials were out-of-date and incomplete. It was not the case that you don't need any programming or development experience to get started with Dart and Flutter, despite the website's claims.
Mark put together a repository that outlined his journey, and Jeff ended up publishing an open-source conference app which was used for AndroidTO itself. (Watch the video to hear why there was no iOS version!)
Proceeds from this AndroidTO went to support the SickKids Tech&Innovation initiative. I also learned about a charitable organization in Canada called the Upside Foundation, aimed at early stage startups, for them to donate equity, which is then distributed to registered charities upon a liquidation event.