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
– 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)
– for particular entry, present keyboard specific for the data to be entered,
enhance user-experience, use data-type driven entry fields, use autocomplete
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
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
– 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)
(download from Android style website)
keep it brief, keep it simple, use human terminoloy, be friendly, most important message first,
describe only necessary things, do not repeat yourself.
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:
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?
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
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)
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+)
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
– 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
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
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.
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
“com.android.vending.licensing.ILicensingService” 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.
Market Billing service (on the client side and on the server side). See the examples in SDK.
– 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.
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
signals cover entire app life span
– users interested? engaged?
seasonality, user comments, fit and polish, unique Android features, (we are not looking into direct ports from other platforms).
ICS specific technologies
– 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.
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:
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
getMaxNumDetectedFaces() > 0 — means the device supports face detection
stopFaceDetection() to stop pulling the data.
(ideas: tracking the face while the user is using an app)
13:15 – going for lunch
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.