By now this is a pretty well known bug that if you type in file:/// (f in caps) in a lot of OSX apps, it will crash it. If you haven’t heard, see here or here or here. The worst part about this is someone could easily perform a denial of service attack on your iMessage app on any of your OSX machines by just sending you a quick message with 8 characters. You can try it right now as well……Oops, did I forget to mention? You will also send your own iMessage into a frezny crash loop…..

If you google around how to fix this, most blog posts would suggest you go and delete anything that starts with ‘chat’ in your ~/Library/Message folder (for example, Gizmodo). I would advice against it unless you don’t care about your chat history being completely erased. With a little terminal and sql you can easily fix it without having to remove your entire chat history.

The idea is pretty simple. The chat.db file that you were told to remove contains your chat history for iMessage. Instead of deleting the whole thing, you simply need to delete the culprit chat message that crashed your iMessage. We can easily do this with sqlite3 and a couple simple sql commands. Let’s get crackin.

It’s been a while since I updated my site. A lot has happened and my life has taken on a different direction! First I finished my thesis and thus completed my Ph.D degree at Berkeley! I accepted an offer from Apple Inc. and now work on the iOS Performance Team that oversees the performance of all iOS devices (iPhones, iPads etc). My team works across the whole programming stack, from app level down to kernel and device drivers, and we focus on issues related to performance, including memory, latency, framerate etc. It has been great!

This site has been down for a while because I forgot that i was hosting on the berkeley school servers, and when I graduated my account expired, but now everything should be back up and running! I will try to update the other portions of the site as well. But for now, have a great 2013!

As I mentioned in my previous post, Learning Android didn’t cover a couple topics, and one of them is Cloud to Device Messaging, or push notifications. When applications are getting data from the internet, there are two ways to keep the data fresh. First is called polling. It means that the app initiates a connection to the server at set intervals to see if there are new data. The problem is determining the polling frequency. Poll too often, you waste a lot of batteries without always getting new data. Poll too rarely, then you risk not getting new data in a timely fashion. The alternative is called pushing, or push notifications (iphone users should be familiar with the term). Instead of the client initiating a connection, the server sends a data packet to the client whenever there is new data, then the client reacts to it. Because there is some overhead to maintain a persistent connection to the server, rolling out a push notification service isn’t a trivial task, but google has done that for us! It’s called Cloud to Device Messaging (C2DM). We piggy back off of the connection that android maintains for gmail, google voice, gchat etc, and register our app to be “waken up” only when the server pings us. Note that the server doesn’t actually send the new data, it only sends an alert that new data is available. This keeps the ping packet small so there is less overhead. It’s up to the client app to receive the notification and then go to the server to retrieve the fresh data. In this post I will explain how to setup this service for your app. I will assume that you went through “Learning Android,” or at least have a basic understanding of the building blocks of Android programming. For the sake of keeping this post under a tolerable reading length, I will only go over the mechanisms. I have checked in a sample c2dm app that’s commented in my github repository, so clone the repository to see the whole picture. I also included a small ruby script to mimic a web server sending c2dm packets to the client device, this way you can debug your implementation without needing to setup a server. By the end of this post you should have an app that you can install on your phone or emulator, and then a way to send it push notifications without requiring any server side coding!

I’ve been following this online book Learning Android which I would highly recommend to anyone that wants to begin learning how to write android apps. It does a great job explaining the concepts of Android development through a non-trivial sample application – a twitter application. It also goes through the process of building the app step by step, improving the app when introducing more advanced concepts. This helps show how to use the building blocks that’s learned to improve an application. It goes through all the building blocks of android apps, and even the more advanced concepts like Android Interface Definition Language (AIDL) and using the Native Development Kit (NDK). I have followed along and built the demo apps while publishing the source code in my github repositories. If you want to learn how to write Android apps, follow along the book and I guarantee that you will not be disappointed!

However, I found that there are some concepts that are missing in this textbook, namely:

• context menus
• android testing framework
• c2dm (cloud to device messaging)

If you do follow along, here are some things to note:

• The System Services chapter has some bugs in the code posted.
• The AIDL chapter doesn’t fully explain how to setup the AIDL client app.
• From a design standpoint there are several design choices that are poorly made for the app in the text. But it does demonstrate how to code the functionality.

Just be sure to read the comments left on the side, as I have left several comments noting the above issues in the text. Enjoy!