All posts in Java

Awesome .jar of the week: org.apache.http.HttpEntity

By On March 30, 2011 In Android Development, Java With Comments Off Permanent Link to Awesome .jar of the week: org.apache.http.HttpEntityPermalink

We just finished building an Android app that uses multipart form attachments sent over http post to an API. Thanks, Apache Foundation, for making this super easy via the HttpMime library:

  File f = new File("/path/fileToUpload.txt");
  PostMethod filePost = new PostMethod("http://host/some_path");
  Part[] parts = {
      new StringPart("param_name", "value"),
      new FilePart(f.getName(), f)
  };
  filePost.setRequestEntity(
      new MultipartRequestEntity(parts, filePost.getParams())
      );
  HttpClient client = new HttpClient();
  int status = client.executeMethod(filePost);

Simple as that… Kind of amazing.

Ignoring Android Files With Subversion

By On November 16, 2010 In Java With Comments Off Permanent Link to Ignoring Android Files With SubversionPermalink

While setting up a new project for Android is fairly simple, checking things into Subversion can get a little tricky to downright annoying if you don’t do it right! One problem which I’ll talk about here is having to deal with seemingly random files making their way into the repository which constantly update themselves and change. If you check these files, the checkout will you will constantly be wrangling with yourself and other developers on your your team, wasting bandwidth and storage space, causing unnecessary conflicts, and just generally causing trouble. The core of the problem is that the files and directories we’re about to discuss are build, resource, or local settings files which will always get updated to run on each developer’s environment.

The following five entries need to be made into a properties file Subversion uses to ignore certain file patterns:

  • .classpath
  • .project
  • .settings
  • bin
  • gen

The following command, svn propedit svn:ignore will be helpful. The second part starts the editor, the third starts it regarding the ignore properties, and the last part tell you where to ignore the files. Period means “this” directory and all of its children. Each entry in this file will essentially be matches. Entries with a period are file types whereas entries without any are directories and their children. Each of these entries must be entered to prevent things like adding paths, libraries, or even just cleaning, refreshing, and running a build of your Android application.

For an Android project the period in the previously mentioned command should be wherever your manifest, the root of the project, is. It can also be a path so something such as app/ (or wherever your application resides). Since all we care about is the crazy things Eclipse and Android generate you want to keep the ignore inside that directory. Each entry is one line inside this file.

After you are done adding the five entries above to your ignore file, save it and check it in. A properly set up project will always show nothing after running an svn status regardless of settings, path, or local changes to the project which would alter the generated or build files but not the source.

Already Checked In

If you are correcting a broken check in because someone checked in any of these files, make sure you exit Eclipse first. Otherwise, it will constantly regenerate and update local copies of the files. You’ll have to make sure your local copies are up to date with no local changes to the repository. Then follow the above steps finishing with an svn remove of the offending paths and file types. Once it is all checked in you should be able to check out and use a clean version of your application.

Using a properly set up repository if you are checking out someone else’s project they’ve checked in without runtime garbage will mean you’ll want to create a new Android project and then select Create project from existing source when starting a new project in Eclipse. Fill in the application name box and navigate to the appropriate application path where the manifest resides. Once you’ve added JARs, external libraries, and/or whatever your application uses a quick refresh and build of your project will generate all the necessary files and you’ll be up and running.

Reference: http://www.petefreitag.com/item/662.cfm

The Android Three-Pronged Attack Test Plan

By On September 28, 2010 In Android Development, Java With Comments Off Permanent Link to The Android Three-Pronged Attack Test PlanPermalink

We’d like to give you some insight on how we test our Android apps like Flicka here at Mokasocial. It’s a three pronged approach that leverages the tools available to Android developers, and it gives us a lot of confidence that we’re not releasing a buggy build.

  1. Unit Tests – This one is a no-brainer, and most serious shops do some degree of unit testing. It’s an important step to undertake to make sure your model classes are doing what you expect them to do, and there are lots of side benefits as well. The Android SDK makes it easy to create a jUnit test project. Unit tests, it’s widely said, are only as good as their coverage – they need to be updated and expanded in the course of development.
  2. Robotium Tests – Often described as “Selenium for Android”, Robotium is a really nifty UI test framework that acts like it’s a user. It sees what the user sees, it clicks like a user clicks, and the team writes test scripts for it to go through. Robotium has a lot of the best components of unit tests and regression tests. The level of thoroughness depends on how specific the test script is.
  3. Monkey Tests – This awesome tool, which comes standard in the SDK, is a very configurable Android stress testing engine that executes absolutely brutal tests on devices, by sending pseudorandom input commands. No kidding – it taps everywhere, switches orientations, pound buttons, all that. It’s especially effective at finding things even dedicated test scripts won’t, because it operates faster than a user, and will happily pound on a button five times before anything loads, or switch orientations while an animation is occurring.

All of these tests take some time to configure and write, but once you get them going they lend a lot of confidence to the development process. Our chosen method is to have a dedicated test machine that’s set up to run the unit tests, then the Robotium tests, then let the monkey have a go for a few hours, then repeat. Every morning, an email is sent to the dev team with a test report. While you are reading this, Flicka is being tested on several levels, and tomorrow we’ll know about every failed assertion and forced quit.

Few platforms have this level of support for testing, in both library form. Thanks a lot for reading, and our thanks to the developers of Java, Android, and Robotium for their killer work, which makes our jobs easier and more fun. Also, download Flicka for Android today!