We spent some time trying to figure out why some html content would not load in our app’s WebView. We found trivial html can be loaded into a WebView using the loadData(String, String, String) method. Rendering complex pages with Javascript is a problem. It turns out the loadData() method requires the html to be URI escaped (RTFM? Bah!). There are additional characters that need to be escaped too, requiring some nasty boilerplate.

The simpler solution (workaround?) is to use loadDataWithBaseURL(String, String, String, String, String). Calls to this method do not require escaping. Pass along a garbage base url (or null), and an empty or null history url for success and profit.

webView.loadDataWithBaseURL("blarg://ignored", getData(), "text/html", "utf-8", "");

Using a VideoView to play streaming videos is quite easy on Android, and the class provides handy callbacks to manage your UI too. For example:

    // set the Uri of the video
    videoView.setVideoURI(Uri.parse(videoUriString));
    // start streaming/playing the video
    videoView.start();

    videoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {
        @Override
        public void onPrepared(MediaPlayer mp) {
            // about to start playing
        }
    });

    videoView.setOnCompletionListener(new MediaPlayer.OnCompletionListener() {
        @Override
        public void onCompletion(MediaPlayer mp) {
            // reached the end of the video
        }
    });

VideoViews can be embedded into your layouts and sized any way that you’d like. However, there is one serious limitation.

According to Romain Guy, SurfaceViews (such as VideoView, etc.) inside ScrollViews (or ListView, etc.) are not supported by Android.

For example, playing a video using a VideoView inside of a row of a ListView seems to work at first, until the user tries to scroll the list. As soon as the list starts to scroll, the video turns black. It keeps playing in the background but you can’t see it anymore because it renders the rest of the video as a black box.

As another example, when the VideoView is scrolled so that it is partially off-screen at the time that the video starts playing, the VideoView does not render the video in the correct location on screen, causing the video to appear mostly black.

So be careful where you decide to put your VideoViews. At first it seems that they can go anywhere, but they cannot.

Web development spoiled me. Set the src tag on an img tag and away you go. For the most part, browsers just do the right thing and cache these requests. Disappointingly, Android does not come with out of the box support for caching content downloaded from the network. Server apis often require SSL, request headers, support for different HTTP methods, multipart post bodies, etc. requiring the use of the apache http client libraries. These libraries are powerful, but are a bear to work with. As far as I can tell there is no support for caching http responses built into the apache libraries, requiring that you roll your own caching scheme. Images often do not have all these complicated HTTP requirements. They’re usually simple HTTP GET calls. This makes the java.net.* libraries appealing. The java.net libraries come with some handy classes that makes caching a breeze.

Here is a snippet that will cause your request to be pulled from the cache, should it exist. If it doesn’t exist, the retrieved response will be written to the cache.

URL url = new URL("https://pivotallabs.com/images/pivotallabs-logo.png");
URLConnection connection = url.openConnection();
connection.setUseCaches(true);
Drawable drawable = Drawable.createFromStream(connection.getInputStream(), "src");

In the past I tried to use the code above alone and found it didn’t work, and no solutions seemed obvious. The javadocs for URLConnection don’t mention anything about ResponseCache, but there is work to be done there to make it all work. The following example shows using Android’s cache directory to cache the responses. You’ll want to take a moment to read the Android docs about the cache dir. There are guidelines for use of the directory. This looks like a lot of code (Java, Java, Java, Java), but IntelliJ will allow you to cntl-shift-space your way to happiness and write most of it for you.

final String cacheDir = context.getCacheDir();
ResponseCache.setDefault(new ResponseCache() {
    @Override
    public CacheResponse get(URI uri, String s, Map<String, List<string>> headers) throws IOException {
        final File file = new File(cacheDir, escape(uri.getPath()));
        if (file.exists()) {
            return new CacheResponse() {
                @Override
                public Map<String, List<string>> getHeaders() throws IOException {
                    return null;
                }

                @Override
                public InputStream getBody() throws IOException {
                    return new FileInputStream(file);
                }
            };
        } else {
            return null;
        }
    }

    @Override
    public CacheRequest put(URI uri, URLConnection urlConnection) throws IOException {
        final File file = new File(cacheDir, escape(urlConnection.getURL().getPath()));
        return new CacheRequest() {
            @Override
            public OutputStream getBody() throws IOException {
                return new FileOutputStream(file);
            }

            @Override
            public void abort() {
                file.delete();
            }
        };
    }

    private String escape(String url) {
       return url.replace("/", "-").replace(".", "-");
    }
});
</string></string>

This is a simple implementation that pays no attention to the response headers, returns no cached response headers, etc. but I think you get the gist. There is one gotcha: the URI passed into the put method does not contain the path info for the url, it must be retrieved from the URLConnection. Happy caching!