Today’s mobile applications share some basic requirements. Users expect simplicity, responsiveness, a great-looking UI that is continually updated, and perhaps most vital: stability.
One of the most frustrating issues for a user is when their application crashes exactly when they need to perform. Poor application stability is a main reason for application abandonment. You might not get a second chance with the user, no matter how cool it is, after only a crash or two.
Suppose you are about to pay for a purchase you have just completed, after filling out a few forms and entering a lot of details. You reach the final stage, click the submit button, and boom… the app crashes.
Or imagine you are watching a live stream of your beloved sports team, and on the last critical possession of the game – your app crashes.
Here’s what TechCrunch has to say on this: “Users have low tolerance for buggy apps – only 16% will try a failing app more than twice.” And here’s some relevant data from TechCrunch:
Avoiding crashes during development - Why is catching and handling exceptions such a major issue?
First approach: Surround all of your code with a Try/Catch block
One potential solution is to wrap all methods with a Try/Catch block - that way all exceptions will be handled and the application will not crash. However, this is not a best practice since an exception is a standard way in Java to signal an error, and hiding the errors will result in malfunctions.
The issue is not simply about catching, but rather about handling errors in the appropriate cases.
For example, there is a class responsible to communicate to the backend server. Typically this class can fail sending requests. Internally this class will handle OS-level communication exceptions, however after a few retries it will give up and throw an applicative exception that allows a higher layer (say a service) to handle it based on the required business logic.
In the above example, catching the exceptions on the communication layer will prevent the business layer from showing an appropriate message to the user.
So this approach won’t work in real-world applications.
Second approach: Plan and implement an exception handling strategy
Exception handling should be carefully planned throughout the application; in some places they should be caught and handled appropriately, and in other places by design they should be propagated to the business layer.
While this approach is the preferred option, not all developers are equally capable of designing and implementing it. Furthermore, the complexity of applications makes it extremely difficult to cover all use cases.
The bottom line is this: No method can provide full coverage.
Even manual and automated QA won’t ensure 100% coverage, as there are simply too many factors that can go wrong in reality (different OS versions used by mobile customers, different carriers, etc.).
So we need a mechanism to report real users' crashes from devices, to allow for quick fixes.
Using third-party crash reporting libraries.
There are several libraries for reporting crashes; ACRA is a popular open source crash reporting library for Android. It allows the application to report an uncaught exception and its details right before the application completely crashes.
Using a 3rd party library such as ACRA may be a good idea, but you also need to consider the following factors:
Adding ACRA require code changes in the application.
Maintenance and scalability of the ACRA server side, where crash reporting data is stored.
Reports. While there are out of the box solutions, this is something that needs to be customized to your preferences.
Overall health of your application. You want to view the crash reports in the context of overall application health – performance, network errors etc.
So while ACRA is a great tool and in some cases it will suffice, it has potential drawbacks and considerations to be made.
HP AppPulse Mobile rescues users from pending doom!
By now we understand that covering all application use cases against crashes is a real challenge, even when you have the best developers on board. Since mobile application users are not very tolerant to application stability issues, it is clear that a reliable crash reporting solution is mandatory.
With the HP AppPulse Mobile SaaS offering, an application developer, app owner, and even management can easily track application crashes as well as other vital aspects of the user experience.
The uniqueness of HP AppPulse Mobile is that it monitors user experience by tracking user actions, thus allowing for a quick and intuitive investigation of the exception’s root cause user action – you don’t just get the line of code that crashed, but the actual user action that caused it.
This allows you to prioritize issues according to their business impact - which is reflected by the root cause user action!
Here you can see the top user actions related to crashes:
Here are crashes per specific user action:
And here you can see crashes on application launch: