StopStalk: From Web App to Mobile App
StopStalk is a one stop website for all the competitive programmers. The website provides features such as:
1. Looking all your competitive profiles at a glance.
2. Stalking your friends’ profiles.
3. Get updates about latest programming contests.
4. Searching problems as per the topics or website names and adding them to ToDo list.
5. Trending problems globally and among your friends.
6. Leaderboard both globally and among your friends.
7. Generating problem recommendations.
And many more features… Do check out yourself :)
Our team had decided to make a mobile app for the StopStalk website. The chosen tech stack was Flutter due to its awesome UI features and also its compatibility with both android and iOS. Since, the website had already a very good backend in web2py, the only problem in front of us was to fetch data and display it to the user.
The solution we came up with was to make APIs for every feature in the StopStalk website, then fetch the data dynamically and display it to the user.
During the API building, we had to deal with basically two types of APIs, GET and POST type.
The GET type APIs were the ones which did not require any credentials from the user, for example the upcoming contests and the global leaderboard. There were some features like user dashboard and friends’ leaderboard which required the user’s credentials to fetch the data and were POST APIs.
The data fetched via APIs was displayed to the user using various Flutter components with the help of FutureBuilder and async requests.
While implementing the solution, we encountered the following roadblocks:
1. Filtering Data:
It was necessary to convert the data to processable form when sent as a request or received via API. One such roadblock occured while trying to fetch search problem results via tags.
Problem: Whenever a request was sent consisting of a problem tag with more than one word, for example “dynamic programming”, no search results were obtained.
Reason found: For problem tags consisting of more than one words, the API should receive requests in the form “dynamic+programming”, not as “dynamic programming” which was not returning any results.
2. Figuring out the Right UI/UX:
It was indeed a very difficult task to figure out the right UI/UX because of the vast information the application had to offer. Consider for example, the Upcoming Contests Screen. Each contest consisted of so many fields such as Name, Date, Timing, Platform, Contest Link and Time Remaining.
Fitting so much data into tabular form (as presented on website) is certainly not a viable option for small devices.
Initially we figured out a UI with every contest card consisting of just the Name, Platform and Time with other information available on opening the card as a page as shown:
But the above process was time consuming since user had to go to another page and then come back to see all the contests, which spoiled the user experience.
Hence, we decided to use a UI consisting of folding cards which helped to optimise the space as well as reduce user time in navigation. Also, its smooth folding enhanced user experience compared to switching screens where it might even take some time to load the data. The final UI for the contests screen was thought as follows:
Further updates in the app will be published soon. Open source contributions are always welcome.
Do give a try to the app and clap for the story if you feel it is worth it :)
Stop stalking and start StopStalking