In Part 4, we dug into accessing our Views from our Activity’s code, and registered an OnClickListener to handle the user’s interactions with our button. In the final part (a big one!) we’ll cover using J2SE libraries, debugging, and Android permissions.

So far we’ve gotten a lot done without too much “boilerplate” coding, and that’s great. But what we don’t have (yet) is an application that leaves its mark on the world. After all, what’s a Twitter application if people can’t benefit from your 140 characters of deep, meaningful insight into the state of the world (or what you ate for breakfast)?

On the shoulders of giants

One great thing about Android is that you have access to a full J2SE stack. That means you can take advantage of lots of libraries other suckers wonderfully generous people have already written. There are some caveats — code using some kinds of runtime code modification / introspection or deep JVM voodoo won’t work properly under Dalvik, for example — but many simpler libraries can be partially reused or just dropped in wholesale in JAR form. For twitter, there’s a great super-light library called JTwitter, released with an LGPL license. Go ahead and download that now — I’ll wait.

Done? Great! Put the .jar file into your project. I’ll create a /lib folder in our project and drag the file there, but you could also keep it in a totally separate folder on your computer to be linked as an external .jar in the project. Then go to Project -> Properties and add the .jar file (add as an external if you’re keeping the .jar outside your project’s folder). And that’s it — Android’s SDK tools take care of turning the compiled code in the .JAR file into proper Android Dalvik bytecode behind the scenes.

Now let’s wire that Twitter code in.

Add at the top of the Activity class:

1
2

public static final String TWITTER_USERNAME = "someusername";
public static final String TWITTER_PASSWORD = "somepassword"; //this is a very bad idea for a real product.

And add to our onclick handler right before popping up that Toast:

1
2

Twitter twitter = new Twitter(TWITTER_USERNAME, TWITTER_PASSWORD);
twitter.updateStatus(twitterStatus);

(Again, you’ll get easily-corrected missing-import errors – let Eclipse autofix that for you by importing winterwell.jtwitter.Twitter).

Advance warnings

Cool – before we run it, though, here’s 3 big caveats/notes:

1. For the purposes of this demo, I’m hardcoding a password into my file. Don’t do this. You probably want to use OAuth, or at least prompt the user for their password and store the encrypted version somewhere.
2. This is running in the same thread as your UI. This makes your app hang during the operation, and could lead to the user being prompted to end your app for being unresponsive (the dreaded “ANR” dialog). For a real app, you’d run the twitter-posting in a separate thread or as a background service, but that’s outside the scope of this tutorial.
3. This actually won’t work yet – trust me, I’m showing you how to debug things. Pretend to be surprised, though.

Go ahead and run the app in debug mode in the emulator (run -> debug -> Android Application). When it loads up, type in a message and click the Tweet! button.

Click 'Tweet!', and then...

You’ll find yourself rudely thrown back into Eclipse with this error message:

Oh no!

When things go wrong

Whoops! So your code isn’t doing what you expect — and worse yet, it blows up and crashes – hard. Once upon a time you’d have to know a series of arcane serial debugging commands to get anything resembling useful output from a mobile phone application. But thanks to the magic of DDMS (Dalvik Debug Monitoring Service), debugging your code is as minimally painful as anything I’ve used until now, and is *actually* less painful than a root canal! Let’s step through the Perspective you get thrown into in Eclipse.

The debug perspective

You’ll notice you can use the Debug panel to view the current state of our application as well as any variables. You can also see the Logcat error messages, which are generated by various application and system events (you can create your own using the android.util.Log library). Right now the only relevant log entry says “InetAddr Unknown host twitter.com,” which isn’t really helpful, but the execution has been paused to let us inspect the code behind that top-level error.

We can resume execution through the exception to the next line of code causing it. Usually this can get you a more detailed error message, and you can even inspect the code and variables at each step. Try it now (it’s the button that looks like “Play” on a tape deck — yes, I said tape deck; so I’m dating myself a bit), and notice the log messages scrolling at the bottom (you might have to click Resume a few times to get the right level of detail).

That's much more helpful.

You can use the Logcat view’s controls to filter error messages by severity or tag if there’s a lot to sort through — in this case, though, a little reading makes the culprit fairly obvious. We never told the app that it needs to ask for Internet access permissions!

Let’s go back and add that to AndroidManifest.xml. Again, you can use the XML wizardy-view to go to the Permissions section and add Uses Permissions -> android.permission.INTERNET, but if you’re old-school or just prefer a good text edit, add this line to the <manifest> node (usually as the last thing before </manifest>):

1

<uses-permission android:name="android.permission.INTERNET"></uses-permission>

Now when your users install this app, they’re warned once on installation that your application will access the Internet (but never again after that).

Go ahead and run one more time, filling in a message:

Now with 100% fewer Exceptions!

And check out our test Twitter account:

It worked!

Hooray!

This concludes the tutorial – but hopefully just starts your Android development experience. Go ahead, start making an app of your own!

To get started (or in case you got lost during this tutorial) you can download the source of the application we’ve built. You can also comment away if you have any questions or feedback on the tutorial.

If you just want to bang around with some more advanced development techniques without starting from scratch, here are some ways you could improve the current app:

• Use the AsyncTask class or a Service to make the updating happen in the background instead of locking the UI
• prompt the user for a username/password on first use, using a Preferences activity (easy way: Preferences from XML)
• Handle network failure gracefully.
• Display a progress bar / loading spinner while tweeting.
• Display updates from the users’ timeline in a ListView.
• use an AlarmService to update the Timeline in the background, displaying a notification to the user
• Cache tweets to an SQLite database or a flat file on the SD card
• Use the Location services and the reverse-geocoder classes to tweet your location

I’ll also be posting a more advanced tutorial on AppWidgets (homescreen widgets) soon – so subscribe to the Active Frequency blog in your RSS reader.

In Part 3, we defined our layout and prettied up our app’s main screen. Now let’s get to the business of real coding – the stuff that makes the app tick behind the scenes.

The Activity

So far, there’s only a few pre-created lines in our Activity, TwitterPoster.java:

1
2
3
4

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
}

Let’s break that down a bit. What this is saying is:
When our Activity is created,
Do generic Activity creation stuff that all Activities do
Then load up the view from res/layout/main.xml for display.

(The “savedInstanceState” isn’t applicable right now; if you’re curious, you can use it to save things like the content of text fields when your view is destroyed – for example, if the user takes a phone call or rotates the screen – and restore them later when the user returns to your activity).

In particular, when
setContentView(R.layout.main);
runs, it gives us access in code to the views inside that layout. In order to access those views, we need to reference them with the findViewById method:

1
2

final Button postTweet = (Button) findViewById(R.id.TwitterPosterPostButton);
final EditText tweetEditText = (EditText) findViewById(R.id.TwitterPosterMessageText);

As you type, Eclipse may give you errors for classses like Button or EditText that haven’t been imported yet. Just use the “quick fix” (Command-1 or Ctrl-1, or hover over the underlined error) to automatically add the missing import statements.

Now that we have our EditText and Button, let’s set an action when the user clicks on the button. For now, let’s just have it Toast us the status message (a Toast is an Android popup that displays a message for a few seconds, then disappears – similar to Growl on a Mac).

1
2
3
4
5
6
7
8

postTweet.setOnClickListener(new OnClickListener() {
    public void onClick(View v) {
        String twitterStatus = tweetEditText.getText().toString();
        Toast.makeText(TwitterPoster.this,
            "You tweeted " + twitterStatus, 
            Toast.LENGTH_LONG).show();
    }
});

Go ahead and try that out.

The OnClickListener and Toast in action

The message, of course, is a lie right now; we haven’t written the code that actually posts to Twitter, but this is a good start. In Part 5, we’ll write the Twitter code and learn how to debug Android code.

On to Part 5!

Code Recap

In case you’ve drifted a bit, here’s what you should have for TwitterPoster.java:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package com.activefrequency.android.demos.twitternator;
 
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;
 
public class TwitterPoster extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        final Button postTweet = (Button) findViewById(R.id.TwitterPosterPostButton);
        final EditText tweetEditText = (EditText) findViewById(R.id.TwitterPosterMessageText);
        postTweet.setOnClickListener(new OnClickListener() {
			public void onClick(View v) {
                            String twitterStatus = tweetEditText.getText().toString();
			    Toast.makeText(TwitterPoster.this, 
                                "You tweeted "+twitterStatus, 
                                Toast.LENGTH_LONG).show();
			}
		});
    }
}

In Part 2, we started an Android project, poked around it a little, and launched an emulator. Now we’ll move on to making the app look like what we want.

You’ll notice I titled this part “Describing Your Layout,” not “Coding Your Layout” or “Programming Your Views.” This is because Android gives you the tools to define most of the characteristics of your Activity’s visuals in descriptive, not procedural terms. This helps speed up development, thanks to the nice GUI-based tools for layout, and helps you keep your programming logic out of the places you define your application’s outward appearances (and vice versa). It’s important to know that you could create your entire app in Java, writing the descriptive code for your layout procedurally in your Activity instead, but it’s a much better idea to keep things separate wherever possible.

The resources

We’re going to build a basic Twitter client, so let’s make it look like one. Let’s switch back into Eclipse and poke around at what we have so far. You’ll recall that besides our Activity’s Java file, we have layout and strings files in the res/layout and res/values folders. Let’s go check them out.

Here’s the basic layout the wizard created for us in res/layout/main.xml:

The main layout xml

You’ll notice there’s also a Layout graphical view for that, which you can switch from/to using the tabs at the bottom of the pane:

The graphical view

It has its limitations, but it’s a good way to get a quick glance at your UI without even firing up an emulator. For example, we can change the pre-generated strings; open up the res/values/strings.xml file and change the “hello” string to something more useful:

Editing strings

You can use the helpful XML properties editor, or just edit the source XML once you’re more comfortable.
Save the file, then go back to the preview of the main.xml:

The preview updates right away.

Handy – we didn’t even have to switch back into the emulator to check our changes out.

Placing widgets

It’s still not much of a screen yet, though. Let’s add a text field and a button to the view. The easiest way to do that is just to drag them from the palette of Views on the left of the preview right onto your layout.

You can drag widgets right onto the layout pane.

If you click to the source view, you can see the XML it generated for those items right there. If you go back to Debug (Run-> Debug) and open the emulator, you’ll see our new text box and button there, just like in the preview pane.

Prettying things up

So far so good, but let’s pretty things up a little before we move on.

Things we’ll fix in this layout:
* Meaningful IDs for items
* Useful button text
* “hint” text for the text box (grey text that disappears when the user starts typing)
* Fixed width for the textbox so it isn’t expanding/contracting as we type
* Layout margins on things so the display can “breathe” a little — this is important both visually, and so fat-fingered users can select the on-screen item they mean to.

You can do this with the Properties editor, which shows below the Layout view by default, or by editing the source XML to look like this:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:orientation="vertical"
	android:layout_width="fill_parent"
	android:layout_height="fill_parent">
	<TextView
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:text="@string/hello" 
		android:layout_margin="12dip" />
	<EditText
		android:id="@+id/TwitterPosterMessageText"
		android:layout_margin="12dip"
		android:layout_height="wrap_content"
		android:layout_width="fill_parent"
		android:hint="What are you doing right now?"></EditText>
	<Button
		android:text="Tweet!"
		android:id="@+id/TwitterPosterPostButton"
		android:layout_margin="12dip"
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"></Button>
</LinearLayout>

Two things to notice here:
We specified our sizes in “dip” — density-independent pixels. This lets us indicate how much space something should use regardless of whether the user is on a high-resolution but small screen (like a shiny new high-end phone) or a low-res but big screen (like a TV). This is a good habit to get in to; it’ll simplify developing and testing applications that will work on present and future Android devices, regardless of resolution or size.

You’ll also notice that while we used the strings.xml file before with the default TextView, we’re using hard-coded messages for the EditText’s hint and the Button’s text. If we were making a proper internationalizable application, we’d use the Strings file to store those, but we’re going to keep things simple for the demo.

One more thing: we still have a pretty generic looking icon for our app if you look around the emulator’s program’s list:

Yawn.

That just won’t do for our cutting-edge Twitter client. I found a pretty good-looking set called Tweeties by Chris Wallace, which has some nice looking icons and is licensed under a CC Attribution-Noncommercial-Share Alike license:

Better!

Let’s use this or one of the other 48×48 .png files in the set. Rename it icon.png, and overwrite the res/drawable/icon.png file. You can drag the file straight from the Finder on OS X or the Windows Explorer into the appropriate folder in the project explorer panel in Eclipse.

Then let’s also use that icon as part of our Tweet button by setting it as the drawable_left of the button, either in the Properties editor or by manually editing the XML with this property:

android:drawableLeft="@drawable/icon"

Then go ahead and Debug the project again (Run->Debug) and pop back into the emulator:

The finished layout

Well, that’s shaping up. Go ahead and mess around with that a bit. Of course, for now it’s just a pretty face — we still have to tell our code what to actually do. We’ll get into that in Part 4.

On to Part 4!

In the first part of the tutorial, we got Eclipse, the Android SDK, and the ADT set up. In this part, we’ll get into our environment, create our first project and poke around in it, and test out the Android emulator.

Fire It Up

Go ahead and fire up Eclipse, and if it asks, choose a workspace (the default’s probably fine for now). Click on the “new android project” button or go to File -> New -> Android Project.

Click the New Android Project button.

The New Android Project screen.

By targeting a specific SDK version and specific vendor libraries, developers have the ability to write apps for a base platform without worrying about users on older hardware and software – they simply won’t see the app in the Android Market, and will see a helpful error if they try to install it manually.

Then click Finish (there’s also an option to create testing code, which we’ll skip for now) and we’ll explore the structure of the folders we have now.

The structure of the project in Eclipse

The AndroidManifest.xml describes your application to the rest of the Android system – what version of the OS it supports, what permissions it needs (for Internet access, GPS information, etc.), how other applications will use it (via Intents and ContentProviders, advanced ways for applications to call each other and share data), what the different screens (Activities) are in the app, and so on.

“src” contains our Java code, and the wizard pre-created an Activity for us. Think of Activities as the code representation of one screen of your application. Here’s the pre-created outline of an activity, which simply tells the system to render the view from a layout file called “main” (more on those in Part 3).

The initial code for our Activity

The “res” folder contains non-code resources; usually “drawable” will contain image files, “layout” will contain XML files you can use to build UI for your application in an easy-to-read way rather than writing it all out in Java code, and “values” will contain things like internationalized strings files, color definitions, or theme styling definitions to apply to your views.

Finally, the “gen” folder contains automatically created code you can think of as placeholders for items in your res folder, so you can easily point to a particular button, string, or image from your code. This speeds up references to that information and makes code completion easy, and it’s done automatically in the background while you work.

We actually already have a working Android app created here. Let’s test it out in the emulator.

Emulation Nation

There are already a half dozen phones in the wild running Android; dozens more will be coming out in the months to come. Each one has a variety of screen resolutions, software versions, and hardware controls. There’s no substitute for testing on actual devices, of course, but the Android SDK includes a good solution for modeling a variety of these in software.

The emulator in Android is based on the open-source qemu emulator, and you can create models called AVDs (Android Virtual Devices) with a variety of hardware and software capabilities. For this project, we’ll create a basic Android 1.6 device with an HVGA screen, a 32MB SD card, and the basic APIs.

Where the AVD Manager is hiding.

Open the AVD Manager and create the new device.

The AVD Creator.

Then go back to the Java view of our project. Let’s go back to TwitterPoster.java and debug it from Run -> Debug -> Android Project. It should auto-launch the emulator here.
Give it a minute for the first boot, then go ahead and your app should launch right up:

Aww, look, our first running Android process! You should go have that bronzed to commemorate the occasion.

Usually, you’ll keep the emulator open for your entire development session. One really great thing about debugging Android applications is that you can quickly edit your code, which builds in the background, then push it into a running instance of the emulator and see the results in seconds. You don’t have to wait to rebuild your code or launch new emulators; you get feedback nearly instantly.

So far, we’ve gotten our environment set up, explored the project layout, and launched the emulator. In our next post, we’ll pretty things up and explore the layout editing tools.

On to Part 3!

Thinking about testing the waters with Android development? Jump right in. We’ll build a neat little application that interacts with a web service.

Yup.

Which one? Twitter, of course.

This is a web form of a talk I gave with Henry Cipolla, CTO of Localytics, at BarCamp Boston 4 and in a longer form at FITC Mobile 2009, updated to cover the 1.6 (”Donut”) release of the Android SDK. The slideshow portion of that talk covers the basic concepts of the platform and slides are available online. I recommend checking it out.

Who is this for?

I assume you’re familiar with development in general, and you’ll find it easiest if you’ve done a little Java programming before and have actually used an Android device, but I assume no in-depth experience with the platform.

Platform Basics

The slides linked to above give a good visual overview, too, and the Android Developers website is an invaluable resource for finding more details on everything Android development related. But here’s the absolute minimum you need to know to get started.

The Android Platform is a full software stack for mobile devices that includes a Linux operating system, hardware drivers, and a bunch of neat low-level libraries you’ll probably never touch directly. It provides end users with a nice interface and handy applications to do things like browse the web, sync their email, and even make phone calls.

It also provides a way for users to securely run applications of their choice, simultaneously, and a set of tools and libraries developers can use to build their own applications — powerful enough to replicate or even replace many of the built-in “core” applications like the home screen or phone dialer.

Android applications are written in Java (J2SE, not a pared-down Java Mobile/Micro (Java ME) as found on many low-end phones) using an open-source J2SE implementation based on Apache Harmony along with tons of Android-specific libraries for things like UI and handy third-party libraries for things like HTTP requests and JSON parsing. That Java code is compiled and then transformed into Android-specific files in a format called .dex, and runs on the phone in a highly optimized VM runtime called Dalvik. Luckily, you’ll almost never have to think about any of those pieces in between writing your code and running it on the phone, since the tools take care of them for you.

Your code eventually runs in its own private highly-optimized virtual machine — it has its own memory space, and even runs as its own system user. This keeps bad code from blowing up the rest of the system and keeps your code secure from malicious software, eliminating risks from things like buffer overflow attacks or memory leaks that can affect other platforms.

Why Android?

The unspoken question here is usually “Why not the iPhone?” From a developer’s perspective, they both offer very good development environments and libraries, powerful testing and debugging tools, and a similar baseline of fairly speedy hardware devices. But the fact is, right now there are many times as many iPhone users and applications as there are Android users and apps. And there’s just plain more money being spent on iPhone apps right now, so from a business perspective, you absolutely can’t rule the iPhone out. There are really a few reasons to think seriously about Android for an application, though:

• Store independence. Your app can never be caught up in “approval limbo” – there’s no waiting period and you can update your app whenever you want. And if you’re unhappy with the Android Market itself, you can look to third-party stores like SlideME or even distribute apps for users to install themselves.
• Device independence. There’s only one iPhone device (or more accurately, 3 phone and 3 iPod Touch models with nearly-identical appearances and hardware) on one carrier (AT&T). Android is on devices from several major and minor manufacturers in a variety of form factors, and will be on phones for T-Mobile, Verizon, and Sprint by the end of the year.
• J2SE. Love it or hate it, there’s a lot of resources for learning it, tons of well-tested libraries, and no need to learn Objective C.
• Background processes. There are things you just can’t do with push notification.
• Little pond. Now that the initial App Store rush is over, it can be difficult to get attention in a store with dozens of new applications in your category every day. The Android Market is comparatively uncrowded, and the user base is likely to grow quickly as new carriers and devices come to market. While Active Frequency’s RockOut application was the only virtual guitar on the Android Market for several months, there are dozens of competitors for the iPhone.

Rather than talk the platform up any more, I’ll jump into writing an app and explain features as I go through it. For now, I’ll just say Android is an open platform and has some cool features like the Intents system, good native UI widgets, a sane and reasonable permissions system, and background processes, along with safeguards against bad code and access to a full J2SE stack.

What will I learn?

The point of this series isn’t to memorize APIs or the right sequences of incantations to do specific tasks, it’s to learn the general process of writing apps for Android.

Specifically, I tell the people watching this presentation live to keep an eye on the quick “prototype-run-test-edit-run…” cycle the tools make quick and simple, on the ease of debugging and getting useful, filterable console output, and in general on getting the a feel for effectively using the build tools and environment to get started quickly. You won’t learn the intricacies of all available tools and libraries in this one tutorial, and there’s no substitute for reading the documentation — but the documentation can’t show you what a typical development cycle looks like.

Know your tools

Most Android developers are using Google’s excellent tool chain. You can ignore some or all of it and write your code in the editor of your choice, interacting with build scripts and testing tools only when you want to, but the tools handle a lot of boring parts for you and give you one interface to handle a lot of functionality.

You’ll want a recent version (3.4 or 3.5) of the Eclipse IDE (Integrated Development Environment) for J2SE, the Android SDK, and the Eclipse ADT plugin to interface with those tools and provide project templates. Be sure to check out Google’s complete installation instructions for details.

Alternatively, you can install the all-in-one Motodev Studio, which includes all of those parts in a simple installer. However, I can’t really recommend that option right now as it’s still in beta and is a full version behind the SDK from Google (1.5, vs. 1.6) as of this writing. For this tutorial, I’m using Eclipse 3.5 for Mac OS X (Cocoa/64-bit) with ADT 0.9.3 and SDK 1.6r1 — the latest production releases as of October 1 2009, but you should be able to follow along just fine from Windows or your Linux/Unix of choice once you set up Eclipse, the SDK and the ADT.

… OK, all set? Great. Let’s move on to Part 2 and start our project.

On to Part 2!

The slides for our intro presentation are hosted on Prezi. Henry will be doing a narrated screencast of his part at some point in the next few weeks, and I’ll be doing a more complete writeup of the code portion with notes in a later post here on Active Frequency’s blog.

You’ll notice I linked in specific files from JTwitter rather than just including the .jar; there’s a lot of unnecessary code in the .jar and the J2SE source is a little lighter and cleaner, and hopefully makes it especially clear what the Twitter client is actually doing.

The demos use the JTwitter library (LGPL), and the icon is from a great Creative Commons set called Tweeties by Chris Wallace.

FITC Mobile 2009 kicks off tomorrow morning in Toronto. I’ll be leading two developer-geared sessions: Diving Into Android Development (with Henry Cipolla of Localytics) and Android Homescreen AppWidgets.

I’ll also be posting slides, notes, and code from the sessions to this blog during the conference, and occasionally Tweeting from our new Twitter account.

Come by and say hi if you’re going to be there!

My fave: Park It DC, possible by the District providing useful data feeds.

Five New User Features that Kick Ass

Here are some features Android end-users will really like, although they shouldn’t matter much to developers.

---

• A2DP – AKA Bluetooth stereo, so you can listen to music and take phone calls without cords. No screenshots to demo, and can’t test it in the emulator, but it’s on the feature list. This is even more crucial for the G1 than for the iPhone, since it doesn’t have a built-in standard headphone jack.
• Soft Keyboard - Terrible for typing real emails, but sometimes you don’t want to slide open the keyboard just to mash out a quick one-handed SMS.
• Music Player Widget – Along with A2DP, easy access to the music player makes Android phones a more viable replacement for an MP3 player.
• Smart Folders – Starred Contacts Folders, for example, which may finally make a competent “speed dial” replacement. The folder’s contacts update dynamically when you change your contacts list, unlike the current release, where you’d have to go add or remove the contact in the folder separately.
• Camcorder – with YouTube uploading. Can’t run this in the emulator, but the application is there and it’s on the feature list.

Five New Developer Features that Kick Ass

These features will make programmers happy. The impact from these will probably take a few days/weeks after release to matter to end users while developers scramble to write code once the final release of the SDK comes out.

• SDK Targeting – A major developer concern is compatibility, especially as new handset manufacturers add their own proprietary software and as some may lock the core OS at a different release than others. You can make one app for SDK 1.1 base devices, and a different one for SDK 1.5 devices that include the Google APIs, for example, and if the user’s software doesn’t match up they can’t run and crash your app.
• AppWidget Framework – Not just for the Home Screen; there might be some nifty uses for in-app embedding of one app inside another that I can’t even fully comprehend yet (maybe a third-party drum sequencer AppWidget inside RockOut, for example).
• JetPlayer – some digging through headers seems to indicate this is Sonivox JET, which looks like a MIDI engine. It also promises to ease development of rhythm games. Not a lot of details on this yet, but expect to see a glut of drum sequencers, pianos, Tap Tap Revolution ripoffs, and MIDI editors popping up on the Market once the documentation is fleshed out a bit.
• SoundPool fixes – my initial testing shows that they’ve fixed some of the bugs with the low-latency SoundPool audio APIs. In API 1.1, calling the stop() method for an audio stream instantly crashed your app. This led to delays in audio as multiple streams had to be muted and allowed to die, and wasted developer time writing code to do audio stream bookkeeping. Now, it just works! Expect better sound from games and more features from apps like RockOut as a result.
• XML File Wizard - I’m generally a TextMate / Vim kind of guy, but there’s a lot of hard-to-remember options to deal with when creating views for an Android app, and fine-grained targeting will get really scary when more hardware comes out with a wide variety of capabilities. A relatively simple way to say “use this template when they’re on a portrait touchscreen device and this one on a landscape device with a trackball” is going to be really helpful, and it should eliminate some programmer confusion.

Five Nice Touches

Details matter. These don’t necessarily make for bragging rights but they all improve the user experience in some way.

---

---

• Carbon-Fiber Applications List – Like a racing bike’s frame, this obviously makes it go faster. But in all seriousness, the semi-transparent apps list in 1.0/1.1 were hard to read at times, and this helps.
• Animated Transitions - Subtle, and most importantly, fast (a fraction of a second) so it adds to the experience rather than just slowing me down.
• Better Bookmarks/Most Visited/History View – History view used to be buried as a menu option. This makes it much easier to manage my favorites without having to dig through menus.
• SquirrelFish – WebKit’s new Javscript engine should make things faster. A lot faster, for Javascript-heavy Web apps. It’s not a visible change, but it’s significant. By most measures, at least on desktops, it’s up to 4x faster than the old WebKit engine. It’s not as fast as V8, the engine Google uses in Chrome, but it should be a nice little bump in responsiveness for Web applications and Android apps with embedded WebViews, like the Gmail app.
• Pictures in Starred Contacts view – Rather than a generic star icon. Looks nice, and it’s helpful for me to find who I’m looking for within a list of favorites since there’s no particular order to them.

Did I miss your favorite new feature? Weigh in with a comment below the entry.

(The title of this post is a nod to our delicious neighbors and Comic Sans MS abusers, Kickass Cupcakes).

Today we released the 1.1 update to RockOut Acoustic Pro. This update adds some neat new features like “Fretting Mode,” which lets you hold the screen to “fret” chords and strum using the trackball. We thoroughly tested the application for both new installs and updates from the old version, on both the Android emulator and an actual G1. Everything looked good.

But when we actually put the update on the Market, some users complained the app was automatically force closing (read: crashing) when they installed the update.

I couldn’t reproduce it, but then a user sent me his log files (thanks to the wonderful Log Collector app). Here’s some relevant parts, and then the explanation:

E/PackageManager( 51): Package com.activefrequency.android.rockoutacousticpro has mismatched uid: 10046 on disk, 10047 in settings; read messages:
...
E/Database( 228): sqlite3_open_v2("/data/data/com.activefrequency.android.rockoutacousticpro/databases/song_list.db", &handle, 6, NULL) failed
...

Here’s why this happened: When we first released RockOut Acoustic Pro we had copy protection turned on. I turned it off a day or two later because an odd Market bug that Google won’t really acknowledge causes copy protected apps not to show at all on the market on many phones (normal G1s, not just ADPs).

This only happened, as far as I can tell, to users who previously had the copy protected version of my app installed.

The copy protection mechanism changes the uid of the application, so that non-copy-protected versions of the same app signed by the same key are no longer recognized as the same application, and are denied access to the database and other resources for the application.

This is never documented anywhere in any official Market or Android documentation, as far as I can see.

Plus, we had no way to figure this out on our own because developers can never install their own paid apps off the market, therefore can never test the copy-protected versions of their apps!

Now that I actually know the root cause of the problem, it’s easy enough to google and I can see I’m not the first dev burned by it.

There’s a ticket to fix this but no progress that I can see. This means Google is aware of the problem, yet doesn’t tell you about it when they know you’re about to break updates for your app by checking or unchecking the copy protection box. This is a 100% predictable result, and should be simple to warn developers about before they hurt their reputation or suddenly get dozens of negative reviews.

The absolute bare minimum Google can do is DOCUMENT this. I can’t see it taking more than 10 minutes to add a warning box when you add or remove copy protection from an app already live on the market, and it would have saved me a good hour of frantic hunting for a bug in my code that wasn’t there.

Is just disclosing this to developers too much to ask?