#micdroid

Top Hot Downloading MicDroid 0.46 APK

I finished up a pretty early alpha of my app, MicDroid, which processes audio with a pitch correction plugin, giving you an effect very similar to the effect you hear in T-Pain songs. The sound output is not quite as polished as the iPhone version, but all the major functionality is now there. I'm still missing nice graphics, but that can come in a future update. Apparently there's a lot of demand for this sort of app on Android, since my crappy alpha version got over 500 downloads in less than 24 hours.

In any case, it's been a good amount of work, and there's still plenty to do!

Planned future features include:

1. Shiny graphics, nicer UI

2. Sharing, Recording to email, Recording to SMS support

3. Possibility of encoding to MP3, or some other format

Handling rotation in Android is actually not as easy as I initially thought it might be. There are 3 different ways of going about it (sort of), although it is a bit more complicated than that.

So as you know, Android apps exist as Activities, which have their lifecycle detailed here.

It's all rather interesting as Android handles rotations by destroying the activity, pulling the different resources necessary for the new layout, and then recreating it. This can be rather costly, and wasteful, especially if your application has to re-populate data. (or even worse, lose unsaved data!) Unfortunately, my application (MicDroid, now available on the Android Market!) happens to be in both of those situations. I have a ListActivity, which must then re-populate itself on rotation, and a recording activity, which must keep recording through rotation.

The first tool Android gives you to help out is the ability to save your instance state using the aptly named onSavedInstanceState(android.os.Bundle) function. It seems to me this is meant for handling longer term application state, which may be needed when the application has been killed by the Android system due to memory constraints, after which the user starts it up again, expecting to start where they last left off. The other problem with using this is the Bundle object, which, despite having support to add primitive types built-in, has a vaguely defined interface for adding complex types. The Bundle object can contain Parcel objects, which are objects that implement the Parcelable interface. This interface basically allows Android to serialize your objects for later retrieval.

I didn't want to deal with that, so I used onRetainNonConfigurationInstance() instead. According to documentation, it will only be used when a new instance of the current activity is immediately created following the destruction of the current instance. In other words, this function exists to facilitate fast rotation! I took advantage of this and stored the current list of recordings into it, restoring it in onCreate() using the getLastNonConfigurationInstance() function to retrieve the old list. Result: rotation is nearly instant, and no longer has the annoying loading spinner. 

The other problem with rotation I had was the fact that Android would destroy the main Mic activity on rotate, killing the current recording if the app is recording, and basically trashing the application's internal state. In this situation, we basically cannot let the activity be destroyed and re-created, as there would be gap time between when the recording is destroyed and restarted. Fortunately we can tell Android that we want to manage certain kinds of configuration changes ourselves using the android:configChanges attribute, which goes in the <activity> node.

By adding the following:

https://gist.github.com/593220

we tell Android that we want to manage orientation changes, keyboard slide in/out changes ourselves.

This is done in the onConfigurationChanged(Configuration) function. By overriding that function, we can load up the layout and resources, re-register our onClickHandlers to the new widget instances, and restore our widget states, all without destroying and re-creating the Activity itself. This lets the application keep recording, since the recorder thread is never killed, giving us a practically seamless rotation. 

Got a call from Antares Audio today saying I'm infringing on their trademark. Oops. 

I always thought this license stuff was a huge pain, but I guess it's something I have to start being more aware of, if for nothing to avoid getting sued.

Anyway, I'd just like to point out that my stuff will typically be licensed under the MIT license, so if you want, you're pretty much free to do whatever

with it, so long as you properly attribute it.

Apparently my app got popular enough that it was linked on Gizmodo!

Anyway, despite the fact I'm not working, it sometimes still feels like I'm on the job when I am fixing things for MicDroid. Today I spent the better part of the day working on error handling code for the recorder/writer threads, which is something I've been trying to avoid for a while, since you know, error handling code isn't the most fun thing in the world to write, and it's been a while since I've had to deal with threading issues. In a way though, I am glad that there is something pushing me to continue to improve on it, and write the boring parts, because otherwise I would have moved on to something more interesting, like getting a port of Tyrian to run on Android. (what can I say, I loved that game... so it's in the pipeline... somewhere) 

There is one thing that I really wish I could do though, and that is to figure out all these weird phone-specific issues that people keep reporting. Holy crap when people said "fragmented" for the Android market were they correct. I have all sorts of reports of MicDroid working on one phone with one version of Android, and all of a sudden not working on another version, or some people who have it working, and others who don't, or even some phones which just plain don't work! (I'm looking at YOU Samsung Galaxy S!) And it's utterly impractical (and expensive!) to get each of those phones to test on. Getting logs and errors only go so far, at some point you just need some face time with the actual device. 

Which brings me to this; I'm now looking to pick up a Samsung Vibrant (I have T-Mobile) to figure out this Galaxy S issue. If anyone knows anyone who can help me out here, it would be much appreciated!

For a while I've had reports on the developer control panel of these weird errors:

https://gist.github.com/593195

This was pretty vague to me, so I didn't pay it any attention (bad idea). It wasn't until recently when I looked up the error that I found out what was going on. It appears that I have a ProgressDialog that spins until the user's recording library is completely loaded as part of an AsyncTask. Turns out, if you cause rotation while the ProgressDialog spinner is going, when it comes time to close the spinner, the ProgressDialog's handle on it's parent Activity is no longer valid, as rotation causes Android to destroy the activity and restart it. Oops. To fix this problem, you can either tell Android how you want rotation handled, using the attribute android:configChanges in the manifest in conjunction with the onConfigurationChanged function, or you can kill the AsyncTask and start it over as part of the activity restart. Romain Guy, one of the Android platform developers actually has a good example of the latter method in his Shelves app, which I thought was the correct way of handling this rotation problem. Since the Android lifecycle allows for your app to be suddenly killed at nearly any time, I would say it is better practice to code in such a way that you are not actively fighting the framework.