Rendezvous

Want to notify yourself the next time you see someone else? Rendezvous is a proximity-triggered notification app.

Comment

Inspiration

We wanted an app that would allow you to no longer forget something when it comes to friends. This is the perfect app for those who live on a college campus where you are often unknowingly close to your friends.

What it does

Rendezvous uses WiFi P2P to detect other electronic devices in its proximity. By combining this technology with a social aspect, Rendezvous allows you to set reminders for yourself such as "Remind me the next time I see Rohil to return his phone charger" or "Let Zach know the next time I bump into him ..." The app takes advantage of Android's notification systems, Wifi P2P interfacing capabilities, UI paradigm, and asynchonous architecture to do this.

How we built it

Rendezvous was built on a client-server architecture. The Android app, written in Java and Android's XML UI language collects data from the phone's networking hardware and sends it to a central Flask server, which maps device addresses to user accounts and provides functionality for reminder setting, authentication, and information processing through various RESTful API endpoints. The Android app uses volley to make asynchronous requests to the server then parses the JSON responses to populate various UI elements. The server runs on the Microsoft Azure cloud and has flexible database and web capabilities thanks to SQLAlchemy and Flask. Our group of 4 split up in half to work on both parts of the project simultaneously then eventually worked to integrate both halves.

Challenges we ran into

Laying down the fundamental layer of the project, the server and database, proved especially challenging. Using a Python ORM to generate the correct model for the data was tough, but not because the code was hard. Although it was our first time using Flask and SQLAlchemy, the docs are very well fleshed out and thus made it easy to pick up as we went along. It was mores because our initial model of the data was incorrect. We continued to develop on the broken model for app routing, and not before long the code started throwing exceptions. Rather than redo the model and rework from the base up, we tried to patch up the flawed model to work with the routing, before finally hitting an impasse. After reviewing our model, we realized certain redundant or unnecessary aspects and restructured the entire ORM. Once that was completed the routing had to be refitted to the data model, before actually working.

The next challenge after that was actually connecting the server to the application. We decided to use volley and asynchronous network requests in order to connect the the separate parts of the whole. The challenge from here stemmed from the fact that it was different architecture than what we had experienced before. It was not tough in and of itself, but it did seem bulky and a majority of it was just getting the right callbacks.

Accomplishments that we're proud of

We're proud that the project was carefully created from a software architecture standpoint. This allows for better collaboration and easier future expansion. A lot of the technologies that we used such as polling data from Android hardware, deploying to the cloud with Azure, and working with ORM software we had to learn along the way and was proud to be able to integrate this in an efficient manner. Finally, our group comes from a very diverse academic background, including chemical engineering, industrial engineering, and computer science.

What we learned

Over the course of the project, we really came together as a team and learned many things. On the backend server, Rohil and Jonathan learned how Object-Relation Mappings can be useful in database maintenance and development. It allowed us more freedom in what types of data we could store in our database and how we connected that Python code to an Android app.

Jason and Zach learned many things about front-end development and Android. Zach learned about Listviews and how to display reminders and friends all on one screen. Jason, between creating the wifi broadcast receiver and managing user passwords, had to learn all the key components of security and hashing.

Overall, most of what we had to do in this project was new to us, and we are thrilled to show you our app in more detail.

What's next for Rendezvous

Rendezvous presents a unique solution to a very common problem; however, there are many features that we were not able to implement do to our time constraint. The first and foremost feature would be the ability to be notified when a friend is nearby regardless of whether or not a reminder has been set to them. In a literal sense, this would allow a user to be informed when a friend is nearby, and Rendezvous could make a suggestion to have a social interaction. This suggestion would come in the form of a textual offer to reach out to the nearby friend and the ability to reach them via some other communication app (Facebook messenger, Google Hangouts, Phone, etc).

In a more broad sense, the overall goal of Rendezvous is to bridge the gap between a college student and increase sociability in a college campus setting. The app currently focuses on user directed interactions, but we aim for Rendezvous to be able to aid the user in creating a rich social experience while in college by giving the user otherwise unknown information about where their friends are and how to connect.

Share this project:

Updates