I have always been fascinated by Machine Learning, and I wanted to create a project that would allow me to utilize this area of research. Along with this, I noticed the growth of Salesforce, the world's largest CRM tools and wanted to see if I could make something that would empower businesses to keep track of customers (or potential customers), similar to what Salesforce does. Today, Twitter is becoming a large part of the way businesses interact with customers and I felt the space for a tool that integrates Twitter and CRM has not been adequately filled.

How it works

Users can start obtaining data for a marketing campaign by entering a hashtag. This hashtag is then sent as a GET request to the Twitter Search API. Before I send the GET request, I filter the possible results by removing retweets and ensuring the most popular (100) results are shown. Once the tweets have been retrieved, the text of the tweets are sent as a POST request to, which returns a sentiment and confidence score. If the confidence score is below 70, I ignore the result returned by the endpoint. Data is then stored locally and presented in an easy to read format. A key feature is the fact that users can add "Engagements", that is to say, target specific users and interact with them. The UI was created with UIKit and Masonry (a wrapper for programmatic AutoLayout).

Challenges I ran into

One challenge that I ran into was that data was loading very slowly. Twitter's API returned results quickly, but the same could not be said for the sentiment endpoint. Due to the architecture of my app at the time, the Twitter API would stop getting called as the sentiment API was running. Looking into how to optimize my network calls, I learned about multi-threading. I ran the sentiment API calls on a background thread, enabling the important data to load quickly and ensuring that the user could still interact with the UI.

Unfortunately, running calls on the background thread, made it hard to know when to update the main thread. To solve this challenge I attempted to use NSNotificationCenter, which ended up solving the issue. I am still working on fully understanding how this solution worked, and I am confident I will be able to do so.

Another challenge I ran into was deciding how to store the data of the app, as lots of data was coming in and going out. To approach this challenge, I decided to use a singleton, that could be read and written to from anywhere in the app. This challenge was overcome during the hackathon, but as I move on further with this project, I will look into using Core Data to handle the data.

Accomplishments that I'm proud of

I am proud that I was able to create a functional prototype of a powerful tool in under 7 hours. Furthermore, this was my first hackathon, and I am glad to enter the world of hacking!

What I learned

Through this project I learned about multi-threading and its use case. It's impact was understood when I was optimizing my application. Along with this, I learned about "blocks", a language feature of Objective-C.

I also learned more about HTTP requests with Objective-C and found a powerful wrapper (UNIRest) that I intend to use in my future iOS projects.

What's next for Pipio

The next goal for Pipio is to use a better API to analyze the sentiment behind a tweet. The current API is not very accurate, and I am interested in working with IBMs AlchemyAPI.

I would also like to add more features to Pipio and store the data in a database for faster query and more structured storage of data (Core Data). Additional features would include: having a conversation with a specific tweeter, increasing the size of the data set and presenting data in charts and diagrams (with the option to save as a PDF).

I am excited to continue with this project!

Built With

Share this project: