Slip

Inspiration

There's nothing more awkward than showing up to a huge networking event at your co-op job being the only millennials who don't have business cards. The first though is, "Why not get business cards?", followed by, "Because I don't want to spend money" and "Because carrying around tiny paper rectangles is annoying," among other things. So, like how it goes with most things these days, business cards becomes an idea for an app, and that app is Slip.

What it does

Slip is a "digital business card platform." On its own, there are a few advantages to a "digital business card." For one, it is easier to collect cards, since most of our physical collection resides crumpled at the bottom of our bags.

But, today, most of our portfolios are hosted online, particularly for hackers, on platforms like LinkedIn, Github, maybe even DevPost. A digital platform could let you share your entire online portfolio at once with peers. And that's what Slip does. It lets you centralized your professional social media and portfolio.

Sign up and integration

Users can sign in with pre-existing accounts with a variety of options, from Google and Facebook to LinkedIn and Github. Later on, they may decide to add more accounts to their Slip profile as they see fit. Users' accounts are displayed on their profile page so that their connections can easily find their social media or, for example, visiting their Github page.

QR Code scan to add

Users can conveniently collect and distribute their digital Slips in-person using QR codes. The codes also carry basic information about the users to be displayed until Internet access is available.

Geo-location

Slip enables users to view potential connections nearby in order to help them build a network of professionals. Slip also lets you leave "geo-messages" for nearby people to read and comment.

View Mutual Connection

If you have mutual connections in the first degree, and or second degree, you can view these connected connection as well. Then try to expand the connection from there.

How we built it

We wanted to build a fast and beautiful app that is very accessible. Therefore, we chose Android, which has an ecosystem of about 70% of all mobile users. We dove right into prototyping our app by building the backend and login system while one of us working on UI mockups.

We quickly assembled a flexible user profile system that allowed us to add more features as we needed to. Once enough of the database code was working and the UI was designed, we started adding features left and right: integration of LinkedIn, view nearby connections, see other's connections, leave geo-messages, etc.

When the app started to grow in size, we sat down and had a pseudo architecture meeting where we planned out how future and present features would fit into the app overall and how we could make the code cleaner and more maintainable.

Challenges I ran into

Integrating the app with firebase was the most challenging issue I've run into during the course of the project. In the past, I used to set up a mySQL server on local host. And then handle the request by having java jdec communicate in SQL directly with the database, or do it through PHP. however, since we are under a more strict time limit here at HackPrinceton (given 36 hours), I have no choice but to use a more established database connection service that is Firebase, provided by google, for Android. This database allowed authorization, google sign-in, cloud-messaging, and a Relational database all at once. However, since it is pretty high level, I do not have write the code for lower level functions, and so I was not quite sure how this structure works. In fact, different than previous dbs, at Google Firebase, you do not handle your own user session transition. The firebase handles it for you. So you make your changes to user log in state, and then through a listener called mAuthListener, the Firebase SDK decides whether your user data has changed and then make decisions for you, if user == null, then signs you up, if not != null then signs you in. Because I do not handle the user state transition myself. it was not that intuitive for me to catch that the firebase detects the user itself in a listener. This took me the entire Saturday afternoon to figure out. Enventually, by consulting my partner who is an expert in working with databases, I learned that the listeners are implemmented in each classes, so that when something goes out of hand, the listener would always catch that and take action against the response.

What I learned

I learnd how to manipulate AysncTask in Java I learned to work with Google's Play service API I learned how to incorporate Facebook SDK into the app I learned to not overestimate what you can do within 36 hrs I also learned to not leave documentation / this hackathon description to 4 am to start writing.

What's next for Slip

We should employ more advanced data analytics and integrate with machine learning to help users centralize their accounts and discover others. We can potentially flesh out geomessaging into a separate app just for fun. We also aim to spread the word for our app. We currently have about 40 users signed up and we want to aim for 100.

Share this project:
×

Updates