Tools/Processes for serious android app development


Published on

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:
Source Control
Bug/Task tracking
Crash reporting
Test Automation
Continuous Integration
Device Matrix testing
Performance testing
Beta testing
A/B testing

Published in: Technology

Tools/Processes for serious android app development

  1. 1. Tools/Processes for serious android app development Gaurav Lochan Little Eye Labs Saturday 7 December 13
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. A/B Testing Perhaps not needed while getting your first release out, but useful once you have more users 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. 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 Test on real world devices through device labs Device Anywhere, pCloudy, etc Saturday 7 December 13
  17. 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. 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. 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. 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. 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 Saturday 7 December 13