Corner/Edge Cases in Mobile App Development
Published on September 10, 2021
This post was originally written in 2017, but we've updated it to be more accurate in 2021.
It's safe to assume that when you put your app in a user's hands, they will follow the path that's laid out before them. For example, you can guarantee that every time a user launches your app, they will start with Screen A, tap on Button 1, fill in fields I, II, and III, and then tap Button 2 to send that form... right?
In our many years of experience building digital products, the only thing that is safe to assume is that your users will always find a way to make your app do something you didn't plan for.
In some cases, your user will push your app to the extremes of its capabilities. This is what we call an edge case.
Other times, they'll find a creative way to use your app which you didn't intend. These are what we call corner cases.
What is an edge case?
An edge case occurs when someone is using your app at the highest or lowest extreme of its intended operation.
Let's say you're building an app in which a user can upload many photos at a time. You might expect an average user to upload 1-10 photos at a time, but let's say a user uploads their entire 100,000+ photo library in one pass. Your system would certainly experience an edge case at that time.
Another example: you are designing an e-mail app. For someone who keeps their inbox organized and sorted into several folders, you might not see a lot of edge cases. On the other hand, for someone who never archives any e-mail, your system might need to handle a single folder with hundreds of thousands of e-mails. That person (which, let's be honest, I'm referring to myself) would be pushing your system to its limits and would certainly constitute an edge case.
How do you fix an edge case?
The easiest way to fix an edge case is to define the smallest and largest values that you will allow for your app.
Using our photo sharing example above, we could force the user to choose at least 1 photo, but limit them to a maximum of 100 photos per session. That way, we can design the system to account for a single photo (the minimum edge) and 100 photos (the maximum edge). If the system can handle those extremes, then it's safe to assume that it can handle any amount of photos in the middle.
Sometimes, defining a maximum may not be a reasonable solution, as is the case for the e-mail example. It would be a horrible user experience for myself if I were only allowed to have 10,000 e-mails in my inbox inside your app. You'll need to get more creative with your programming to handle these cases.
One approach to solving edge cases is a technique called "lazy loading." When it comes to e-mail, you will never need to have instant access to every single e-mail you wrote. You could assume that a user will only need instant access to e-mails received in the last 7 days. When your app starts, you could load those recent messages for quick display. If the user decides to read an e-mail from three months ago, they could search for it and have the system load it at that time (in other words, it could "lazily" load that message).
Side note: I’m working on my digital hoarding after reading this article that uses interactive animations to reveal the collective environmental cost of our cluttered inboxes.
What is a corner case?
A corner case is the result of a user executing an unexpected sequence of actions which leads them to an unexpected area in the app.
In other words, the user does something for which you didn't account when designing your app.
Let's say that to use your app, a user needs a valid e-mail address. In order to verify their e-mail address, you run it through some code to check that it uses one of the common top-level domains (like .com, .net, .org, and .edu).
The app would correctly validate our
jedmahonisgroup.com e-mail address, but using our
jmg.mn e-mail address would not make it past your validator. By golly, we've just found a corner case!
Another example of a corner case would be a user accessing your app from an outdated device. Given Android’s fragmented marketplace, this corner case is quite likely to occur.
How do you fix a corner case?
With experience, you can account for most of the common corner cases by making smart design decisions up front. Using our e-mail validator example, we would no longer use a validation algorithm which doesn't account for the new top-level domains.
Another great way to account for corner cases at the earliest stages of development is to use trusted open source software for common components into your app.
For example, your Android app needs to scan barcodes. If you were to roll out your own tool from scratch to do the scan, you would need to account for a variety of factors, including:
- The different cameras on each Android device
- Presenting an image on the screen
- Prompting the user to center the device on the barcode
- Reading the image to see if it has a barcode
- Correctly determining which of the many different types of barcode standards you'll use to interpret that barcode
Instead of wasting your time and introducing countless corner cases into your project, you could research and incorporate an open source library. Choosing a framework in use by a lot of other developers likely means that they've already run into and accounted for those corner cases.
Unfortunately, there is only so much you can do to account for corner cases at the early stages of development. More often than not, corner cases only become obvious the second you get your apps into the hands of your customer.
Users are always going to find unintended ways to use your software. By monitoring crash reports/analytics and constantly asking for feedback from your customers, you can get better insight into the actual use of your app, and decide how you want to address these corner cases.
You can fix a corner case in many ways, including:
- Update the user interface to make the intent of a feature crystal clear
- Update the backend of the app to handle unexpected user input
- Educate your users on the expected way to use the app by publishing tutorial videos and blog posts
- Ignore it
Sometimes, the best approach is the last one. Often, a corner case occurs under a set of circumstances which are incredibly difficult to reproduce. If a developer cannot easily reproduce a corner case, it can take a lot of time (and ultimately money) to fix them. The cost to fix every single corner case may not be worth it in your product.
Opportunities, Not Bugs
Let me be clear: your digital product team is responsible for hunting down and eliminating as many bugs as they possibly can before shipping to your customers. Unit testing is a great strategy for dealing with corner and edge cases, and real world tests performed by a quality assurance team will ensure your app is performing to the best of its ability.
The unfortunate reality is that corner and edge cases are part of doing business in the digital world. To add salt to the wound, it's often your best customers who end up finding them, because the power users of an app will run into its limitations and quirks before a normal user.
The good news is that this presents a golden opportunity to deliver a great user experience for those users!
Listen to feedback from your customers. If they're pushing your app to its limits and hitting edge cases, work with your engineering team to reach a solution which will help them get the most out of your app.
If they are pressing a weird combination of buttons to trigger a crash, take the time to understand why they chose that combination. It might lead to you changing some confusing UI and creating a better app experience for everybody.
The best apps find a way to gracefully handle an edge or corner case, and choosing a great product development team will be the first step you can take to make sure your users get the most out of your app, no matter how they use it.