A Marketplace where every User can be a Renter, or a Rentee.
“Try-before-you-buy.”
This simple but important concept is the backbone of our waste-reduction app, eRent.
About
Vision
Create the ultimate marketplace for reusing and reducing waste produced by product over-consumption; the best way to try out a product before making the purchase decision.
The Problem
People are often stuck in a predicament when faced with buying something expensive: Buy it and enjoy it, or regret the purchase (or don’t buy it all).
People may also have too many things, which sit idle in their garage or elsewhere; they could be rented out during downtime, to make a passive income.
The Solution
eRent aims to fix these through providing a marketplace where anyone can be a Renter or a Rentee.
Renter: put items you own up for rent; choose the price and duration.
Rentee: browse thousands of items; try out products without much commitment.
Features
Account Management
Create an account, and
join the eRent community.
View your profile to see
your ratings and posts.
Bookmark posts to save
your favourite items.
Posting and Renting
Create and delete posts featuring your items.
Browse the homepage
to find the latest items.
View posts for more info
and rent out an item.
Tech Stack
Our team, SegmentationFault, is very proud to share with you our Tech Stack, which powers eRent; we used a Git Flow branching strategy for branching control.
The UI Layer was inspired by the likes of Google and Windows. Google’s Material You design centers around rounded corners and drop-shadows for elements, without overusing shapes. Furthermore, Windows 11’s interface also follows these guidelines, with simplicity at it’s core; shapes are simple. Finally, gradient’s are splashed on all backgrounds to give a friendly and welcoming feel to the overall experience.
The Logic Layer connects both the UI and the DB layers between seams. It uses Dependency Injection with Interfaces for all Object and Database instances, and obeys S.O.L.I.D Principals, avoiding Code Smells. The Domain Specific Objects (DSO), passed between layers, are Post and User objects (by ID). In addition, it does Unit, Integration and System testing using JUnit and Mockito.
Finally, the Database Layer uses HyperSQL for persistence and general storage of posts and users, and has many tests to ensure data is properly stored, added and used.
UI
Material You (Shaping)
Soft-Gradient (Backdrops)
Glassmorphism (Elements)
|
Logic
S.O.L.I.D Principals (Code Smells)
3-tier Testing (Between all seams)
Dependency Injection (Interfaces)
|
Database
HyperSQL (Persistence)
JUnit & Mockito (Layer Testing)
Meet the Team
Learn about the amazing team behind the app, alongside what they learned since joining the project.
Brett
R O L E
Database Layer Developer. Logic and DB Layer linking. Main documentation writer. Resident SQL and Git Expert.
L E A R N E D
How to write JUnit and Mockito integration tests; bring all layers together in Android Studio; channel patience, leadership and communication into everyday workflows;
Alejandro
R O L E
App visionary. Architecture planning (whiteboarding, dependencies, features). UI Layer Developer.
L E A R N E D
How to break down features by dependency and layer; keep track of large scale architecture; organize members and tasks; maximize MR and Branching potential.
Kaiden
R O L E
Logic Layer Developer. 3-Tier seam connections. Extensive Unit, Intergration, System testing.
L E A R N E D
How to harness Android Studio’s full toolset; use Git and Git Workflows; link layers between seams; write Mockito and Espresso testing suites.
Ishraq
R O L E
Logic Layer Developer. UI and Logic Layer connections. General App display and functionality.
L E A R N E D
How to work cooperatively as a unit; take task responsibility; understand Android Studio; deeper understanding of App logic layer functionality.
Shaun
R O L E
Database Layer Developer. Extensive DB functionality additions. Integration and Unit Testing
L E A R N E D
How to write JUnit tests; write integration tests; test using Mock Databases; use Git and Git Workflows; plan and structure interfaces for a wide range of Database usage.
Retrospective
Overall
Our team came up with the idea for eRent within the first couple minutes of brainstorming; we were inspired. Unfortunately that also meant our features list was a bit bloated and unrealistic. Here is a breakdown of how our project went, with the hindsight of completion.
What Worked
- Everyone was an expert in at least one of the layers, so we were fast to build them.
- Communication was constant, and questions were encouraged.
- Planning was done well in advance and work was dynamic, allowing priority switching.
- All members were understanding of the knowledge level of others, and there wasn’t many disagreements.
- The features we ended up focusing on were robust, and had depth to them. We also all agreed upon a dropping a feature, when the need arose.
- Comments were plentiful, and code was professionally written; no shortcuts or bad practices made it to final releases.
What Didn’t + [Iteration fixed] Solution
- Dev Tasks were not properly used, so people weren’t sure where to start
- [I1] Additions/changes of any size now required a dev task.
- Some features were too big, but we didn’t want to accept that.
- [I2] We sat down and restructured our feature list in a realistic way.
- Branches had no set rules, and began becoming hard to track.
- [I1] Fully switched to Git Flow, with a main, dev and feature branches.
- Some Database and Logic code went untested.
- [I2] With more time, code coverage was >80%, and Mockito was added.
Individual Thoughts
Alejandro
“We started overambitious, trying to stuff too many features in, but overall we overcame any hurdle thrown at us. Everyone pulled their weight, and Dev Tasks were used to their fullest to dish out work efficiently. The resulting app is something we are all proud of.”
Brett
“We started slow as everyone got to grips with the tools, but once we had then productivity skyrocketed. Through effective use of meetings and Dev Tasks, we maintained excellent communication and were able to deliver an amazing app.”
Israq
“Our journey started with ambitious goals, stumbling initially. However, strong communication and effective task distribution kept us on track. As we grew more adaptable, we achieved our project objectives, delivering an exceptional app.”
Kaiden
“At the start we didn’t know the tools well and were a bit disorganized; we didn’t get much done. However, after the first iteration we committed to being more organized and we saw our productivity rise greatly. Overall I think we did a great job and I am happy with the app we were able to make.”
Shaun
“We started with a lots of goals to reach, but soon realized that we had underestimated the amount of work that needed to achieve them. However, thanks to good communication and distribution of tasks between members, we were able to complete the required goals and deliver an awesome app.”
Closing Remarks
This project was an amazing venture into how applications are planned, created, launched and then maintained, in the real world. You learn what works, and what can go wrong (and something will go wrong).
Most importantly, you learn the solutions for said problems, and how to ensure they are minimized in the future.
As it stands, in final release form, eRent was a great first attempt.