MySongsList App

Project collaboration with: Michael Law

This app was made as a collaboration between a friend and myself.  The goal of this app was to further practice Android development skills, while also working with different API’s and integrating their services together.  The idea in the app was to tackle the problem of finding and keeping track of music you like.  To do this, our app accesses your account information on 8tracks, which calls itself ‘Handcrafted Internet Radio’, and tracks the songs you have marked as favorites, and stores the song name and artist in a file for you, which can be accessed either online, or on your desktop, using a Dropbox account.

The main components to this project were:

  • Access 8tracks API for song information
  • Store songs that have previously been marked as favourite’s in an SQLite database on the Android phone
  • Access Dropbox API for storing your songs list in a text file

The 8tracks API  is set up quite well for this task, by making a simple call to the API as follows:<USERNAME>/favorite_tracks?api_key=<API_KEY>&format=json

This call returns a JSON object containing all the information about every song currently marked as a favourite by the given user.  We then parse the JSON object to grab the song and artist names of all of the songs.  After the songs have been found, they are displayed to the user, who can then choose which songs they would like to store.  Users can either select them one by one or they can be selected all at once by tapping a single button.  All songs that are found are stored in an SQLite database, which tracks whether or not the track has previously been stored.  This is shown to the user by displaying those songs over a red background, as opposed to a green background for songs that have  not been selected before.  However, previously selected songs can be double tapped to have them added to the file again.

Integrating with the Dropbox API was very quick and easy, by following their tutorial we were able to create and access our file within the Dropbox folder without issue.  Dropbox has set up their API quite nicely, so integrating it looks very clean and easy to use.


Screenshots of multiple different views of the app functionality.

Tagged , , , ,

Charity Communication Platform App

Project collaboration with: Michael Law, Tim Schonberger

This app was made in November of 2012 as part of a community Hackathon competition in my workplace. The Hackathon competition required teams to develop an app solution for a given charity’s business problem.

Our assigned charity was looking for a way to enhance communication and engagement between their customers, in the first world, and their suppliers, in the third world.  This had the unique challenge of creating communication between the two while the suppliers only had basic phone and texting services on their cell phones.

My team, consisting of two coworkers and myself, designed a fully functioning app with the 24-hour time frame between the announcement of the business problem, and the judging.

Our solution involved multiple components:

  • Display products and suppliers in a coherent manner
  • QR-Reader, to create an initial link between products and the app
  • Connections to the charity’s online store
  • Profile pages for the suppliers to provide personal information and display communication between the suppliers and customers
  • Ability to send a message to the supplier directly

Note: Portions of the screenshots have been blurred to protect anonymity for this project.

Displaying Products/Suppliers

The basic functionality of the app allows the user to either sort through the available products by their name, or to sort by the name of the supplier of the product.  Clicking on products would load the online store webpage for the product while still in the app itself.  Clicking on the supplier would load a page displaying all the products created by that supplier, along with buttons linking to that suppliers’ profile page and to a page allowing for a message to be sent to the supplier.

The information for the suppliers and products is all located in a simple MySQL database on our webserver.  When loading, the app calls a PHP script on the webserver to grab all the information required for both the products and the suppliers’, which the PHP page returns in the form of a JSON object.  The JSON object is then parsed and the objects for each of the products and suppliers are created.


Supplier and Products views



A QR-code

The idea behind having a QR-Reader is that QR codes would be located on the merchandise, and when scanned using the QR-Reader in the app, they will launch the profile page of the supplier within the app.

We decided to set up the system so that if the QR  codes were scanned outside of the app, they would still lead to the profile page within a web-browser, however, with a message that the app can be downloaded for added features, such as communication between the customer and the supplier.

To implement this functionality, we used the open source library ZXing.  Which is a library for Android and Java that can process multiple different formats of both barcodes, and QR codes.

Implementing ZXing was done using the same techniques found in their tutorial here.  All we had to do after following that tutorial was supply the code to handle the scan result to verify a correct QR code was scanned and launch the profile page.

Profile Pages

Profile page

Profile page

We created basic profile pages for each of the suppliers dynamically, by loading their information from our MySQL database.  Information displayed on the page included their name, photo/logo, how long they had been a supplier, as well as communication logs, showing both what the supplier has been saying lately, and what others have been saying to the supplier.  These pages were created with the aim to more directly engage and invest users in their preferred supplier, as well as show the communication between users and suppliers, perhaps answering any common questions.

The information loaded from the database, includes: Name, photo web address, supplier start date, profile text, and communication username.

The communication information is loaded using the methods described below.

Communicating with Suppliers

The toughest part of this project was coming up with a way to communicate with the suppliers, using only texting services.  The key to doing this, within the constraints of the 24-hour competition, was to do this in a way that was quick to implement, and completely scalable.

Posting a comment to the supplier

Posting a comment to the supplier

I came up with the idea to piggy-back on top of another service that already has the text communication infrastructure in place: Twitter.  Twitter allows for users to send and receive tweets directly from their registered cell phone, so all we had to do was integrate their service into our application.  As well, Twitter limits the number of characters that can be sent in a message to 140 characters, less than the 160 characters that SMS text messages are limited to.

Twitter was integrated into our app using the Twitter4J API, an unofficial Java library for communicating and connecting with Twitter’s API, that integrated with our Android app well.

We implemented Twitter by setting up one default account that all messages from the app to the suppliers would be sent through.  This way, there would be no required logging in for users.  This is advantageous in both simplicity for the user, and for security in hiding the usage of Twitter, to prevent potential abuse of the system.

Accounts for suppliers were created in a specific way by pre-pending our app’s name to the supplier’s name.  That way, our app is able to figure out which Twitter account to send the message to, when given only the supplier name.

In a similar fashion, we were able to load the supplier’s stream of tweets that they had made and display them on the profile page.

Tagged , , , , ,