DaedTech

Stories about Software

By

IntelliJ IDEA: Saying Goodbye to Eclipse

I received a recommendation from Ted Young recently to try a switch to IntelliJ IDEA as an alternative to Eclipse IDE. I’ve been using Eclipse for years, but figured I’d give this tool a try, as it’s brought to you by the clever folks that make Resharper. Uncle Bob uses it in his series of Clean Code videos as well. I’ve been watching these lately, and his fluency with that IDE is making me long for something a little more… polished than Eclipse. I guess I’m spoiled by Visual Studio.

Anyway, I’ve installed the Community version of IntelliJ. Over the weekend, I spent a few hours porting my home automation project, Daedalus, to be usable by IntelliJ. Mostly, this involved turning it into a Maven project, and then ironing out a handful of miscellaneous details and quirks. I’m already much happier with this IDE than I was with Eclipse.

For starters, the Intelli-Sense (or whatever it’s called) is vastly superior to Eclipse. The static analysis for things like non-compiling code is also much snappier and prettier. And, beyond that, little things do what I’m used to from Visual Studio (e.g. ctrl-tab between code files). It’s weird, but a few things like that here and there really add up to being happier with the user experience. Using IntelliJ feels like coming home, which is impressive, since I’ve never used it (and I don’t even use ReSharper). Color me impressed.

Here is a handful of other miscellaneous observations so far:

  • Ctrl-W and Ctrl-Shift-W widen and narrow selected scope, respectively (equivalent of the numpad + and – in CodeRush).
  • Getting my black background seemed pretty tedious. I didn’t discover until the end that if I set some high level setting with black background, that mostly became default.
  • On the flip side, the color scheme in there is awesome – I can vary RGB ratios and darkness independently, meaning I can keep the default color scheme, but make all the foreground colors a lot lighter so they show up on black.
  • If you download the Community (read: free) version, bear in mind that you get no server integration. It took me a long time to figure out that I couldn’t integrate Tomcat as that’s only for the pay-to-play version
  • The last bullet isn’t a major hindrance. I just set up an Ant build to deploy a WAR file and set the Ant build up to run after successful compile when I want to deploy. The only thing I lose is the ability to start Tomcat in the IDE and browse in the IDE but both of those were pretty flaky in Eclipse anyway. Keeping a browser window open isn’t the end of the world.
  • When I go to commit to SVN, a window pops up with code analysis messages, giving me what I assume is the Java equivalent of StyleCop or FX Cop. This is pretty awesome since my idiomatic Java is pretty rusty. I imagine this will help shake off some of that rust.
  • Still haven’t worked out all of the shortcuts for running tests in TDD. Options seem better than Eclipse, but I still have to tame them.
  • The project/module definition in place of Eclipse’s workspace/project definition is a little odd, but whatever.

That’s about it, so far. I’ll probably have more posts to add as I go. I wish I had documented and blogged about the conversion from Eclipse, as that was relatively straightforward, but with a few gotchas, since I didn’t have Maven set up for Eclipse and I did have the Spring/Tomcat/Jstl dependencies. Thing is, I kind of started off not thinking I was actually going to switch and just doing some exploratory puttering, so I didn’t get into the documentation mindset until it was too late. Oh well, c’est la vie. If anyone’s curious about anything I did, please feel free to comment or shoot me an email.

At any rate, I think I’m probably going to close the books on Eclipse. I suspect that my only future debate here is whether or not to upgrade to the paid Ultimate version of IntelliJ. Given that I alternate between .NET and Java, the relative synergy between IntelliJ and Visual Studio is simply too huge an advantage to pass up. I realize that Eclipse probably has a richer plugin library, but to be honest, my opinion of Eclipse has always more or less been “meh, it works, I guess”, rather than “ooh, this is nice!” After even just a few days with IntelliJ, it’s hard to see myself going back.

By

JSTL Core ForEach Loop

Today, I was pleasantly surprised at how easy a time I had setting up some JSP pages to interact with my ongoing Java/Spring MVC home automation server. I seem to remember the setup for this being annoying in a past Java life, but my experience today was the opposite. So, here is a brief summary of what I did.

My plan is to install MongoDB to store the data that I’m going to use. I don’t know if this is the right choice, but it seems like a lightweight one in that I can always go “heavier” with a RDBMS later, if that seems warranted. There’s also a bit of a “let’s try it out” motivation for me in that I can add another tool to my toolbox in the process. But, that’s a task for another time (and probably another post). For now, I’m going to mimic having a persistence structure with the following java class:

Read More

By

JUnit for C# Developers 4 – BDD, Mocks, and Matchers

This is yet another in my series of posts on using JUnit from the perspective of a C# developer.

Goals

Today, I have the following goals in my quest for JUnit TDD proficiency.

  1. Use a BDD-style testing scheme with nested classes.
  2. Use mocking framework to verify method call
  3. Use mocking framework to verify method call with parameters.

Getting to Work

First up, I’d like to see how to employ the test organization scheme described in this post by Phil Haack. The idea is that rather than simply having a test class per class under test, you’ll have a test class and nest within it a sub class for each method in the class under test.

Under Drew’s system, I’ll have a corresponding top level class, with two embedded classes, one for each method. In each class, I’ll have a series of tests for that method.

When you look at this in the test-runner, you see the same descriptive name, but the tests are better organized and can be run at another level of granularity. I’ve come to favor this style when I’m writing code in C#, and I thought I’d see how well it ported to JUnit. As it turns out, the test runner ignores the tests if you simply stick them in sub-classes. I poked around a little and discovered a post by Joshua Lockwood where he had the same idea and found a solution. I tried this out and it got me almost all the way there. I did need one minor tweak, however. (His post was written in 2008, so plenty may have changed in the interim). The “Enclosed” class that he uses required me to import “org.junit.experimental.runners.Enclosed”. By adding this line, I was off and running (though I did have to manually add the import as the IDE didn’t seem to find it):

Notice the class annotation and the new static nested classes. These nested classes do have to be public and static for the scheme to work. In addition, it seems that once you use the “Run With Enclosed” paradigm, all tests must be in enclosed static classes to run. If you had some defined in the test class itself, the test runner would ignore them.

So, now that organization is better, onto more concrete matters. I now want to use my mocking framework to verify that a method was called. I want to add a method to the controller that takes a room name, a light name, and a text command (“on” or “off”) and issues a command to the service based on that. Using Mockito, I wrote the following test:

The statement at the end is the equivalent of the “assert” here. I start out by building a mock using Mockito, and then I hand it to my overloaded builder, which injects it into my CUT. I perform (or will perform, since this method isn’t yet defined) an operation on the controller, and then I want to verify that performing that method resulted in a call to the interface’s toggleLight() method. The “any” parameters are known as “matchers” and they can be used in tests not just to see if a method on a collaborator was called, but with what kinds of parameters.

In the C# world, I use Moq and am a big fan of it. If you use this in C#, this whole paradigm should look pretty familiar. We create a mock, inject it, manipulate it, and verify it. Verify here is a static method that takes the mock as an argument, rather than an instance method of the mock, and mock creation is the same, but beyond that, these constructs look very similar, right down to the static “any()” methods for argument matching.

My final goal was to get to the point of using the aforementioned matchers to make sure the service methods were being invoked as I envisioned. To make the last test pass, I wrote the following “simplest possible” TDD code:

Since the unit test allowed for any Light object and any boolean to be the parameters, I opted for null and false, respectively. Doesn’t get much simpler than that. To advance my goals a bit, I know that when the command string passed to the method is “on”, I want to call the service with boolean parameter true. So, let’s see how that test would look:

It’s a nearly identical test, but this time around, notice that I’ve traded “anyBoolean()” for “eq(true)”. Now this test will only pass if the toggleLight() method calls the service with boolean true. the eq() static method returns a matcher for a specific value. Getting all tests to pass is pretty straightforward here:

Obviously, this method is pretty obtuse and needs some work, but I’ll get to that in the “off” command parameter case. The beauty of TDD is that you go from obtuse to rigor and accuracy by adding only the complexity you need in order to satisfy the next requirement. So, to recap, here is the current state of affairs of the controller:

and the test class:

By

Basic Unit Testing with JUnit for C# Developers 2

Last night, I posted about my adventures with TDD in Java from a C# developer’s perspective. As I start to shake my Java rust off a bit, I’m enjoying this more and more, so I think I’ll keep this series going for at least a bit, documenting some of my trials, travails, successes and failures. I don’t know that I intend to turn this into a long-running series, but I’m hoping to throw enough up to get a test-conscious C# developer off and running with Java.

Briefly, Some Good References

So, as part of this adventure, and to get off on the right foot, I’ve been referencing some external information. James Shore has been working on his blog series, “Let’s Play TDD” for over a year now. This is an excellent idea for those trying to get familiar with TDD as a practice. For me, I’m more interested in seeing the simple mechanics of testing in Java, such as where the handiest place to put the JUnit window is. Seriously. It sounds lame, but watching video of someone unit test in Eclipse is incredibly helpful for showing me little details that I’ve been missing and wouldn’t have thought to google.

Another reference is Jakob Jenkov’s tutorial on reflection for Java annotations. If you’ll recall, I mentioned this last time and, as it turns out, this, like many thing in life is possible. So, on that note and without further ado, here’s some code!

And Now For the Code!

These are two new tests that I added. The first one reflects on the light controller class, seeing if the light() method has an annotation of type RequestAttribute. The second test takes it a step further and sees if the first value of request mapping is “/light” (this is the base URL to which I’m going to map).

And, here is the updated code that this drove:

All I added was the annotation to light(). And this, unlike the last, more contrived example, I did in true TDD fashion. At this point, I should mention that I found a stack overflow question about whether or not testing for the presence of annotations made sense. Accepted answer seemed to say that it’s fine with a couple of dissenting responses below that.

Personally, as a mild digression, I find the dissent baffling, particularly if those people are familiar with TDD. I’m looking at my light controller class, which needs an annotation to work properly within the Spring MVC framework. It doesn’t currently have one. So… case closed. If I’m following TDD in earnest, I cannot go adding this without a red test. Uncle Bob is pretty clear on this point in his three rules of TDD: “You are not allowed to write any production code unless it is to make a failing unit test pass.” Now, I fancy myself more purist than pragmatist, so the reasoning behind this that speaks to me is that this is a testable alteration I’m making to my class, so why wouldn’t I test it?

Java-Things I’ve Learned

Here are a few random things I learned during tonight’s foray into Java TDD:

  • A more traditional import for asserts is org.junit.Assert.*;
  • “import static” versus just import allows me to use static methods without a qualifying type or being a child class of the class containing the static method. This feels icky to me, like C# extension methods, but I’m grudgingly using it for now with my tests and assert (I may revert to traditional import).
  • Java has a foreach loop: (for myString : someStringArray). During my last go-round with Java, I’m pretty sure that this didn’t exist yet.
  • Java has isinstanceof keyword. For my fellow C# travelers, here is your version of if(x is Foo)

By

Basic Unit Testing with JUnit for C# Developers

As I’ve blogged previously, I’ve become increasingly dependent on TDD to the point where I’m basically addicted to the practice. I start to get nervous and twitchy if I’m writing code that isn’t driven by tests — it feels like putting a mop into a bucket of filthy water and then using it to ‘clean’. In other words, writing code without tests feels like pushing dirt around aimlessly while having no positive effect.

But, I digress. The purpose of this post today is to document my implementation of TDD in Java using JUnit, coming from two solid years of almost exclusive C# work. So, bear in mind that I may make some mistakes here or violate some best practices (and feel free to comment and correct me), but it’s my hope that I get the basics right and perhaps can help someone else going from C# to Java.

First Things First

I won’t go into a lot of detail here, but I’m using Eclipse and have set myself up for Spring development. I had created a small, working Spring web app, and I had a little code here, but wanted to test first with any new code. To do this, I followed my C#/Visual Studio instincts and went to create a separate project containing my tests. About 85% of people from a smattering of languages favored this approach in a poll by Phil Haack, and the approach earned an answer and a vote, if not top honors, on stackoverflow.

When you go this route in Eclipse, there is no JUnit project to create, so you just create a standard java project. I did this and populated it with a directory structure mirroring that of my actual application, putting the tests in the ‘same’ package as their class under test counterparts. And then, really all that was needed was to import the org.junit.Test library which, apparently, was already wherever it needed to be (I realize that this is not helpful if you don’t have it, but this really isn’t the emphasis of this post).

Onto the Tests

The first thing I did was to create a class called LightControllerTest, as I was interested in creating a LightController class. And, I need that class to have a method called light() that would return a ModelAndView. So, I created the following test:

A few things to note here, fellow C# developers. One is that the equivalent of MSTest [TestMethod] is the java @Test annotation. This tells the test runner that this is a unit test. Another thing to note is that I’m using the spring framework’s assert, which may not be applicable if you’re not using Spring MVC. There is also JUnit’s assert available to you. I chose the Spring one because it had isInstanceOf(), which reminded me of MSTest’s “Assert.IsInstanceOfType()”.

So, with my test written and not compiling, I wrote the following code:

Now, I was primed to have a red test instead of a non-compiling one, but I needed to run the test itself. In Eclipse, there are various ways of doing it, but the closest I could come to Ctrl-R, T was Alt-Shift-X, T. Good enough – that seems to scope them the way MSTest does as well, with only the one test running, even though I defined another in a different class. But, as with Visual Studio, there are a number of different ways to run the tests — from the little green “play” button dropdown, from the context menu right clicking on the project, from within the JUnit window that appears once you run the tests, etc. So, I ran the test, saw it fail, and deleted the return null line in favor of the one that would make it pass. A little contrived, I realize, but you’ll have to cut me a bit of slack as I iron out the early kinks. Later, I’ll write tests that fail before they pass — I promise.

I’ll have to play for a bit to get myself really familiar with the ins and outs, and I’ll probably follow with more posts like this. I’m also going to be muddling my way through other random issues like “is it appropriate (or even possible) to test that a method is annotated” and “is there anything like NCrunch for Java/Eclipse”? Stay tuned! :)

By

Adding a Google Map to Android Application

I’m documenting here my first successful crack at adding a google map to an android application. Below are the steps I followed, with prerequisite steps of having the Android SDK and Eclipse installed, and being all set up for Android development (documented here).

  1. Created a new Android project
  2. Navigated to Help->Install New Software in Eclispe.
  3. Added a new source with URL http://dl.google.com/eclipse/plugin/3.7
  4. Selected all possible options (why not, right?) to have access to the google API in general.
  5. This install took about 5 minutes, all told, and I had to restart Eclipse
  6. In my new project, I navigated to project properties and went to Android, where I selected (the newly available) “Google APIs”
  7. From here, I got excited and ran my project, and was treated to a heaping helping of fail in the form of an error message saying that I needed API version 9 and my device was running API version 8 (Android 2.2.1). I fixed this by opening the manifest and changing the uses-sdk tag’s android:minSdkVersion to 8. Then when I ran, I had hello world on my phone. (Later, when all was working, I just deleted this line altogether, which eliminated an annoying build warning)
  8. With that in place, I added the node

    to my application node in the same manifest XML file.

  9. Then, as I discovered in an earlier post, I had to add
  10. From there, I followed the steps in this tutorial, starting at number 4.
  11. One thing to watch for in the tutorial is that you should add the lines about the map view after all boilerplate code already in onCreate or mapView will be set null and you’ll dereference it.

With all of this, if you ignore the bit about the API key, what you’ll wind up with is a map with no overlay on your phone. That is, it looks like everything is normal, including zoom icons, but the map hasn’t loaded yet. This was the state I found myself in when I decided that I’d take the last step and get the API key. This was not at all trivial.

I understand that if you’re familiar with the concept of signing software for distribution in app market, this probably makes sense. But, if this isn’t something you’ve been doing, it comes straight out of left field and, what’s more, there was no real place where how to do this was described in any detail. So, I’ll offer that here.

  1. Navigate to your JAVA_HOME bin folder (wherever your java and javac executables are)
  2. Run the command
    keytool -v -list {keystore}

    . The -v is important because this gives yo all the fingerprints (the default is SHA1, which won’t help you in the next step — you want MD5). The keystore is going to be debug.keystore, which is what your device uses for signing when you’re developing and not releasing. For me, this was located in C:\documents and settings\erik\.android on this win XP machine (YMMV with the directory)

  3. What you’ve done here is generated a fingerprint for the developer debug keystore that Eclipse automatically uses. This is fine until you want to deploy the app to an app store, at which time you’ll have to jump through a few more hoops.
  4. Take the key that this spits out and copy it (right click and select “mark” in cmd window), and paste it into the “my certificate’s MD5 fingerprint” text box here: http://code.google.com/android/maps-api-signup.html
  5. This will give you both your fingerprint, and an example layout XML to use in your Android map project
  6. Copy this into your project’s layout, following the guide for naming the attribute that contains the key. (That is, find your layout’s com.google.android.maps.MapView node and set its android:apiKey attribute to the same as the one on the page you’re looking at.
  7. Once you’ve got this, you can paste it into your map layout, run your app (phone or emulator) and get ready to start navigating to your heart’s content

After I went through all this, I found this clearly superior tutorial: http://mobiforge.com/developing/story/using-google-maps-android. This is really great for getting started, complete with code samples and starting as simple as possible.

By

Compiling XML! (Not really)

So, here’s another one filed in the “hope this saves someone some grief” category. I was cruising along with my home automation ‘droid app, setting my layouts and wiring up my button click handlers, when all of a sudden, I was getting weird build errors about. I couldn’t run or even build. When I tried to build, I got messages about different things being redefined in my main XML layout file. This was strange, since I hadn’t edited it directly, but was using the graphical layout tool.

As I inspected the errors more closely, I began to understand that there was apparently some rogue XML somewhere. A bug in Eclipse? With the Android SDK plugin? Had I been hacked by someone with a very strange set of motives? I opened up my layout folder and this is what I saw:

Wat?

After some googling around and experimentation, I discovered that this file is generated if you run with the Play icon and the XML file open as your selected window in the editor. Perhaps that’s something that Eclipse users are used to, but coming from a pretty solid couple of years of Visual Studio, this had me mystified. So, lesson learned. Don’t run if you have XML open in Eclipse (or anything else you don’t want slapped with a .out between filename and extension and apparently included in compilation.

Cheers :)

By

Re-Learning Eclipse

Recognizing and Understanding My Irritability

I’ve been dabbling off and on in Android development lately. For a long time, I used Eclipse on a regular basis and got to know the ins and outs of it quite well, but as a look at my tag cluster will tell you, Visual Studio has been my main IDE over the last couple of years. The result is that my Eclipse skills are getting as rusty as my Spanish (fluent enough to read novels when I was 20, rusty enough to struggle reading the blurbs about movies on Spanish language channels now). So, picking it back up is an experience in annoyance. I now expect everything to work the way Visual Studio does. That’s kind of ironic since when I first switched over to Visual Studio, I downloaded this plugin, called “AsEclipse.”

As a user, I’m entirely justified. Jakob Nielsen describes the effect of user annoyance.

Annoyances matter, because they compound. If the offending state-field drop-down were a site’s only usability violation, I’d happily award the site a gold star for great design. But sites invariably have a multitude of other annoyances, each of which delays users, causes small errors, or results in other unpleasant experiences.

Even if no single annoyance stops users in their tracks or makes them leave the site, the combined negative impact of the annoyances will make users feel less satisfied. Next time they have business to conduct, users are more likely to go to other sites that make them feel better.

He’s talking about E-commerce websites specifically, but I believe the same wisdom applies to any application. User annoyances add up. If you’re a Windows user used to Mac or vice-versa, weird little things happen that run counter to what you expect. The thing that you think closes a window toggles or maximizes it. The hot-key that you punch has no effect. You’re pissed off before you even realize it. Same thing happens with competing IDEs.

Getting Zen

So, rather than let myself get annoyed, I’m going to document some things here to help me remember how to do things in Eclipse that I take for granted in Visual Studio — to retrain my fingers and brain a bit. I’m going to be keeping this page open as I work, and I’m hoping others find it useful as well. So, without further ado, here is a list of shortcuts/techniques:

  • Switch between files (ctrl-tab in VS): Ctrl-F6 or Alt-Arrow. (Note, this doesn’t rotate through like VS, but switches between most recent, ala Notepad++
  • Resolve reference (Ctrl-Shift-Period in VS): Ctrl-Shift-M
  • Camel-Case Tabbing: Ctrl-Alt-Arrow (with CodeRush anyway): Ctrl-Arrow.
  • Build (Ctrl-Shift-B in VS): Ctrl-B
  • Auto-comment method (/// and then space in VS): Alt-Shift-J
  • Comment block (Select and press “/” with VS/CodeRush): Select and press Ctrl-/.

I’ll probably come back and add to this list as time goes on, but I figured I’d get it started. Hopefully you find it helpful too. Also, please, by all means, add any additional ones to the comments here, and I’ll add them to this list as well.

By

Getting Started With Android Development

I posted some time back about developing for Android and getting set up with the Android SDK, the Eclipse plugin, and all that. For the last six months, I haven’t really had time to get back to that. But now I’m starting to delve into Android development in earnest, so this (and potentially other upcoming posts) is going to be about my experience starting to write an Android application. I think I can offer some interesting perspective here. I am an experienced software developer with breadth of experience as well as depth in some technologies, but I am completely new to Android SDK. Hopefully, my experiences and overcome frustrations can help people in a similar position. This also means that you’d be learning along with me–it’s entirely possible that some of the things I post may be wrong, incomplete, or misguided in the beginning.

This post kind of assumes that your knowledge is like mine. I have a good, if a bit rusty from a year and a half of disuse, working knowledge of Eclipse and J2EE development therein. I’m also familiar with web development and WPF, so the concept of object-oriented plumbing code with a declarative markup layout for the view is quite familiar to me.

Notes about Setup

Just as a bit of background, I do have some things set up that I’m not going to bother going through in this particular post. I have Eclipse installed and configured, running on a Windows XP Pro machine. I also have, at my disposal, a Samsung Epic 4G running Android 2.3. (I forget the name of the food that accompanies this version, and, to be perfectly honest, something strikes me as sort of lame about naming your releases after desserts. Different strokes, I guess.) I also have installed ADB and the drivers necessary for connecting my computer to my phone. And finally, I have the Android virtual machine emulator, though I think that just comes with the Eclipse SDK plugin or something. I don’t recall having to do anything to get that going.

Creating a new Android project

One of the things that’s difficult when you’re new to some kind of development framework is separating what actually matters to your basic activities and what doesn’t. Any framework-oriented development, in contrast to, say, writing a C file and compiling it from the command line with GCC, dumps a lot of boilerplate on you. It’s hard to sort out what actually matters at first, especially if your “training” consists of internet tutorials and trial and error. So I’m going to note here what actually turned out to matter in creating a small, functional app, and what didn’t so far.

When you create a new project, you get a “SRC” folder that will contain your Java classes. This is where you’re going to put a class that inherits from “Activity” in order to actually have an application. I’ll get to activities momentarily. There’s also a “Gen” folder that contains auto-generated Java files. This is not important to worry about. Also not important so far are the “assets” folder and the Android2.1-update1 folder containing the Android jar. (Clearly this is quite important from a logistical perspective, as the Android library is necessary to develop Android apps, but it makes no difference to what you’re actually doing.)

The res folder is where things get a little interesting. This is where all of the view layer stuff goes on. So if you’re a J2EE web developer, this is the equivalent of the folder with your JSPs. If you’re a WPF/Silverlight developer, this is the equivalent of a folder containing your XAML. I haven’t altered the given structure, and I would’t suggest doing it. The layout subfolder is probably the most important, as this is where the actual view files defining UI components in XML go. In other subfolders, you’ll find places where your icon is defined and where there are centralized definitions for all display strings and attributes. (I haven’t figured out why it’s necessary to have some global cache of strings somewhere. Perhaps this is to take advantage of some kind of localization/globalization paradigm in Android, meaning you don’t have to translate yourself for multi-lingual support. Or maybe I’m just naively optimistic.)

The other thing of interest is the AndroidManifest.xml. This contains some application-wide settings that look important, like your application’s name and whatnot. The only thing that I’ve bothered so far to look at in here is the ability to add an attribute to application called “android:debuggable=”true”. Apparently, that’s needed to test out your deployable on your device. I haven’t actually verified that by getting rid of the attribute, but I seem to recall reading that on the Android Dev forum.

Those are all of the basic components that you’ll be given. The way that Android development goes on the whole is that it is defined in terms of “Activities.” An activity can loosely be thought of as a “screen.” That is, a very basic application will (probably, unless it’s purely a background service) consist of one activity, but a more complex one is going to consist of several and perhaps other application components like services or content providers. Each activity that you define in your application will require a class that extends the “Activity” class and overrides, at least, the “OnCreate(Bundle)” method. This is what you must supply to have a functioning application–at the very least, you must set your activity’s content.

To summarize, what you’re going to need to look at in order to create a hello world type of app on your phone is the Java file you’re given that inherits from activity, the main.xml file in layout, and the manifest. This provides everything you need to build and deploy your app. Now, the interesting question becomes “deploy it to where?”

Deployment – Emulator and Phone

I quickly learned that the device emulator is very, very slow. It takes minutes to load, boot, install your deployable in the virtual environment. Now, don’t get me wrong, the VM is cool, but that’s fairly annoying because we’re not talking about a one-time overhead and quick deployment from there. It’s minutes every time.

Until they optimize that sucker a little, I’d suggest using your phone (or Android tablet, if applicable, but I’m only going to talk about the phone) if it’s even remotely convenient and assuming that you have one. As I discovered, when you run your Eclipse project as an Android app, assuming you’ve set everything up right, the time between clicking “run” and seeing it on your phone is a couple of seconds. This is a huge productivity improvement and I didn’t look back once I started doing this.

Well, let me qualify that slightly. The first time I did it, it was great. The second time I deployed, I got a series of error messages and a pop up asking me to pick which deployment environment I wanted: the emulator or my phone. I wanted my phone, but it was always shown as “offline.” To counter this problem, I discovered it was necessary to go on the device itself and, under “Settings,” set it never to sleep when connected. Apparently, the phone going to sleep sends the ADB driver into quite a tizzy. If you have hit this, just changing the setting on your phone won’t do the trick. You’ll need to go into the platform-tools directory of wherever you installed the Anrdroid SDK and run “adb.exe kill-server” followed by “adb.exe start-server”. For you web devs out there, think of this as clicking on the little tomcat dude with the stop and then the little tomcat dude. :)

Now with this set up, you should be able to repeatedly deploy, and it’s really quite impressive how fast this is considering that you’re pushing a package to another device. It’s honestly not noticeably different than building and running a desktop app. The server kill and start trick is useful to remember because there is occasional weirdness with the deployment. I should also mention a couple of other things that didn’t trip me up, but that was because I read about them in advance. To debug on your phone, the phone’s development settings need to be configured for it. In your phone’s settings, under “Applications,” you should check “Allow Installation of Non-Market Applications” and, under “Debugging,” check “USB Debugging”. (On my phone, this is also where you find “Stay Awake,” which caused the problem I mentioned earlier, but YMMV.)

Changing the Icon

One of the first things that you’ll notice is that your “Hello World” or whatever you’re doing deploys as the default little green Anrdoid guy. Personally, when I’m getting acquainted with something new, I like to learn about it by changing the most obvious and visible things, so very quickly I decided to see how changing the icon worked. In your “res” folder, there are three folders: “drawable-hdpi”, “drawable-ldpi”, and “drawable-mdpi”. A little googling showed me that these correspond to high, low, and medium resolution phones. Since Android developers, unlike their iOS counterparts, need to worry about multi-device support, they need to have a vehicle for providing different graphics for different phones.

However, at this point, I wouldn’t (and didn’t) worry about this. I took an image that I wanted to try out as my icon and put it into these folders, overwriting the default. Then, I built and I got some error about the image not being a PNG. Apparently, just renaming a JPG “whatever.png” isn’t enough to trick the SDK, so I opened it in MS Paint and did a “Save As,” selecting file type PNG. This did the trick. As best I can tell, your icon will be capped in size, so it’s better to err on the side of making it slightly too big.

Changing the App Name

When I set all this up last winter, I followed a tutorial that had me build an app called “SayHi”. I was trying to prove the concept of taking an Eclipse project and getting it to run something, anything, on my phone. As such, when I picked it back up and started playing with it, the app was still called “SayHi”. However, I don’t want this app to say hi. It’s actually going to be used to turn lights on and off in my house in conjunction with my home automation. So, I’d like to call it something catchy–something imaginative, you know, like “Light Controller.”

This is actually refreshingly easy for someone who has been working with Visual Studio and Clear Case–a tandem that makes renaming anything about as convenient as a trip to the DMV. Under “res->values,” open the “strings.xml” file. You’ll have tabs at the bottom to view this as raw XML or as a “Resources” file. Either way, the effect is the same. You’ll change the “app_name” string to the value that you want, and that’s it. On the next deployment to your phone, you’ll see your app’s new name. Pretty cool, huh? Two easy changes without any code or having an app that actually does anything, and it at least looks like a real app until you open it.

At this point, I should probably mention something that may not be familiar to you if you’re just getting started. In Eclipse and with the Android SDK, you have various options for how you want to view the XML files. The manifest one seems to have a lot of options. The strings one has the XML versus resource choice. From what I recall, this is a feature of Eclipse in general–I believe plugins can supply their own view of various file extensions. If you want to see what all is theoretically available for any file, XML or not, right click on it and expand “Open With.” That’ll show you all the options. It’s important to remember that even though you may get defaulted to some kind of higher level, GUI-driven editor, you always have the raw text at your disposal. Having said that, however, my experience editing layouts taught me that, for beginners, it’s a lot easier to use the SDK’s layout editor. You’ll save yourself some headaches.

This post has gotten pretty long, so I’ll save my adventures with layouts and GUI components until next post.

Acknowledgements | Contact | About | Social Media