Are you tired of seeing this when you look at your platform JAR in Eclipse?
Dude, where's my source?
January 18, 2010
December 30, 2009
Editing XML resources for Android in Eclipse
Just the other day, I was griping about the way Eclipse ADT tools dump out XML in long unreadable lines like this:
As with so many things, Eclipse is your friend if you just know how to set it up. As it turns out, Artem Russakovskii of Beer Planet recently wrote an excellent post with instructions for configuring Eclipse to auto-format your XML pleasingly so it will look more like this:
I can do no better than to refer you to the post. In case he moves it or something, the short-and-sweet version is:
- Window -> Preferences -> XML -> XML Files -> Editor
- Source -> Cleanup Document
Making your XML readable means it’s also a lot more writeable. The ADT GUIs for working with resources are very handy, and you might not think you want to write XML by hand, but Eclipse is your friend here, too: it will suggest and auto-complete tags and attributes for you.
Eclipse can suggest and auto-complete allowed tags, attributes, and values for attributes based on the XML schemas supplied by the SDK. If Eclipse isn’t automatically suggesting (or like me, you’ve turned off auto-suggestions because they’re annoying), you can just press Ctrl-Space with your cursor placed where you’d like a suggestion in the document, use the arrow keys to choose a suggestion, and hit Enter to accept one. As you can see above, the suggestions come with at least minimal descriptions to jog your memory. This makes writing XML “by hand” almost completely painless.
Comments Off
December 23, 2009
Emulator frustrations for n00bs
Here are a hodgepodge of issues related to using the emulator.
The emulator takes forever to come up
Yes, yes it does, especially the first time you start it. It’s emulating booting up a complete OS running on a different architecture (ARM processor) than your development machine – so yeah, it’s a little slow. If you have an Android device you know that even running natively it’s not exactly an instant startup, so expect some delays in the emulator too.
Just go ahead and start the emulator when you start Eclipse and it’ll be there when you need it. Keep it running, there’s no need to stop and start it all the time.
Why does deploying a package to the emulator keep failing?
Often this is because you’re trying to deploy before the emulator has finished booting (because you waited until you were ready to try out your app before starting the emulator). The Home process needs to be running before a deploy will work. It’s a common n00b mistake to try the “run” button on Eclipse, watch it start an emulator and fail to deploy, kill the emulator, and try it again – it will never succeed until the emulator finishes booting.
Deploy may also fail for basically the same reason when the device bridge server has failed (see below) and Eclipse DDMS starts a new emulator (or tries to).
Of course, the other reason deploying may fail is if there’s something wrong with your package. Perhaps the API you’re developing against isn’t available on the emulator, or you’ve messed up something in the application manifest. But those problems should be fairly easy to diagnose from the error messages on the console.
I keep ending up with emulators that can’t be attached to
I’m not sure why this happens – something to do with networking (esp. during suspend/hibernate), or non-Sun Java JDK, or updating components while an emulator is running. But sometimes you’ll be running an emulator and it won’t show up in the list of emulators (either the command line adb devices or in the Eclipse DDMS perspective – or I’ve seen it show up in the perspective but without any processes).
Of course the simple remedy is to kill the emulator and start a new one, but as noted previously, that takes forever. The emulator is running – why can’t you connect to it?
Try using the “Reset adb” option from the DDMS Devices view menu, or restarting the server at the command line:
adb kill-server
adb start-server
Otherwise I don’t know what you can do. I have a question in about this and I’m waiting for an answer, too.
My emulator keeps offering to “force close” odd things, especially at startup
This is pretty common for me at least; you may never have seen it if you have better hardware. Just choose the “wait” option, everything will work out. I have a theory about this – perhaps someone who knows better will enlighten me if I’m wrong. Android has a policy of offering to force close non-responsive elements, where “non-responsive” means it hasn’t handled an event five seconds after it was notified of the event. As noted above, you’re running an emulator here, and it tends to run a bit slowly – but the clock is still ticking in realtime. I believe it’s simply a matter of certain parts of the operating system taking too long to respond, especially at boot time. Just ignore it and wait for them to finish.
December 22, 2009
What’s with the various API levels and types in the SDK?
(As of SDK 2.0.1)
The API levels 1.0 through 2.0.1 are versions of the framework with which you develop Android applications (see http://developer.android.com/guide/appendix/api-levels.html for more). They’re fairly backward compatible but not completely. These are also referred to by integer API numbers and sometimes names:
- 1 = version 1.0
- 2 = version 1.1
- 3 = version 1.5 (Cupcake)
- 4 = version 1.6 (Donut)
- 5 = version 2.0 (Eclair)
- 6 = version 2.0.1
The devices out there may be one of several different versions. At the time of writing, my stock T-Mobile G1 is at 1.6 (and may never get 2.0 as evidently the memory requirements are prohibitive). The Droid runs 2.0. I seem to recall hearing of another phone that was still stuck on 1.5 (the Cliq?). If you want to know the relative percentages of what’s out there, check the Platform Versions Dashboard.
When you develop an application, you have to specify what API level you’re developing for. Then the device will know whether it can support your application. For the widest support you’ll want the earliest feasible API (probably 1.5 for now), but then you’re missing out on the features of later APIs.
When you’re selecting the “target” for creating an emulator or developing an app, you also have a choice of developing against the Google APIs or not. These add more libraries for your application to use – currently, this is basically just if you want to integrate Google Maps into your application; later versions of the API may have other useful libraries. The language of “Google API” is a bit confusing when added to SDK/Android API versioning. It’s added functionality on top of the standard Android platform – each “Google APIs” target also includes the API platform with the number given.
Comments Off
December 14, 2009
The Eclipse ADT plugin for creating projects says I need to choose a target, but there’s nowhere to choose a target!
This was a particularly frustrating one, but it’s really simple to resolve.
Creating a project - how do I specify the build target when none is listed???
This is a simple problem of screen real estate. When the dialog is not long enough vertically, the part that is shrunk (down to nothing!) to fit is the Build Target selection box. The only way to get it to show up is to expand the dialog vertically – you may have to increase your screen resolution to fit it all in (I found this out while working on an Eee PC – a screen height of 600 pixels won’t cut it!).
For completeness, I should probably mention that your SDK comes with no build targets – you have to download some after unzipping it. But if that’s your problem, you should still see a white space in the Build Target selection box where the targets would be.
This is a pretty strange design problem. Seems to me it would make more sense to occlude the bottom of the dialog in this situation rather than something essential in the middle. Or just put a scrollbar on the dialog!? I found a few other people complaining about this problem.
December 8, 2009
My emulator looks different than in the examples!
Illustrations of emulator usage in books and on the web have emulator skins that look like devices, but if your SDK is at all recent, the emulator doesn’t look like that – the screen is bare. This is a seemingly insignificant thing, but strangely no one seems to talk about it. I didn’t find any documentation explaining this – I had to ask like a n00b on the IRC channel. Well, to save you the embarrassment – it’s pretty simple. For the API 1.5 and before, the emulator looks like a device. For 1.6 and after, it doesn’t. If you really want your emulator to look like that, you need to use an emulator targeted at 1.5 or before – as far as I can tell, there’s no setting you can use to configure 1.6 or 2.0 to show the device skin from 1.5.
Emulators for versions 1.5 and 1.6
December 7, 2009
Missing dependencies for the Eclipse ADT plugin
When installing the plugin, depending on your setup, Eclipse may fail with a message that dependencies are missing.
com.android.ide.eclipse.adt.feature.group requires 'org.eclipse.wst.xml.ui 0.0.0' but it could not be found
Unless your Eclipse is too old (the plugin requires 3.4 or above) this is not really a problem with Eclipse, the SDK, or ADT, but rather how various operating systems package Eclipse. The appropriate components need to be installed or Eclipse needs to be configured with the appropriate software update site for its version so that it can resolve dependencies for you. (more…)
Comments Off