Can your IDE do this?

So I’m tapping out a test method in my favorite tool for developing mobile software and it looks like this:

View errorMessage = errorDialog.findViewById(findIdForStringIdentifier(ERROR_MESSAGE_TEXT));
assertTrue("Expecting a TextView field", errorMessage instanceof TextView);

Then I notice… no, scratch that I don’t even notice that auto-complete has sprung into action and is offering me the proper completion at the top of the list, “getText()”. It happens in the most subtle way as my subconscious mind already knows what it wanted to do and it directs my fingers to accept the completion. What I end up with is:

View errorMessage = errorDialog.findViewById(findIdForStringIdentifier(ERROR_MESSAGE_TEXT));
assertTrue("Expecting a TextView field", errorMessage instanceof TextView);
((TextView) errorMessage).getText()

Hi, I’m Cliff. You’re here because your IDE doesn’t do what my IDE does. I’m here because I’m ecstatic over what I’ve learned in the last 10 minutes. Look again at the above code snippets, both before and after and follow what happened in between. The important part is where the 1st line establishes a local variable of type “View”. To my amazement auto complete picked up and inferred it was a type of TextView when I started keying the 3rd line and it offered me not just any random or alphabetized list of suggestions but a preferred suggestion that matched exactly what was being conjured up in my grey matter. (For those unfamiliar with Android programming, a view does NOT include a “getText()” method.) And while I didn’t have to futz with the usual, “oh… I have to either declare my local type as a TextView or add a cast” my IDE does this inference then later performs the cast on my behalf keeping my cursor within the proper context so I can continue adding logic. It happened so “matter of fact” like and so quickly that I didn’t catch on until I had completed typing the line at which point I had to do a double take.

How does it know I need a TextView? Is it because of the preceding assert with the “instanceof” comparison? Does it just naturally assume most views will need to be eventually cast to a “TextView” type because that’s all most Android devs know how to use anyway? Is it reading through the xml layout and determining the type based on the integer id returned from my custom “findIdForStringIdentifier” that is taking a String constant id? Has Jetbrains quietly figured out how to read brainwaves over my Mac’s wifi antenna? I don’t know and I don’t really care!

I had done similar programming in other IDEs (Eclipse, Netbeans, X-Code, Visual Studio) but never have I ever had such an experience where an IDE literally read my mind, did the excessive back-spacing, parenthesis wrapping, casting, and continuation of thought for me. It’s these little nuggets that I keep finding in IntelliJ Idea that keep me addicted. I could go on for days on how wonderful this one… read it… ONE experience, out of hundreds of similar experiences, made my life today but I won’t. I’ve argued the merits of Idea to plenty of developers over the years but until you actually experience how do they put it…? “Development with pleasure” Until you actually live out a few of these scenarios you will continue to grind out code the usual way, hitting refresh/rebuild project to clear the red squiggles that really shouldn’t be there, dealing with arbitrary auto-complete suggestions, not truly being able to refactor code effectively as you could otherwise.

IntelliJ Android Test java.lang.NoClassDefFoundError: junit/textui/ResultPrinter

A short post for those who are wondering if I’m still alive. I got an error trying to run unit tests in an Android project under IntelliJ Idea and I got stumped. After a few minutes of Googling it dawned on me that I had chosen to run the test using a JUnit run configuration instead of an Android run configuration. That is when I right clicked the test method, my mind insisted on chosing the more familiar white window-looking icon with the red and green arrows instead of the Android icon, also with red and green arrows. I was associating the android icon with execute apk and not run tests. I now notice the little chevron-looking arrows and realize they refers to the red, green, refactor life cycle of development.. duh!