A few days ago I exchanged my malfunctioning Droid Bionic for a shiny refurbished HTC Rezound. Although I’m certainly not a fan of HTC’s Sense overlay (except the awesome lock screen), I consider this exchange to be a major upgrade. Sure, the CPU is clocked a bit higher and sure the screen has a greater pixel density (342 ppi vs 256 ppi), but the one feature that makes this exchange so worth my while is that the HTC Rezound offers an unlocked bootloader.

Just last week, HTC announced that any phone sold after September 2011 will be eligible to have its boot loader unlocked with the HTCDev.com unlock tool. The only catch is that in order to obtain the unlock binaries, you need to complete HTC’s workflow of submitting your device ID and agreeing to discard any hope for every making good on your manufacturer’s warranty.

I guess this is considered pretty progressive compared to some other device manufacturers (I’m looking at you Motorolla), but I think we deserve more. Google’s flagship android devices, (nexus one, nexus s, galaxy nexus) all come with an unlocked bootloader off the shelf without any determent to their warranties. This is how all phones should be.

As a consumer, I want to be able to buy a device and truly own its hardware. When I buy a phone, I want it to be completely unlocked and willing to accept my modifications. I understand that there are risks involved with modding my phone, and I definitely do not expect manufacturer’s to support my devices after I modify them, but it just seems so strange that my warranty is voided after merely unlocking it. By unlocking my phone, I introduce no harm or change to my device, yet I’m out of luck when it comes to manufacturer’s support.

I moved to this HTC device after a long history of using Motorolla phones. I’m tired of having my phone completely locked down. I applaud HTC for taking this step in the right direction, but still, things could be better.

It’s time for the official announcement of my internship plans for the summer of 2012. After a long semester of phone calls and interviews with companies around the country globe, I have set decided to join Atlassian as a summer software development intern.

Atlassian has put together one of the most exciting internship programs that I’ve ever come across (Full description here). The plan is to bring out six software development and user experience students to spend their summer together to create, from concept to launch, an entire new product, feature, or plug in. We’ll be spending half of our summer in Sydney, Australia and the rest in San Fransisco.

If any of you are familiar with the famous Joel on Software blog, this concept may seem a bit familiar. Fog Creek software, who’s FogBugz software competes with Atlassian’s Jira, actually ran a similarly styled internship program back in 2005 and found great success. The entire process was documented in the film Aardvark’d, which I had a great time watching. (Note: You probably don’t enjoy documentaries, software development, and internships as much as I do, so take my review with a grain of salt)

I’m not sure exactly what my project will be at this point, but once I’m introduced to my fellow interns in the coming months, this will become more clear. I can say for certain, though, with Atlassian’s awesome company culture and the nature of this internship, (and from what I’ve seen in the Aardvark’d documentary), I am going to have a blast this summer.

I’ve mentioned that I have a bit of Android experience but I’ve never really went into any details. The reason for this secrecy is that I wanted to hold off on the story until I had something to show for my work. Today, I can finally share with you my Android creation.

Earlier this evening, my friends and I released our first Android app! It is called TerpMeals and can be found here. TerpMeals is an app that lets University of Maryland students view any upcoming (or previous) value meal menus from the on campus dining halls.

Although TerpMeals is a relatively simple app, it was not created without its share of challenges. The biggest roadblock that kept popping up throughout development was dealing with Android fragmentation. There are tons of different devices that run Android and they all run slightly different versions of the OS on completely different hardware. We had to produce an app that would work just as well on a 3 inch phone with wifi as it would on a 10 inch tablet with 3g.

The best part of the whole process was knowing that our project has the potential to be genuinely useful for University of Maryland Students. We’ve already seen almost 100 installs and we’ve been getting a lot of great feedback from our users! Although planning has already started for the next app, I’ll be keeping an eye on TerpMeals and pushing new features and fixes as often as I can.

Although its pretty bare now, you can be the first to find out about our new apps and updates at www.512Technology.com

Cloud9 is an awesome IDE for web based languages that lives entirely in your web browser. It offers most of the important little features that a standard desktop IDE can provided such as content-assist and quote/parenthesis/brace pairing and even includes a (javascript) debugger. I also love that it has a command line (with content-assist for git commands!) and can easily integrate my development environment with my favorite code hosting site, bitbucket. Cloud9 is available in three flavors – hosted(free), hosted(paid), or local.

As awesome as the service is, I’m not willing to drop $15 a month from my college student budget for a premium hosted account. I’m also not interested in the free hosted account because it leaves my code open and available for anyone to find and play with.  With these two limitations in mind, I’ve decided to run a build of cloud9 locally on my own hardware.

Installing Cloud9

Installing Cloud9 wasn’t as simple as I had hoped. Many of the guides I had found worked only with 32 bit linux or relied on dependencies from github that didn’t seem to exist any more. Eventually I found success with v2 of the guide posted here: http://gratdevel.blogspot.com/2011/03/easier-way-of-setting-up-cloud9-on.html

I’ve made a few modifications to the procedure though, so here are the exact steps I used to install Cloud9 on Ubuntu 11.10 64 bit:

Update your apt-get repository and install dependencies

sudo apt-get update
sudo apt-get install -y build-essential g++ curl libssl-dev apache2-utils git libxml2-dev

Clone and build nvm, the Node Version Manager, and install the latest stable version. I used v0.4.12.

git clone git://github.com/creationix/nvm.git ~/.nvm
. ~/.nvm/nvm.sh
nvm sync
nvm install v0.4.12
nvm use v0.4.12

Add nvm (version specific) to your path

echo "export PATH=~/.nvm/v0.4.12/bin/:$PATH" >> ~/.bashrc

Create a folder to hold Cloud9 and o3. This isn’t necessary, but I don’t like a cluttered home folder.

mkdir ~/local
cd ~/local

Clone and build the development branch of Cloud9

git clone git://github.com/ajaxorg/cloud9.git
cd cloud9
git checkout devel
git submodule update --init --recursive
cd ..

Clone and build o3, a Cloud9 dependency. After building, we’ll need to move the o3.node file to a place where Cloud9 can access/expect it

git clone http://github.com/ajaxorg/o3
cd o3
./tools/node_modules_build
cp build/default/o3.node ../cloud9/support/jsdav/support/node-o3-xml-v4/lib/o3-xml/
cd ..

Start Cloud9 with local access only

node ~/local/cloud9/bin/cloud9.js -w ~/yourproject

To enable off-box connections start Cloud9 with

node ~/local/cloud9/bin/cloud9.js -w ~/yourproject -l 0.0.0.0

To making starting Cloud9 easier, I’ve created an alias. With this I’ll be able to start Cloud9 just by typing: cloud9

echo "alias cloud9='node ~/local/cloud9/bin/cloud9.js -w /var/www -l 0.0.0.0'" >> ~/.bashrc

Now, start up Cloud0 and point your browser to your yourserver.com:3000 and you should have full access to your Cloud9 IDE

Securing Cloud9

So far, I haven’t found a way to provide any password protection or authentication on my local Cloud9 other than disabling off-box connections entirely. Since I use cloud9 to access my code from around campus, this wasn’t an option for me. Instead, I leave Cloud9 disabled throughout most of the day and turn it on via ssh only when I need to use it. I keep my server’s ip address and host name a secret and I’m running Cloud9 on a nonstandard port, so I’m not worried about anyone accidentally stumbling across my code. Even though this isn’t a perfect solution, it makes me feel secure enough to continue using Cloud9 while I sort out a better solution.

Our solution relied heavily on Android’s Cloud to Device Messaging Framework. When users would request any data from our web “control panel”, our server would send a push notification to our tracked phone with a short one or two word message.  The phone would then use this message to determine what kind of information the “control panel” was requesting. Instead of displaying this message as a notification, like many apps do, we used the message we received to silently kick off a background service that would query the device for whatever information was requested and POST the information back to our server.

One of the main focuses of our app was gathering location data. We realized, of course, that every other team would do the same, so we implemented a way to display the information we gathered in a format that we considered a lot more “human readable” than a latitude and longitude.

From the phone’s gps (or network location provider) we were able to grab the phone’s geographical coordinates, altitude, reported signal accuracy, compass bearing, and speed. We took all of this information and plugged it into the Google Maps Javascript API to generate a map that could pinpoint the location of the  phone. We also took the coordinates and ran then against Google’s Geocoding API to convert them into a human readable street address.

With our push notification system, we were able to control just about any action on the phone. The features we highlighted were the abilities to remotely take pictures, place phone calls, and capture audio. What we considered our biggest selling point, however, was the ability to control the Android AccountManager. With access to the account manager we could protect our online identity by forcing our phone to forget all of our stored passwords. More importantly, we were able generate a list of all of the accounts logged into any app on the phone.  If the person who stole our phone had used any app that required authentication, we would be able to see their email address or user name. For the sake of convenience, we also generated links to facebook and google searches for each account name that we could find.

Overall, I had a great time with this contest. Luckily the judges were able to see through our not so creative app name and below average design skills and still crown us as the winners. I’m learning more and more about Android development with each project that I do and it was really cool to get a chance to work with the Google Maps API. Now that this is all over though, its time to collect my prize and enjoy some free time.

Early in October, I received an email from the cs undergraduate office here at the University of Maryland advertising a technical contest sponsored by Booz Allen Hamilton. The contest was open to students from the University of Maryland as well as 8 other east coast universities between Penn State and Georgia Tech.

The premise of the contest was pretty interesting. Contestants were to play the role of the developers behind the latest and greatest Android phone and were faced with the challenge of designing a way to recover their company’s prototype phone in the case of theft. Not only were we to determine the location of the phone, but we had to go a step further and identify whoever had stolen it.

As soon as I read that the contest was Android related, I was ready to sign up. About a month prior to this competition, a few friends and I got together and decided to make an Android application. By the start of the competition, we were just short of completing our app but with a bit of Android experience under our belts we decided to put our project on hold and enter the contest.

I want to explain the technical details of my team’s solution, but before I do, I’m going to skip to the end of this story for the lame readers who don’t care about the technical junk. My team created a website that could communicate with a linked Android phone and display a variety of information from the device that could be used to identify the user and location of the linked phone. We were up against 19 other teams and we came in first place! Our prize for winning was a galaxy tab 10.1 for each member of our team!

In an effort to keep this post from being way too long, I’m going to stop here and pick up next time with the technical details.