Android Draggable View

The standard approach to implementing a draggable/movable View in Android is to rely on DragShadowBuilder. For many situations, this would be the easiest approach. However, in some cases, where, for example, you need to modify the view as it is being dragged, DragShadowBuilder won’t do, as it’s just not flexible enough.

As part of a larger project, I created an alternate implementation of a draggable View, without the dependency on DragShadowBuilder. With this approach you have full access to the view being dragged (actually, the cached Bitmap image of the view), and, as such, the view can be modified while moving.

The code is available on GitHub.

Antair Headers is now open source

In 2010, I wrote a utility for Antair that allowed us to easily view the email headers of any email in the BlackBerry inbox.

The application integrated nicely with the BlackBerry inbox, making it really simple to view the headers of any incoming email message.

We released the application as a free app shortly thereafter. From what I heard, quite a few system administrators have found a use for it.

Today, I cleaned up the code a bit, and released the project as open source.

Product portfolio

We did some inventory over the weekend, and I managed to grab an interesting photo out of the process.

Each one of these sticky notes represents a product we built and released over the past 9 years, not including ports, or work done for clients.

Product portfolio

Gone Home

In 2010, I placed Heavy Rain into the #1 slot of my favorite games list.

As of yesterday, the #1 slot has a new entry —

Gone Home Game

No game has ever held my thoughts for so long after I finished playing it. No game has ever left so much of an emotional impact. A reviewer described Gone Home as “disarmingly tender”. I think that’s a perfect description.

Testing your mobile app against a server on the local network.

I often build mobile apps that have a web app counterpart. Typically, during development, the web app is running on some local machine, while the mobile app is being tested on a device.

A common issue that arises with this setup is that the mobile app, being tested on a device, doesn’t know the host name of the machine where the local web app is running.

With web development, I would set up a hosts file on each machine, to let it know how to reach the other hosts. But with a mobile app, I can’t simply modify the hosts file on the device (well, you can, but you would need a jailbroken device).

There are various solutions to this, such as modifying your router settings, but I find it easier to just use an HTTP proxy.

Here is how I would test an iOS app, with a web app counterpart running on a local Windows machine named “athena”.

If I just run the web app on “athena”, and then run the iOS app on my iPhone, the iOS app would not be able to connect to the server running on “athena”, as the iPhone doesn’t know what or where “athena” is.

The idea here is to run an HTTP proxy on “athena”, and then have the iPhone route its network traffic through the HTTP proxy. Since the HTTP proxy runs on “athena”, it can read the hosts file on that machine, which has an entry pointing the name “athena” to something like So, when the iPhone routes its network traffic through the proxy, the proxy can then resolve the name “athena”, and direct the request to the web app being served there.

It’s worth noting that the HTTP proxy does not need to run on the same machine as where the web app is running. The proxy can run on any local machine, as long as that machine has a hosts file with an entry for the location of the machine from which the web app is being served.

For Windows, the HTTP proxy I like to use is Fiddler.

After installing Fiddler, I go into options, and make sure “Act as system proxy on startup” is checked, and that “Allow remote computers to connect” is checked.


After that’s done, I go into the File menu and make sure “Capture traffic” is checked.

Fiddler is a great option on Windows. There are also great options for setting up local HTTP proxies on a Mac, such as the Charles HTTP proxy.

Once my HTTP proxy is running, it’s time to configure the iPhone to use that proxy. I will need to know the IP address of the machine where the HTTP proxy is running. In my case, the proxy is running on “athena”, which has the local IP address of The Fiddler proxy is listening on port 8888 (this can be seen in the Fiddler settings dialog).

On iOS 7, to set the proxy, I go into Settings, then, Wi-Fi, and select my Wi-Fi network. I scroll toward the bottom of that screen to find the section for HTTP PROXY. I click on “Manual”, and enter the IP address (Server) and Port of the machine on which my HTTP proxy is running. I entered for the Server, and 8888 for the Port.


That’s all. Now, when I run the mobile app on my iPhone, and the app wants to connect to the web app on “athena”, the network request is routed to the Fiddler HTTP proxy running on, the proxy reads the hosts file, finds the entry for “athena”, and directs the traffic to the correct local machine.

This is an easy way to test your mobile apps against local web servers. Just don’t forget to disable the local HTTP PROXY setting on your iPhone before you leave the house!

If you make mobile apps for a living, check out Uberdeck. It’s a service we started to allow mobile app developers to make more money from their apps, and to prevent negative reviews.