Android Development: How to get GPU Acceleration for your AVDs

I was quite excited when I first read the news that the Android Emulator now supports using your PC's GPU for better graphics performance.  Trouble is, the aforementioned announcement doesn't contain any information on how it works.  I only discovered the answer thanks to Google's revamped developer site, wherein I stumbled across an emulator setup guide I had never seen before (I'm assuming that it actually was there before, and that it isn't a brand new page.  I could very well be wrong on that).

Anyway, the answer is found in the settings page for your virtual device. In the hardware section, you can click "New", and choose the "GPU Emulation" property.  Set it to yes, and your graphics card will be put to work (provided it is supported; I'm not sure how well it works in all environments).

Click the 'New' button in the 'Hardware' section, and you'll be able to add GPU emulation as a property (It's shown at the bottom of the property list here).

So far, the results are impressive.  The virtual device still takes a while to load up (though not as long as it did when I first tinkered with the SDK, years ago), but once it's on, it is very smooth and responsive, enough so to make it worthwhile for testing.  This could make it much easier to test future projects on multiple device types.

The guide above also explains how to configure Virtual Machine acceleration, using the VM extensions  supported by modern processors.  This is another welcome feature for improving emulator performance, but it looks more complicated to setup.  Namely, you have to enable the VM extensions for your CPU via the BIOS, and install extra virtualization drivers.  The drivers are the real showstopper, as the guide warns that they can conflict with the drivers for other VM software like Virtualbox.  The fix is to only enable one set of drivers at a time - this is easy enough in a *nix environment, but I'd have to go and find out what Vitrualbox installs.

Once you've got your drivers under control, there's one last caveat; to use VM acceleration, your virtual device has to be running an x86 CPU, rather than the traditional ARM chip.  This isn't really a problem - Intel has already put out an x86 based phone, and the support is there.  You just have to remember to take the extra step, because these AVDs go to ARM by default.

If I dip my toes into this CPU virtualization, I'll come back here with my findings.

Notepad App: The Rest

With the Scratchpad finished, the next step was to get the regular notepad functionality working.  Since I already had a working example, all I had to do was fit it into my existing codebase.  This turned out to be fairly easy, and I had a half-working example after no more than an hour's work.  Getting it working well was another matter entirely.

For one, the text on the main screen was small, and only the text itself was responsive to touch input.  If the title of a note was small, it was almost impossible to open (and if there was no title, it was completely inaccessible).   This fix taught me just how important it is to understand the built in Android layout rules.  The "wrap_content" rule, for instance, can be a bad choice for setting the width of a view. So can "match_parent" if you aren't aware of what the parent view's width is set to.  This is yet another area in which blindly following sample code can get you in trouble, when all of a sudden your GUI is lined up all wrong and you don't know why.  I ended up re-evaluating the width and height of every View in every XML file in the app, since this forced me to justify each and every setting.  By the end, I had everything looking the way I wanted it, and more importantly, I understood why.

My initial porting attempt also broke a small (but handy) feature from the sample Notepad app; if there were no saved notes, a special "no notes" message was displayed instead.  In my app, however, this message was displaying even when there were notes present.  It turns out that this feature requires your app to be designed in a very specific fashion, which happened to be the case for the sample app, but not mine.  Specifically, the Activity in question needs to:

• Subclass Android's ListActivity class.
• The layout file associated with the Activity needs to contain one ListView and one TextView, and they must be id'ed using two of Android's standard View names - "list" and "no_notes".

Looking at my app, I knew that my layout file used different id names, and that my class only extended  Activity. An easy fix to be sure, but there was another problem - could I still cram the Scratchpad 
button onto the page?  If I added it to the layout file, would it display?  And even if it did, would the ListActivity accomodate the code responsible for handling click input?

The answer to both of these questions is "yes" and "yes".  By using a ListActivity, you benefit from having a built-in ListView object to use, but you aren't married to it.  Remember that you can technically associate any layout file to a ListActivity.  It helps if some of the Views defined in the layout are structured in such a way to work well with the class, but even then you can still add more on top of it.  Then, once you add extra buttons and gizmos, you simply write a click handler for each one. For me, this translated into an extra layout entry (for the Scratchpad button), and a single, small click handler.  Nice and easy all around, and I learned a ton about how views and activities relate to each other.


After that, it was just a matter of making a few final touch ups, such as having the cursor appear at the end of the title when opening a note, and giving notes a default title when none is entered. All told, this phase of the work took almost as long as the last, but I got far, far more done.

I'd like to end this entry with a list of additional lessons learned.   All told, this was a very rewarding experience, and I feel more motivated than ever after achieving this small success.

•  For the first time, I used version control on a personal project.  I'm using git, as I'm used to it from work, and it worked like a charm.  When I tried to refactor the app to use a ListActivity, I created a new branch: it was nice to know that, should it not work, I could revert back to a working state.
• I'm planing on going back to this app at a later date, to make some improvements. Specifically, it could use better error handling, and it would be nice to have more flexible controls for adding/deleting/editing content.  Perhaps even a home screen widget for displaying the Scratchpad.
• I ran into an issue using StringBuffer; namely, I was trying to reuse the same StringBuffer instance without cleaning it out, so it kept preserving its previous content.  Ideally, what I should have been doing was creating a new object every time, but sometimes I still think like a C coder, and I considered that a waste of memory.  Yeah yeah, there's garbage collection, I know, but wiping the buffer was trivial, and now I feel like I can go to sleep tonight.
• Next up, a tasks app.  It'll be far more complicated, but even more useful too.

Notepad App: Scratchpad

I've finally a useable part of my personal app.  The Scratchpad function is working fully.

I made a serious mistake when working on this part, by trying to store the Scratchpad data in a SQLite database.  Such a DB makes sense when you are storing multiple notes, but the Scratchpad is just one big note, a text dump for storing quick thoughts that I don't want or need to create a full, separate note for.  There's no need to wrestle with database queries and row integrity.  I lost several hours struggling to get things working, to the point where I almost gave up.

Thankfully, I sat back down and researched alternative storage methods.  After all, this kind of data could easily be stored in as a text file, and as it turns out, Android has tools for doing this.  You can create storage files that are viewable and readable only by the app itself.  Using this technique, I got the Scratchpad working very quickly, and while I am happy it works, I'm also more frustrated with the fact that I'll never get those wasted hours back.

This reveals a major flaw in my skills as a programmer.  I rely on sample code too much, to the point where it holds me back.  I needed to store data; what I should have done is look through the reference documents for ways to do this.  Instead, I looked through the samples I had previously read through.  Since all of these samples were dealing with ListViews, they all used SQLite tables.  It wasn't the only storage choice available, but it was the only one I was exposed to.  Thus my tunnel vision set in.

The other problem with using sample code is that sometimes the only thing it can teach you is how certain parts of the API work within the context of this specific example.  Unless you can read the code and understand how to use a featured method  in any given situation, then you don't really understand how to use it.  If you then proceed to copy and paste that code into a completely different context, what will you do if it breaks?  Scramble, of course, because you don't know enough about how it works.

I made these mistakes with the Scratchpad, and for my own sake, I need to learn from them if I am to get the remainder of the app completed without experiencing this level of frustration.

The Moral of the Story: Use sample code to get a feel for how a complete program reads and flows.  But when it's time to do something yourself, figure out what it is you want to do, and look through the API to find pieces that will help you do that.  Work with them until you find out what it really does, and if it isn't suiting your purposes, start looking again.  By the time you have a working prototype, you will be able to explain why it works (and if it turns out there's a better way you could have done it, don't worry.  That can come in a new version, when your skills have improved).

Notepad App: Intro

My first attempt at an Android App is to make a notepad application.  As it turns out, the Android sample code has a fully functioning notepad in its sample code folder.  It's simple, but if all you want is to write and save notes, it's perfect.

However, I want to do slightly more than that. Namely:

- I want to be able to write individual notes, with titles, that I can save (this is what the Android sample project already offers).
- I want to have a single, giant note, called the "Scratchpad", which I can access quickly, and fill with quick bits of text.  The point here is not organization, but to allow me to just get things down before I forget.

In theory, this should be a simple job.  Just take the existing example, add a new button on the screen for the Scratchpad, and an additional, super basic text editing window for modifying it.

Let's see just how simple it will be for me in practice. Consider this a developer diary of sorts.

Android bloggers

For me, by far the worse aspect of the Android ecosystem is the community of bloggers surrounding it.

On one end of the spectrum, you have the professionals.  These folks are technically proficient, so their sites are at least partially useful.  But being professionals, they absolutely need to attract (and maintain) a large readership.  What that usually translates into is an extreme focus on only the latest and greatest devices.  When you constantly remind people that they are behind the times (even if their phone is brand new), it messes with them psychologically.  They will perpetually lust for gizmos which are out of their reach, and so they will constantly revisit these sites to get their fix.  When people get into this gadget frenzy, they forget that the bloggers themselves live in a tech writer bubble that in no way reflects the habits of the average user.  They get demo units and early access; they often have a new primary phone every month (or every other week!).

I find that these professional sites a great resource when you're in the market for a new phone, but once you find the right one, there's no good reason to come back.  You're not going to find much in the way of tips and tricks for your new hardware, and after a couple of months, you might not even get timely news in regards to OS updates.

On the other side, you have the amateur/barely professional bloggers.  These sites are run by writers whose bylines state that they've had an Android phone for a year or less.  They refuse to do anything resembling journalism.  Their news pieces are instead culled from rumors, speculation, and bullshit.

To give you an example, do a search for news on the 4.0.4 software update for the Verizon version of the Galaxy Nexus.  It's been mysteriously absent for months, and no one's sure what's happening, or when it will arrive as an Over the Air update.  But if you do a Google news search, you'll find tons of Android sites stating that the update is already out on OTA.  Their proof?  Other shitty Android sites, who in turned linked to yet another.  Follow the trail far enough, and you'll realize that there was never any concrete evidence supporting these claims.  It appears as if the entire community is linking to each other in a neverending circle of BS.

Staying with the Nexus, the other typical news piece announces that the update is available directly from Google, and is ready to be installed manually.  You just need to make sure you unlock your phone.  And root it.  Or maybe you don't need to root it.  Who knows, because everyone gives a different set of instructions on how to apply it (and their comments sections are filled with people asking why it isn't working).  Most of these sites have no idea what they're talking about, and I find myself uncomfortable trusting anything they provide, be it news, tips, or a download link.

It's unfortunate, because it means that a lot of the potential inherent in the platform will be inaccessible to a huge number of users who simply don't want to be given the runaround.  Whenever I see someone express their fears of rooting their phone, I completely understand where they're coming from.  With some of these sites, it would be akin to driving your sedan into a shady chop shop for repairs.

Android Development

Last winter I was inspired to try my hand at iOS development. The experiment didn't last very long.  I just couldn't get the hang of any of its key components.  The Xcode IDE, the Objective C language, none of it clicked.

In a similar fashion, I recently tried to get into Android phone development, but this time I'm actually making progress.  I can think of at least one obvious reason - thanks to my work experience, I'm already familiar with Java development and the Eclipse IDE. The question on my mind is just how much of a difference this makes.

For example, regardless of the language being used, I feel like Google's documentation is better than Apple's.  But is that really accurate?  Or is it simply that the Android tutorials were easier to get through because I wasn't also trying to learn a new language? On the same note, I feel like working with Eclipse was much simpler than Xcode.  I know why I like using Eclipse, but is Xcode really as bad as I think?  I know my perspective is clouded, but I can't tell if it is warping my expectations.I'm not surprised that working on iOS proved harder at first, but did I give up too quickly because it wasn't exactly what I'm used to?  In other words, I don't want to give up on something unless I know it really, truly isn't clicking with me.

All I can do is describe the differences in my two experiences.  If you're out there, feel free to tell me where I'm being too harsh or too lenient on either platform.

IDE's - XCode VS Eclipse

Xcode has a weird way of switching between contexts.  One minute the interface looks like this:

And the next, like this:

and sometimes there seems to be no obvious way to switch between one and the other. Technically, this isn't much different than how Eclipse displays its features across multiple perspectives (each with different visual configurations), but the saving grace of Eclipse is that it never takes away your control.  You can add, remove, and relocate a feature to any part of the IDE that you want, and you can always access a list of available perspectives.  In Xcode, I would find a way to go back to a previous screen layout, only to find it was missing a window somewhere.  Where did it go?  Did I follow the right workflow?  I have no idea.

Additionally, XCode is laid out very much like iTunes.  Aside from the sense of visual unity, I don't think there is any benefit to this decision.

Documentation

The documentation for the two platforms differ in both content and ideaology.  Here's a clip of Apple's "Getting Started" page for iOS development:

Set aside the fact that this looks like a generic search result page, and notice that the first document listed covers such topics as App Store submission.  This is supposed to be developer documentation - monetization shouldn't be the first priority for such an audience.  

Furthermore, the subsequent topics each tackle a very narrow aspect of App development.  It's important to understand Networking and Data Management, but until you understand the general structure of an application, how will you know where (and how) to apply these topics?

Ultimately, I gave up on relying on exclusively on Apple's provided documentation, and started looking elsewhere.  I found that no matter where I looked, every guide on iOS development shared an obsession with MVC design model. Let me be clear - there's nothing wrong with MVC.  In fact, it is crucial for the purpose of most apps.  But the thing about design models is that they're guidelines.  There aren't many hard and fast rules governing them.  This means that different people will interpret them differently, and and there's no way to establish a definitive, "right" way of doing something.  Breaking up your code according to the MVC model can have its benefits, but it won't magically make your code work better or run faster.  But iOS developers don't seem to agree with me on this, and so they focus on adhering to the model at the expense of explaining the actual code.  A typical line from a tutorial would read like this:

We need to start off with our Model, so here's some code that will create one for us.  Don't worry too much right now about what this all means, just know that this is how you set up Objects/variables/messages/etc in Objective C.

If there's one objective observation I can make, it is that these iOS tutorials are at a disadvantage, in that they assume (understandably) the reader is not well versed in Objective C.  They're trying to teach two things at once, and since most app developers are more interested in making piles of cash money than in learning the nuts and bolts of a programming language, the details of ObjC are deferred on as much as possible.  That being said, it is important to know why you are doing something the way you are, even if you don't entirely know how it works.  The sample applications I read through were made purposefully over complicated, and by the end of each I had no better handle on Objective C than I did before I started.

Google's Android documentation takes opposite approach.  It is clearly by developers, for developers.    If you work through the beginner guides, you'll barely see a word written about MVC.  When writing a basic app, there's not enough code to justify separating the model from the control, and the view is little more than a few lines of XML. The authors of the dev. docs understand that there's little reason to introduce MVC until there's an actual benefit to using it.  Until then, they are more than happy to help you build a simple app from the ground up.  Here is a snippet of the Android Development site:

Notice that the focus is entirely on how to build applications, with additional info on individual topics.  If you take advantage of the Android dev. docs, you can get a solid foundation upon which you can add the specific features you need.  The progression feels entirely natural.

The major disadvantage of the dev. docs is that instead of assuming you don't know the language (like Apple does with Objective C), Google assumes you're already well familiar with Java (and in some cases, the concepts behind the Android SDK).  One early tutorial (a simple notepad app) namedrops both anonymous inner classes and the Dalvik VM.  If you know what any of this means, the tutorial is a joy to work through.  If not, you may find yourself completely lost.  This isn't necessarily a good thing, but at the very least there's no mistaking who the intended audience is (and I'd still argue that the articles do a pretty good job at explaining each method call, right down to what the arguments are for).  

Final Verdict

There are a lot of idealogical differences between iOS and Android, and it isn't surprising to see them bleed into the development practices for both platforms.  That being said, the situation with iOS isn't as bad as I've made it out to be.  Apple's introductory material may be general and useless, but the full documentation set manages to cover every concept with great detail.  If you're a serious programmer, you'll sort through it all if you really want to, and I think Apple knows that.  They don't take care of this audience because they know we'll take care of ourselves if we have to.

Gunpla Chronicles - Upper Body

For reasons which will be explained later, I'm going to detail the remainder of the build process in this single post.  Apologies for the lack of photos.

Right Arm - I was a bit too tired when I assembled the right arm, and when I get tired, I tend to do things fast and sloppy.  Some of the pieces became warped at the cut points, though luckily most of these pieces were part of the exoskeleton, meaning they'd be concealed under the outer armor.  The rest of the assembly process went smoothly, which was a welcome state of affairs after the crisis I had with the leg joint.

My stickering got a lot better with the right arm.  I found myself coming up with a process; I would remove the sticker with the hobby knife, transfer it to the nail care stick, and apply to the model.  I then used the stick to reposition and set it in place.  All told, the stickering wasn't perfect (the larger decals on the shoulder mounted shield are a little off angle), but it was still a dramatic (and noticeable) improvement.

I did the entire arm in a single night, spending a little under three hours.

Left Arm


My cuts were a little less messy with the left arm, and my stickering was better still.  I'm especially proud of how I placed the decals on the spiky shoulder pad.  This is also the section where I got a lot better at sanding and filing.  I discovered that if I used a lighter touch, I could remove much of the discolored plastic. I also began to file along the length of the piece.  Previously, I'd put the tool at an angle, focusing it on the target area.  If I wasn't careful, this could cause even more damage.  I used my new skills on the scratched section of the Heat Hawk, and the results were more than acceptable.

Between the legs, arms, and weapons, this was my best work yet.  When I started writing these posts, I said that I didn't believe one could get significantly better as a builder after just one or two kits, but now I can see how wrong I was about that.  If you strive to do good work, and pay attention to your mistakes, you can make major strides after just one model.

This arm was also done in one night, though I can't recall how much time it took.

Chest


I felt more awake for building the chest than for either of the arms, yet I probably made some of the worst cuts yet.  Just like with the arm, a lot of them ended up being concealed, but there were more than enough on the visible sections.  I also got a little too heavy with the file, to the point where I started to file away otherwise good sections of a piece.  I don't think this is easily apparent anywhere on the torso, unless someone were to hold the model right to their eye.  Nevertheless, I must not repeat this performance in any future builds.

I did the chest over the course of two nights, and probably spent another three hours total on it.

Head


The head is the defining part of a Zaku, and I wanted to make sure I didn't screw it up.  I was careful to the point of paranoia, and it paid off in spades. I even managed to note and interpret the suggestion in the instruction book which said to set the red eye sticker before sticking the eye construction into the head proper.

In terms of perfection, I think this was ultimately my finest work (though due to the greater number of stickers, I'm still most proud of that left arm).  Build time was well under than hour.

 A note on topcoating


I used my entire can of paint to topcoat this model.  In fact, I barely had enough to give the head a once over.  This makes me wonder whether I didn't start with enough paint in the first place, or if I simply wasted a lot of it due to bad technique.  I don't think any of the parts wound up with a spotty topcoat, but I'd have liked to have gone over them one more time.