Table of Contents
Whether you are a developer or just a user, the way Uber’s taxi booking app works must have surprised you for at least once. But have you ever thought which deep-rooted problems Uber has puzzled out to deliver such a magical app? And more importantly, how they have doped out those problems?
In this blog, I will exhibit 5 different mobile app development challenges or problems and will answer a much-anticipated question that how Uber has solved that problems like a piece of cake?
Keeping the app alive all the time
Generally, most of the apps are developed to satisfy interaction-based tasks, like sending a message or sharing a photo. As soon as the user closes the app and clears the memory, the app is no longer in the active state. But with the case of Uber, driver partners keep the app open for hours to get the ride request, check the earning details and to find the route. Most of these features are only accessible when the app is running. So, If a driver is online but closes the app and clears the memory, he cannot get the ride request. Uber wanted to fix this issue and so, they did it. They wrote a code in such a way that the app keeps running in the foreground even when there is no activity in the background.
In the following image, you can clearly see that the driver gets the ride request when the app is running in the foreground (left image). He even gets the request when the app is running in the background (right image).
However, Uber has found that the approach they were using to keep the app live all the time was not the best in the class. As a result, the app became code-heavy and troubled drivers with its unexpected behavior and duplicate features.
Following are a few more problems associated with Uber’s previous driver app.
- Rather than just in a small part of the application, feature classes of the app existed in the application scope.
- Code duplication was the standard issue.
- When the app was back-grounded, head-up notifications popped up every time.
Uber opted out MVC architecture and introduced a more advanced architecture named RIB(Router Interactor Builder). It takes the decision within its scope and avoids unnecessary activities.
Because of the RIB, Uber wrote an activity-independent code, which means, the driver gets the request regardless of whether the app is running in the background or not. Similarly, the navigation runs regardless of whether there is an activity related to visually displaying navigation direction or not.
Not only Uber but all other apps for on-demand services and e-scooter rental businesses are equipped with the in-built navigation for drivers and riders. But what matters the most is the accuracy of inbuilt navigation!
Talking about Uber, Uber openly accepts that navigation of its app isn’t 100% accurate. The inbuilt map often shows the wrong route or long route to the drivers. Following image belongs to official sources of Uber, depicting how errors in the map can impact the service.
Sensing the urgency, Uber has started working on map inconsistencies. But the approach they have chosen is remarkable.
They have built CatchMapError system that keeps getting GPS signals from driver app and automatically identifies the errors in the map. How? Let’s find out.
Refer the following images, image A and image B. Image A shows the suggested route driver has to follow and Image B shows the route which driver has preferred as there is ‘no right turn’ sign at the intersection of 8th ave and Fulton street. Uber’s CatchMapError system keeps the eagle-eye on this kind of disparities and updates the map.
(Image A – Uber’s suggested route)
(Image B: What driver has preferred)
More than 70% of people consider app size before downloading it and the size of the Uber app is relatively high, around 60 MB because of so many services, languages, and payment methods. That app also demands higher network bandwidth and specific hardware performance.
While Uber’s driver and rider apps were breaking all records, data revealed that many riders from Latin American countries and Asian countries don’t have sufficient network and devices with higher performance rate.
To address this challenge, Uber developed a Uber Lite app which works perfectly even on old phones and with lower network bandwidth. But how they developed the Uber Lite app which is sized under 5 MB? Let’s figure it out.
- The map takes up lots of bandwidth. So, Uber added it as an option and riders can optionally see the map if desired.
- Instead of the address of the pick-up location, Uber Lite only allows riders to add a point of interest or current location.
- The library is one of the reasons why the Uber app is sized 60 MB. So, they became very particular while building Uber Lite app. They tied up with many library owners and split those libraries into desired modules only.
- They used RIB to terminate unnecessary layers from the architecture.
- Instead of PNG resources check-ins, they used vector image formats.
Big data challenge
Users using mobile apps provoke a pile of data. Generally, this data is divided into queries and users data. All major companies prefer to have big data to analyze and improve their services. It also helps them to measure success before launching a new product.
If we talk about Uber, then there is no other company which relies on data as much as Uber. Uber accommodates a dedicated data warehouse team to maintain massive data. But it is an uphill battle to maintain data that is sized in petabytes. What makes it even more challenging is the fact that storing data requires storage options which are costly.
During Uber’s initial years, they adopted a fairly common approach and stored the data in different clusters according to the nature of the data. They also used to replicate all data to keep their business running when data of a cluster is somehow damaged.
But as the size of data increased, they soon found out that fully replication approach – replicating each piece of data across every cluster, wasn’t efficient. Thus, they opted for the partially replicated database system.
However, due to thousands of queries and hundreds of tables, the storage requirement in the partially replicated database system is also high. So, how the data scientists of Uber has solved this problem?
Thanks to empirical observation, data scientists of Uber have found out that only 10% of the data utilizes 90% of the disk. So, if they configure only that 10% of the data, they can easily achieve disk space efficiency.
Moreover, they also have written a few algorithms which generate purposefully sub-optimal solutions and save disk space up to 5%.
If a user comes across any trouble, the app allows him to contact the customer service executive on a chat or on a call through the mobile app itself. But for Uber, it isn’t as easy as other apps.
Considering the way Uber app works, the driver is also the fundamental part of the customer service. So, Uber app lets rider text Uber driver if he is not moving toward the rider. But for the driver, it is dangerous to reply rider while driving the car. This is why Uber started thinking about a possible solution that allows drivers to drive and communicate with the riders at the same time. And soon, they came up with a smart reply feature or one-click chat.
The one -click chat makes the conversation between riders and drivers faster and more seamless. When a rider sends the message to the driver, the driver can reply to him by clicking on any one suggested reply. This magical thing happens because of machine learning and natural language processing.
Consider the following image. It presents the working model of the one-click chat. Here, if you look closely, you will find out that the OCC model is very important.
The OCC model is divided into two parts – intent detection and reply retrieval. Intent detection module receives the message and finds the intent in it with the help of machine learning algorithms and natural language processing. It then shares the intent with the reply retrieval module which finds the answer and shows 4 suggested replies.
In the nutshell
Uber is undoubtedly one of the most robust mobile apps. They have achieved it with constant app development practice and with the efficient use of machine learning, AI and natural language processing. But they are not done yet. They are still powering up their app by employing many groundbreaking technologies. They solve all taxi app development related problems in the most possible ways. If you as a developer ever want to marry with inspiration, read Uber’s case studies.
About the Guest Author
Vishal Virani is a Founder and CEO of Coruscate Solutions, a leading taxi app development company. He enjoys writing about the vital role of mobile apps for different industries, custom web development, and the latest technology trends.