Don’t you get a deja vu when you run a new app and discover the same issues all over again? It’s actually no wonder you do, as some key mistakes tend to recur no matter how hard the developers vow not to repeat them in their next app. Oftentimes, bugs are device-specific due to different configurations and hardware. In this blogpost, we’ve put together a list of mistakes that software engineers make during programming, coding, and tuning, which inevitably lead to bugs in the software.
Internet Connection Issues
A mobile device is not your laptop or desktop at home or in the office for which the ability to be connected to the Internet through a stable LAN connection is a natural thing. Smartphones and tablets are always suffering from WiFi network instabilities and switching between 2G/3G/4G/Wi-Fi networks.
A mobile app should be prepared to handle the following issues:
- Application start when internet connection is off
- Internet connection is lost during the data uploading/downloading - this issue is really critical as crashes during data transfers may cause loss of data, so you need to double-test it
In such cases, the app should always inform the user about internet connection loss. Best is a dialog message about the connection status.
WEB Server Issues
Due to various reasons, servers can also have issues, bugs and crashes.
Mobile client should handle the following issues:
- The web server does not send data to the mobile client
- The web server is not responding
- Mobile client received empty data
- Mobile client received invalid data
In such cases, the app should always inform the user about the issue.
In most cases, if the server request is not utilising the user generated data, the user does not care for the server error reason. It only makes sense to inform about 2 kinds of issues: Internet Connection Loss, and Lack of server response. Also, a special message describing the mistake in user generated data should be shown when this data is required for the server request.
Data Caching And Cache Removal
Most of the applications that connect to the internet, download data from some servers. The app then stores the data in a specially defined place, so next time the app needs that data, it doesn’t have to download it again, but just check if the data is up to date, and use the cached data. This approach has the following advantages:
- Battery charge economy
- Data charges economy
- Performance Increase
Caching data is quite useful, however it may cause some challenges:
- The device quits updating data for some reason. As a result, a user won’t get updated data (images/texts/news)
- The app finds that an update is available, kills the old data and starts download. The download gets disturbed by either internet connection loss, server error or invalid data, and as a result a user can neither see the new, nor the old data. In such case, the application should only replace the old data with properly and fully downloaded new data
- Incorrect update mechanism. For example, the app checks for updates only at the set time or in the wrong timezone
- Data update should run in the background, so that it’s not visible for the user, or if it needs to be visible - by showing the progress bar
Hard-Coded Data
There are various bugs related to hard coding data in the app. Quite frequently this issue occurs in multi language applications. As an example there are cases where developer needs to add a message about the internet connection failure. What he does is just make the message with hardcoded English text, instead of adding the text of the message to the text resources file. As a result, all users, despite their localisation, see only the English version of the message. The issue is not critical, but sometimes it pays not to be sloppy. Much worse is the case when the button with the text is just an image and then it’s more difficult to localise it.
Another case is when a programmer decides to hard code some data, or text with future plan to change it and then simply forgets about it.
Data Upload Issues
When users are offered to upload certain files through the app, sometimes users can perform quite unexpected actions, such as:
- User can try to upload big size files (20 MB or more)
- User can try to upload multiple files at once
- User can try to upload damaged or corrupted files (photos / music / videos / documents)
- User can try to upload video/music files instead of photos or documents
If the developer failed to predict these scenarios, the application’s behaviour, if user tries any of this, may result in a critical crash.
In such cases the app should always inform the user about the requirements. Best is internal check for file’s type/size/quantity, and a hint for a user, with the file type / size and quantity limitations.
Login and Access Tokens for Users
If a mobile app uses Access Tokens, you should remember that they have expiration date. Once it expires, the server will not authenticate you any more, so the app should predict such case and handle it properly.
Recommended behavior of the app: ask to log in again.
Data Migration Issues
Apps that allow the users to create and store user generated data are the first to have trouble with database migration. Often when the new version of the app is released, it’s built with a new version of database (e.g. v2.0).
When users of v1.0 start to update their apps to the new v2.0, database migration should take place. It means that all data from v1.0 has to be moved over to the new, v2.0 database.
If the migration process is incorrect, it may result in crashes, incorrect data records, or most likely, users will lose all their saved data. And that’s critical for apps like these.
User Interface Peculiarities
- Fonts: type/size
- Buttons: size/positions/quality
- Input fields: size/resizing/scroll
UI design:
- Text format does not match the design
- Positioning does not match the design
- Alignment does not match the design
- Deviations do not match design
- Missing shadow (bottom panel for text / popups / buttons)
- Distorted graphics resource - stretched / cut off (background / button pop-up window, icon, logo)
- No selectors
Double screen openings:
- This happens if you quickly press the same button twice. Relates to Android OS. This is an issue of the OS itself, and should be resolved by a quite unpleasant workaround. Such as setting up a click listener that will kill the interaction for a short period of time if the button was pressed at least once.
Depending on a particular project this might not be treated as an issue.
Opening two or more screens simultaneously:
- This occurs when you press a few buttons (tabs) at the same time. The app opens two screens at once. You have to leave the first screen and then you go to the second one, which you have to leave as well. Developer should simply set the "splitTouchEvents=false", and this prevents such issues, but this is only on OS 3.0+.
iOS Issues
- The app crashes when it tries to open the email app (email settings: user account not set)
iOS rejection because of incorrect iCloud use:
- iCloud iOS: Application by default stores unnecessary data on the iCloud. If the data is user generated, then Yes, it needs to be backed up on the iCloud, but if it’s some kind of database or temporarily uploaded files, it will cause the copy to gain size quickly, and will result in App Store rejection.
- In App Purchase: Renew button should be available and behave according to the specification.
Android Issues
- The application crashes when trying to open a third-party application.
The reason is that Android is quite a segmented OS, that has recently been installed onto many different types of devices. A set of preinstalled applications may vary, and in some cases there might not be any map application, audio/video player or email client. Then your application has to display a warning message, but never crash.
- Changing the API level, without notifying the customers. This is a critical issue that newbies are likely to make. This relates to the API level of the Operating System. For example, Android 2.3 has an API level - 10, Android 4.1 - API level - 16 and so on. Older Android versions cannot support some of the features that are in newer versions, and some sloppy developers might say something like “Hey, I need this lib to work but it’s just not working on that OS version. I’m gonna raise it to a higher version.” If he has not informed anyone about that, it will cause issues. As a result, after the app goes to the market, it won’t be delivered to some 40% of expected recipients because they are still using the older OS version, which the app is no longer good for.
- The application crashes after a user quits and restarts it. This issue is quite commonplace for newbie developers. They often can’t predict a case when the app can be killed by the OS when sent to background. Next time the user starts the app, it will crash. These kinds of shortcomings are quite easy to detect by activating the following option (Settings->Dev Options->Don't Keep Activities - Android).
- The application crashes when it tries to open a third-party application.
SEE ALSO: