I've managed a team that developed serious android apps, and ended up dabbling with tools out there and processes/systems. Here is a quick summary of the various things to think about if you're serious about android development, and in some cases, my recommendations. This covers: IDE Build Source Control Bug/Task tracking Crash reporting Analytics Test Automation Continuous Integration Device Matrix testing Performance testing Beta testing A/B testing Backend-as-a-Service

1. Tools/Processes for serious
android app development
Gaurav Lochan
Little Eye Labs
Saturday 7 December 13

2. Introduction
Lots 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

3. 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

4. Overview
IDE
Continuous Integration
Build
Device Matrix testing
Source Control
Performance testing
Bug/Task tracking
Beta testing
Crash reporting
A/B testing
Analytics
Backend-as-a-Service
Test Automation
Saturday 7 December 13

5. 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

6. Build
Ant 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

7. Source Control
Git 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. Automation: Others
Monkey 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

14. 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

15. A/B Testing
Perhaps 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

16. Device Matrix testing
You *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

17. Performance Testing
App 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

18. 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

19. Beta-testing
It’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

20. Backend-as-a-Service
Most 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

21. 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