Android 1.5 to 3.0: a compatibility journey

Android 1.5 to 3.0
a compatibility journey

Emanuele Di Saverio
Senior Technologist
frog

Monday, May 23, 2011

Who?
• Emanuele Di Saverio
– Senior Technologist for Android Platform @

– Open Source Committer


Objectives

• Code Compatibility
• Screen Compatibility
• User Interface Patterns
• a Real Life Example


DISCLAIMER!

bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla the following is result of my professional experience and will be
technical and advanced topics, I will give for granted a good level of familiarity with the
platform bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla


1.5 - Cupcake

• Virtual Keyboard: IME
• AppWidget
• 2 New Widget


1.6 - Donut

• Screen Fragmentation
• Resources Framework
• Search Integration for
App


2.0 - Eclair

• Support for HTML5
• Bluetooth Support
• Sync Services


2.1 - Eclair (again)

• Live Wallpapers
• Enrich WebKit
• lots of bug ﬁxes


2.2 - Froyo

• App on SD
• Cloud 2 Device
Messaging

• Device Manager
• Data backup


2.3 - Gingerbread

• Near Field
Communication

• Gyroscope,
Barometer, various
Sensors

• StrictMode
• SIP

2.3.4 - Gingerbread
(again)
• more NFC Api
• more BT Api
• lots of Bug ﬁxes
• ﬁx for ClientLogin
• Accessory DevKit


3.0/3.1 - Honeycomb


• Every release brings new classes, new
methods, changes and deprecations

• We Want New Features
• We Want to target ALL devices
• We Don’t Want to constantly rewrite!


Target
API
Level


Android does no
magic here

We compile against
only one JAR:
choose our feature
set!

On device we will
have di erent
classes


Code Fragmentation

• 3 Techniques
• Canary
• Switch by Code/Resource
• Reﬂection


Canary

• Canaries are use in cave digging as a
“probes” for venomous gases
• If they don’t come back, you can’t use
that cave
• We want a Code Canary!


• We can’t replace or modify Java
Classloader in a Dalvik VM :(

• classes are veriﬁed as soon as
somebody new them

• ..so classloaders load classes lazily!


If this code is executed on a VM where
ScaleGestureDetector class is not
available, we can “gracefully degrade”

class Canary {

android.view.ScaleGestureDetector delegatto;

static void tryNewClass() {
android.view.ScaleGestureDetector foo = new
android.view.ScaleGestureDetector(null, null);
}
/* use the delegatto */
}


...by catching the VerifyError!

(explain please...)

try {
Canary.tryNewClass();
initalizeNative(ctx);
} catch (VerifyError th) {
th.printStackTrace();
}


Switch by Code

• use info from android.os.Build
• can be used on the ﬂy
• or via Factory pattern if performance is
needed (i.e. operations on UI Thread)


ad-hoc
public class RomaSkiFragmentActivity extends
FragmentActivity {
private final boolean isHoneycomb =
android.os.Build.VERSION.SDK_INT > 10;

@Override
protected void onCreate(Bundle arg0) {
super.onCreate(arg0);
if (!isHoneycomb) {
requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);
}

/* cut */


factory
public static synchronized LocalDevice getInstance() {
if (instance == null) {
int vInt = LocalDevice.getVersionNumber();
log.i(LocalDevice.class, "Parsed version number is " + vInt);
if (vInt < SDK_NUM_2_0) {
instance = new it.gerdavax.easybluetooth.LocalDevice1Impl();
} else {
instance = new it.gerdavax.easybluetooth.LocalDevice2Impl();
}
}
log.i(LocalDevice.class, "Returning: " + instance);
return instance;
}

private static int getVersionNumber() {
return Integer.parseInt(Build.VERSION.SDK.trim());
}


Switch by Resource

• leverage the Resource framework
• the -v su x is for versions
• es. -v4 resource will be selected for Api
level 4 (Donut)


Reflection
• Java allows us to:
• instantiate classes starting from their
name in a String
• invoke methods, even private
• inspect fields, even private
• Some problems with final and static
though
• With big power comes big...risks

If you miss
something...
private static int R_id_message_handle = -1;
static {
try {
Class clazz = Class.forName("com.android.internal.R$id");
R_id_message_handle = clazz.getField("message").getInt(clazz);
} catch (Throwable e) {
// who cares
e.printStackTrace();
}
}

public static void setRightAlignToMessageField(Dialog d) {
if (R_id_message_handle != -1) {
TextView tv = (TextView) d.findViewById(R_id_message_handle);
if (tv != null) {
tv.setGravity(Gravity.RIGHT);


android-bluetooth library
void bindAndListen() {
try {
Method bindMethod = bluetoothSocketClass.getMethod
(METHOD_BIND, new Class[] { String.class });
bindMethod.invoke(bluetoothSocketObject, new Object[]
{ "devicename-tobeignored" });
Method listenMethod = bluetoothSocketClass.getMethod
(METHOD_LISTEN, new Class[] { int.class });
listenMethod.invoke(bluetoothSocketObject, new Object[]
{ this.port });

Method getPortMethod = bluetoothSocketClass.getMethod
(METHOD_GET_PORT, new Class[] {});
Integer getPortMethodReturnValue = (Integer)
getPortMethod.invoke(bluetoothSocketObject,
new Object[] {});
this.port = getPortMethodReturnValue.intValue();
} catch (Throwable t) {
throw new RuntimeException(t);
}
}


disclaimer on Reﬂection

• It’s dangerous: depends on names, avoids
compiler checks, makes your code ugly
without remedy
• It allows to access @hide functionalities,
and break the public API
• Google hates it: for good reasons
• ...and makes you feel quite a hacker :)

Screen Fragmentation

• Google tackled aggressively the
fragmentation problem since 1.6

• The approach is based on “buckets”:
this is an -eventually correct- approach


small medium large xlarge

ldpi

mdpi

hdpi

xhdpi


small medium large xlarge

cheapo,
ldpi highly
portable
midrange,
mdpi
old school
iPhone one
hdpi like (or handed tablet
wannabe) tablet

xhdpi


• It’s not a universal solution!
• What happens if I have a extra-large
screen with low density???


• But it works for real-life devices
• Pragmatic Balance between
performances and image deﬁnition

• That’s why “eventually correct”


The Real Reason

• behind screen compat framework is...
• keeping the physical size the same (dpi =
dot per inch)

• has to do with human size factor
...with the size of the thumb actually :)


Real Estate

• so I just have to provide image for ldpi
mdpi and hdpi and I am set, right?
• NOPE
• you real estate will change!


• 800x480 (240 dpi)= 5/3
but DIPs are scaled
• 480x320 (160 dpi) = 3/2
homogeneously!
• 320x240 (120 dpi) = 4/3


Solutions

• Modal Controls:
SlidingDrawer, FlipViews, Alerts,
Notiﬁcations
• or simply cut the ancillary content!


Some solutions


Some solutions/2


...but don’t do Least Common
Denominator :(


Design Patterns

• Google doesn’t enforce constraints on
Application UI Design
• No Censorship, No Certiﬁcation, No
Approval!
• ....but strongly suggests them


Android UI Design
Patterns


Twitter App
GoogleIO 2010


Twitter App
Home Action Bar
GoogleIO 2010
Dashboard

Live Wallpaper Quick
Actions


Resources
• Home, QuickActions, ActionBar:
Cyril Motter’s GreenDroid
https://github.com/cyrilmottier/GreenDroid

• Dashboard:
Roman Nurik’s Layout
https://gist.github.com/882650

• Live Wallpapers:
SDK Samples: CubeLiveWallpaper
http://developer.android.com/resources/articles/live-wallpapers.html


Designing Android UIs
for Phones and Tablets

• Pattern consolidated and implemented in
platform

• Direct support for ActionBar and Home
• Extension to tablets

• IO Schedule App is again reference
implementation - Fragment Compat!!!


Home
Action Bar

Dashboard


So...

• Use the patterns - they are designed for
delivering YOUR content
• Use the libraries - they provide
consistent and compatible
implementations
• Concentrate on the “painting” instead
of the “frame”


A real life example:
RomaSki

• Application for keeping under control
webcams from Ski Resorts in the Rome area
(I needed it)

• Compatibility Fragment Library
• Versioned Scale


for Phone


Tablet


Fragments breakdown
1


Fragments breakdown 1I


Action Bar (was: “Title”)
• title Bar under HoneyComb is so powerful! Also has
tabs! is ACTION Bar

• ...forget it! Fragments Compability Library doesn’t
allow

• You have to inherit by compat FragmentActivity, not
the HoneyComb one, same classes but di erent
pkg!


non-HC Tablets


More Compatible than
Google :)
“early” 2.2
tablet


Versioned Scale
• Android uses GestureDetectors for decoupling
• ScaleGestureDetector is in 2.2 and up
• 2.0 already had multitouch though: class
copypasted from source

• 1.6 single ﬁnger gesture: custom
ScaleGestureDetector


private OnScaleGestureListener mListener;
private ScaleGestureDetector internalDelegate;
private Canary nativeDelegate;

public ScaleGestureDetector(Context ctx, OnScaleGestureListener listener)
{
mListener = listener;
int buildInt = android.os.Build.VERSION.SDK_INT;
if (buildInt == android.os.Build.VERSION_CODES.DONUT) {
internalDelegate = new ScaleGestureDetector16(ctx, this);
} else if (buildInt == android.os.Build.VERSION_CODES.ECLAIR) {
} else if (buildInt >= android.os.Build.VERSION_CODES.FROYO) {
try {
Canary.tryNewClass(ctx);
initalizeNative(ctx);
} catch (Throwable th) {
th.printStackTrace();
}
} else {
throw new RuntimeException("Version not supported! " + buildInt);
}}


GML Diagram
(galactic modeling language, Craig Larman)


Design API for change
• The public interfaces of the Versioned
ScaleGestureDetector are same as SDK one

• In the future will be easy to switch back to SDK!
since
• IceCream Sandwich is expected for Q4 2011, with new
(unspeciﬁed) compatibility features!


Resources
• GoogleIO Schedule App src:
http://code.google.com/p/iosched/

• RomaSki src: https://github.com/hazam/RomaSki
https://github.com/hazam/hAndy

• Dan Morrill: Android Open Source & Compatibility Tech Lead
twitter: @morrildl

• HC Design Patterns: https://docs.google.com/present/view?
id=ah8kttmgmwgb_21d9rnw7d6


What was left out
• AndroidManifest ﬁlters: <supports_screen> will suprise
you,

• 2.3 adds <compatible-screens>
• Fragments Compatibility Library :/
• Accessory DevKit support for 2.3.4 library :/
• Google TV! (10ft experience, but mostly D-Pad)


Android 1.5 to 3.0: a compatibility journey

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Android 1.5 to 3.0: a compatibility journey

Ähnlich wie Android 1.5 to 3.0: a compatibility journey (20)

Mehr von Emanuele Di Saverio

Mehr von Emanuele Di Saverio (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Android 1.5 to 3.0: a compatibility journey