• Connect your Android device and your PC with the same network, e.g. by connecting the PC to the same Wifi.
• On the PC, install Fiddler.
• Make sure, Fiddler is configured to allow remote computers to connect:
  
• If you want, you can user Fiddler also to capture HTTPS traffic:
  
• In your Android app you have to set your PC as proxy server for the HTTP traffic. To do this, you have to provide the proxy information to the HttpClient by setting a HttpHost instance pointing to your PC’s IP address and the port Fiddler is listening at as proxy in the Http parameters:

  HttpParams httpParameters = new BasicHttpParams();
  HttpHost proxy = new HttpHost("<your PC's IP>", 8888);
  httpParameters.setParameter(ConnRoutePNames.DEFAULT_PROXY
          , proxy);
  
  httpClient = new DefaultHttpClient(httpParameters);
  

Now let Fiddler run on your PC and capture the traffic. Compile your Android app and start it on your mobile device.
That’s it. Fiddler should now show you what’s going on between your Android app and the servers it is connecting.

Troubleshooting:

Your app can’t connect to the server

• Make sure, that the correct IP address is set as proxy.
• Make sure, the PC is reachable from your Android device. E.g. check if the Android device is connected to the same Wifi as the PC
• Make sure, that Fiddler correctly setup the Firewall. Try connecting with disabled firewall.

Say, you want to test, if there was a HTTP request sent at all. In this case, you can use the following code:

assertTrue(Robolectric.httpRequestWasMade());

Or you want to check, if a call to a certain uri was made:

assertTrue(Robolectric.
        httpRequestWasMade("http://www.myserver.com/"));

If you want to check for some more complex rules, you can use the method hasRequestMatchingRule of the FakeHttpLayer class and provide a request matcher that tests your criteria, e.g. if the request contains a certain header:

assertTrue(Robolectric.getFakeHttpLayer()
    .hasRequestMatchingRule(
    new RequestMatcher() {
        @Override
        public boolean matches(HttpRequest request) {
            if (request.containsHeader("X-CustomHeader")) {
                return true;
            }

            return false;
        }
    }));

To get the sent requests in the order of sending, you can use the method FakeHttpLayer.
getSentHttpRequestInfos and then e.g. check if the correct number of requests has been sent, the correct methods have been called, etc.:

List<HttpRequestInfo> sentRequests =
        Robolectric.getFakeHttpLayer().getSentHttpRequestInfos();
assertTrue(sentRequests.size() == 2);

HttpRequestInfo firstRequest = sentRequests.get(0);
assertTrue(firstRequest.getHttpRequest()
        .containsHeader("X-CustomHeader"));
assertTrue(firstRequest.getHttpHost().getPort() == 8080);

Conclusion
Robolectric provides some very helpful methods to test if your code sents the correct HTTP requests in the correct order.

• One response for all: Robolectric.setDefaultHttpResponse
  Using this static method, you can set a HTTP response that is returned by the fake HTTP layer when there is no other response rule matching. If you only set an HTTP response with this method, all HTTP requests made will receive the given HTTP response as return value.
  E.g. if you always want to return just a success code, you could use the following line of code:

  Robolectric.setDefaultHttpResponse(200, "response body");
  

  or you always want to fail:

  Robolectric.setDefaultHttpResponse(400, null);
  

• Using defined order of HTTP responses: Robolectric.addPendingHTTPResponse
  Using these static method, you can just put HTTP responses in a queue, which will then be returned by Robolectric one after the other for consecutive HTTP requests.

  Say, the first HTTP request should return a status code of 400 and the second one a status code of 200:

  Robolectric.addPendingHttpResponse(400, null);
  Robolectric.addPendingHttpResponse(200, "some content");
  

  To make sure a failing test does not leave some responses in the queue, you should always call Robolectric.clearPendingHTTPResponses after each test.

• Complex response rules: Robolectric.addHTTPResponseRule
  In some cases it can be useful to setup the fake HTTP layer to return HTTP responses based on hostaddress, the path on the server, the HTTP method, etc. E.g. if you want to provide a 200 response for the uri http://www.myserver.com/successfullcall and a 400 response for the uri http://www.myserver.com/failedcall you can use the following code:

  ProtocolVersion httpProtocolVersion = new ProtocolVersion("HTTP", 1, 1);
  HttpResponse successResponse =
          new BasicHttpResponse(httpProtocolVersion, 200, "OK");
  Robolectric.addHttpResponseRule("http://www.myserver.com/successfullcall", successResponse);
  
  HttpResponse failedResponse =
          new BasicHttpResponse(httpProtocolVersion, 400, "Bad Request");
  Robolectric.addHttpResponseRule("http://www.myserver.com/failedcall", failedResponse);
  

  Of course, you can also provide some content with your responses by adding an entity to the response object:

  successResponse.setEntity(
          new StringEntity("the content to return"));
  

• Dynamic Responses
  Instead of adding static responses to some pre-defined rules, you can also create an object that inherits from ResponseRule and where you can create new HTTP response on every request.
  As an example we want to return the number of the request as content each time our rule matches:

  class CountingResponseRule implements ResponseRule {
  
      private int mCounter = 0;
  
      @Override
      public HttpResponse getResponse() throws HttpException, IOException {
          HttpResponse response= new BasicHttpResponse(
                     new ProtocolVersion("HTTP", 1, 1), 200, "OK");
          response.setEntity(new StringEntity(Integer.toString(mCounter));
          mCounter++;
  
          return response;
      }
  
      @Override
      public boolean matches(HttpRequest request) {
          String uri = request.getRequestLine().getUri();
          if (uri.equals("http://www.myserver.com/counter")) {
              return true;
          }
  
          return false;
      }
  }
  

  Then add this rule using

  Robolectric.getFakeHttpLayer().addResponseRule(
          new CountingResponseRule()));
  

Conclusion
Robolectric provides a powerful way to return different HTTP responses to HTTP requests in your code and test how your code reacts on these responses. It is easy to create test cases which verify that your code will behave correctly even if the server reacts with weird responses.

Of course, Robolectric does not create a real UI for the tests. The way Robolectric allows testing of Android applications, works by intercepting the creation of instances of Android classes and provides some kind of proxy objects for them (so called Shadows). This way, the Robolectric developers have been able to rewrite parts of the platform’s behaviour, emulate the logic of a lot of classes and internally keep track of the state of the objects.

While this allows for efficient unit and integration testing without starting an emulator, it is clear that Robolectric tests do not replace testing on real Android devices or emulators with different OS versions. There are a few reasons for this:

• The code just emulates the logic the Robolectric developers have implemented. For the most common use cases, this works well, but you find missing/limited functionality quite quickly. This will improve over time. Nevertheless, one has to be aware of the fact, that not the real Android classes are used and the behaviour can be different from the Robolectric classes.
• The Robolectric framework does not emulate the real lifetime of an whole application. E.g. it will not start an activity or a service on its own. Also, it does not emulate the lifecycle of activities. This is by purpose, since it anyway is meant only for testing single units of the app. Of course, you can check which intent is being sent from an activity, which allows for testing the correct behaviour.
• There are also general limits to this concept. E.g. when your app is not based on the standard View classes, but uses OpenGL, this can not be tested with Robolectric. I would say, all cases where real hardware is involved, can not be tested.

In summary, Robolectric allows efficient testing of a lot of use cases of an Android application. It is certainly not enough to make sure it will run on all devices. But it already provides a way to cover a lot of use cases of standard Android applications and make sure that the single components of your app behave correctly.

One thing that is heavily missing is better documentation, though. Without having the source code of Robolectric available and checking how it is implemented or looking at the unit tests of Robolectric itself, I would have not been able to figure out how some things are expected to work.
Therefore, I will try to collect here some howtos and hints for Robolectric in the coming weeks.

Being in San Francisco and attending the conference was very inspiring. The keynotes have given a great overview what is possibly coming in the future and having Tim O’Reilly speaking about leveraging the openness of the Android platform was very motivating. As well as seeing what people are doing with standard hardware, like the NASA with Nexus S based mini satellites is crazy.

What was also great, was to “feel” what makes the bay area so special in terms of innovations: ways are short, it is easy to connect with people from great companies ( be it startups or established ones), you get first class information from first hand, and people are very open to try out new things.

Regarding devices: I had the impression that tablets are not really in focus of the Android developers. One is aware that you should support them, but most focus lies on the phone. This is also backed by the numbers that have been presented by Flurry: Android tablets are not very wide spread.

The Flurry talk was very interesting BTW. Seing which categories are having the most usage time and and how and when people are using the apps have been enlightening. Also that a typical lifecycle of an app is independent of the category and that in average 50% of the users will not use your app anymore after one week.

Cross Platform

A topic that was very present was how to effectively develop apps that should run on multiple mobile platforms, mainly iOS and Android, and what to care about in designing the interface. As expected there was no silver bullet for this problem. However, a very interesting way to approach this is to mix native and HTML5 content. But not in the way e.g. Phonegap is doing it. Instead, the app itself is developed natively but wherever possible a webview with reusable HTML5 code is integrated. Especially, this seem to working well with views containing only a certain amount of information, like a detailed view or similiar. This approach was mentioned several times to be used successfully, e.g. by LinkedIn’s Director of Engineering Mobile Kiran Prasad and Nick Farina, CTO from Meridian.

In designing apps the general concensus was to keep the apps similiar but adapt to platforms where the concept is different. E.g. an Android app should normally not need to have a back button in the UI but should rather leverage the hardware back button instead. Also an interesting point mentioned by Kiran Prasad is that especially the navigation behavior is different on the platforms. On Android users are used to getting back also to a different context where on iOS they are e.g. not expecting that and instead back is working on the current context only.

Regarding designing the workflow of an mobile app, Kiran Prasad provided a great overview how LinkedIn does it. He provided the analogy to speak of room planning when designing the app and concentrate on how the rooms are connected and what the rooms do and have instead of room decor. Especially interesting was they they found out that if you have more than 4 rooms (to stay in this analogy) people will make it hard for people to navigate in your app. In addition, each room should not have more than 3 levels of depth to not confuse the user.

Recommended Talks

The slides and videos of most talks are publicly available, so don’t hesitate to go there and check it out.

Some talks I can recommend for viewing (not for all of them videos and slides are already present. Hopefully, these will be posted later):

• What Android Can Learn from Steve Jobs: Tim O’Reilly’s Keynote
• Getting the Magic on Android Tablets: Suzanne Alexandra from Motorola provides some great hints on how to design apps for Android tablets
• Challenges of Building HTC Sense: David Wu from HTC provides excellent tips and tricks on how to improve performance of your apps and how to provide a good user experience.
• Cross Platform Mobile Applications: How LinkedIn Does It: An excellent talk by Kiran Prasad from LinkedIn on how to successfully design and develop cross platform mobile apps
• From iOS to Android: Nick Farina from Meridian talks about their experiences in develop cross platform mobile apps
• Beautiful Android: Eric Burke from Square provides some good hints on creating pixel perfect apps on Android

Nevertheless, in cases this approach might be appropriate, it is not obvious how to configure the location of the database if you are using SQLiteOpenHelper. The solution is to overwrite the context’s openOrCreateDatabase method. This method is called by SQLiteOpenHelper when it needs to open the actual database.

E.g. you can use the following code to store the database in the applications private folder on the sdcard.

@Override
public SQLiteDatabase openOrCreateDatabase(String name, int mode,
CursorFactory factory) {
    File externalFilesDir = getExternalFilesDir(null);
    if(externalFilesDir == null) {
        return null;
    }

    File dbFile = new File(externalFilesDir, name);
    return SQLiteDatabase.openDatabase(dbFile.getAbsolutePath(), null, SQLiteDatabase.CREATE_IF_NECESSARY);
}

To overwrite this method, you can either inherit from ContextWrapper and then provide the wrapped context to the constructor of SQLiteOpenHelper or you can e.g. provide an own Application class with this overwritten method and then give the application context to the constructor of SQLiteHelper.

Since integrating the UIWebView is not straight forward for all features, you can find here a summary on how to accomplish this.

What do we want to achieve?

First, let’s define what we want to do: The view should behave like a normal text view, but display rich text instead of normal text only. This also means that in some cases, we want to have a transparent background and if the user clicks a link, the page should be opened in the external browser.

Adding the UIWebView

The UIWebView can be added to your view as you do with any other view, either programmatically or using the Interface Builder.

Setting the Text

To set the text, you call the method loadHTMLString:baseURL: on your instance of the UIWebView. You can set the baseURL to nil if you want. For the content string you have to keep in mind that the view is made to display HTML pages. Therefore, you have to provide valid HTML content for the HTML string.
Setting a very basic HTML string could look like the following:

NSString* plainContent = @"My <strong>HTML</strong> markup";
NSString* htmlContentString = [NSString stringWithFormat:
  @"<html>"
   "<body>"
   "<p>%@</p>"
   "</body></html>", plainContent];

[webView loadHTMLString:htmlContentString baseURL:nil];

Setting Text Properties

If you want to change the font, the font size or other markup related properties, you have provide this properties in the HTML string, e.g. by setting the body style. Of course, you can use the full power of CSS, but we want to keep this article simple. So, to set font and font size for the whole document you can use the following code (note the additional style element for the body):

NSString* plainContent = @"My <strong>HTML</strong> markup";
NSString* htmlContentString = [NSString stringWithFormat:
    @"<html>"
     "<style type=\"text/css\">"
     "body { font-family:Marker Felt; font-size:24;}"
     "</style>"
     "<body>"
     "<p>%@</p>"
     "</body></html>", plainContent];

[webView loadHTMLString:htmlContentString baseURL:nil];

Transparent Background

If you want to have a transparent background for your UIWebView, you have to set this property on two places. First, you have to set the background color of the view itself to be transparent. But since the webpage you display also has a background color, this is not enough. Therefore, you also have to set the background color of the HTML content to be transparent by setting the background property of the body style to “transparent”:

[webView setBackgroundColor:[UIColor clearColor]];

NSString* plainContent = @"My <strong>HTML</strong> markup";
NSString* htmlContentString = [NSString stringWithFormat:
     @"<html>"
      "<style type=\"text/css\">"
      "body { background-color:transparent; font-family:Marker Felt; font-size:24;}"
      "</style>"
      "<body>"
      "<p>%@</p>"
      "</body></html>", plainContent];

[webView loadHTMLString:htmlContentString baseURL:nil];

Open links in External Browser

By default, the UIWebView handles links by itself and loads and displays the linked content. Since we do not want this behavior we need to catch clicks on links and forward them to Safari (or any other app that handles the clicked URL).

UIWebView provides a delegate property for this, where you can set a delegate implementing the UIWebViewDelegate protocol. The important method for us is webView:shouldStartLoadWithRequest:navigationType:

So in viewDidLoad you could set the delegate to an instance of an object implementing the following method:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
    if ( navigationType == UIWebViewNavigationTypeLinkClicked )
    {
        [[UIApplication sharedApplication] openURL:[request URL]];
        return NO;
    }

    return YES;
}

If a link is clicked, we just forward the linked URL and let the OS handle it using the default application.

Important side note: If you set a delegate to the UIWebView, do not forget to set it to nil before releasing it, e.g. in your dealloc method, like it is mentioned in the UIWebView documentation.

Conclusion

Using the UIWebView for displaying rich text is not difficult when keeping in mind, that you are actually using a full web browser. Following these simple steps allows you to integrate the UIWebView very easily:

1. Add the UIWebView to your view hierarchy as you would do with any other view
2. Set the text by wrapping it into a simple HTML markup
3. Set the text and content properties by changing the body style of your HTML markup
4. Implement the UIWebViewDelegate protocol and set the delegate of your UIWebView to forward clicked links to the default handler

Java Performance blog: How to really measure the memory usage of your objects

Android Developers blog: Avoiding memory leaks

Java Performance blog: Eclipse Memory Analyzer, 10 useful tips/articles

Google IO 2011 Session: Memory management for Android Apps

Since I did not want to display the real data but only the processed data on the activity, I needed a solution for this problem. My first try was to include a hidden SurfaceView in the layout, but the SurfaceView does not create a surface if it is not visible. This post provided the first hint for solving the problem: You have to include a surface view and set the layout_height and layout_width parameters to “0dip”. This will trigger creation of the surface but the surfave view is virtually invisible.
Unfortunately, when trying this solution with different devices, it turned out that it does not work correctly  on all devices. On some devices the SurfaceView need to have visible size to make the camera preview work.

Finally, what worked on all devices is to overlay the SurfaceView completely with one or more other views so that it is logically visible but the user can not see it. In this way you can easily draw you own processed preview data in a custom view that is hiding the real preview.

Additionally important for further processing of the image data or if you want to display your own preview is that the camera data you get in your preview callback is normally not in RGB but YUV format. If you want to draw the image on a Canvas, you first have to convert the data to RGB, e.g. by using the method you can find described in this post of the Android Developer Forum.

(Interesting sidenote: the YUV format contains the grayscale image in the first width*heigth bytes, so if you just need a grayscale image, no conversion is needed).

Up from API level 8 there is also a YUVImage which you can use to convert the provided data to RGB, see stackoverflow for an example.

The reason for this behavior is that you are trying to transition between subviews of the root view. However, although the coordinate system of the subviews are correctly rotated so that they are displayed in the correct orientation, the root view itself is not rotated. Therefore, the animation on this view is also not rotated.

A possible solution to this problem is to add a new subview into your root view ( with the same size) and move all existing subviews to this new subview so that they are no longer direct children of the root view. Your animated transition is then not applied to the root view but to the new subview and it is therefore correctly rotated.