DroidCon NYC 2016
Updated November 12, 2016 with available videos from touchlab
This year I was lucky enough to attend DroidCon NYC, and soak up as much Android dev goodness as I could. There were a bunch of interesting talks, for a varying degree of knowledge level. Definitely something for everyone, something I can speak to, being I am very new to mobile/Android development.
During the conference, I seemed to find myself in the most popular talks, so when I could get a seat, I tried to take notes. I’ll compile them here so they can benefit more than just me.
Understanding Performance In The Wild
As someone who has been tasked with hunting down performance issues in web apps, I have been very interested in getting more insight into how that process works with native apps. Considering the multitude of issues you can run into server side, as well as on the network, adding native device performance as a factor seems like a whole new world of pain.
With Facebook being an international titan, Delyan’s talk did a great job communicating some of the hard-won lessons learned. Some of the highlights:
Keep in mind a wide variety of data caps and speeds when building out native performance reporting. Last thing you’d want is a ton of upset users because you burned through their cap sending debugging info. This can be mitigated by only sending data if enabled with a feature flag, random sampling of various degrees, or only uploading device metadata once, then joining it server side with subsequent events
The Observer Effect is very real: just trying to measure performance will impact performance and can make it difficult to separate signal from noise.
Be mindful of which clock you use for time reporting. Some clocks will default to reporting a time in the 1990s if the device is just starting up, and has not fetched the current time from the network.
Don’t be too trusting of reported data: exclude extreme outlier data points (5 hours, 5 years, etc). Pick sane minimum and maximum values so real issues do not accidentally get hidden in noise.
If things continue to not make sense, then you need to ramp up how much data you are collecting. This is where feature flags help a great deal, so you can activate additional levels of debugging data collection until you pinpoint the issue.
Effective Authentication User Experience for Consumer Apps
With rampant security breaches hitting the news, seemingly daily, Steven’s talk was one of the talks I was most interested in. Sign-up and login can be some of the biggest pain points, whether engineers realize it or not, and it was great to hear what someone from Google’s Identity Platform team had to say on the subject.
The presentation echoed concerns that are widespread when it comes to security: the delicate balance between maintaining a high level of security, and minimizing friction for users. If you make security hard, users WILL find a way to be insecure, or just not use your app. Some of the points I made note of:
Sign-up is “scary”: Give users the ability to access and navigate around as much of an app as possible before pushing to sign-up. Letting them see what it does and try things out before forcing sign-up eases a lot of concerns. Make sure to have a clear call to action and explanation of what they are getting into to further ease their minds.
Merge sign-up and sign-in: This becomes a lot easier when using an Identity Provider, so pushing for that can make life much easier. Otherwise grab the identifier (username or email) first and check if they have an account.
Sign-up with as little as possible: Strive to ask the bare minimum from the user. Things like auditing what information is essential to be functional, pulling information you need from an Identity Provider, and don’t make the user repeat themselves with passwords or emails.
Defer password creation: Create a strong and unique password for users, and rely on email only. Regardless of new or existing, send a “magic link” to a user’s email to let them authenticate.
Duplicate accounts: If a user signs up previously with an email and password, then uses an Identity Provider for that email (like Google), add the provider to the previous account and log them in. Be careful to only do this with “Authoritative” providers for the email, like Google auth for Gmail. Other providers, like Facebook, only know that the user AT SOME POINT had that email attached to their account.
Don’t roll your own auth: With the ever increasing number of hacks, the likelihood is that you WILL get hacked. Especially if you are just starting out, there is no reason to ever store user passwords. Solutions like Firebase allow you to offload responsibility to more battle tested code and infrastructure.
Integrating SDKs – secrets, strategies, and automated performance testing
Although offloading knowledge and functionality to a battle tested and well maintained SDK can make an engineer’s life much easier, doing so is not without risks. Sam discussed some key strategies to evaluate SDKs before incorporating them into your android app.
In a vast majority of cases, any intellectual property related to an SDK should be all server side, so the SDK itself should be open source to allow auditing.
One of the first criteria to check is the size of an SDK: the number of methods as well as the size “on disk” can cause a lot of headaches. Be extra wary of anything over 200KB.
Investigate what data an SDK collects: Does it collect things like MAC address or Android ID, and what does it need them for? Any collected identifying information has security and privacy implications for your users. Does it create a WebView just to fetch the user agent, possibly introducing performance issues?
What is the SDK’s network strategy? How much data does it transfer, and how often? This can have a negative impact on both a user’s data plan AND battery life.
Verify that the SDK has its own ProGuard rules, as they would be much better coming from the maintainer.Verify performance: Use Android Studio to monitor cold start and memory usage after adding an SDK. Using automated performance testing like from CodeLab can help make sure you don’t accidentally hamstring your app’s performance. General rule of thumb is SDK initialization should take less than 20 ms, and operations should take less than 1 ms.
Never use version wildcards when including SDKs, each updated version should be vetted and verified before upgrading. Tools like the Gradle Versions Plugin can help notify when new updates are available, as falling too far behind can be just as dangerous.
Practical GraphQL for Android
GraphQL, a very impressive Facebook Open Source offering, seems to be an incredibly powerful tool to help build robust APIs. Somewhat similar to JSON API, GraphQL gives an API consumer more power over the data they receive. Considering how sensitive mobile clients can be to data usage and number of network request, GraphQL can make a huge difference for network heavy apps.
With GraphQL, you don’t typically need to version, since clients are discovering attributes and relationships, and fetching them specifically.
GitHub is one of the newest GraphQL APIs, built with the Ruby server library
The easiest way to get started in GraphQL is to wrap your current API, with something like Express GraphQL
“Zero to GraphQL in 30 Minutes” by Steven Luscher is an excellent intro to starting a GraphQL API
There is currently no definitive native Android client for GraphQL, which leaves a big opportunity for OSS
When building a client, focusing on Fragments as opposed to Types seems to be a better strategy.
Honorable Mentions
There were a few talks I attended, but for one reason or another don’t have adequate notes, thankfully touchlab was recording the talks, so I’m able to at least share them here.
Android is for Everyone
2FA Beyond SMS
Bonus
At the conference I was lucky enough to win a Phantom 3 drone from the fine folks at mParticle! And here is the first (of many) videos of it in flight: