This document discusses patterns for scaling mobile teams using Android examples. It covers organizing teams by product vs technology, adopting patterns for consistent development practices, testing strategies like unit testing, behavior testing and contract testing, and selecting technologies like native vs hybrid development. The goal is to build predictability, speed up feedback loops, and allow teams to continuously deliver features at scale.

1. Patterns to scale mobile teams
Using examples for Android
Priyank Gupta
Sahaj Software Solutions Pvt. Ltd.

2. Mobile is eating the world

3. Evolution in last 5 years
Mobile Inclusive Mobile First Mobile Only

4. Building it for 3.2 billion people
7.1 Billion - World population
7.9 Billion mobile devices
3.2 Billion Internet Users
State of connectivity 2015 - Report
Mobile users are the internet users

5. Worldwide market-share
Smartphone market share - Report
Android
iOS
Others
83%
14%
03%

6. Everything in ‘context’
Discovery
DeliveryMedia
Payments
Aggregation
Discovering content, deals, products,
places and information happens
based on location, context and
conversations..
Payments, wallets, money transfers
and currency conversions happens
via mobile apps instantaneously.
News doesn’t come from media
houses. News is crowd sourced,
crowd curated and pushed real-time
to consumers on mobile.
Delivery is done across diverse
products and services; ordered,
scheduled and tracked via mobile
real-time.
Services are aggregated and made
available on mobile across all domains.
Delivery, taxis, food, handy-work etc.

7. Why mobile is different?

8. Challenges
Multiple
platforms and
form types
No control on
environment /
device
Work across
version and
device types
Design with
usability at
center. Stay
ahead of
competing
feature set
Forced SDK
update and
different
runtimes
Dalvik, ART,
Arm6, Arm7

9. Survival for fittest
Ideas
Tons of ideas see
daylight in an healthy
ecosystem
Saturation
Redundant businesses
cause saturation to occur
Consolidation
Consolidation in form of acquisition,
mergers and natural death.
Healthy co-existence
Winning teams are lean,
agile, ahead of competition
and know how to scale.

10. What affects scalability

11. Things that matter
Hiring & People
Team organization
Technology selection
Development practices
Scalable design
Testing & Safety nets
Release cycle & practices

12. Technology selection

13. In business of delivering experience
HTML5
Native
Custom
Bridges
Cordova
HTML5+
Service workers
React
Native
Xamarin
Selecting mobile implementation strategy
Experience + Reach
Cost
Laser
Cover your bases
Long term strategy should focus on building a native experience. The journey can
be gradual or with a jump start.
No adoption
No magic bullets

14. Organizing teams for scale

15. Technology teams vs..
Release 1 - Mix of feature X & Y
Android
iOS
Services
Siloed by
technology
/platform
If feature parity is
important then
lowest
denominator goes
into release
Missed opportunity
to optimize services
based on common
domain across
platform
Easier to draw
boundaries.
Initial velocity
gain due to
technical
know how.

16. .. Product team
Release 1 - Feature X
Release 1 - Feature Y
Services iOS Android
Initial
velocity
impact
Shared
understanding
of product as a
whole
Feature
parity
maintained in
releases
Can get away
with a leaner
team.
Problems
solved once.
Service design
can have
considerations
for clients
baked in right
from start

17. Handovers & feedback loops
Development
Design
Testing
Story started
Story done
Quicker feedback loops keeps the cost of change low
and validates the shared understanding constantly.

18. Services are part of product
Services
App
Own
services as
first class
deliverable
Use patterns
to decouple
legacy
services
Leverage REST
Level-3
characteristics to
make service
adaptive
Use patterns to
optimize services
for target
consumer
platform

19. Scaleable dev practices

20. Predictability & Consistency
Where would you find the code to fetch details from database?
Can you predict how someone on team would fetch images in background?
Will everyone know how to find the service call you wrote?
Can everyone on team predict what’s going to be covered in an espresso test?
Do you know where to find the styling for a specific UI element?
Using conventions you can build predictability on team to simplify mental models
needed to understand the codebase

21. Define the simple machines
Screw Wheel & Axle Pulley Lever
A simple machine can hammer in the basic principle and allow far
more complex machines to be developed with coherence.

22. Adopting patterns
Persistence /
db
Web ServicesUI / Styles Debugging
Invest time in first of everything. Build a team-wide definition and
reuse the pattern to promote consistency and predictability.
Background
tasks / Services
Device
hardware

23. Web service patterns
for consistent service calls across features.Retrofit + Singletons + Observers
Callback implementation
for Retrofit API (Singleton)
Retrofit service
interface
Observers
Activities,
fragments or
services
Data retrieved from
service (possibly cached)

24. External integrations patterns
BFF approach | Adaptive API
Adaptive API
Backend for
frontend
Downstream systems
Adaptive proxy APIs
Consumer centric
abstractions - BFFs
for optimal experience of services on devicesAdaptive APIs BFFsor

25. for consistent execution of short async tasksAsync task wrapper + Observers Thread (Pools)or
Asynchronous tasks patterns
Obtain instance
Set data
Fire task
Check references
Call observers
Die or loop
Main thread
Spawned/Pooled thread

26. Scaling commits with patterns
Feature one
Feature two
Master
Feature toggles explained
vs
Requires complex CI setup to constantly identify and
merge branches and test state at any point of time.
Requires building a feature toggle functionality with
dynamic toggles and tests to validate all feasible path.
Master
Feature one
toggled off
Feature two
toggled off
Feature two
toggled on
Feature one
toggled on

27. Debugging and logging patterns
Force upgrade Debug console Thread local
logging
Crashlytics
Build consistent set of practices to debug issues using Debug console Crashlytics Thread logging

28. Building reliable safety nets

29. TDD - Achieving 80-85% coverage
1
2
3
4
5
6
With domain
logic extraction
Dependency
injection with
constructors
Mock objects
using mockito
Powermock +
Mockito for
static classes **
Countdown
latches &
listeners for
threads
Presenter
pattern to
extract view
logic
Building the most comprehensive set of tests at unit level

30. Behavior tests with page object pattern
pattern comes in handy to modularize behavior tests and mimic flow relationshipsPage Object
Home screen
Product listing
Notifications
Orders
Execution
context

31. Asserting app behavior
Service
Stubs
Real
Service
APIs
can be used to address the coverage gap left by unit tests in AndroidEspresso
WireMock Mountebank Stubby

32. Making behavior tests effective
Turn on
‘don't keep
activities in
background’
Among all
others, run the
smallest
supported
emulator with
software
keyboard
Immediate
app
distribution
to alpha.
Hallway
testing
Multiple
emulators in
cloud or via
Docker images
across CI agents
Keep behavior tests lean, quick and focused on happy path

33. Testing the service contract
Actual
Service/APIs
Contract
Tests
Service
Stubs
Contract tests run typically few times a day. A stub replaces remote service for
behavior tests to keep tests responsive, stable and predictable.
Every commit
Periodically

34. Testing cross app flows
is a great starting place to orchestrate tests across apps
Uber engineering blog
Octopus by Uber
Consumer app
Warehouse app
Consumer on iOS
Orchestrator

35. Thanks for pulling through!
priyaaank