Over 855 million people in the world ride a bike, and this amount is growing. Our client is just one of them.
A few years ago, he was looking for a mobile app for cycling trips and he was unable to find exactly what he was looking for - there were many apps with tracking functions for cyclists, but they didn’t meet his specific needs.
As cyclists like sharing their results, our client thought it would be amazing to have a tracker, GPS and social network in one mobile app. That is how Bikesimizer idea came into existence.
56 miles
23 miles
10 miles
Since he was working with a limited budget, our client couldn’t afford the implementation of a full project, and it was necessary to design a minimum viable product in the most cost-effective way. Besides, there were already a lot of tracking apps on the market, such as Strava, so Bikesimizer required improved tracking accuracy to compete. We also needed to consider crucial specifics of social networking, such as high load.
According to these requirements, our team formed the next scope of work:
As the product should attract investors’ attention, we decided to implement the most valuable functions:
We implemented all these features on the base of ASP.NET Core and related technologies for the server side logic, whereas the mobile application both for iOS and Android has been done on the base of Xamarin platform.
As a social network, Bikesimizer should run a huge capacity. If all the users logged in, searched for friends and chatted at the same time, a single server wouldn’t be able to handle this capacity and would stop working.
We divided the app features between dedicated services and built a microservice architecture connected with Azure Service Fabric - a system platform provided by Microsoft.
Azure receives and spreads the load between servers. When the user limit on a particular server is exceeded, Azure creates a server clone to run an additional load. It is a great advantage for startups, as it’s difficult to predict the amount of future users and determine the number of servers required.
Using Azure Service Fabric, clients pay only for spent capacity, depending on the amount of users.
Server is overloaded
Server Clone
On the way to the clearest tracking results, we faced the problem of uncertain riding time. The thing is, during cycling people make stops at traffic lights in the city or have a rest in the countryside. Usually, it is inconvenient for users to press “start” and “stop” buttons in the tracker app every time they stop, and thus, it leads to inaccurate results.
It was crucial for us to provide the maximum possible clarity for results, so we decided to use the Google Fused Location API Provider to solve this issue. If the API doesn’t receive users’ new location coordinates within 30 seconds, the tracker stops working.
After cyclists start moving, they can switch on the tracker by themselves, or it will be automatically switched on after receiving new location coordinates.
The next issue we were faced with was extra coordinates, which led to showing longer distances than in reality, outside the town, or in bad weather conditions. GPS transmission signal worked with low accuracy and recorded with distortions.
We used the Kalman filtration to providing the most realistic tracks. If a signal is low, longitude and latitude of the tracker are calculated from:
If GPS coordinates differ from math coordinates, the tracker doesn't take them into account. If a signal is completely lost, Bikesimizer uses previous path coordinates and connects them with coordinates, under the condition that the level of signal is high.
After we dealt with the extra coordinates issue, our quality assurance team noticed that the tracker worked correctly at high (50mph) speeds, but under lower speed (<10 mph) the track recorder provided incorrect results, or even stopped recording. Our team had to provide accurate tracking at a speed of human walking, cycling and driving for Bikesimizer to compete in the market.
Developers calculated the average cyclist speed and distance, then checked our math on real distance. Then, developers analysed the results, changed coefficients and repeated these situations until we achieved the correct results. Our team used the Kalman filter to reduce the error’s impact and obtain the object’s position, so we could provide the result with 98.9% accuracy.
Team
Work Time
937 h
The web MVP
721 h
The app MVP
We have put considerable efforts into the development and testing of Bikesimizer, as we wanted to bring all the best of everything into one project. Our team provided a cost-effective solution with microservices architecture and eliminated every issue connected with tracking accuracy. We decreased costs for Bikesimizer maintenance after the launch and ensured profitable investments for the shareholders.
As a result, Bikesimizer stays commercially viable, and the number of users continues to grow. Over 29.3K messages were sent, over 15.1M miles roads were shared with other users and 420M calories were burnt. We are proud to be a part of this project and to continue our collaboration.
Andrei Yazik
Bikesimizer DWC-L.L.C. — COO
UAE, Dubai
"On behalf of Bikesimizer team let me thank you for all the great work you have contributed to our product. We enjoy the cooperation and wish you all the best! Looking forward for more help from your team."