Digital archives contain as usually understood by professional archivists and historians.
This week's developer video features Jason Tomlinson of Hands-On Mobile. He wrote Amazed, an application open sourced in the apps-for-android project. Things Jason mentions in the videos include:
This and other Android developer videos can be found here.
Last week we introduced a couple Android developers who shared how they built their Android apps and gave their insight into Android app development. This week, we have videos of two developers who've built music-related apps.
The first is of Allan Hsu—he wrote imeem's Android app. A couple of things he mentions in his videos:
The second video features Casey Langen—he wrote the Amazon MP3 for Android app. Things he mentions in the videos include:
Check out other Android developer videos here: Android App Developers.
As we mentioned yesterday, the Android Market is now open for developers to upload their applications. I'm pretty excited because Market, along with the availability of the first Android-powered phone and the Android 1.0 SDK, puts the basic pieces of the Android platform into place for developers to create and distribute their apps.
To help developers better understand what's available to them, we've collected stories from some Android application developers. In the videos, you'll hear them talk about how they built their apps, their takes on the Android platform, and also some tips they want to share with other developers. I think they have a lot of insight to share about Android application development, so I hope you'll find these videos useful.
Here are the first two developers in this series:
Jeff Sharkey is an ADC finalist—he built CompareEverywhere.
Jacob Abrams is from Glu Mobile and helped to build their first Android app, Bonsai Blast.
Keep an eye on this blog, our YouTube channel, or the playlist for this series for more of these videos in the coming weeks.
Last month I outlined some details around Android Market. Today, Android Market launched for users to download applications along with the first Android-powered phone—the T-Mobile G1.
With Android Market, users can easily download apps to their Android-powered phone. Users can also rate the apps they've downloaded and leave comments. These users' ratings along with anonymous usage statistics help determine how apps are ranked and presented within Android Market.
If you're a developer, you will be able to register and upload your applications starting next Monday, 2008-10-27, when we've wrapped up a few final details. In order to make sure that each developer is authenticated and responsible for their apps, you will need to register and pay a one time $25 application fee. Once registered, your apps can be made available to users without further validation or approval.
Starting in early Q1, developers will also be able to distribute paid apps in addition to free apps. Developers will get 70% of the revenue from each purchase; the remaining amount goes to carriers and billing settlement fees—Google does not take a percentage. We believe this revenue model creates a fair and positive experience for users, developers, and carriers.
There are already over 50 apps available in Android Market today. You can view a showcase of some of these apps—which include multimedia, location-based tools, barcode scanners, travel guides and games—at http://www.android.com/market/. Now that Android Market is live and ready for contributions, we hope to see developers adding their own compelling apps starting next week.
In the coming months, we'll continue to roll out additional tools and enhancements to Android Market. We also expect to see additional Android-powered devices rolling out by different carriers around the world. Starting today, you can get a device, test your apps on it, and get them ready for upload. On Monday, to share your app with the world, simply register, upload your application and publish it. It's really that easy. I look forward to seeing what you bring to the Market.
Update: As of Monday morning (2008-10-27), http://market.android.com/publish is now available for developers to publish their apps on Android Market.
When we released the 0.9_r1 beta SDK, we mentioned that the Maps API included with Android would soon require an API key to function correctly and load map tiles. Part of the reason for this was that the Terms of Service (ToS) for the Maps API had not been finalized.
Today, I'm pleased to be able to tell you that the new Android Maps API ToS are now finalized and they're actually pretty exciting. Most of the restrictions present in the old ToS are now gone—for instance, it's now permissible to use the Android Maps API to build "friend finder" style applications. There are still a few limitations, but not nearly as many as before.
Now that the ToS are finalized, it's time to take the next step. Until now, developers have been able to use any value for their Maps API key—that is, the Maps API keys weren't enforced. However, starting early tomorrow morning (Oct 22nd, PDT), we are turning on Maps key enforcement, so the grace period is ending very soon. This means it's also time for developers to acquire and begin using real API keys. Here's what you'll need to do:
The way the keys work is that when you use a MapView, it queries the system to find the public fingerprint ID of the certificate used to
sign the currently-running application. The MapView then works with the server to verify that the certificate which signed the current application is the same certificate to which the current Maps API key belongs. If they match, then tiles are displayed; if they do not match, then no map tiles are displayed.
You will need one Maps API key for each certificate you use to sign your applications. That is, you'll need separate Maps API keys for both your debug-time signing certificate used in the emulator, and for your release-time certificate you'll use when publishing your apps. Fortunately this is free, and there is no limit to the number of keys you can acquire. Finally, note that this only applies if you're using a MapView in your
Android application. If you don't use Maps at all, or if you use an Intentto launch Google Maps, you don't need to follow these steps.
Be sure to get your Maps API key now to avoid a disruption.
Over the past year, we announced Android, released several SDKs (eventually resulting in the 1.0 SDK), gave out the first half of the $10,000,000 prize money for the Android Developer Challenge, and prepared the first Android-powered device for users. Tomorrow, the T-Mobile G1 goes on sale.
But today, we're making what might just be the most exciting announcement of all: we and our Open Handset Alliance partners have now released the source code for Android. There's a huge amount of code and content there, so head over to http://source.android.com/ for all the details.
I'd like to offer a huge thank you and congratulations to my colleagues and the Alliance partners for what I hope will be a red-letter day for the open source community, and openness in the mobile industry.
About this time last year, my colleagues and I were preparing for the first of the "early look" SDK releases. I remember being a little freaked out—November 12 was starting to sound awfully close! But I think I can safely speak for the entire Android team when I say that we were all very excited about that upcoming release. In the year since, we've run and concluded the first Android Developer Challenge, given away $5,000,000, released more SDK builds, and worked with our partners to prepare the first device for users. It's been quite the whirlwind of a year.
In one of those strange cosmic symmetries, here we are a year later, and we're once again very excited about an upcoming release. I'm referring, of course, to the first Android-powered device that our colleagues at T-Mobile have just announced—the T-Mobile G1. We can't wait to see our hard work on store shelves and in the hands of users, but today we're almost as excited because we're announcing the brand-new Android 1.0 SDK, release 1.
Yes, that means we're officially at 1.0. Of course the SDK won't remain static—we'll keep improving the tools by adding features and fixing bugs. But now developers can rely on the APIs in the SDK, and can update their applications to run on Android 1.0-compatible devices. The Android Market beta will also launch with the T-Mobile G1, providing developers an easy and open way to distribute their applications on that and later devices. I've already seen a lot of applications that have me stoked, and I can't wait to see things really come together as developers cross that final mile to prepare their applications for Android 1.0.
So what's next for us? Well, we'll keep working on the SDK, as I said. But we're also working hard with our partners in the Open Handset Alliance on the open-source release, with the aim of making the code available in the fourth quarter. The second Android Developer Challenge is also on the horizon—watch this space for more details. We're also already working on the future of the Android platform, and on more devices. We've updated the Developer Roadmap, and we'll keep updating it as more information becomes available.
It has indeed been quite an exciting road to get to where we are today. The road stretches on ahead though, and we're not slowing down for a moment. I look forward to meeting and working with many of you developers out there—and trying out your apps on my phone!
Happy Coding!
The Panoramio web site has a great collection of photos from all over the world, and they also have a very convenient web API. I thought it would be a lot of fun to use Android to access this content while you are out walking around – and especially to have Android find interesting photos based on your current location. The resulting open source application is now available in the apps-for-android project.
The application starts by showing your current location in a custom MapView. You can pan and zoom this map to choose the area you want to search.
Once you have selected a search area, the application downloads thumbnails of the most popular photos taken within that area:
You can tap on an item to see more details.
From here you can use the menu to find more pictures by the same photographer or to see the original photo on the Panoramio site. My two favorite features, though, help you find the location of the photo in the real world. You can show the location on the map along with your current location:
Or, you can bring up a radar view that uses the compass and GPS to show you the location of the photo in relation to your own location:
I thought that other applications might want to use the radar view for their own purposes ("find me the nearest taqueria"), so I split that into its own package. You can find the source for that in the Radar project. Of course, you don't need the source in order to use this feature. Because of Android's component architecture, all you need to do us use an Intent:
Intent i = new Intent("com.google.android.radar.SHOW_RADAR");
i.putExtra("latitude", 37.422f);
i.putExtra("longitude", -122.084f);
startActivity(i);
The code for these applications is not very long, but they are a good example of how to use a number of Android's location APIs:
I've written a small application called WebViewDemo that shows how you can add web content to your application. You can find it in the apps-for-android project. This application demonstrates how you can embed a WebView into an activity and also how you can have two way communication between your application and the web content.
A WebView uses the same rendering and JavaScript engine as the browser, but it runs under the control of your application. The WebView can be full screen or you can mix it with other Views. The content for your WebView can come from anywhere. The WebView can download content from the web, or it can come from local files stored in your assets directory. The content can even be dynamically generated by your application code. For this example, the HTML comes from a local file called demo.html.
This application does not do very much: when you click on the android, he raises his arm.
This could, of course, easily be accomplished with a little bit of JavaScript. Instead, though, WebViewDemo takes a slightly more complicated path to illustrate two very powerful features of WebView.
First, JavaScript running inside the WebView can call out to code in your Activity. You can use this to have your JavaScript trigger actions like starting a new activity, or it can be used to fetch data from a database or ContentProvider. The API for this is very simple: just call the addJavascriptInterface method on your WebView. You pass an object whose methods you want to expose to JavaScript and the name to use when making calls. You can see the exact syntax in WebViewDemo.java. Here we are making our DemoJavascriptInterface object available to JavaScript where it will be called "window.demo".
Second, your Activity can invoke JavaScript methods. All you have to do is call the loadUrl method with the appropriate JavaScript call:
mWebView.loadUrl("javascript:wave()");
Our WebViewDemo uses both techniques: when you click on the android, it calls out to the activity, which then turns around and calls back into the JavaScript. WebViews are very powerful, and they may be a valuable tool to help you build your application – especially if you already have a lot of HTML content. As it happens, we've used exactly this approach in some of the applications we've written.
Years ago I was addicted to a simple game that I played on my then state-of-the-art Pentium-75. In this game, balls would bounce around, and I would try to partition them into small enough spaces so that I could go to the next level where more and more balls would be added. As of a couple of months ago, for the life of me, I couldn't remember the name of this game. So when I sat down to write an application for Android in my 20% time, I thought, why not try to recreate something similar? After completing most of the game and showing it to some of my friends at work, one of them said, "Oh, this reminds me of JezzBall!" Eureka! If working on this game does nothing more than reveal the name of one of the favorite games of my youth, I'll call it a success, but in the meantime, I'm happy to announce that the source of this application, named Divide and Conquer, is now available on apps-for-android.
The game starts with instructions:
and begins simply enough with one ball bouncing around. You drag your finger in a horizontal or vertical gesture on the screen to initiate a line that extends until it reaches the edges:
In each level, once you've shaved off 80% of the original area, you move to the next level. Here's a screen shot of level 6:
If a ball hits a line in progress, you lose a life:
Once you are out of lives, it is game over:
While this game isn't going to win any awards for cutting edge graphics, it demonstrates use of several Android features and APIs:
DivideAndConquerView is a custom View that implements its own onDraw method using the Canvas methods, and gesture detection using onTouchEvent and a helper class DirectionPoint. It keeps track of the state of the game using BallEngine, and reports relevant events back to the main activity of the application, which, in turn, keeps track of and controls the state of the game. The application is configured to be full screen in its AndroidManifest.xml file.
I've posted three new open source samples to the apps-for-android project: Triangle, SpriteText and Downloader.
The first two samples, Triangle and SpriteText, show techniques that would be useful to anyone using the OpenGL ES 3D graphics APIs to write Android applications. The samples contain several reusable classes that may eventually be incorporated (in some form) into the SDK. Chief among these is the GLView class, which abstracts the OpenGL ES book-keeping code from the rest of the application. GLView helps handle the extra work OpenGL ES applications have to do when the activity is paused and resumed, and when the display goes to sleep and wakes up. In the Pause/Resume case the OpenGL surface has to be recreated. In the display sleep / wake-up case the entire OpenGL context has to be recreated.
The first sample, Triangle, shows how to use the GLView class and the OpenGL ES 3D library to display a spinning textured triangle. Think of it as the "hello, world" of OpenGL ES apps. Because it's relatively simple, it's a good place to start when experimenting with the OpenGL ES API.
The second sample, SpriteText, shows how to efficiently display screen-aligned text using the GL11Ext.glDrawTexiOES method. SpriteText contains a reusable LabelMaker class for drawing static text and screen-aligned images, as well as a Projector class for finding the 2D screen coordinates corresponding to a 3D point, and a MatrixTrackingGL class for keeping track of the current transformation matrix. Finally, it shows how to use these classes to display a milliseconds per frame counter. A ms/f counter can be helpful for tuning graphics performance.
The third sample, Downloader, shows how to add a downloader activity to your application. The downloader activity runs at the beginning of your application and makes sure that a set of files have been downloaded from a web server to the phone's SD card. Downloader is useful for applications that need more local data than can fit into an .apk file. For example a game could use Downloader to download the game's artwork, sound effects, and level data. The Downloader activity is designed to be a drop-in addition to your application. You customize it by supplying the URL of an XML configuration file which lists the data files that need to be downloaded.