Wednesday, July 21, 2010

Android Hands-On - literally!

Android Hands-On












by several Googlers:















Android phones were handed out like candy.

(a bit dated, but still good)

http://developer.android.com (for app development)

Agenda
- What make a great app?
- UI design tips
- Developing REST client apps
- Porting existing C codebases
- Lots of Q&A time at the end

What make a great app?
Roman Nurik
1) Speed, responsiveness
- Use AsyncTasks and Services
2) Quality/Polish
- Clean, flexible, beautiful UI
- Feature completeness
- Stability and error resilience
3) System UX integration
- Widgets, notifications, live folders, Quicx Search box, accounts, sync, etc
- Intuitive and correct navication, proper use of back, menu, search buttons
Bonus: Cross-app integration
- Exposing public intents, content providers, URL schemes, etc

User Interface Design Tips
1) Dos/Dontshttp://oscon2010.blogspot.com/2010/07/android-what-wherefores.html
- Don't simply port from other platforms
- Do create versions of all resources for high density screens
2) Design philosophy and considerations
- Choose clear vs. “simple”
- Content vs. chrome
- Enhanced by the cloud
- Design considerations: screen size, screen density, portrait/landscape, primary ui interaction method, keyboard
3) UI framework features you should definitely be using
-
- Resource qualifiers: ie res/layout, res/layout-port, res/layout-land, res/layout-large-port, res/layout-large-land
- patch drawables
4) New UI design patterns
- introduced in last google i/o talks
- dashboard, action bar, quick actions
5) Icons
- http://j.mp/androidfun for some icon ideas

Official Twitter app was developed by Google. Will be open sourced. No timeline on this.

The Google I/O conference app is still available in the app store. Source is available at: http://code.google.com/p/iosched

Developing REST client apps

1 min. intro to REST

Native REST Client vs. Mobile Web App
- Deep system integration (ie, contacts, sync UI)
- Can run in the backgroud, sync on a schedule
- Potential faster – binary formats
- Some things aren't yet possible with HTML/JS (eg, taking a photo)

Implementing REST
- do data operations in a service, not an activity

Thress design patterns to handle
1) Service API
2) ContentProvider API
3) ContentProvider API with SyncAdapter

Intermission: Android YouTube Commercials

Why SVG isn't supported (yet):
- rather expensive from a storage perspective
- not many websites use it currently
- it might be in foryo

Porting C codebases to Android

Native Code whys:
- Existing C/C++
- HPC
- OpenGL EL 2.0 (in Android)

NDK
- c library
- math libs
- minimal c++ (stl port)
- logging in android
- zlib
- jni graphics
- new in 2.2 (ndk debugging on retail devices)

Using JNI (Java Native Interface)
- public static native void …
- plain 'old JNI can be used

Case Study: Audio Processing and Mixing

Case Study: Driving Android Display from Native Code

Showed a demo of a C (and OpenGL) version of Tetris on a Nexsus One

OSCON shirts

Veracity: DVCS

I spoke to a guy from SourceGear today about Veracity. It seems like a tool to watch. They are looking at mapping DVCS concepts to databases, request trackers, and so on. He said they will have a library version as well. No stable API yet though. Also sounds like they have a working distributed request tracker right now. 

Sound promising.

http://sourcegear.com/veracity

Nexus One

r0ml

(insert notes here)

Android: The What & Wherefores


Dan Morrill (Google)
Android project manager

This talk is about Android as an open source project.

Agenda
First things first
Project overview
Tools and tallies

First things first
What we mean by open:
Quote from source.android.com “No central point of failure...”
“I disapprove of what you have to say, but I will defend to the death you right to say it/.” Evelyn Hall
Before Android there were gatekeepers on getting mobile apps on devices.
Google has a very liberal for getting apps on the Android Market (similar to getting a video on YouTube)
Omitted: security, fraud, illegal, copyright

Project overview

Overall Goal: Improve App User / Developer Expirence

ASOP – Android Open-Source Project
Not a distro; a single corpus of software
Apache License 2.0 (mostly)
Partially non-public development process
Open for any use … but to join the eco system you mst be compatible.

Why Apache Licence?
It's close to BSD. Patent clause.
Why not GPL: OEMs should be free to keep their changes
There are some GPL s/w, like Bluetooth and Webkit, in Android

Who a partially non-public development process
(two source repos – one internal to google and one on soruce.google.com)
- We're defining a platform as we go
It we do this in the open, people WILL shop early
We simple can't afford inconsistent API implementation
Contrast with HTML5, where platforms are already defined
- It's necessary to complete
We're not a software project, we are a consumer electron project.
Margins are small; competition is fierce; mindshare is king.
Splashy launches and campaigns are How It's done.
- Private development actually not ENTIRELEY true...
kerenal dev done (almost) entirely in the open
SDK compatibility Test Suite recent moved open-source
NDK is moving open

Balancing open source with platform integrity
Compatibility is a BIG issues

Tools and tallies
Uses git for SCM
Uses repo for cross-git-project automation (a big shell for loop)
Uses gerrit for our review-before-commit process (see review.source.android.com)
Also see code.google.com/p/gerrit

kernel.org is really good and globacl git hosting
OSUOSL.org is really good at hosting Java apps

See source.android.com/source/life-of-a-patch.html WOW

Demo of submitting a patch.

Note to self: try gerrit

AOSP on Devices
Up through Eclair, it was hard

Numbers
40 company, 4000 users
1000 contributions
80% acceptance rarre

Larry broke out the stamps when asked for his autograph

Chris meets Larry Wall, Pearl creator