Tools/Processes for serious android app development

Gaurav LochanLittle Eye Labs

Saturday 7 December 13

IntroductionLots of folks are getting serious about building on Android

Android development is sufficiently different from web and desktop software

If you’re starting out to build a serious app, there are many choices you have to take. I’ll list them and make recommendations (suited for a small team starting up).

I’ve tried to simplify things, but, YMMV.

Saturday 7 December 13

Me?

I’ve worked as an engineer/tech-lead/manager at Microsoft, VMware, Flipkart and a few startups.

Worked on Android for 3 years now.

Ran a startup that built an android app + backend

Managed a team at Flipkart, responsible for 5 apps, applied lean-startup principles [video, slides]

Now I build a tool to help android devs (Little Eye Labs)

Saturday 7 December 13

OverviewIDE Continuous IntegrationBuild Device Matrix testingSource Control Performance testingBug/Task tracking Beta testingCrash reporting A/B testingAnalytics Backend-as-a-ServiceTest Automation

Saturday 7 December 13

IDE

Eclipse was the original supported IDE. Not intuitive and has quirks.

Google is now pushing Android Studio (built on IntelliJ). More intuitive IDE, integrates well with gradle (the new build system), but is still pre-release.

If starting from scratch, learn to use Android Studio, unless the bugs block you. It’s harder to switch later.

Saturday 7 December 13

BuildAnt is the old supported way

Gradle is new shiny thing

Maven is used, though mainly by open source libs, or existing maven shops

Start with Gradle, unless you have lots of experience with Ant/Maven. But do choose one so that you can automate builds from cmdline

At Flipkart, we built and shipped from Eclipse :-(

Saturday 7 December 13

Source ControlGit is absolutely incredible, I’m not going to suggest anything else

But at least 1 dev on your team needs to understand it well.

Great hosting options - GitHub, Bitbucket, Assembla

GitHub is well-understood but expensive. BitBucket is free and has other useful tools.

Use any client (I use both cmdline & SourceTree)

Saturday 7 December 13

Bug/Task Tracking

The Github / Bitbucket trackers are good enough

GitHub is more basic but ‘Milestones’ can be used for release mgmt (used them at flipkart)

Asana is great for task tracking, can be used for bugs, not great for release mgmt.

Trello / Pivotal tracker are great for agile project mgmt, not so much for bugs.

Saturday 7 December 13

Crash Reporting SDK

You *must* use one, from day 1.

ACRA - More flexible, but doesn’t come with it’s own collection/reporting service.

Crittercism, Bugsense, Crashlytics - all good products

I like Crittercism the most, but Crashlytics is free!

Register two instances (Dev and Prod) to separate the dev noise from production issues.

Saturday 7 December 13

Analytics SDK

You *must* use one before you sending builds out for feedback, to understand what users are doing!

Start tracking broad analytics that make sense - be prepared add more with each iteration

Google Analytics and Flurry have been around for a while. MixPanel on Android is new.

Use an abstraction layer so you can switch if needed

Saturday 7 December 13

Automation: Unit Testing

ie, Testing code in isolation, not the whole product.

Eclipse/ADT support junit out of the box. But junit tests won’t run on your desktop (calls to android.jar will fail) so you need to mock out android.jar.

RoboElectric

Mockito

AndroidMock

Saturday 7 December 13

Automation: Integration

ie, Testing the complete product (or at least, different parts of the product working together)

Frameworks basically provide a way to trigger an action from the UI, and then check for the different outcomes.

MonkeyRunner from Google (Python)

Robotium (Java)

Calabash

Saturday 7 December 13

Automation: OthersMonkey tool (from Google) - fuzz-testing tool

Spoon (from Square) pushes tests to multiple devices, aggregate results, and takes screenshots.

FEST for more readable assertions (from Square)

Services that auto-generate tests (e.g. TestDroid, Xamarin TestCloud, AppThwack)

Recomendation: Start with Robotium for UI, RoboElectric for unit tests. Plan for Spoon.

Saturday 7 December 13

Continuous Integration (CI)Jenkins and Travis are popular CI servers for android

I’ve only used Jenkins, which was easy to set up

Android plugin to create different emulators

You *must* generate your builds from your CI server, and at least start the app on an emulator.

You *should* configure CI to create emulators with different OS versions/configs, and test each build for a bit with the ‘monkey’ tool - Bang for the buck.

Saturday 7 December 13

A/B TestingPerhaps not needed while getting your first release out, but useful once you have more users

clutch.io: Open-sourced by Twitter. You’ll need to host it, but it’s open source!

Lots of paid services - haven’t used them so can’t really comment on them.

Only when you have enough active users

Needless to say, need to collect analytics first.

Saturday 7 December 13

Device Matrix testingYou *must* test on multiple devices - OS versions, screen sizes, manufactures, hardware, network configs.

Buy some test devices across the matrix, but...

test OS/Screen sizes against emulators and/or manymo.com

Test on real world devices through device labs

Device Anywhere, pCloudy, etc

Saturday 7 December 13

Performance TestingApp Performance is about responsiveness and system resource consumption.

Responsiveness

Badly implemented UI - Use tools like Hierarchy Viewer, Droid Inspector. Android 4.x has tools in ‘developer options’ for quickly figuring issues.

Memory allocations - Little Eye and/or MAT

CPU - TraceView, Systrace, Little Eye

Saturday 7 December 13

Performance Testing (2)Understanding Resource consumption

Battery - Little Eye can show you consumption for each thing that your app does

Network

DDMS, Little Eye give broad network usage graphs

Little Eye, New Relic, Crittercism can give detailed HTTP stats info

Saturday 7 December 13

Beta-testingIt’s critical to get early feedback (and device coverage!), before pushing to the store.

You need to be able to manage/track the builds, and collect feedback.

Google Play beta testing does the former

You need to do the latter. Crash reporting and Analytics will help here.

Services for system data, e.g. BetaGlide/TestFairy

Saturday 7 December 13

Backend-as-a-ServiceMost apps talk to a backend API. If the backend is simple and is persisting data, you can use a hosted service and not write/maintain one yourself.

Huge productivity win if your devs are app guys

I’ve used Parse and StackMob in production (both support server-side code). Parse has better docs, StackMob supports a dual ‘staging/prod’ environment.

FireBase is popular for real-time apps

Saturday 7 December 13

Summary

Lots of stuff to think about before you jump in

You can choose not to do all of them, but now it’s a conscious decision :-). Plan around this upfront, then focus your efforts on building a great app.

Share feedback/comments/experiences:

@gauravl

http://www.slideshare.net/gauravl/

Saturday 7 December 13