Android: The New Container

In the early days of Java Servlet development back in 1996 we had very little tool support. As the tools evolved the teams I was a part of started incorporating multiple build paths. The code was built in the IDE, but it was also built on the desktop using ant. This was good because the developers were building the same way as Cruisecontrol.

I think Android is going to be no different. I see a strong correlation between writing and testing servlets to run in the J2EE container and writing GUI and services for Android. For me this is marking a return to a platform with week tool support. The weakness I'm first percieving is unit testing. I have not yet found how to press one button to run all the tests. That is, one button press will launch the emulator (if needed), hot deploy the code to the container/emulator, and execute the in-container tests. Then there is the out-of-container tests that have no dependency upon the container.

Google Docs Publish to Blog Feature

My Android & Mockito post came from Google docs - publish to blog - feature. I had much higher expectations that the formatting wouldn't get mangled. My code segments lost their indent! I must have missed some requirement. Just my style to initially think I've done something wrong or the problem would have been fixed by now. I'll think that way until I prove myself wrong, and so doing prove myself right -- that I used the feature right.

Android & Mockito

During the day I'm a mild mannered (debatable) Java developer currently paid to work on a multi-threaded server with it's own RCP client. This is important because I've started to pick up some habits from that team. One habit in particular is the importance of using a mocking framework. The day job uses jMock. I find the expectations blocks clumsy things that run against the flow of a non-mocking JUnit test. As a result I've started using Mockito on my own projects. I try to avoid theological debates out this framework or that. It's more important that I like the public interface. It doesn't decrease the value of a mocking (or stubing) framework.

My wife recently encouraged me to buy an HTC G1 phone. She's great, isn't she! Two days later, I'm using the development kit, working on my first application. After poking around at the API, and getting the lay of the land it was time to get serious and understand how to interact with the platform. To that end I need to write some unit tests.

So I want to write a unit test for an implementation of android.view.View.OnClickListener. The interface has only one method, no surprise here, it's an onClick method: "public void onClick(View view)". Here's my implementation:

class MyOnclickListener implements OnClickListener {
public void onClick(View view) {
Intent intent = new Intent("a.unique.string");
intent.addCategory(Intent.CATEGORY_DEFAULT);
activity.startActivityForResult(intent, 1);
}
}

What the "activity.startActivityForResult" method does is not germane to this story. Just know that I need a test that makes sure that method is called with the right Intent. How do I know it's the right Intent object? So here's my first pass at a test:

@Test
public void onClick_WithRealIntent() throws Exception {
Activity mockActivity = Mockito.mock(Activity.class);
View mockView = Mockito.mock(View.class);

MyOnclickListener testObject = new MyOnclickListener(mockActivity);
testObject.onClick(mockView);

Intent expectedIntent = new Intent("com.google.zxing.client.android.SCAN");
Mockito.verify(mockActivity).startActivityForResult(expectedIntent, 1);
}

I'm betting here that the Intent object has an equals method based on that constructor argument. But running this test fails horribly. Now, I should note that in RCP fashion I've created a separate project to hold my unit tests. So the test project (in Eclipse) depends on the "real" project. Both projects have the android buildSpec and nature.

#
# An unexpected error has been detected by Java Runtime Environment:
#
# Internal Error (434C41535326494C453041525345520E4350500B65), pid=14086, tid=3084753808
#
# Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
# An error report file with more information is saved as hs_err_pid14086.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

So I poke around after the crash file reveals little to no details of what happened. And low, and behold, there is evidence that android junit run configurations fail by default. So we have to edit the run configuration as suggested and try again. I'll point out that I'm not exactly as they suggest. I'm using Junit4, my bootstrap classpath is only the JRE library, and I added android.jar to the UserEntries under the default classpath.

java.lang.RuntimeException: Stub!
at android.content.Intent.<init>(Intent.java:27)
...

Argh! What's that mean! We could take a look at the android source code to see what happens on Intent.java:27. Our implementation class will still have to call "Intent intent = new Intent("a.unique.string");". Now comes in another habit picked up from the day job. I'm still not sure if this habit is a good one. When dealing with the JMock tests for the projects server there is a series of "provider" classes. These are really simple factory pattern classes that don't have any logic, they just new up an object, they they provide instead of factor(y). Here's what I mean:

public class MyOnclickListener implements OnClickListener {
private final Activity activity;
private final IntentProvider intentProvider;

public MyOnclickListener(Activity activity) {
this(activity, new IntentProvider());
}

MyOnclickListener(Activity activity, IntentProvider intentProvider) {
this.activity = activity;
this.intentProvider = intentProvider;
}

public void onClick(View view) {
Intent intent = intentProvider.provideIntent();

activity.startActivityForResult(intent, 1);
}

static class IntentProvider {
public Intent provideIntent() {
Intent intent = new Intent("a.unique.string");
intent.addCategory(Intent.CATEGORY_DEFAULT);
return intent;
}
}

That package visible constructor is for our test. Now our test can use a mock Intent because the test is going to provide a mock IntentProvider:

@Test
public void onClick_startsActivity_WithTheRightIntent() throws Exception {
Activity mockActivity = Mockito.mock(Activity.class);
Intent mockIntent = Mockito.mock(Intent.class);

Mockito.when(mockIntentProvider.provideIntent()).thenReturn(mockIntent);

MyOnclickListener testObject = new MyOnclickListener(mockActivity, mockIntentProvider);
View mockView = Mockito.mock(View.class);
testObject.onClick(mockView);

Mockito.verify(mockActivity).startActivityForResult(mockIntent, 1);
}

and now we have a green bar. But at what cost? This is an important question. We just created a constructor and an inner class JUST FOR THE TEST. Those two elements doubled the amount of code in MyOnClickListener! This is not the end. I'll contiue to analyze this issue.

ThinkPad Dual Screen

I needed to use the VGA output on my Thinkpad to give a demonstration on Java Connector Architecture. A very short search later led me to this forum posting http://ubuntuforums.org/showthread.php?t=346555 that has a link to this http://ozlabs.org/~jk/docs/mergefb/.

Now I can use xrandr to turn on and off rudimentary screen mirror.

xrandr --output VGA --auto
xrandr --output VGA --off

I'll update here when I successfully get the desktop spread across both screens. As a word of warning, I just turned of xrandr VGA output (--off) and all running applications were locked. I could swap focus between them but the applications themselves did not respond. Beware.

When Did I Start Work Today (linux)

When working in Windows (XP at least) it's an easy matter to jump to the event viewer security log to see when you first authenticated this morning. Here's a handy way to get the same information from Linux. Just replace the [your.user.name.here] with the name with which you authenticate.

su -
grep pam.*[your.user.name.here] /var/log/messages

Pretty Print XML in Java

Something I keep forgetting how to do. Obviously something would need to be done to make this any sort of utility class. This is simply an example of the classes that can be used to perform pretty print of an xml string. There are many more ways to get the actual string from a file or Document.

import java.io.ByteArrayInputStream;
import java.io.InputStream;
import java.io.OutputStream;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.Document;

public class XmlTest {

 public static void main(String[] args) throws Exception {
  String xmlString = "<tag><nested>hello</nested></tag>";
  DocumentBuilder documentBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();

  InputStream inputStream = new ByteArrayInputStream(xmlString.getBytes());
  Document document = documentBuilder.parse(inputStream);

  XmlTest xmlTest = new XmlTest();
  xmlTest.serialize(document, System.out);

 }

 public void serialize(Document doc, OutputStream out) throws Exception {

  TransformerFactory tfactory = TransformerFactory.newInstance();
  Transformer serializer;
  try {
   serializer = tfactory.newTransformer();
   //Setup indenting to "pretty print"
   serializer.setOutputProperty(OutputKeys.INDENT, "yes");
   serializer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", "2");

   DOMSource xmlSource = new DOMSource(doc);
   StreamResult outputTarget = new StreamResult(out);
   serializer.transform(xmlSource, outputTarget);
  } catch (TransformerException e) {
   // this is fatal, just dump the stack and throw a runtime exception
   e.printStackTrace();

   throw new RuntimeException(e);
  }
 }
}

I drafted this description of services to give non-technical individuals understanding of the services of a Service Oriented Architecture (SOA). I refined it a smidge here from its original context. It is not a complete, thorough example. It focuses on giving a definition to the word service.

We use services everyday. An example is that you don't have to be a barista to drink an espresso. You simply order, pay, and enjoy your beverage. This analogy has a good correlation with the service orientation of software architecture. In software we call this a black box. You don't know what happens inside the box. You put in money and espresso comes out. A service consumer needs no knowledge of how a provider has implemented a service. The Consumer need only know the input required and output expected from the service. In our example of the espresso service, a barista takes money as input and outputs espresso. As a consumer, I need not know how to grow, harvest, roast, and brew coffee beans.

There are cost and quality aspects to consider. How much will it cost the service consumer, who has no prior knowledge of coffee beans, to go from plant to espresso? Would the quality be the same as when the coffee experts do the same thing? Clearly the answer is to leave espresso and the service logic to the experts. This frees each consumer to put full effort into their own area of expertise.

Welcome and Thank You

There is such a wealth of information on the internet. I am continually amazed. I have such an expectation that someone else already gave a good answer for any question, that I won't need to provide answers of my own. I do however need a space where I can catalog the answers I have found. Who knows, maybe I'll eventually find a topic that I can provide a novel approach to solving. Should it happen I can use this space to share and give back to the community from which I have gained so much.

So I say welcome to my blog. I also say thank you. Thank you, internet, for all the answers past, present, and future.