Charles Engelke's Blog

My second Google IO Bootcamp session, presented by Antony Sargent.

I hope I can find his slides on-line. They are based on this HTML5 presentation that’s been floating around. At least, it looks like it.

Chrome Extensions are written using HTML, CSS, and JavaScript. HTML5 is giving you many more capabilities already, even without writing new extensions. Native code is coming; it runs in sandbox of the browser. But that’s not what we’re talking about now.

There’s a gallery of extensions at chrome.google.com/extensions. In general, you can post any kind of extension there. No review process unless your code uses certain restricted APIs (in which case you’ll have to sign something indemnifying Google).

Extensions are easy to install. Click on a link and download.

Writing extensions is “Like writing a website” (where all your users have a really fast, standards-compliant browser). But they add some simple APIs for things a regular web page can’t do.

• bookmarks
• history
• i18n
• processes
• tabs/windows

Start an extension with manifest.json file

{
   "name" : "Sample manifest file",
   "version" : "1.0",
   "permissions" : [...],
   "description" : "My first extension",
   "icons" : {
      "48" : "icon-48.png",
      "128" : "icon-128.png"
   }
}

Permissions is an array of permissions you need. For example, you can say you want to use cross-site Ajax requests.

You develop extensions right in Chrome itself. You need a text editor, nothing else special.

Enter the URL chrome://extensions/ (or use a menu choice to get to Extensions manager). Click on “Developer mode” to get buttons for development. Put your work in a single folder, and point to it here.

“Isolated Worlds”. Your content script for your extension can see the DOM, but not JavaScript locals in your own page.

Introducing the background page. Not displayed anywhere, but “rendered” by the browser in a hidden page. This is where you’re going to register listener functions, etc. There are APIs for this background page and your content page to communication with each other.

Much of the API is asynchronous.

Experimental APIs need to be enabled with command line options when launching Chrome.

We went very fast and covered very detailed items without enough time, but detailed documentation is all on-line. Seems easy for web developers. I’m not sure why I want to do this, though.

I’m attending the first IO Bootcamp at this year’s Google IO. It’s just starting, and my first session is Android 101, presented by Roman Nurik from the Android Development Team. These are my very rough notes.

This talk is about writing your app and then publishing it (hence the name).

Writing your App

• platform features
• surfacing your UI
• intents (“awesome” pay attention)
• speech, location, sensors
• native development

Publishing your App

• registering
• targeting
• buying and selling
• other distribution

Android is an open platform, and open source. So is the SDK.

Mostly Java and XML (C/C++ available for native development with NDK).  It’s not native Java bytecode. The bytecode is further compiled to “Dalvik”.

You can replace the core apps with your own.  See http://source.android.com. Almost all (the speaker thinks all) apps are using only public APIs.

More than 60,000 Android devices are shipping each day.

There are many different devices with different screen sizes, resolutions, and pixel densities. Grid of 9: small, normal, large screen by low, medium, high dots per inch.

As of May 17th (prior 14 days), almost nothing with small/low dpi, all the rest with normal screen size. About 2/3 medium pixel density, 1/3 with high density.

An app is collection of several components, defined in AndroidManifest.xml.

• screens, services, programs, types of things it listens to, types of content it provides
• Activities
• Services
• Content Providers
• Broadcast Receivers

Surfacing your UI

Launcher icons, status bar notification, widgets (very little code, mostly just a simple UI), quick search box (since 1.6), live folders and live wallpapers.

Concurrency

Users can multitask. Their apps get paused, not closed.

Background services are invisible apps with no GUI, but unobtrusive event notifications.

Intents

Pay attention! Intents “link” activities, services, and receivers.

Consist of

• an action (e.g., ACTION_VIEW)
• categories (e.g., CATEGORY_DEFAULT)
• a URI (e.g., content://contacts/people/123)
• “Extras” metadata
• Can also be hard coded class names (com.foo.FooActivity).

Example: press a button. Creates and intent, Uses a URI. You launch the activity. System looks for everything that can handle that intent. “Do you know how to edit a contact?” (Answer is in manifest.)

Intents are both intra- and inter-app.

Example apps: WHERE and OpenTable. WHERE finds a restaurant. You can click “reserve now” in WHERE, and it will fire an intent to OpenTable to make the reservation. Note that WHERE only shows this button if there’s some app installed that can handle the intent.

“Shortest introduction to the important parts of Android” that he’s ever done (less than 30 minutes).

Speech Input

• voice to text, processed by Google returned to device (and app).
• Fire an intent. Also every text input box has this automatically with the microphone icon.
• Understands English, Mandarin, and Japanese.

Location and Mapping
LocationManager service that determines location and bearing.  App can register for periodic updates by time and distance.

Google Maps library

Be sure to target the SDK with maps enabled.

Example: Places directory. Shows you distance and compass bearing. Then can view in Map View, which is very similar to the Google Maps applications.

Hardware and Sensors

• Camera
• Microphone
• Accelerometer
• Compass

Examples: Layar, Google Goggles

Native Development Kit (NDK)

• Use in conjunction with the SDK (I guess, not “instead of”)
• Performance critical code
• C/C++
• Also re-use existing code

developer.android.com is the place to get everything. Code, information, it’s all there.

Download the SDK,
Install Eclipse and ADT (Android Developer Tool) plug-in
Look through tutorials and samples
Run them on the emulator or a real device

Strong developer community.

Publishing your app

Register at market.android.com/publish/ to use the market. Has a nominal fee. ($25 when I checked just now.)

Takes only a few minutes from uploading your app until it’s available to all.

“Don’t update too often because then your end users will be pretty pissed.”

Targeting Options:

• Device capabilities (SDK level, minimum and maximum, Screen size
• Location
• Target countries
• Operators (if applicable, generally discourage this)
• Matches to user’s service provider

Only certain countries for sellers (9 including US, UK, Japan, some EU).  4 currencies only ($, pounds, euro, yen).

Only a dozen countries for buyers, who must have Google checkout account.  Prices in seller’s currency. Then confirmation, then estimated price in buyer’s currency, then choose payment method.

Can also distribute via USB, or downloading from any website.

Application is in a .apk file, can put it on any site. Users visit the URL of the .apk file, and Android will install it (if “Unknown sources” is checked in device settings).

Very high level overview. I want to understand the specific mechanics of intents a lot better.