MonoDroid: XML Layout Not Created in Resource.Designer.cs

I’ve started diving into MonoDroid a little bit, and I was following the directions here to create a ListView. The first step is to create a layout for each of the ListView items, which I followed, but the Resource.Designer.cs file was not updating with my newly created layout.

While developing with Android in Eclipse, the resources are auto-generated by just creating the files in the layout directory, which, evidently, is not the case for MonoDroid in Visual Studio. After searching a bit, I found this BuildProcess page for MonoDroid. It explained that resource files need the Build Action property of AndroidResource in order for the Resource.Designer.cs file to be updated with the layout.

Not sure if it’s possible to change the default, but out of the box the Build Action for an xml file is Content.

To fix:

  1. Right-click the xml file in the Solution Explorer
  2. Click Properties
  3. Change Build Action to AndroidResource

Useful Eclipse Shortcuts

I do a lot of programming on a laptop without a mouse, and Eclipse shortcuts are imperative if I want to remain productive. Even when I do have a mouse, using keyboard shortcuts is usually faster than trying to click around for what I need. Here is a list of shortcuts that I use often.

Ctrl+Shift+l – Show Shortcuts

Navigation
F3 – Go to Definition
Alt+Back – Back
Alt+Forward – Forward
Ctrl+l – Go to Line
Ctrl+m – Maximize/Minimize Active View or Editor
Ctrl+Home – Go to Beginning of File
Ctrl+End – Go to End of File

Productivity
Ctrl+1 – Quick Fix (i.e., create method if you are calling one that does not exist)
Ctrl+7 – Toggle comment
Ctrl+d – Delete line
Ctrl+Shift+f – Format
Alt+Up – Move Lines Up
Alt+Down – Move Lines Down
F2 – Show Tooltip Description

Debugging
F11 – Debug
Ctrl+F11 – Run
F5 – Step Into
F6 – Step Over
F7 – Step Out
F8 – Continue
Ctrl+Shift+b – Toggle Breakpoint

Emulator
F6 – Turn On/Off Trackball
Ctrl+F12 – Switch to Next Orientation (Portrait, Landscape)

java.lang.RuntimeException: Stub!

I recently tried to run my junit tests to ensure that I didn’t break anything after monkeying around with my code, and I ran into the following error:

Exception in thread "main" java.lang.RuntimeException: Stub!

Here’s my code that runs my tests:

public class RunTestSuite {
public static void main(String[] a) {
TestRunner.run(suite());
}

public static Test suite() {

TestSuite suite = new TestSuite();
suite.addTestSuite(MyClassTests.class);
return suite;
}

}

The stack trace pointed to line 8, so I didn’t know what to make of it since I just had this setup correctly, and TestSuite is a JUnit thing.

Googling mostly resulted in issues with using an Android Test Project (I’m not) and running the tests in your desktop’s JVM instead of the actual device’s (see here).

Eventually, though, I found this post that informed me that the JUnit library needs to be at the top of the test project’s build order.

Here are the steps to change the build order in Eclipse:

  1. Right-click your test project
  2. Click Bulid Path->Configure Build Path…
  3. Click the Order and Export tab
  4. Select the JUnit reference
  5. Click the Top button

If you’d like to see what I’ve been up to with my Android programming, check out my Email Yourself app.

EasyMock Exception NoClassDefFoundError

While trying to set up my JUnit test project in eclipse to be able to mock the dependencies of my classes under test, I was receiving a java.lang.NoClassDefFoundError exception on the call to EasyMock.replay(myMockedObject). Included in my build path were easymock-3.0.jar, objenesis-1.2.jar, and cglib-2.2.jar.

I eventually found this site, and saw that I needed cglib-nodep-2.2.jar in my build path instead of just cglib-2.2.jar. Odd that EasyMock didn’t mention that .jar specifically.

Simplifying Context in Android with Roboguice

If you have done any database work for Android by extending SQLiteOpenHelper, you have also had the experience of passing a Context down through the layers of your application to your database adapter. This is annoying because while you want the focus of your programming efforts to be on your application domain, part of your application design is focused on forwarding a framework-specific variable. Fortunately, roboguice comes to the rescue with just a few handfuls of code.

First, you’ll need to create an application class that inherits from RoboApplication:

public class MyApplication extends RoboApplication { }

RoboApplication contains the method protected void addApplicationModules(List<Module> modules) that you can override and add any modules that you’ve defined to the List, so you can add the following to your application class:

@Override
protected void addApplicationModules(List<Module> modules){
modules.add(new AbstractAndroidModule(){
@Override
protected void configure() {
requestStaticInjection(DBAdapter.class);
}
});
}

The method requestStaticInjection() injects static fields that have the @Inject annotation into the specified class. Therefore, we can add the following to our database adapter class:

@Inject private static Provider<Context> contextProvider;
private Context mContext;
public DBAdapter()
{
mContext = contextProvider.get();
}

The last piece of the puzzle is for your Activities to extend from a Robo*Activity (RoboActivity, RoboListActivity, etc.) which will hook up the static injection:

public class MyActivity extends RoboActivity  { }

Now, whenever an instance of the DBAdapter is created, roboguice will inject our current Context into contextProvider before calling the constructor:

DBAdapter dbAdapter = new DBAdapter();

Another way to inject a context provider into the DBAdapter is to use the usual guice injection strategy of creating an interface, implementing it, and configuring an AbstractModule. This approach requires more overhead, but perhaps creates a cleaner solution. I might write another post detailing this method if there’s interest.

Thanks to Donn Felker for clarifying some points.

My Blog

Well, I never thought that I would actually start a blog. I don’t even like the word “blog”. It’s like a mix between some trendy marketing term and the sound of someone vomiting (blahhg). Oh, wait, that sound is just me after reading the majority of the blogs online. Usually some self-absorbed person who thinks that I want to read their inner-monologue detailing– Ugh, I can already start to feel my slide to the dark side. Let me get through this post, and then we shall never speak of this again.

I initially started looking into a blog because I’ve been developing more for Android lately, and I’ve found that the amount of information that the web contains on the subject isn’t as plentiful as some of the other technologies that I use, like .NET. I thought posting about my Android tribulations could simultaneously help me learn more about the subject, and help other developers solve their issues that I have already encountered. I also hope that writing about Android will motivate me to remain passionate about it. I will often start some endeavor with great interest and passion, but the interest inevitably fades with the passion right behind it; it seems writing could be a good way to keep that interest and passion going. Finally, I’ve always wanted to improve my writing, and this will give me that opportunity.

While most of my posts will revolve around Android, there undoubtedly will be some on other topics that I’m interested in. From software to poker; from meditation to driving tactics. I hope someone finds something of interest.

Now, let us never speak of this blog post again.