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.
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
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.
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
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.