3 AUDIOBOOK COLLECTIONS

6 BOOK COLLECTIONS
2
Contents

Legal and Disclaimers 7

License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

How to support this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Limited Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Limitation of Liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Trademarks Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Acknowledgments 9

Donators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Cover image and illustations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Preface 11

About this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Who should read this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Philosophy and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

How this book is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

How to use this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Conventions used in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Recommanded references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

About the author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Part 1 : The Agile Android Toolbox 19

Getting Started with Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Introduction to Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3
4 CONTENTS

Quick Intro to Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Getting to know Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Android Emulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Testing Android on real devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Configuring our test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Testing the Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Our first red-green-refactor loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Static Code Analysis Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Part 2 : Automation 101 25

Droplet setup on Digital Ocean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Setting up Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Useful Jenkins plugins for Android Development . . . . . . . . . . . . . . . . . . . . 26

launching a first CI job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

GitLab Installation on our Droplet . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Integration between GitLab and Jenkins . . . . . . . . . . . . . . . . . . . . . . . . 26

Setting up a first CI job for Fizz Buzz . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Adding TDD to Fizz Buzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Publishing APKs in Jenkins for beta testing . . . . . . . . . . . . . . . . . . . . . . . 27

SonarQube Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Integration between SonarQube and Jenkins . . . . . . . . . . . . . . . . . . . . . 27

Setting up email notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Receiving build notifications on Android . . . . . . . . . . . . . . . . . . . . . . . . 27

Securing Web access using SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Part 3 : Agile Software Project Management 29

Agile project management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Setting up Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Redmine Integration with our environment . . . . . . . . . . . . . . . . . . . . . . 30

Installing the BackLog plugin in Redmine . . . . . . . . . . . . . . . . . . . . . . . 30

Quick Introduction to the Backlog plugin . . . . . . . . . . . . . . . . . . . . . . . 30

App design mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

CONTENTS 5

BDD and Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Simplifying using code injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Android source code modularization . . . . . . . . . . . . . . . . . . . . . . . . . 31

Automatization using Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Part 4 : Lean Android 33

DRY-ing out the Android development process . . . . . . . . . . . . . . . . . . . . . 34

Setting up an efficient Build-Measure-Learn loop . . . . . . . . . . . . . . . . . . . 34

Part 5 : Scaling 35

Automation strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

On-demand Jenkins slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Automated deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Large scale testing on real devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Team collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Offshore development : how to find great collaborators . . . . . . . . . . . . . . . . 36

Multiple target using the same source code . . . . . . . . . . . . . . . . . . . . . . 36

Part 6 : Advanced Topics 37

Reducing time to market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Monetization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Low cost marketing tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

How to deal with legacy apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Appendix : About technological watch and agility 39

How to observe a technological watch . . . . . . . . . . . . . . . . . . . . . . . . . 40

Selecting the best tool for the job . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

The Agile Android Developer Philosophy . . . . . . . . . . . . . . . . . . . . . . . . 48

6 CONTENTS
Legal and Disclaimers

License

Agile Android Software Development by Etienne Savard is licensed under a Creative Commons
Attribution-NonCommercial 4.0 International License.
For commercial use of this book, please contact the author for inquiries (see the book website
for contact information): http://agiledroid.com

How to support this book

Donations

This book is free (as in free speech, not free beer). Donations are welcome, and a great way to
show your support for my work. All donators will be credited in the acknowledgments section of
this book. You can give any amount you like.

Opinions

Please share your opinions and comments about the book by answering this short survey: http:
//goo.gl/4xosAm

Referral Links

In the electronic versions of this book (pdf, mobi, epub, etc.), you will find referral links in the
text. These links allow the author to get paid if you end up buying the products to which they
refer. At any time, you can decide to copy the link text in your web browser rather than clicking
the hyperlink to directly access the product page or service.

7
8 CONTENTS

Limited Warranty

Symbiosoft warrants that the ebook files are free from defects in the operational sense that they
can be read by a PDF Reader, ePub reader, Kindle, or other. EXCEPT FOR THIS EXPRESS LIMITED
WARRANTY, SYMBIOSOFT MAKES AND YOU RECEIVE NO WARRANTIES, EXPRESS, IMPLIED, STATU-
TORY OR IN ANY COMMUNICATION WITH YOU, AND SYMBIOSOFT SPECIFICALLY DISCLAIMS ANY
OTHER WARRANTY INCLUDING THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS OR A
PARTICULAR PURPOSE. SYMBIOSOFT DOES NOT WARRANT THAT THE OPERATION OF THE EBOOK
WILL BE UNINTERRUPTED OR ERROR FREE. If the ebook was purchased in the United States, the
above exclusions may not apply to you as some states do not allow the exclusion of implied war-
ranties. In addition to the above warranty rights, you may also have other rights that vary from
state to state.

Limitation of Liability

IN NO EVENT WILL SYMBIOSOFT BE LIABLE FOR ANY DAMAGES, WHETHER ARISING FOR TORT OR
CONTRACT, INCLUDING LOSS OF DATA, LOST PROFITS, OR OTHER SPECIAL, INCIDENTAL, CONSE-
QUENTIAL, OR INDIRECT DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE EBOOK.

Trademarks Disclaimer

Symbiosoft logo and name are trademarks of Symbiosoft (9250-2780 QUEBEC INC.).

Product names, logos, brands and other trademarks referred to within this work are the prop-
erty of their respective trademark holders. These trademark holders are not affiliated with Sym-
biosoft, our products, or our websites. They do not sponsor or endorse our materials. Below is a
partial listing of these trademarks and their owners. This list is subject to change without notice.

Android is a trademark of Google Inc. Portions are modifications based on work created and
shared by Google and used according to terms described in the Creative Commons 3.0 Attribution
License.

Opinions expressed in this eBook are those of Etienne Savard, and may not be shared by Sym-
biosoft’s customers.
Acknowledgments

Donators

You will find below a list of all donators that contributed money to support this free book. Your
support to this project means a lot, and best efforts were deployed to meet your expectactions
while writing this book.

Thank you!

Early adopters

Below are the first donators when this book was still in its infency. Thank you to have believed in
this project early on. You drived me forward during this journey.

• David Conde Ortega

• Ryan De Gruyter
• Francis Perreault
• Douglas Carvalho
• Elaine Dias Batista
• Juan Jose Sanchez Silos
• François Roy
• Francis Toth
• Carmen Radu
• Joe Jimenez
• Kevin Berglund

Kickstarter campain contributors

Coming soon!

9
10 CONTENTS

How to be listed here?

You can add your name to this list too by donating.

Cover image and illustations

All illustrations of this book, unless specified otherwise, are the original creations of either my
daughters, Lea and Marianne, or myself.

Lea draw the cover image for me on the whiteboard after she saw the Android mascot somewhere
in my home office. I colored and edited the original drawing using GIMP.

Thanks Lea & Marianne.

Preface

Android can be a lot of things depending on your point of view.

For Google, Android is a vehicle to expand their business into new areas where they were absent a
few years ago. Google has evolved from a web search engine into a company with many product
lines and businesses—from mobile phones, music, and books to video-on-demand. With the
release of Android Lollipop, you can also add TV and wearables to that list.

For mobile manufacturers—such as Samsung, LG and HTC—Android is an Open Source mobile

operating system (OS) they can tweak and use without paying royalties.1

For users, the Android OS is less visible but is nevertheless a critical piece of their daily activities.
They depend on Android to send and receive emails, chat, take pictures, entertain, and much
more. Average users are not power users, and as such they will want quality apps that will run
without crashing.

For us as developers, Android is a way to express our creativity (outside of our 9–5 routine), learn
mobile software development, and make some money on the side. Regardless of the reason
that brings you to Android software development, you are (or will be) faced with the same prob-
lems that fellow Android developers encounter every day. These include: fragmentation, legacy
code, bad code, ineffective monetization, and so forth. Most of these burdens can be avoided
or mitigated by using the right tools and techniques combined with an agile mindset. These ef-
fective techniques and tools can help you enjoy Android programming even more by freeing up
your time, so you can really develop—instead of just fixing problems, looking for answers on
StackOverflow, avoiding pitfalls, or rewriting the same boiler plate code over and over again.2

By the end of this book, you should be a more productive and, therefore, happier Android soft-
ware developer. You would be surprised what a happy developer can accomplish!

1
If you omit the fact that Microsoft collected Android patent royalties from Android smartphone manufacturers. (http:
//www.businessinsider.com/microsoft-earns-2-billion-per-year-from-android-patent-royalties-2013-11)
2
My definition of boiler plate code is this: Any code that doesn’t add value to the final product. In our case, the product
is an Android app. In Lean Startup terms, it’s synonymous to waste (waste of time, resources, money).

11
12 CONTENTS

About this book

When I started learning Android programming, I sometimes found myself confronted by a daunt-
ing task and wondering, “Is there a more agile way to do this or that?” I’ve been searching for
answers in Android programming books expecting to find something about the tools I use daily
in my job but used in the context of mobile application development. Yet I have found nothing.

Why is that? There are a bunch of great tools out there that can make your Android software
development experience more enjoyable. Many of these tools are free and Open Source, but they
are not covered in any book. My theory is that most Android programming books are targeted
at novices and seldom at intermediate-level Android developers (our audience here). I think you
have to experience (and even suffer a bit) with Android app development before you start looking
around for more agile, alternative ways of doing things.

In this book, we covering most of the tools normally described in Application Lifecycle Manage-
ment (ALM) or DevOps3 books, but used in the context of Android software development. Think
of DevOps for a team of one!

I also share my experiences about monetization, marketing and other things not related to An-
droid programming per se, but essential to successfully publishing an app in Google Play or other
Android app stores.

Because of the number of topics covered in this book, I will not throw a bunch of code in your face
(lucky you). Instead, I’ve selected a simple example that we will use from the first chapters until
the end of the book—the FizzBuzz app.4 The Fizz Buzz algorithm is great to teach developers how
to do test-driven development (TDD), and it is simple enough to let us focus on the techniques
rather than our problem-solving skills. We evolve this app from a wireframe concept on paper to
a fully functioning app that we release to Google Play. All of the concepts demonstrated in this
book are usable for other apps you develop. At the end of each chapter, there are some hints to
guide you on how to use the concepts to your own benefit.

Who should read this book

This book is targeted at experienced software developers who are familiar with at least one Object
Oriented Programming (OOP) language, such as C++, C#, or Java. You should also have some basic
understanding of source code control (preferably Git), shell scripting and Linux (if you know how
to open a command shell, you will do great).

The techniques and tools shared in this book are presented mostly in the context of a team of
one—that is, one indie developer who wants to take his Android development workflow to the
next level. The concepts presented in this book can also apply to larger teams, but this is not our
main audience.

To get the most from this book, you should already have read one or more entry-level books about
Android programming (see the following Recommanded References section), and you should
3
For details, see the DevOps definition on Wikipedia: http://en.wikipedia.org/wiki/DevOps
4
See the Fizz Buzz article on Wikipedia for details: http://en.wikipedia.org/wiki/Fizz_buzz
PHILOSOPHY AND GUIDELINES 13

already have released one or more Android apps to Google Play.

This book does not cover Android basics, but it does its best to address all those questions you
may end up with after we present advanced topics. In the case where some intermediate to
advanced knowledge is required to fully understand a topic, you are provided with references to
look up.

Additionally, if you have some experience with Agile software projects, this will give you a head
start, but it is not required.

Finally, if you are an experienced developer working full-time for your boss’s software company—
and dreaming of doing your own things—you will find food for thought in this book. Likewise, if
you’re looking to improve your Android programming workflow, learn new tools and techniques,
develop more agile apps—and even make some money with Android—this book is definitely for
you!

Philosophy and guidelines

Big disclaimer: This book is, at times, very opinionated. Mea culpae, the core of this book comes
from my years on the IT battlefield, and I’ve learned the hard way what works and what doesn’t.

I beg you to differ and share your view about any subject covered in this book in the discussion
group (see the following How to use this book section). For this book, I have positioned some
tools that I find work great in the context of Android project development. They may not be
the best tools on the market, but they are the best I have found to get the job done. (They also
happen to be the tools I know and use every day). I will explain the process I use to select tools
among many equivalents in the chapter on technological watch. You will be able to use these
concepts beyond Android app development

I’ve developed the book examples on Linux and haven’t fully tested these on Windows or OSX.
However, due to the portable nature of Android (and Java), they should work out-of-the-box on
any platform. Generally, for the sake of agility, I do my best to select tools that are platform-
independent or web-based. If some examples or scripts don’t work as expected in your develop-
ment environment, I encourage you to submit a bug report to me with as much detail as possible
(and if you happen to find a solution specific to a platform, send that as well). If I can help you, I
will, or another reader might be able to give you a hand.

I designed the content of this book as a greenfield project (that is from scratch or without the
legacy) and for a team of one or a “two-pizza team”5 in mind. At times, the tools and processes I
present will seem like killing a fly with a bazooka if you’re a lone developer, but they will help you
structure your work and keep you organized. In fact, if you end up growing your app business
(and I hope you will!), you will be grateful that you have observed a Spartan discipline with your
Android projects because the best practices already will be assimilated by you and your team,
and they will serve as the cornerstone of your Android business.

5
An expression coined by Jeff Bezos, CEO of Amazon. A small team (usually between 6 to 10 people) you can feed with
two pizzas.
14 CONTENTS

All designs, processes, examples, concepts, and such presented in this book had to meet the
following criteria before being included:

• Must be scalable;
• Must respect the Don’t Repeat Yourself (DRY) principle and be automated if possible;
• Must be agile (that is, tolerant and adaptable to change);
• Must reduce or (better) eliminate waste (for example, time, money, resources);
• Must not get in the way of the developer.

All of this was taken into account for the sake of helping you reduce the time-to-market for your
apps and let you focus on developing great ones.

How this book is organized

This book is organized in six parts:

1. The Agile Android Toolbox

2. Automation 101
3. Agile Software Project Management
4. Lean Android
5. Scaling
6. Advanced Topics

In Part 1, we set up and present the tools I propose to fill your Agile Android developer toolbox.
By the end of Part 1, you will have set up a development environment that will help you build
our example application. In Part 2, building upon what we’ve learned in the previous chapters, I
teach you how to optimize your development process by automating tedious or repetitive tasks,
so we can concentrate on tasks with added value in building our final app. Then, in Part 3, we
look at software management using Agile tools and methodology. We also talk about subjects
like behavior-driven development (BDD) and TDD to help us document our code and designs. In
Part 4, we locate and eliminate sources of waste. We follow some theories provided by the Lean
Startup movement and learn how to implement an effective feedback loop (Build-Measure-Learn
loop) for Android software projects. In Part 5, I show you how to use cloud computing to your
advantage and scale your builds and tests to multiple environments. Finally, in Part 6, I talk about
more advanced topics, such as marketing for your apps, publishing, and monetization tips and
techniques.

In the appendix, I present less technical subjects that are usefull but not at the core of Agile
Android software development. I present the techniques I use to monitor the evolution of the
market, so I am alerted when new trends or opportunities surface. I also present how to select
tools among equivalent alternatives.

I hope you enjoy the ride!

HOW TO USE THIS BOOK 15

How to use this book

The first three parts of this book are meant to be followed in order like a tutorial. First, we put
in place a development environment to support the Agile workflow we propose. Then, in the
subsequent parts, we use that environment to build our example application and to improve it
as we progress. You can always skip some content if you are already familiar with it. The Git
repository is designed to provide you with the example app at a working state corresponding to
a specific chapter. So you can pick it up from there and continue with more advanced topics
without getting lost. If we think a chapter can be skipped by the more advanced readers (without
impacting their comprehension of the following chapters), you will see an optional icon marking
that chapter (see the following Conventions used in this book section).

The book was written with the idea of releasing it to the community in parts as it was written.
That way, I was able to build a Build-Measure-Learn loop from the beginning à la Lean Startup.6
This book will continue to develop even after it is released, and it will be updated regularly using
feedback from readers and by following the new trends the Android ecosystem brings us. So,
as a complement to this book, I strongly encourage you to register—for free—to the following
communities to stay informed of new events related to Agile Android Software Development:

• Google Group: https://groups.google.com/forum/?hl=fr#!forum/agile-android-software-development

• Google+ community: https://plus.google.com/u/0/communities/106666596834203709065
• Mailing List: http://eepurl.com/XTV8H

You should also register for a free account on GitHub to access the Agile Android Software Devel-
opment repository : https://github.com/Agile-Android-Software-Development. You will be able
to get all the examples, scripts, and much more from the Git repository.

Conventions used in this book

The following conventions are used in this book:

Constant width

Used for source code listings and reference of class, variable, parameter names, and such refer-
ring to code snippets.

Constant width in bold

Indicates source code that was modified to illustrate an improvement to a previously presented
source code listing.

Italic

Used when referring to URLs, filenames, file extensions, and to put emphasis on technical terms
the first time they are cited in a chapter.
6
http://theleanstartup.com/
16 CONTENTS

This icon indicates a tip or a suggestion.

This icon represents a notice or warning.

This icon illustrates that a section of text can be skipped and is provided only to offer some depth
to a topic but is not essential to its understanding.

Recommanded references

If you need to deepen your knowledge or dust-off your Android programming skills, I recommend
you the following books :

• Phillips, Bill, and Brian Hardy. Android programming : the Big Nerd Ranch guide. At-
lanta, Ga: Big Nerd Ranch, 2013. Print. ISBN-10: 0321804333.
• Mednieks, Zigurd R. Programming Android. Farnham: O’Reilly, 2012. Print. ISBN-10:
9781449316648.
• Clifton, Ian G. Android user interface design : turning ideas and sketches into beau-
tifully designed apps. Upper Saddle River, NJ: Addison-Wesley, 2013. Print. ISBN-10:
0321886739.
• Murphy, Mark L. The Busy Coder’s Guide to Android Development. eBook. Website:
https://wares.commonsware.com.

About the author

Étienne Savard is a dad, a certified Professional Scrum Master (PSM), a pragmatic programmer,
and an Open Source advocate. He has been a software developer for a long time. It all started
on a TRS-80 Color Computer (when 64K was a lot of memory and 16 colors were enough). Since
then, he has continued to pursue his quest to boldly go where no developer has gone before!

Étienne works as an IT consultant helping companies (from startups to large corporations) inte-
grate best-of-breed tools and best practices into their software development process, including
most of the same tools and practices presented in this book.

He started Android programming with the Gingerbread version of Android by reading books,
following tutorials, and looking at a lot of source code. Étienne has also released a couple of apps
ABOUT THE AUTHOR 17

on Google Play with some success and a lot of trial and error. He enjoyed Android programming
from the start because of its openness, community, and architecture. Etienne has found that the
only missing part in the Android ecosystem is a more agile way of developing Android apps. This
book is here to fill that gap.
18 CONTENTS
Part 1 : The Agile Android Toolbox

In the following chapters, we will guide you, step by step, and setup an highly productive and
portable agile software development environment. You will learn to use docker to setup a devel-
opment environment that will be portable, versionable in git (yeah!) and that you will be able to
share with other developers (if your development team grows). We will also setup a continuous
integration (CI) server, an artefact repository server and other tools that will be helpful to DRY
our android development workflow.

19
20 CONTENTS

Getting Started with Docker

What is Docker

Simply put, Docker is an Open Source program that enables a Linux application and its depen-
dencies to be packaged as a container. Unlike other virtualization solution, Docker don’t try to
emulate the hardware. As a result, provisoning, deploying and launching docker containers is
fast. Thanks to the dockerfile, the recipe to provisoning a particular container can be shared, ver-
sionned (using git for example) and used by other dockerfiles as a dependency—hence enabling
modularity—and, most importantly, is portable. You will use the same dockerfile to deploy a
container to your developer laptop as you would on a server in the cloud.

Why should I care as an Android developer?

The Docker project was open sourced on March 2013. In this short lapse of time, Docker man-
aged to become immensly popular among the software development community, and is now
supported by most of the major cloud plateform providers—such as Red Hat, Google, and Ama-
zon.

But, as an Android Developer, the main advantage of using docker is that you could use it for
versionning your software development environment and to distributed it. You could also version
it in git to capture it’s evolution, and even revert some changes if you need to. It could anihilate
completly the but it works on my machine syndrome by allowing you to develop, compile, test
and deploy the same controlled—contained—environment over and over independently of the
underlying hardware.

Another use case I see for Docker, is when a developer join an existing team. All you have to do
to set her up and running is to share with her your docker repository pointing to your dockerfile.
Docker will provisionning automatically her work environment in less than minutes—yes min-
utes—not days. If she mess up her development environment somehow, she can just destroy
her container and fetch a new one.

It may seem overkill right now, but you will probably thank me someday! When your hard drive
fail, when you lost your laptop or if you just had a bad Friday, and want a fresh start on Monday.
The overhead of running apps over a thin virtualization layer—instead on the real machine—is
negilgeable in comparison of the hours you will save down the road.

Setting up Docker

Setting up Docker on Linux is straight forward as long as your Linux distribution comes with a
recent 64 bits kernel (version 3.10 or better). For this book, I used Linux Mint 17 distribution (a
derivative of Ubuntu) and was able to setup Docker in less than 5 minutes—your mileage may
vary.

On Windows and OSX operating systems, because they don’t run the Linux Kernel natively, you
have to use an installer named Boot2Docker which consist of a small Linux virtual machine (less
GETTING STARTED WITH DOCKER 21

than 27 MB in size) running on Virtual Box with Docker pre-installed. Boot2Docker boots in 5
seconds. I will describe the installation process using the 2 methods.

Linux installation

In this section, I will describe all the steps necessary to install Docker on Ubuntu. If you hap-
pen to use other Linux distributions—such as Fedora, Arch or SUSE—please, consult the official
online documentation for instructions for your particular distribution: https://docs.docker.com/
installation/#installation

Requirement A 64 bit installation is required to run docker containers. Your Linux distribu-
tion must also run a recent kernel (3.10 or more recent version). Older version may lack some
required features needed by Docker.

To check if your version is compatible, open a Linux terminal and enter the following command:

uname -a

That command should output something similar to this:

Linux esavard-UX32VD 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00

UTC 2014 x86_64 x86_64 x86_64 GNU/Linux.

Where 3.13.0-24-generic is the version of the kernel, and x86_64 is the architecture (in this
case, Intel 64 bits processor). If you read something like x86_32 instead and a version lower than
3.10, you might have to upgrade your linux distribution to a newer—64 bits—version that can
support Docker.

For the rest of this book, we will assume that you are using at least Ubuntu Trusty 14.04 or a
derivative. If it’s not your case, please, refer to the Docker official documentation or ask for help
on the book’s forum.

1) Open a terminal and type the following commands: sudo apt-get update

2) Download docker binaries, and install the additional packages (if needed), do the following:
wget -qO- https://get.docker.com/ | sh

3) to use docker as non-root (without sudo) Do: ‘sudo usermod -aG docker whoami

4) Close your current terminal and open a new one (to reload any sripts or environment
variables the Docker installation may have added).

5) Test the installation: sudo docker run hello-world

You should see something similar to the expected output below.

22 CONTENTS

Unable to find image 'hello-world:latest' locally

511136ea3c5a: Pull complete
31cbccb51277: Pull complete
e45a5af57b00: Pull complete
hello-world:latest: The image you are pulling has been verified.
Important: image verification is a tech preview feature and should not
be relied on to provide security.
Status: Downloaded newer image for hello-world:latest
Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:

1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(Assuming it was not already locally available.)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

If instead you see something like the following message:

FATA[0000] Cannot connect to the Docker daemon.

Is 'docker -d' running on this host?

Then you may have to restart—or start—the docker deamon using the command: sudo
service docker start and re-run the installation test:

sudo docker run hello-world

If your installation was a success, proceed with the next section Hello Docker. If not, as always,
ask for help on the book’s forum.

Windows installation

Hello Docker

The Docker public repository

Once you have setup your own docker project on GitHub—or fork an existing one that you have,
you can ultimately make it public on the Docker’s repository. You can access it from: https://
registry.hub.docker.com/
INTRODUCTION TO ANDROID STUDIO 23

The Agile Android Software Development containers

Going further

If you want more examples and ideas on how to use Docker, visit: http://docs.docker.com/userguide/

Introduction to Android Studio

TODO

Quick Intro to Git

TODO

Getting to know Gradle

TODO

Android Emulators

TODO

Testing Android on real devices

TODO

Configuring our test environment

TODO

Testing the Test Environment

TODO
24 CONTENTS

Our first red-green-refactor loop

TODO

Static Code Analysis Setup

TODO
Part 2 : Automation 101

You will learn in the following chapter to build upon the tools we setup in part 2 to automatize
your development process. Those techniques will help you, independently of your team size, to
free to elevate you above the crowd of avid coding monkeys.

25
26 CONTENTS

Droplet setup on Digital Ocean

TODO

Setting up Jenkins

TODO

Useful Jenkins plugins for Android Development

TODO

launching a first CI job

TODO

GitLab Installation on our Droplet

TODO

Integration between GitLab and Jenkins

TODO

Setting up a first CI job for Fizz Buzz

TODO

Adding TDD to Fizz Buzz

TODO
PUBLISHING APKS IN JENKINS FOR BETA TESTING 27

Publishing APKs in Jenkins for beta testing

TODO

SonarQube Installation and Setup

TODO

Integration between SonarQube and Jenkins

TODO

Setting up email notifications

Jenkins

GitLab

TODO

Receiving build notifications on Android

TODO

Securing Web access using SSL

TODO
28 CONTENTS
Part 3 : Agile Software Project
Management

You will learn how to manage your Android projects using agile tools, from the idea on the white-
board to the user’s hands and beyond.

29
30 CONTENTS

Agile project management tools

TODO

Setting up Redmine

TODO

Redmine Integration with our environment

Jenkins integration

GitLab integration

TODO

Installing the BackLog plugin in Redmine

TODO

Quick Introduction to the Backlog plugin

TODO

App design mockup

TODO

BDD and Android

TODO

Simplifying using code injection

TODO
ANDROID SOURCE CODE MODULARIZATION 31

Android source code modularization

TODO

Automatization using Gradle

TODO
32 CONTENTS
Part 4 : Lean Android

You will learn in the following chapters how to “DRY-ing” out you development process to elimi-
nate any inefficient tasks and replace them with automatition if, and only if, they add value to your
final product : your app. We will also cover how to put in place an efficient “Build-Measure-Learn”
loop as described in the Lean Startup methodology targetted specifically to produce quality An-
droid apps.

33
34 CONTENTS

DRY-ing out the Android development process

TODO

Setting up an efficient Build-Measure-Learn loop

TODO
Part 5 : Scaling

You will learn in the following chapters how to use the cloud to test on more device in less time.
Your build environment will be available for anyone from anywhere. You will also learn how
to grow your team using offshore or nearshore collaborators. How to interact with them using
collaboration tools. We will also cover continuous deployment using the latest Google Play API
and Jenkins.

35
36 CONTENTS

Automation strategy

TODO

On-demand Jenkins slaves

TODO

Automated deployment

TODO

Large scale testing on real devices

TODO

Team collaboration

TODO

Offshore development : how to find great collaborators

TODO

Multiple target using the same source code

TODO
Part 6 : Advanced Topics

In this part, we will share tips to reduce time to market by using library to modularize our apps and
produce sequels faster if needed or to simply reuse boiler plate functionnalities across multiple
apps.

We will also see how to monetize application for Android. What’s working and what’s not. How
to market your application on a shoestring budget using ASO techniques to get notified among
millions of existing apps.

Finally, we will see how to convert your legacy Android apps from Eclipse to Android Studio to
use the new ide and replace Ant builds by more flexible Gradle builds.

37
38 CONTENTS

Reducing time to market

TODO

Monetization

TODO

Low cost marketing tips

TODO

How to deal with legacy apps

TODO
Appendix : About technological
watch and agility

In the following chapters, I teach you the tips and tricks I’ve learned over the years that will help
you effectively follow the trends in our ever-evolving field. I also give you the techniques to help
you select the best tools among a group of equivalent candidates. These techniques apply not
only to Android libraries and tools, but to all ranges of tools used in IT in general. I use them every
day whenever the need for a new tool arises. Finally, I present my Agile Android programming
philosophy.

39
40 CONTENTS

How to observe a technological watch

A mile wide and an inch deep

As an IT consultant, I’ve learned to stay on the cutting edge of innovation. I don’t do this for the
money; I do this because I’m a technology junkie—I like to know what’s coming up, and I want
to embrace the change instead of fear it. That state of mind opens up a lot of opportunities that
the majority of our fellow developers won’t see, staying comfortably in their day-to-day routine.
Instead, they follow trends only after they’ve become mainstream, and safer bets.

There are two groups of developers : the early adopters, and the followers. Personaly, I prefer to
be an early adopter, and I also like to work with teams of early adopters. When I introduce new
tools in a development team, the early adopters tend to be better ambassadors of change than
the followers, which results in less resistance to change—independent of the scale of it. Change is
like a stream that becomes a huge torrent when the snow melts in the spring—you can’t oppose it
when it reaches a critical mass. The choice is then pretty simple : you ride the wave of change, or
you risk being submerged by it; and becoming obsolete. Blackberry is a good example of a sinking
boat—they once were the leader of the smartphone market, but they sat on their success and
were submerged by their competition. What they didn’t seem to understand is that no company
drives the market—customers do. Now Blackberry is struggling as is Microsoft because they were
too late to jump on the smartphone train. On the other hand, Google and Apple have taken the
early adopter approach, and that has paid well—a billion times over! Neither Google nor Apple
invented the smartphone but they saw the opportunity; and embraced it.

Now, as a developer, you can also be on the cutting edge of technology by observing a wide
technology watch of the entire IT market. But, how do you do this without spending too much
time and energy?

Luckily for us, there are tools to help us, and—for the most part—they can be automated. So,
you can spend only a couple of hours a week sweeping the market in search of a nasceant trend
and digging deeper only when you see an interesting opportunity.

In this chapter, I start by presenting tools and techniques to observe the IT landscape as a whole,
then I show you how to pinpoint your research to monitor interesting trends in more detail.
Obviously—because of the subject of this book—I will show you how to observe Android trends
specifically, but the techniques demonstrated here can be aplied to observe any technology you
want.

What’s hot, what’s not

One of my favorite tools is the TIOBE Index—it gives a good overview of where our industry is
headed. The TIOBE Index is computed monthly using various data collected from major websites.
Each month, TIOBE presents the results in a table ranked by popularity among more than 150
programming languages.

As of this writing, the C programming language (16.721%) is the king of the hill followed closely
by Java (14.140%), and Objective-C (9.935%). It is no surprise that two of the three top languages
HOW TO OBSERVE A TECHNOLOGICAL WATCH 41

for September 2014 are mobile programming languages—the mobile industry is still emerging,
but the demand for mobile developers is high. I will leave it as an exercise to find out why the C
language is the #1 language.

Another good way to take the pulse of our industry is to monitor the job sites—even if you’re not
looking for a new job! It’s a great indicator of the demand for a particular technology. I recom-
mend using a job aggregator for your monitoring because it saves you the trouble of registering
at many job search websites, and it provides you with alerts delivered directly to your inbox.

I particularly like job aggregators like Indeed for its capacity to monitor the job market globally, by
region, or even by metropolitan area. Always use simple queries to get the most possible results.
For example, I have an alert for Android, which returns a lot of hits. You can quickly browse the
aggregated jobs list to spot only the more interesting ones and determine the most commonly
requested technologies for similar jobs. Be careful though, some technologies are hotter in the
US than, let’s say, in Canada or Europe. For example, if you monitor Go programming language
jobs, there is a big chance your search hits will be mostly located in the United States, and you
will find fewer jobs elsewhere. That doesn’t mean Go is irrelevant and not worth monitoring. Go
is a fantastic language that will continue to evolve, but it is still not very popular in Canadian or
European corporations. That’s why it is important—while observing a technological watch—not
to rule-out niche technologies; they may become the C language of tomorrow.

I recommend you register for the InfoQ Weekly newsletter, which is a newsletter that covers
a variety of subjects related to software development. InfoQ also provides interviews, videos,
books, and more. They organize a biyearly conference called QCon. I have followed the InfoQ
website since 2006, and I have never run out of interesting news.

Keep up with Android

In the previous sections, I’ve shared some tips to help you stay informed about our entire
industry—now let’s go into more detail and focus on Android specifically.

There are a lot of blogs, forums, news sites, and such about Android. If you read everything, you
will be left with no time to develop great apps! Personally, I like to focus my search, so I am not
overwhelmed by information.

One great way to achieve this is by using Google Alerts to target only one keyword for each alert.
I recommend you have as many alerts as you have trends that you want to follow. It is pretty
straightforward to create a new alert—visit Google Alerts: https://www.google.com/alerts. If you
enter Android in the search field and then click the search button, you are presented with a
preview of the most pertinent news—with millions of potential matches—that you will receive
on a daily basis in your inbox. If you click on the More Options button, you can refine your
alert by source, language, region, and result type. I recommend you leave all fields with their
default values, except maybe the language field. That will be set by default according to your
local settings (for example, mine are set automatically to French). You could select English or
All languages, or you could create multiple alerts—one for each spoken language you want to
monitor. It’s also important to keep the results type to Only best results. That will provide you
with the more pertinent news and minimize the irrelevant news. When you are satisfied with the
42 CONTENTS

results, enter your email address and click the Create Alert button. You will then start to receive
news from various sources—blogs, newsgroups, forums, news sites, and such—directly to your
inbox without any further effort on your part.

Google Alerts will provide general news about Android. If you want to observe Android trends
with a developer’s eye—to discover what technology to learn next, for example—Google Alerts is
not enough. My number one source of information about Android development is the Android
Weekly newsletter. I encourage you to subscribe to this free newsletter to receive fresh news
about Android development on a weekly basis. It’s one of the major Android newsletters. They
recently crossed the 15,000 subscribers mark—and most of these are Android developers.

Other good newsletters are Android Central, Android Authority, and Phandroid. However, most
of the time you will find the same news in these newsletters that you find in your Google Alerts—
unlike Android Weekly. You could register for these newsletters and—if one doesn’t provide you
with enough interesting information—you can always unregister later.

One last source of information, albeit a little more noisy, is LinkedIn Groups. There are many
groups related to mobile and Android, so I will not list them here. You can do a search on
LinkedIn’s website. Focus on those with the most members because you’re more likely to find
interesting discussions. Don’t forget to activate the Daily Digest option for each group so you
receive the top news directly in your inbox.

Technological watch vigilance

I have one last piece of advice before moving on—don’t be tied to one source of information.

In this chapter, I’ve presented my tools of choice to help you stay informed about the market and
its evolution. I like to use anything that can bring me information directly to my inbox, where I can
use filters to order everything, and then read the news when I have the time. This may not be your
cup of tea, and that’s okay. You can probably find the same information on various discussion
forums, or even on some Facebook pages. Personally, I find that these other web mediums
present too high a risk of distraction—oh, look at the cute little kitty!!!—and could ultimately
move me away from my goal: staying informed without spending too much time scouring for the
pertinent information through a pile of insignificant distractions.

There is one last source of information—routed through developer’s brains—that I would like to
tap into using automated tools, but I can’t. That is the StackOverflow website. If we could access
and aggregate the questions asked by millions of developers, order them, and data mine them,
it would be a great source of insight on the market—perhaps even the greatest of all! I’m pretty
sure we would get great insights from that pile of questions and answers. It’s on my wish list for
Santa Claus.

Resources

• TIOBE Index: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

• Indeed: http://www.indeed.com
SELECTING THE BEST TOOL FOR THE JOB 43

• InfoQ: http://www.infoq.com
• Google Alerts: https://www.google.com/alerts
• Android Weekly newsletter: http://androidweekly.net/
• Android Central newsletter: http://www.androidcentral.com/newsletter
• Android Authority newsletter: http://www.androidauthority.com/newsletter
• Phandroid newsletter: http://phandroid.com/dev-newsletter/
• LinkedIn Groups: http://www.linkedin.com/directory/groups
• StackOverflow: http://stackoverflow.com/

Exercise

Why is the C language the #1 language on the TIOBE Index?

Hint: check how the index is composed.

The C programming language was invented in the seventies by Dennis Ritchie, so how
can it still be relevant today? Join the discussion on our Google Group, and share your
theory on the following discussion thread : https://groups.google.com/forum/#!topic/
agile-android-software-development/-WxI4PMP-Pg

Selecting the best tool for the job

As an Open Source software advocate, I prefer working with free software—as in freedom, and
as in free beer—because I can lay eyes on the source code, and assess the source code quality,
architecture, and even the seriousness of the developpers involved in the project just by doing
a checkout of the project public repository. In comparison, you can’t look at the source code of
most of the commercial software before deciding if you will buy it or not. There is some exception
to that rule in the form of software developped using an hybrid model where a community edition
is available as also a commercialy supported—and more feature complete—version; the IntelliJ
IDE from JetBrains is a good example of that kind of product. Google engineers have tweeked
IntelliJ Community Edition—the Open Source version—to produce Android Studio.

The Open Source community is composed of hundred of thousands—or even more—software

projects. A couple of years ago, Sourceforge.net was the de-facto home for Open Source projects.
Now, with the rising popularity of distributed version control systems (DVCS)—such as Git—
GitHub has replaced SourceForce as the developers hosting provider of choice for Open Source
projects. Open Source is now used by many organizations and is, in many case, critical for their
daily operations. I will not dissert here why and when the perception of the corporate world
about Open Source switched—from a perception that Open Source as hobby—to considering
Open Source as a serious alternative to commercial software. Noneless, that shift in perception
affect how we write software today, and it affects the Android developer community too: it is a
fertile ground of high quality Open Source frameworks, and libraries. Luckily, that make it easy
on our shoestring budget—if you happen to be a lone developer or part of a startup—but that
brings another challenge, which is the topic of this chapter: How do you select the right tool
44 CONTENTS

among equivalent candidates?

I have putted an emphasis on right in the previous sentance for a reason: a tool could be right for
you, but not for another developer. In this book, I’ve positionned many tools, which choice you
could agree with or not. It all depends on your own software development flow and how these
tools fit in. In the following sections, as an example, I will show you how I have selected the test
driven development (TDD) framework we will use thoughout this book.

At the end of this chapter, you will be able to use those techniques to evaluate yourself Open
Source software in term of quality, maturity, and so forth. You will be also able to reevaluate my
choice of a TDD framework if it doesn’t suits you. Just by changing the required feature sets and
the ponderation of those features the final result of the evaluation will not be the same.

Rest on the shoulders of a giant

Some choice of tools for this book were obvious and didn’t required much analysis on my part
before selecting them for our Agile Android developer toolbox. A good example is Jenkins as our
continuous integration (CI) server. While Jenkins won’t win any UI design contest, it has a huge
and active community. Consequently, there are more plugins available for Jenkins—to extend its
functionnalities—than all the other CI servers combined. For that kind of obvious choice—when
not just going with the mass—I rely on popular annual reports to justify my gut feelings. In the
Java world, there is two yearly reports I trust :

• The Eclipse Community Report : http://www.eclipse.org/org/foundation/reports/annual_

report.php
• The Java Tools and Technologies Landscape by Zeroturnaround (makers of JRebel) : http:
//zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/

There are also reports from the research firms available—such as the Gartner Magic Quadrant—
but they focus more on corporate tools and not solely on Open Source—these reports also hap-
pen to cost lots of money. Instead of buying one of those reports, I suggest you invest instead
on cloud hosting, and a fast laptop—with lots of memory, and a large SSD. Most of the time, you
should go with the mass and trust the Open Source project that leads the market—like Git for the
DVCS. Not that the other tools are not good but because—when you need help—the probability
to get answers from the Internet are better. You will end up spending less time searching for
answers, and more writing code. But, when there is no obvious market leader, you have to do
an assessment among equivalent tools to find out the best tool for the job.

Open Source software assessment

In this section, I teach how to use a custom software assessment methodology to compare equiva-
lent tools, and then make an informed decision. There is a couple of existing assessment method-
ologies, but most of them are now unsupported by their creators. For example, I was involved
in the translation—English to French—of the Business Readiness Rating (BRR) methodology in
2005. The BRR initiative was ambitious in that it was—for the first time—proposing a formal,
SELECTING THE BEST TOOL FOR THE JOB 45

and repeatable method to assess Open Source software using a set of known metrics. It was a
great improvment over some more hands-on evaluation methods such as Navica’s Open Source
Maturity Model.7 But the BRR failed to get widely adopted and the OpenBRR website is now in
a coming soon state for a long time. You can still find the RFC and the template spreadsheets
used to compute the readiness rating, but not from the BRR website. Methodologies like BRR
are great in case of medium to large corporations when you have to give justifications to upper
management about your technological choices. For example, bureaucratic gymnastics are some-
times required when you want to set—or replace existing—corporate standard even in the case
of a better, cheaper, and Open Source alternative is available. If you are interested to know more
about the various Open Source software assessment, there is an article on Wikipedia about it.8

Some other people have pickup the BRR templates, and revisited them—the templates are avail-
able under an Open Source license after all. One mature initiative is the templates offered by
Smals—a Belgian healthcare company—as Modèle de sélection OSS (French for Open Source Soft-
ware Selection Model). You can download the templates, and the instructions freely from their
website: https://www.smals.be/fr/content/mod%C3%A8le-de-s%C3%A9lection-oss. The down-
load links are at the bottom of the webpage—even if the content is in French, the templates are
in English. As you will see if you consult the templates, there is a lot of information to fill in before
we can get any rating computed. That’s a great amount of work and research if you’re alone, and
only want to make an informed decision about a new tool.

This is why I will present you in the next section with a custom assessment methodology which
is less verbose—to the point—and more suitable for small teams.

Defining our unit testing environment

Metrics

How can we evaluate, and select unit testing tools for our Agile Android development toolbox?
As we have seen before, the BRR–and the like–proposes formal processes to evaluate, compare,
and select Open Source solutions by comparing the score of similar software. But, they are a bit
overkill for small teams and one time evaluation. This is why I present you my own no-time-to-
waste assessment methodology that focus only on selection creterion we really need to assess
software development tools.

First, to help determine our feature requirements list, we will use Wikipedia’s article List of unit
testing frameworks. Many langugages and plateforms are covered by that article but there is no
specific section about Android. Fair enough, we will look at the C++ section to see if we can pick
some features from there by observing the column names:

• xUnit: Indicates whether a framework should be considered of xUnit type.

• Fixtures: Indicates whether a framework supports test-local fixtures. Test-local fixtures
ensure a specified environment for a single test.

7
http://en.wikipedia.org/wiki/OpenSource_Maturity_Model
8
http://en.wikipedia.org/wiki/Open-source_software_assessment_methodologies
46 CONTENTS

• Group fixtures: Indicates whether a framework supports group fixtures. Group fixtures
ensure a specified environment for a whole group of Tests
• Generators: Indicates whether a framework supports data generators. Data generators
generate input data for a test and the test is run for each input data that the generator
produces.
• Mocks: Indicates whether a framwork supports simulated objects mimicing the behavior
of real objects in controlled ways.
• Exceptions: Indicates whether a framework allow tests to expect exceptions as part of
the test result.

• Grouping: Indicates whether a frameword supports grouping tests into a test suite.

Those criterias can be used to evaluate any unit testing frameworks because they are generic
and not tied to a specific programming language nor plateform. Those are also good example
of discrete criterias–that is: they can be answered by “yes” or “no”–which is usefull to quickly
rule-out any candidate that doesn’t match an must have feature.

Then comes the more empiric criterias–those can’t be answered by “yes” or “no”. Those creterias
need to be converted to measurable metrics. To do so, we will define a scale–with values going
from 0 to 5–that we will use as comparison factors. For example, if you define that an must have
criteria to your unit testing framework of choice is to support Android, you could have this kind
of scale:

• 0: Doesn’t support Android

• 2: Support Android
• 4: Support Android and mobile Web
• 5: Support Android, mobile Web, and iOS

Obviously, you will want to rule out any candidate that will score a 0 on the supported platforms
scale. Other factors could be the following:

• Supported plateforms
• Scripting Language
• Test creation tools
• Supported API levels
• Community
• Real or emulated devices support

Feel free to add or remove some of that list as you see fit. As I mentionned before, this assessment
goal is to help you to find the right tool. After all, you will have to leave with it–not your boss or
project manager.
SELECTING THE BEST TOOL FOR THE JOB 47

Weighting factors

The score will then be applied with a pain factor ratio—how much will it hurt you in your job
if you don’t have access to the said feature. If we use the precedent example, the pain factor
ratio for the supported plateforms will have a ponderation of 1 on a scale of 0 to 1—or 0 for not
required or 1 for must have. So, a multi-platform unit testing framework will score a 5 using the
scale defined earlier.

Those weigthing factors are very subjective and–most of the time–couldn’t be re-used as-is for
another evaluation intended to a different developer or a different team. What is a must-have
for you might not be for someone else. For example, if your IDE of choice is Android Studio, you
might have a criteria named Android Studio integration for evaluating your unit testing frame-
work. You could then apply to this criteria a pain factor of 85% (or 0.85) because it is a must
have but not something you couldn’t live without (or a pain factor of 1). Which will not be true
for another team used to the command line interface (CLI) that will give a pain factor of 0 to the
same criteria. You get my point.

So, we are done with the theory. We will now see how to select a unit testing framework that fits
most of our need as an Agile Android developer.

Defining the requirements list

The first step before we can even select our tool of choice for unit testing we have to found as
many possible candidate as possible. Hopefuly, there is a couple of resources available to help
us with that task.

The first one you should consider is The Android Arsenal website (https://android-arsenal.com/)
which presents an up-to-date inventory of tools and libraries for Android software development.
Tools are organized in categories and can be sorted using basic criterias such as registration
date, last update, and rating)—which are not very helpfull with our assesment. You should use
The Android Arsenal search fonctionnality to get a quick list of potential candidates, and nothing
more. Unfortunatly, at this moment, there is no way to have access to a list of tags, which is what
could be interesting for us. So, using the search tool, enter testing as search term and you will
be presented with a list of potential candidates.
Keep in mind that you will have to revisit each candidate on that list to dig more details from the
source code repository or the project’s homepage. The main reason for that is how The Android
Arsenal organize information using tags. For example, some testing frameworks will show up
when you use TDD search term but not when using testing keyword—even though they will fit in
both categories.

Your second source of potential candidates should be GitHub—the defacto source code hosting
service—for Android projects.
48 CONTENTS

Defining pain factors

Finding potential candidates

Quick brooming using the requirements list

Computing scores and evaluation results

The Agile Android Developer Philosophy

TODO
 This book was distributed courtesy of:

For your own Unlimited Reading and FREE eBooks today, visit:
http://www.Free-eBooks.net

Share this eBook with anyone and everyone automatically by selecting any of the
options below:

To show your appreciation to the author and help others have

wonderful reading experiences and find helpful information too,
we'd be very grateful if you'd kindly
post your comments for this book here.

COPYRIGHT INFORMATION

Free-eBooks.net respects the intellectual property of others. When a book's copyright owner submits their work to Free-eBooks.net, they are granting us permission to distribute such material. Unless
otherwise stated in this book, this permission is not passed onto others. As such, redistributing this book without the copyright owner's permission can constitute copyright infringement. If you
believe that your work has been used in a manner that constitutes copyright infringement, please follow our Notice and Procedure for Making Claims of Copyright Infringement as seen in our Terms
of Service here:

http://www.free-ebooks.net/tos.html
3 AUDIOBOOK COLLECTIONS

6 BOOK COLLECTIONS