Basically, just adding android:cacheColorHint=”#00000000″ to the ListView enabled transparency while scrolling.

I ran into two memory leaks in Android itself in WebView, and Typeface. Both are because of bugs in the OS, so if you’re encountering memory leaks, and all your code looks pretty watertight, (Meaning you never pass Activities as a Context to a View, and you use WeakReferences for static inner classes) you might be hitting one of these.

The first bug for WebView is described here.

The solution is just to call destroy() on your webview in the onDestroy() method of the containing activity, then set any references to that WebView to null, just in case. The app I’m working on is webview heavy, so this was causing some grief.

The second bug for Typeface is described here.

The issue was that I was creating a new Typeface from assets in the onCreate method of my activity. Every time I did this, it was allocating around 700k of memory, which then never got released. Big, big problems. The solution in this case is to initialize the typeface object in a static class (You can subclass Application and stick it there if you want, but be aware that you can’t call getAssets() before the first activity gets it’s onCreate method called.) and then use that one instance for any TextViews you may have.

The only way I managed to figure out what was causing the leaks was to go into adb shell, and then use dumpsys meminfo. That showed me a whole lot of bad.

Apparently, Adobe AIR 2.0 has now added support for UDP, and this post by Jeff Winder shows how he’s added accelerometer support to RemoteDroid, and is using it to control an Adobe AIR application. Check out the video below:

http://code.google.com/p/remotedroid/

You’ll also always be able to find the latest .apk and server files there.

Part of my reason for open-sourcing it is that I’m just one person, with just one phone. Like or not, Android has already fragmented, and will probably fragment even more in the future, so support for every Android device out there will become increasingly difficult. That’s where open-source comes in.

I’m looking for contributors to help debug on platforms other than the G1. There are several issues that I simply can’t fix because I have no way of replicating them. Additionally, other people might think of features that I haven’t or haven’t had time to implement. If nothing else, people might be curious about how RemoteDroid works, and open-source is a great way of dealing with these issues.

If you’d like to help, feel free to email me at admin@remotedroid.net, or use the feedback form.

Pragma: no-cache, and all the other server-side headers also have no effect as far as I can tell.

It makes sense though. Since the browser’s on a mobile network, and since they want to minimize network traffic as much as possible, caching is going to be extremely aggressive.

An example of this might be if you have a game thread, or some process going that you don’t want to have to shut down and restart just because you suddenly have to deal with a keyboard. The solution to this is Activity’s onRetainNonConfigurationInstance() method, as described here:

http://android-developers.blogspot.com/2009/02/faster-screen-orientation-change.html

Now you know!

Here’s a quick little tutorial on how to use it.
quick alert tutorial

Luckily, I found another page that details a better, though more time consuming way of doing things.

Compiling for Android

Basically, you’re downloading the Android source and compiling it to get a cross-compiler that links to the appropriate Android libraries, and anything else you might need.

CAVEATS:

1. Compiling takes a VERY long time. Don’t start the compilation over SSH, because something bad will happen, and you’ll be forced to close the SSH session, which’ll bork everything. If you’re doing stuff remotely, VNC into your Linux box, open a terminal window there, and do what you need that way.
2. I haven’t tested this on anything other than Linux.

This is exciting for two reasons,

1. It’s Doom!
2. It’s actually native code running with a Dalvik frontend.

Now, Dalvik doesn’t have JNI, so how can you write something in C and run it?

This guy will lead you down a link-clicking rabbit hole that’ll tell you how. The important parts are the compiler (Choose ARM GNU/Linux and IA32 GNU/Linux), and the technique of running system commands from Dalvik, which is detailed on Gimite’s page.

One note, he links to a dynamic link method of getting everything to work, which doesn’t seem to be strictly necessary. I just compiled this:

#include <stdio.h>

int main (int argc, char** argv) {
	printf("Hello world!\n");
	return 0;
}

File newHello = new File("/data/data/com.joshsera/hello");
try {
	newHello.createNewFile();
	BufferedOutputStream out = new BufferedOutputStream(new FileOutputStream(newHello));
	BufferedInputStream in = new BufferedInputStream(this.getAssets().open("hello"));
	int b;
	while ((b = in.read()) != -1) {
		out.write(b);
	}
	//
	out.flush();
	out.close();
	in.close();
	// chmod?
	this.doCommand("/system/bin/chmod", "777", "/data/data/com.joshsera/hello");
} catch (IOException ex) {

}

public void doCommand(String command, String arg0, String arg1) {
	try {
		// android.os.Exec is not included in android.jar so we need to use reflection.
		Class execClass = Class.forName("android.os.Exec");
		Method createSubprocess = execClass.getMethod("createSubprocess",
		String.class, String.class, String.class, int[].class);
		Method waitFor = execClass.getMethod("waitFor", int.class);
		
		// Executes the command.
		// NOTE: createSubprocess() is asynchronous.
		int[] pid = new int[1];
		FileDescriptor fd = (FileDescriptor)createSubprocess.invoke(
		null, command, arg0, arg1, pid);
		
		// Reads stdout.
		// NOTE: You can write to stdin of the command using new FileOutputStream(fd).
		FileInputStream in = new FileInputStream(fd);
		BufferedReader reader = new BufferedReader(new InputStreamReader(in));
		String output = "";
		try {
			String line;
			while ((line = reader.readLine()) != null) {
				output += line + "\n";
			}
		} catch (IOException e) {
			// It seems IOException is thrown when it reaches EOF.
		}
		
		// Waits for the command to finish.
		waitFor.invoke(null, pid[0]);
		
		// send output to the textbox
		this.addText(output);
	} catch (ClassNotFoundException e) {
		throw new RuntimeException(e.getMessage());
	} catch (SecurityException e) {
		throw new RuntimeException(e.getMessage());
	} catch (NoSuchMethodException e) {
		throw new RuntimeException(e.getMessage());
	} catch (IllegalArgumentException e) {
		throw new RuntimeException(e.getMessage());
	} catch (IllegalAccessException e) {
		throw new RuntimeException(e.getMessage());
	} catch (InvocationTargetException e) {
		throw new RuntimeException(e.getMessage());
	}
}

Anyway, this has a few issues:

1. The newly created file is out of control of the install/uninstall process. When the user uninstalls your applicaton, the binaries you’ve copied will remain where they are, taking up space. This is bad. What I’m doing, is copying the file over in the onCreate method, then rm-ing it in the onDestroy method. This adds to the startup time as you’re copying files around whenever you start up, but at least it’s clean.
2. If Android goes to a machine with a different processor, your app probably won’t work. At the moment, this isn’t a big deal, but there’s rumors of Android being installed on netbooks, so this could become a problem later.

Well, googling around today, I found this article on Kalman filtering, which might help me to cut down on some of that noise.

Kalman Filtering

Maybe, if I can get that working, Wiimote-style pointing could find it’s way into RemoteDroid sometime in the future.