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.

Android + Arduino wireless from Guus Baggermans on Vimeo.

Well damn!

One note for Nexus One users, the Nexus One apparently has some pretty serious multitouch problems, making click and drag a bit wonky. I’d advise sticking to tap-to-click and hold for dragging items around.

Another change is that I’ve removed the trackball as mouse functionality. Now clicking the trackball acts as a CTRL key, and moving the trackball acts as a scrollwhell, making it more like ConnectBot, and making the user experience a little bit more consistent.

Lastly, I’ve added better support for the soft keyboard. All keys, except for the ones that don’t have direct analogues on your regular keyboard now work. (long-press keys still aren’t supported) In the future, because of differing physical keyboard layouts between devices, I’m going to try to get RemoteDroid to recognize which device you’re using, and change what it sends depending on that, but for now, at least the soft keyboard should be pretty consistent.

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

OI File Manager

There are several good file browsers out there, but I like the philosophy behind this one. I prefer the directories and folders metaphor over the idea of every app keeping it’s own list of files, a la iTunes, or the iPhone’s big list o’ apps home screen. This means access to the filesystem. At the moment, there isn’t a native file picker widget/view/whatever, so OpenIntents designed their file browser to provide that.

With that in mind, the next app is

Download Crutch

This just allows the Android browser to download any file type. Currently, it only downloads files that have corresponding apps. This is by design. Since Android doesn’t have a native file browser, if you were to download something without an app to manage it, you’d never be able to delete it. People will make new apps, and those apps will be able to deal with different files, therefore they need a way to tell the browser what the new file types are. I guess Download Crutch just tells the browser that it’ll handle everything.

Terminal Emulator

Because every computer needs a command line.

Connectbot

An SSH program for Android. If you have a Linux box running somewhere, you can just SSH into it, then use IRC, or any command line program you want. I think you can even use SSH tunneling, but I’m not sure.

Tetherbot

It takes some configuring, and it’s really only good for browsing the web, but when I happen to have my laptop with me, and there’s no wifi available, this app is indispensable. T-Mobile isn’t keen on tethering, so this app can’t be released on the market, but lucky for us, Google lets us install whatever the heck we want on our phones. Eventually, Google will allow us to write native apps, and we’ll hopefully start to see true tethering apps, (You can already do this if you’ve rooted your phone) but until then, this app works pretty well.

So basically, what I really want is a very small computer that also happens to be able to make phone calls. Netbooks won’t fit in my pocket, and don’t serve as phones. The iPhone’s soft keyboard bugs me, I don’t like it’s overly managed interface, and the fact that it’s completely tied to iTunes. Windows Mobile just blows, and Palm is somewhat outdated, so we’re left with Android.

At it’s heart, a mobile phone is just a computer, and computers at their heart, are supposed to be able to do just about anything that you can figure out how to tell them to do. These apps aren’t everyday use programs, but they go a long way towards providing the kind of flexibility that you should have out of these devices.

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.