The traditional approach to bug reporting in mobile apps is limited to crash reports and network issue reports. Crash reports can indicate where and how the crash happened but are often not enough to identify the causation. What usually happens is that developers end up spending way too much time and effort trying to identify and analyze the reason for the crash and in trying to reproduce the problem. The problem becomes even more complex if it is a network call issue.

How bug reporting should work?

Now, imagine a scenario where you can track each function in your Android or iOS app and not just the usual mobile app crash reporting or network issue reporting. The moment a crash occurs inside a particular function or if the function execution is delayed, a bug report will be sent to you with all of the parameters that were passed into that function. This will make it easy for you to identify and reproduce the bug or error.

The better approach to bug reporting through function tracking

Here is how to function tracking should ideally work. The bug reporting tool should keep checking the parameters that are passed into the function and should monitor if the function.

• Takes more than the desired time to execute.
• Throws an exception.
• Returns an unexpected output.

If one or any of these issues are identified, your bug tracking tools like JIRA or Bugzilla (or any other similar tools) and/or your communications channels like Slack should be notified with all relevant data points.

The added advantage of tracking functions is that you can chain asynchronous functions and get reports if the chaining fails or is delayed.

We at Finotes (read ‘Fai notes’) approach the problem in a way which ensures that you won’t end up adding more lines of code. If your logic demands x lines of code, it will remain as x lines even after integrating the function with Finotes SDK. This approach ensures near-zero performance impact as no extra logic is pushed into the function.