skepcode

I love this photo. The “Pale Blue Dot” is Earth, as taken from Voyager 1 in 1990. Carl Sagan said it best:

“From this distant vantage point, the Earth might not seem of particular interest. But for us, it’s different. Look again at that dot. That’s here, that’s home, that’s us. On it everyone you love, everyone you know, everyone you ever heard of, every human being who ever was, lived out their lives”

Amazingly, Voyager 1 is still alive and kicking it, and is now nearing the theorized Heliopause. It’s estimated that by 2015, the Voyager 1 could be the first man made probe to ever leave our Solar System.

I prototyped a new method for speeding up the turn around time on Titanium using JSON, a DexClassLoader, and a pre-dex’d JAR that we can ship with upcoming versions of our SDK. Essentially this allows Titanium apps to be just a shell for the JS and Resource files, while a hefty dex’d JAR of all the native Android code sits on the sdcard and doesn’t slow down the deploy time by requiring a long dexification of the entire Titanium class tree.

With the emulator, I’ve seen simple JS changes go from 2-3 minutes package/deploy/launch time down to 10-20 seconds. While using the very nifty android-x86 emulator, I’ve seen a round trip time that is nearly instant. Here’s a somewhat reusable snippet that I made from my existing prototype for launching an Activity from a custom ClassLoader. Keep in mind this is very very insecure. The only reason I’ve even used it here was for prototyping purposes, as I’ll probably end up restructuring our bootstrap code to work with an existing Activity

Another jewel from Paige today, an iPhone App for Roman Catholic Confessions: Confession: A Roman Catholic App

There’s a few things I find funny about this app:

• It provides a handy list of sins, just in case you didn’t know if you’ve committed one.
• After you’ve committed a sin, just reach for your iPhone and put a check mark next to it. How convenient!

The logical follow up would be an app for priests that automatically syncs the confessions of their parish for on-the-go forgiveness!

After my long-winded post on the deficiency of the Android MessageQueue, I ended up implementing an internal message queue that wraps Handler/Looper directly. This is currently being used in Titanium to better support lifecycle events for Android Activities, and seems to be pretty high performance. On top of the ability to pull and dispatch a single message from my custom queue, I’ve also added blocking primitives that allow two threads that are waiting on results from each other to still process other messages in the queue. Here’s the initial code:

https://github.com/appcelerator/titanium_mobile/blob/mac_lifecycle_refactor/a...

While we’re waiting anxiously for the Honeycomb release announcement tomorrow, Don pointed me to an article that disects some of the new features of Android 3.0 / Honeycomb. In short, it looks like there’s some really great new concepts and APIs: A refactored animation framework, Fragments, a new “action” bar, and of course the new revamped UI with a focus on tablets.

I whipped this little python script up tonight because I needed a quick and dirty way to kill a debuggable processes on my Nexus S without using Eclipse or DDMS. This is essentially a bare-bones implementation of a JDWP Command Packet using the DDMS command and EXIT sub command (the format was taken from Android’s ddmlib). Enjoy!

In most modern (and some not so modern) UI frameworks, you have the ability to invoke a single iteration of the main (UI) thread while other blocking/background tasks execute. The reason you only want a single iteration, is so that your code can loop however it needs to, then delegate back to the UI framework to perform it’s drawing when necessary. A common use case for this is allowing a responsive UI while you block the main thread.

Just a quick list of examples I’ve pulled from past experience and Google:

• Win32: GetMessage.aspx) and DispatchMessage.aspx)
• GTK / Glib: g_main_context_iteration
• Qt: QEventLoop::processEvents
• SWT: Display.readAndDispatch)
• wxWidgets: wxApp::Dispatch

In Android however, this ability is hampered by a single API omission: the ability to retrieve a single Message from the MessageQueue.

Android actually provides very flexible Looping and Message primitives that give your application a way to tightly and efficiently communicate between threads. All you need to do is create a Handler from the thread you want, which implicitly creates a thread-associated Looper, then start creating/sending Messages off to your thread to be processed.

This API is not only useful for developers, but it is the basis of the main (UI) thread in the Android OS. The main Looper of Android can at any time be found by calling Looper.getMainLooper()), which gives you direct access to being able to process messages on the UI thread.

So here’s the problem: I’m blocking the main thread (for the sake of argument, let’s not care why), and while I block I need the OS to dispatch messages that are queued. In Android, there’s a handy method on Handler called dispatchMessage) that does exactly that! So in pseudo code, what I want to do is:

Handler handler = new Handler(Looper.getMainLooper(), callback);
while (blocking) {
    handler.dispatchMessage(handler.getNextMessage());
}

Unfortunately though, there’s no method on Handler that returns the current message on the queue. Handler itself is actually just a wrapper around Looper and MessageQueue though, so let’s dig deeper to see what we can find. Looper has a method called loop), but unfortunately it loops until the Looper is told to quit. We might be able to pre-send a quit message by calling Looper.myLooper().quit()), which would break us free of our inner Looper.loop() call. This approach seems sound until you start digging in the MessageQueue.enqueueMessage code, and find that the queue will throw Exceptions after the quit message has been processed, making it unusable. Obviously, this would be bad :). If you scroll up just a little bit, you’ll see that MessageQueue actually has a method called next() that does exactly what we want! The problem now is that Google has decided the method should only be package private, and of course the symbol isn’t even available for use in the android.jar that ships with the Android SDK. So effectively, we are dead in the water with this approach.

I haven’t come to a conclusion which path I will follow yet, but the only ways I see around this are:

• Use reflection hacks to get the MessageQueue.next() method, and call it directly by getting the MessageQueue from the main Looper (expensive, and could break if MessageQueue.next is ever renamed, which is highly possible since it isn’t public API).
• Construct an internal primitive message queue for my application’s messages, so I can at least process my own messages while blocking

Tonight, Paige introduced me to an interesting Skeptic / Atheist personality on YouTube called Evid3nc3.

The first of his videos she showed me was a clever comparison of belief vs. disbelief of Evolution. There are ~800 names on a petition the Disovery Institute collected of scientists who say they do not believe in Evolution. The punchline however, is the scientific community’s response: Project Steve. The petition counts the number of scientists named Steve that say they do believe in Evolution. According to the updated Steve-o-meter, there are over 1100 Steves that believe in Evolution! The video does a good job of delivering the point in a humorous manner:

On Evid3nc3’s YouTube channel, there’s also a work in progress video series about de-converting from Christianity to Atheism. He seems to be genuinely respectful towards the beliefs of his Christian audience, which gives him extra points in my book. Most of us (Agnostics, Atheists, Humanists, etc) have come from some kind of faith, and it would be good if we all remembered that from time to time.