Team JenericspresentRendezVenue
RendezVenue Demo Video
Find, attend, and organise events!
This is your new go-to app for retrieving, collecting, and curating events on the fly within an Android environment. RendezVenue simplifies the hassle of scouring event content with a targeted search functionality to get the events you want, where and when you need them.
Do you prefer working with Outlook, DigiCal, or maybe even simply Google Calendar? No problem, we’ve got you covered. Effortlessly synchronised to a local calendar app of your choosing, RendezVenue takes a holistic approach with full system integration.
We worked to a tight MVP, building from a clear concept to a robust, clean, and bespokely-crafted implementation. The idea for RendezVenue evolved from a desire to create a product from which all team members would benefit. This was about the group, not the individual; we wanted everyone to feel that the project was as much their own as it was anyone else's. As the project progressed, things got interesting. Our awareness of new technologies and methods allowed us qualify the project with a unique twist and a complete momentum of its own.
RendezVenue boasts a slick UI experience, with automatic background location filtering kicking in from the get-go, granting instant access to events as far as the eye can see. Entrusting response caching and computationally-demanding processes to the backend keeps the user experience uninterrupted. The frontend team have worked hard on embellishing the visuals with snappy graphics, elegantly designed, laid out, and all carefully chosen to complement the overarching theme.
The Team
Jack Goodwill
Jez Davis
Jude McElhone
Joel Tan
Jannel Jones
Technologies
In the backend, we have a Spring Boot REST API which connects in to a remote PostgreSQL database instance hosted within Neon, structured within the Spring Data JPA framework for Hibernate. Communication with our third-party API is mediated via the RestClient dependency with Google Guava for cache management. We relied upon JUnit and Mockito for testing. On the frontend, we worked within the Android Studio IDE relying upon the Jetpack Navigation, Glide and the Retrofit client.
To keep compliant with the external API's Terms of Service, for which there were clear stipulations on data retention, we made use of Google Guava for automatic cache management. This gave us the ability to store Ticketmaster's proprietary data, giving multiple users, within a set geographic area, the ability to retrieve content instantaneously and tailored to meet their particular search criteria. The cache is automatically cleaned when data is deemed to have grown stale; that is, where it has either gone unused for a specific length of time, or where it has existed in the cache for more than a maximum amount of time, whichever comes first.
Guava was an easy choice for this case, as it is extremely well documented and was quick to integrate into our program - a key consideration given the acute time constraints under which we were operating.
We used Jetpack Navigation for its robustness, allowing us to give a fluid user experience when navigating between sections of the app. Use of a NavController allowed for smoother navigation between various layers with multiple points of entry. Implementing a NavGraph gave us complete oversight to sensibly structure our navigation paths. It also allowed us to visualise how our data was being passed between fragments, relying on the SafeArgs dependency for inter-fragment type-safe navigation. We used Glide in our Android frontend to load and display images effectively. Once images are loaded, Glide also facilitates efficient caching, allowing for a polished and stable user experience while browsing images.
Challenges Faced
Frontend:
Creating Dialog boxes to ensure that Date and Time fields were uniformly shaped to work with, not only the internal Calendar Provider API, but also our very own Spring Boot API backend. It was, in fact, through a combination of helper classes and the invocation of SafeArgs functions made available via the Jetpack Navigation libraries, that we found a solution, transforming the Date and Time fields accordingly. Adapting the app’s theme also proved more difficult than we had anticipated. The high level of thematic customisability was a mixed blessing; a stark reminder that with great power comes similarly great volumes of dispiritingly dense documentation.
Backend:
The greatest accommodation was ensuring that we adhered to the Ticketmaster Terms of Service for continued use of their Discovery API. We were limited to a default quota of 5000 API calls per day, rate limited to 5 requests per second, and limited to 200 instances of Event per response. Similarly, we had to keep compliant to their terms on data retention. This forced an immediate revision and a partial overhaul of our design for the backend. Yet we were adamant to keep using Ticketmaster. The solution: delegating automated cached management to Google Guava. It allows us to track data usage and flush stale data periodically, all the while enhancing response times on the frontend and limiting third-party requests. It felt too good to be true, but it works flawlessly; the proverbial two birds with one stone.
FAQs
On which external APIs does RendezVenue depend?
Our ethos centres on limiting over-reliance on external APIs. We rely solely on Ticketmaster's Discovery API.
Where can I get RendezVenue?
We will shortly be making the project repositories public. Please be aware that some of the critical files required for AES encryption will not be made available with this release.
Is RendezVenue available in Kotlin?
Not presently. This project was foremost an exercise in developing a full-stack Android application in Java.
How long is a piece of string?
Great question. For an empty string, about 40 bytes, I believe.