3.1 Checking of mobile application source code

Checking source code means reading, reviewing and verifying the code of a mobile application before and during testing, so that faults are found at the place where they are written and not by users after release. A careful check looks at whether the code handles failures safely, follows agreed standards, is easy to read and can be traced from one version to the next. For example, a pharmacy chain's ordering app may work perfectly on the developer's phone, yet crash on a customer's phone when the network drops in the middle of an order. A systematic check of the source code would have revealed that the network call had no failure handling. This topic covers two practices: handling errors inside the code, and revising the code through review and version control.

3.1.1 Error handling techniques

Error handling is the set of coding practices that detect a problem, respond to it safely and tell the user or developer what happened, without the application crashing or corrupting data. Mobile apps are especially exposed to errors because phones lose network coverage, run low on memory and storage, are interrupted by calls, and receive unexpected input from users. Good error handling keeps the app usable and protects the user's data. Example: a SACCO member app that requests a loan balance should show "No connection, please try again" when the network fails, and not close suddenly.

Types of errors in mobile application code

Knowing the type of error helps a developer choose the right technique to handle it.

• Syntax errors: The code breaks the rules of the language, such as a missing bracket or misspelt keyword. The compiler or editor normally rejects the code, so the app cannot be built until it is corrected.
• Runtime errors: The code compiles but fails while running, for example dividing by zero, reading a null value, or opening a file that does not exist. These are the errors that crash apps in users' hands.
• Logic errors: The code runs without crashing but gives wrong results, for example a discount calculated on the wrong amount. These are the hardest to see because no error message appears.
• Resource errors: The device cannot supply what the app needs, such as network, storage, memory, camera or location permission. They depend on the phone and its condition, so they must always be expected.
• External service errors: A server, payment gateway or other service returns a failure, a timeout or data in an unexpected format. The app has no control over these, so it must respond to them gracefully.

Core error handling techniques

• Try-catch-finally blocks: Code that may fail is placed in a try block, the failure is caught in a catch block, and cleanup such as closing a file or database connection is placed in a finally block. Catch specific exception types before general ones so that each problem receives the right response.
• Input validation: Data is checked for presence, type, length and range before it is used. For example, a hospital appointment app should reject a date in the past and a phone number with the wrong number of digits before sending anything to the server.
• Null safety and defensive checks: The code tests whether a value exists before using it, and uses the language's safe features, such as nullable types and safe-call operators, to avoid null reference crashes.
• Custom exceptions and error codes: Developers define their own error types, such as InsufficientFundsException, so that each failure has a clear meaning and can be handled in a specific way. Result objects that carry either a success value or an error are an alternative to throwing exceptions.
• Meaningful user messages: The user sees short, plain guidance on what to do next, such as "Check your internet connection and try again". Technical details such as stack traces are never shown to the user.
• Logging: The code records the error type, a message, the time and the place where it occurred, so developers can investigate later. Passwords, PINs, card numbers and other sensitive data must never be written to logs.
• Timeouts and retries: Network requests are given a time limit, and may be repeated a limited number of times with increasing waits between attempts. Retrying forever drains the battery and may duplicate transactions, so retries must have a limit.
• Graceful degradation and fallbacks: When a feature fails, the app continues with reduced function, for example showing saved data from the last successful update. Example: a farm records app can show yesterday's milk collection figures from local storage when the server cannot be reached.
• Asynchronous error handling: Background tasks, callbacks, promises and coroutines need their own error handling, because an exception thrown in the background does not reach the try block in the main code.
• Global exception handlers: A last line of defence catches any error not handled elsewhere. It records the failure and shows a safe message or restarts the screen, instead of letting the app close without explanation.

Example of error handling in source code

The Kotlin function below validates its input, handles a network failure and a server failure separately, and returns a clear message.

fun loadBalance(memberId: String?): String {
    if (memberId.isNullOrBlank()) {
        return "Enter a valid member number"
    }
    return try {
        val balance = api.getBalance(memberId)
        "Balance: Ksh. $balance"
    } catch (e: IOException) {
        Log.w("Balance", "Network failure", e)
        "No connection. Check your internet and try again"
    } catch (e: HttpException) {
        Log.e("Balance", "Server returned ${e.code()}", e)
        "Service is busy. Please try again later"
    } finally {
        progressBar.visibility = View.GONE
    }
}

Checking error handling in source code

When reviewing code, follow these steps to confirm that errors are handled properly.

1. List the risk points: Mark every place where the code reads user input, calls a network or server, reads or writes storage, uses a sensor or permission, or parses data. These are the places where failures begin.
2. Check that each risk point is protected: Confirm that every risk point sits inside a try-catch block or has a validation check before it. An unprotected network call is a defect.
3. Check the catch blocks: Make sure specific exceptions are caught, and that no catch block is empty. An empty catch block hides a failure and makes later debugging very difficult.
4. Check the user messages: Confirm that each failure produces a clear, polite message with a next step, and that no technical detail or sensitive data is displayed.
5. Check the logging: Confirm that errors are recorded with enough detail to trace them, and that no passwords, PINs or personal data are logged.
6. Check resource cleanup: Verify that files, database connections and listeners are closed in a finally block or by the language's automatic resource features, even when an error occurs.
7. Check retries and timeouts: Confirm that every network request has a timeout and that retries are limited, so the app cannot hang or repeat a payment.
8. Record and correct findings: Write each weakness with its file and line, correct it, and run the app again with the failure conditions, such as airplane mode or invalid input, to confirm the new behaviour.

3.1.2 Source code revision

Source code revision is the continuing process of reviewing, improving and tracking changes to the code so that every version is correct, readable and recoverable. It has two parts: human review of the code by other developers, and version control, which records who changed what, when and why. Revision matters because mobile apps are changed repeatedly, and an unrecorded change can introduce a fault that nobody can trace. Example: a county revenue collection app is updated every month, and version control lets the team see exactly which change broke the receipt screen and return to the last working version.

Code review

In a code review, one or more developers other than the author read the changes and comment before they are accepted into the main code. Reviews catch logic mistakes, security weaknesses and unclear code that the author no longer notices. Reviewers should check the following points.

• Correctness: The code does what the requirement says, including special cases such as empty lists, zero values and missing data.
• Error handling: Failures are caught and handled as set out in the techniques above.
• Readability: Names of variables and functions describe their purpose, functions are short and do one task, and comments explain why something is done and not only what.
• Coding standards: Indentation, naming style and file organisation follow the team's agreed standard, which keeps the whole codebase consistent.
• Security: No passwords, keys or tokens are written directly in the code, user data is stored and sent safely, and permissions requested are only those the app needs.
• Performance and resources: There are no unnecessary loops, repeated network calls, or objects kept in memory after they are no longer needed.
• Duplication: Repeated code is moved into one reusable function, so a future correction is made in a single place.

Version control

Version control software, most commonly Git, stores every saved change of the code as a commit in a history. Developers work on branches, which are separate lines of work, and merge them into the main branch only after review. The commands in the table are the ones used most often in revision.

Procedure for revising source code

1. Create a branch: Start from the latest main branch and create a branch named after the task, for example fix-login-timeout. This keeps unfinished work away from the stable code.
2. Make small, focused changes: Change one thing at a time, such as one fix or one feature. Small changes are easier to review and easier to undo.
3. Review your own changes: Use git diff to read every changed line, and remove leftover test code, unused variables and temporary messages.
4. Commit with a clear message: Write a short message that states what changed and why, for example "Add timeout to loan balance request". Messages such as "changes" or "fix" give no help later.
5. Submit for peer review: Push the branch and open a pull request, so that another developer can read the changes and comment against the review checklist.
6. Respond to comments: Correct the points raised, commit the corrections and ask for the review again until the reviewer approves.
7. Resolve merge conflicts if they appear: A conflict occurs when two developers changed the same lines. Open the marked file, decide which lines to keep, remove the conflict markers, then test and commit the result.
8. Merge and tag the version: After approval, merge into the main branch and tag the release with a version number. Rerun the application to confirm that nothing else was affected.

Refactoring and version numbering

Refactoring is the improvement of the internal structure of code without changing what the app does. Examples include splitting a 200-line function into smaller ones, renaming unclear variables and removing duplicated blocks. It is done in small steps, and the app is run again after each step to confirm that behaviour is unchanged.

Versions are commonly numbered in the form major.minor.patch, for example 2.4.1. The major number rises when changes break compatibility with earlier versions, the minor number rises when new features are added, and the patch number rises for bug fixes. For example, a bank's mobile app moving from 2.4.1 to 2.4.2 signals a bug fix only, while 3.0.0 signals a major redesign.

Good revision practices

• Commit often: Frequent small commits give a detailed history and reduce the loss if a device fails.
• Never commit secrets: API keys, passwords and signing keys must be kept out of the repository, for example in protected configuration files that are excluded from version control.
• Protect the main branch: Require a review before anything is merged, so that no one can change the stable code unchecked.
• Keep a change log: Record the changes in each release in plain language. For example, a school fees app can note "Version 1.3.0: parents can now download a fee statement".
• Back up the repository: Keep the code on a remote server as well as on developers' computers, so a lost laptop does not mean lost work. A contractor delivering an app to a client can also hand over the full history as proof of work done.