Two devices, two different user experiences, too much hassle

At the beginning, our inspiration came from a simple issue: when using a desktop or laptop computer to access a website, all of the functionality of our smartphones and/or tablets wasn't being used. Mobile devices have become ubiquitous as easily accessible and multi-functional portable computers. These devices, having access to a wide array of sensors (such as cameras, gyroscopes, gps, etc.) are capable of quickly providing various types of data to websites.

However, when using our desktops to browse the internet, we are incapable of accessing all of our phone's functionality! We cannot utilize the extra screen space of our phone, nor can we provide data from our phone's sensors to the website. Hence, we came up with the idea for a service that could link the functionality of mobile devices with traditional full-size computers. (And we named it AquaPoodle because why not?)

What it does

AquaPoodle Transfer (hence referred to as APT) is our proof of concept for a web service that can take data from a mobile device and provide it to a desktop or laptop computer in a simple and accessible manner. To allow a user to send data from one device to another, there are three primary steps:

  1. Establish a linkage between the mobile device and the computer using a QR code,
  2. Provide a mobile site to prompt the mobile device to obtain some data, and
  3. Send the data from the mobile device to the computer.

How we built it

The actual implementation of APT is fairly involved. Here we will break down the primary steps into the actual code involved.

Establishing a linkage: Ensuring that the user's mobile device and computer are linked requires a lengthy process of developing a unique session ID and then passing it from the computer to the mobile device with a QR code. To achieve, this, the unique ID must traverse the hierarchy of the code, from the web service down to the mobile device.

To begin the external web service generates a unique ID hashed from the mac address of the computer, the current time, and an internal device counter. The user will utilize a chrome extension that will then receive the unique ID. From there, the external web interface develops a QR code based on the URL that the mobile device will navigate to, and the unique ID. The QR code is then provided to the chrome extension. The user then scans this QR code with their mobile device's camera. At this point, the chrome extension and the mobile device both have the same unique ID.

Prompting the mobile device: Prompting the mobile device to provide some data, in this case a photo, is achieved by navigating to a URL that contains javascript that provides the appropriate prompt. This URL is contained in the QR code referred to earlier. Here, assuming an android device is being used, the user may choose to provide a photo in the mobile device's storage, or to take a new photo. In either case, the photo is sent via a post to the server, which then caches it.

Sending data to the computer: Finally, the server can take the cached photo data (here encoded in base 64) and send it through a post to the user's chrome extension. The chrome extension then decodes the photo data and displays it in the toolbar to then be used where appropriate.

Challenges we ran into


We ran into an inane number of issues over the course of our 24 hours of coding, which are compiled here:

  1. Chrome extension errors: Numerous issues arose from finding out how to make a chrome extension interact with an external server and update accordingly. Many google help pages were queried.
  2. Uncountable number of server errors: There was a constant fight against server errors as we slowly but steadily worked our way through syntax and configuration problems, fueled by coffee, red bull and Huel(TM). We tried to host our server on but the domain provider eated it (T_T) .
  3. Session IDs that are not so unique: Determining a way to make session IDs that wouldn't clash required some trial and error as we logically decided which unique values could be used to make session IDs.
  4. Android apps that don't compile: We attempted to develop an app that would provide the functionality achieved by the mobile site provided through a URL in the QR code. Achieving this proved to be infeasible for the amount of time available, as working through the complex syntax of the Android code API and implementing a separate library to read scanned QR codes was just too much.

Accomplishments that we are proud of

  1. Implementing an external library in Android code API to (nearly) provide functionality with reading barcodes or QR codes.
  2. Hosting our own server!
  3. Creating a functional chrome browser extension!
  4. Having fun and not losing our sanity!!

What we learned

Although we learned tons about javascript and server hosting, our most important development was how to work as a team. Splitting the workload efficiently, organizing meeting times and working together with synergy was highly rewarding and essential to our success.

What's next for APT

One early example we envisioned was to display a user's shopping cart for a given webpage on their phone, and then allow them to select items from the phone shopping cart to navigate to the appropriate webpage on their laptop or desktop. Given the chance to extend APT, we would like to work on extending the functionality to be more generalized, and at a further point in development, make an API of this code to provide more possibilities with sharing data between mobile and full webpages, so that the first idea could be possible.

Share this project: