from ADL2012, Auckland

Wednesday, Feb 8, 2012


Definite Android Design
morning tea follows

Market services for Developers

ICS: communication, Connectivity & Camera

after lunch – practical sessions and codelab

Starting at 9:20. Running slightly late.

Conversations on Twitter: #adl2012

What’s the best way to contact the developers team:

* Stackoverflow, android section – the best resource.
* Google Plus Android developers
* and Google Plus hangouts (on weekly basis)


Talks and presentations

Definite Android Design

Home screen, identity. Application Icon? Should you have Widget? Important choices to be made about the identity of your app. In the market listing one should emphesize that there is a widget, advertise it.

Make widgets resizable, instead of different widgets for different sizes.

Launcher Icons: 48×48 dp
In Market listing: 512×512 px

distinct silhouette, 3-dims, front facing, slight perspective, slight depth
App icon is visible in different places (see Recently Used apps)

Persistent UI bars
– status bar
– navigation bar (replacing the physical buttons)
– system bar (tablets, combines both, status bar and nav bar)

Controlling the System Bar icons. Two different modes: dimms the bar, or removes it (hidden navigation).
View.setSystemUiVilibility LOW_PROFILE and HIDE_NAVIGATION


Common App UI

1. Main action bar (Top of the GMail app, for example)
2. View control
3. Content area
4. Split action bar (bottom of the GMail app)

scrollable and swipable side-wise
UI improvements (extending the fixed tabs)

– section divider (lower contrast, non-interactive element)
– organise sections into groups. Use them.
– line items: single, multiple lines, custom items with icons, checkboxes, buttons, etc

Generic grids
– grids scrolling
veritcally scrollable lists: Z-pattern, from left-to-right first, then top-to-bottom
horizontally scrollable grids: top-down, left-to-right.
– Grid lists with labels: semi-transparent panels for labels, control contrast, ensure legibility

– Scroll indicator appears only when needed
– Index scrolling (e.g. alphabetically organised lists)

Text fields
– single-line/multi-line
– for particular entry, present keyboard specific for the data to be entered,
enhance user-experience, use data-type driven entry fields, use autocomplete

Spinners (drop-downs)
Use spinners where appropriate, do not force user to type everything in

3D-buttons vs. borderless buttons
Use the borderless buttons where it makes it obvious for interactivity

Indeterminate Activity
1. activity bar (blue bar, like in browser)
2. activity circle spinning
Let user know when there are things going on in the background.

Progress bar – same as above, used when you know the end-point of an activity


New UI components in ICS

New sliders and on/off switches added in ICS
Use on/off switch instead of check-boxes

Checkboxes – use them for multiple selections. Use them when terminology of on/off does not apply

Radio buttons – single selection from a group of choices

Picker – picking element from a list. Kinetic scrolling. Tap on the entry field,
and the user might be able to start typing. See Date-and-Time pickers.

Prompting the user

Dialog boxes: optional title, content area, action buttons

Alerts (title bars are optional: is it truly required to have the title?)

Popups: lightweight, single-action choices

Toasts: feedback to the user after some action has completed. Do not use them a lot.
Try to not show Toasts from background process, if you have to, provide sufficient context to the user.


Style and themes

Themes, introduced in 3.0, ‘pure google experience’, called Holo. Guaranteed on Android 4.0
Normally do not force a particular Theme on user, but you could.

Touch feedback, important to user to smooth the interaction (glow at the end of lists, transparency when removing item from Recently Used list)
Devices and displays

– be flexible layouts, optimise layouts
– 1 dp = 1 px at 160 dpi, px = dp * (dpi / 160)


– Android 3.2 or better: smallest width 600dp (sw600dp), before Android 3.2, large or xlarge layouts
– 48dp = ~9mm, touchscreen objects should be 7-10mm

– lists, use 4dp gaps for buttons, and 8dp for icons, bottom and up
– sides – leave 16dp on each of the side for accidental touching through holding the phone

Best practices:
– use wrap_content, fill_parent, dp (‘match_parent’ same as ‘fill_parent’)
– do not use hard-coded pixel values
– do not use AbsoluteLayout
– use alternative bitmap drawables for different screen densities: ldpi (120dp), mdpi (160dp), hdpi (240dp), xddpi(320dp), nodpi, tvdpi(213dp). Rationale: reduce the stress on the computing resources on a smaller devices. Script the build process so you only have high-res resources and automatically generate lower-res resources if applicable.
New font: called Roboto
Text sizes: micro 12sp, small 14sp, medium 16sp, large 18sp (sp scales with the user settings)
Colour schemes
(download from Android style website)
Writing style
keep it brief, keep it simple, use human terminoloy, be friendly, most important message first,
describe only necessary things, do not repeat yourself.


Action Bar

1. App icon
2. View control (tabs or drop-down), category/account (in Gmail it is the account, in Calendar it is the day/week/month view)
3. Action buttons (replaces OptionMenus)
4. Action overflow

On the phone, in Vertical view, the Action Bar is split into top and bottom parts of the screen.
In Landscape mode and on tablets the Action Bar is kept together, as a single unit.

ViewControl, Tabs, can be used on their own too

Action Bar items:
Frequently Used
more than 70% of times, constantly repeated?, would extra step be burdensome?
especially cool or a selling point! Needs to be effortless!
First class action in similar apps? If in Action overflow would users be surprised?

Action overflow
Overflow is not a menu. Menu shows up in the navigation bar instead as an overflow.

Sharing Data, Share ActionProvider

Action bar icons
32x32dp, but effective space is 24×24 (plus spacing)
Style: flat, not too detailed, smooth curves, sharp edges, mono-colours
Contextual Action bar (CAB)
Long-press gesture – used for CAB

show the user what makes sense in a given context

Long-press – show the user contextual Action Bar (instead of Menu options)
E.g. selecting one photo shows particular contextual action bar, selecting
multiple photos changes what’s available

Contextual icons: 16x16dp but effective 12x12dp

Style: neutral, flat, simple, use colours,



Un-intrusive inform users of events, time-sensitive, involves other people, pertinent to the user
Do not use notifications: for info not related to the user, not time sensitive,
information already visible, recoverable errors, do not use it for spam, starting/stopping services,

Icon/photo, app icon; Title/Name, Message, Timestamp, Secondary icon

Make it personal, navigate to the right place, timestamps for time sensitive events, cleanup after yourself
If the notification was not read, after a while the notification should be cleaned automatically.

Do not use multiple notifications, instead try to collapse multiple ones into single notification

Provide a peak of what notification is about (in the bar)

Ongoing notification (e.g. for music player, controlling music player)

Make notifications optional

Icons: 24x24dp, effective 22x22dp

Style: flat, simple, single visual metaphor,
Colours: entirely white, system may darken them


UI Patterns


touch: trigger default functionality
long-press: select and show contextual action bar, multi-selection
swipe: navigate between views, scrolls overflowing content
drag: rearrange data in view, move data in container
(story on backporting drag-and-drop to Android 2.1)

double-tap: zooms into the content (similar to pinch-open)
pinch-open: zoom in
pinch-close: zoom out
General structure of the app

– top level views
– category views
– detail/edit views
Examples: some content placed in the top-level view, use analytics to determine what views users spent
most of their time in). Try to contextualise the experience.

Category view (app dependant)
swiping with flexible tabs, or fixed tabs

Spinner on list view to cut through a hierarchy and action on individual item

Consider lights out mode (to highlight the content).

Define and use the “hero moment” in your app. Examples of the albums 3d carousel view in music app, or the people card in people app.

Gmail – swiping goes through e-mails in a given label (folder)

Try to keep hierarchy level up to 3 or 4 levels. Do not make it too long.



Up vs. Back button behaviours

UP – Action Bar, Navigate screen hierarchies, Cannot exit app

Back – System Bar, Navigates screen history, can exit app

Developer can manipulate the “back step” to put some intermediate screen for user interaction.
Useful when going to a practicular screen from a widget.
Combining multiple views: Fragments
Strategies for combining multiple views, eg. on a tablets you can combine multiple fragments together.
On phones, show different fragments in their own acitivities.

Expand/collapse strategy (collapse one of the fragments)

Show/hide strategy (completely hide one of the fragments)


Backwards compatibility

Physical buttons used instead of navigation soft-keys. Overflow items show up in the “menu” button.
SDK includes ActionBarCompat (provides Action Bar for Android 1.6+)
Thin wrapper
API <=10, lib supported
API > 10, system implemantation

Fragments: re-usable UI components, can be used as non_UI data objects.
Organise layouts in sections, each section is a fragment.

ViewPager, PagerAdapter class for swiping, part of the SupportLibrary.
SupportLibrary – Fragments, Loaders, ViewPager/PagerAdapter
Eclipse: Android Tools/Add Compatibility Library


Pure Android experience

Do nots

– mimic UI from other platforms
– carry over platform-specific icons
– do not use tabs at the bottom, use tabs at the top
– use labeled back buttons
– use righ-point curret icon



– use action bars
– build intelligent context-aware apps
– pre-load data at appropriate times
– focus on the user experience (do’h!)
– provide offline support/data pre-load/working offline, sync when online


More info at:


Market Services for Developers

12:10 talk by @ryosukem

Rapid growth of the Market
700k Activations per Day

400k applications in total, also growing fast
11b app installs in total

Licensing services

Google can help and facilitate to validate the applications installed against the database of purchases.
What to do when the License check fails? Granting the user trial-period, trying to convert a pirate into a user?

License Verification Library

Client Attack:
disassemble Dalvik/native code,
alter the response from the library to ignore the server result and always return “licensed”.
Reassemble the application package. Sign the package with an alternate signature.

High-quality applications are modified for profit by different pirates.
advertisements hijacking
in-game goods collection and re-sell on auctions

How to make the app tamper-resistant?
– use obfuscator (e.g. ProGuard)
– Modify the LVL code, in different of your apps
– Make code more resistent:

change bindResult = mContext.bindService(new IntentILicensingService.class.getName()), to
“” with some transformation

Use hashing and CRC checks, use reflaction to call the API
calls instead of making the call directly. Use NDK. Use the code signed and
downloaded from the server.

When Pirates becoming Vampires (sucking on server bandwidth or resources)
Try using the server-side verification and connection tracking.


In-App billing

Market Billing service (on the client side and on the server side). See the examples in SDK.


Cloud storage

– copies application data to the server
– backup/restore capabilities
Provides devices independant way of storing the data for users. Introduced from Froyo but not used widely.

Cloud Messaging

C2DM service – Allows you to push some of the lightweight messages directly to the user devices.
200k msgs/per day for free.

Ranking in Android Market

based on many signals,
designed to provide end-users helpufl results
different categories
signals cover entire app life span
– users interested? engaged?
– updates?

seasonality, user comments, fit and polish, unique Android features, (we are not looking into direct ports from other platforms).


ICS specific technologies

Android Beam

– NFC based sharing technology, zero setup (on the user side), data exchange, social sharing
– based on NDEF message push standard
– 4cm or less
– uses: google wallet

NdefMessage, setup URL or MIME type in the first record.
Receiver end: notification of ACTION_NDEF_DISCOVERED intent

Context aware data sharing.

WiFi Direct

based on the WiFi Alliance standard,
provides Peer-to-Peer connectivity,
doesn’t need hotspots or Access Points

all the calls are asynchronous, allows peer discovery and connection, high-performance connection at a range

setup a BroadcastReceiver, responses are via callback interfaces:
– peerListener

State change: enable/disable
Connection Changed: connected/disconnected
Peers changed: new devices are in range, obtain peerList
Changes to self, i.e. ‘this’ device

The group has always a single GroupOwner


Android Camera API

added API for face detection: mouth, eyes, bounding box, etc
custom exposure metering APIs
focus API

getMaxNumDetectedFaces() > 0 — means the device supports face detection
FaceDetectionListener.onFaceDetection(Face[], Camera)
stopFaceDetection() to stop pulling the data.

(ideas: tracking the face while the user is using an app)


13:15 – going for lunch


Practical work

Eclipse session on Sharing, Action Bar and ViewPager. Lots of fun, wit and geekiness.

Fragments that require arguments should be instantiated through a static method newInstance,
that creates and attaches a Bundle to the new instance.

Architectural problems of where to keep “managing the fragments” logic. In the Activity?

New style of UI for mobile devices – re-thinking the principles.

NFC is off when the screen is off.


Leave a Reply

Your email address will not be published. Required fields are marked *