Communication of the mobile application with the server is not the sole concern of the developer. It should be designed what the user will see when data does not arrive, the session is closed, or the result of the operation remains unclear. Backend and API decisions are therefore considered together with the interface plan.
Not every application needs the same infrastructure
A simple tool that runs only on the device may not require a remote server. Server-side tasks become obvious if there are shared accounts, records synced across devices, or centralized order management. Using an off-the-shelf service does not eliminate these responsibilities; It should also be known where the data is located and what will happen when the service is interrupted.
Write down the source for each important information in the design meeting. Where does product stock come from? At what stage is the address changed by the user registered? When will the admin update appear on the phone? Without these answers, producing a screen with sample data alone may hide incomplete decisions.
Show transaction status clearly
Let's take a recording stream as an example. The user filled out the form; pressed the send button; connection lost. The server may have accepted the recording but the response may not have reached the phone. The fact that the interface immediately declares failure and requests resubmission increases the risk of double recording in some jobs. While the technical team determines the transaction ID and retry behavior, the designer prepares the clear status message and secure next step.
- The draft that has not yet been sent and the saved record should appear separately.
- The pending transaction should not be presented as completed.
- The retry button should explain which action it is repeating.
- Last update information should appear where old data influences decisions.
Working offline is a behavioral plan, not a screen
Android's offline-first architecture guide explains how to handle local and network data sources together. From the user's perspective, three decisions are important: what can he see while disconnected, what can he change, and what happens if there is a conflict when reconnected?
If two employees are likely to change the same record, the suitability of a rule such as "last entry wins" should be evaluated. The designer does not choose the technical rule alone; However, if the user will be asked to make a choice, the screen and explanation must be prepared.
Checklist to deliver to developer
Document idle data, loading, lack of authorization, end of session, and connection issues, as well as the main flow. Instead of spilling the actual error details to the user, design a clear explanation and necessary guidance. Technical security tests are no substitute for nice error messages.
API interface states guide covers the general checklist, and mobile application design covers transferring these decisions to the screens. When working with Selçuk Aker, interface delivery and server development responsibilities are defined separately.
Frequently asked questions
Do I definitely need to rent a server for my mobile application?
It depends on the functionality of the application. An on-device tool can run serverless; shared online data may require different infrastructures. The technical team should make the selection based on need.
Should all operations stop when the internet goes down?
No, but it must be defined which operations can be continued safely. Situations where incorrect decisions may be made based on old data are also evaluated.
Does the loading effect solve the connection problem?
No. It describes waiting for an effect. Timeout, retry, data protection and help path should also be addressed.
