Mobile terminals: what is inside a phone?
A mobile terminal is a handheld computing device: a smartphone, a tablet or a smartwatch. Main parts:
- Processor and memory (the brain and its short-term memory)
- Touch screen for input and output
- Sensors: accelerometer, gyroscope, compass, GPS, light, camera, microphone, fingerprint
- Storage for apps and files
- Radios: mobile network (4G/5G), Wi-Fi, Bluetooth, NFC
- Battery, which limits how much work an app should do
Common systems are Android and iOS. Apps can be native (made for one system), web apps (run in a browser) or cross-platform (one code for both).
App architecture: UI, logic and data layers
Splitting an app into layers keeps it neat and easy to change.
- UI layer: screens, buttons, lists. It shows information and receives taps.
- Logic layer: rules and calculations, for example 'if the battery is low, show a warning'.
- Data layer: reads and writes data on the phone or on a server.
A tap goes down the layers and the answer comes back up. Because each layer has its own job, you can change the look without breaking the rules. Good UI design for phones: big touch targets (at least 44 px), simple screens, one main action per screen, and responses within a second.
An app has a life cycle: it starts, goes to the background when the user switches apps, and can be closed by the system. Save the user's work when it goes to the background.
Sensors in apps
Sensors turn the real world into numbers.
- Accelerometer: measures acceleration in m/s² along x, y and z. At rest it shows gravity, about 9.8 m/s² downward. Used for screen rotation, step counters and tilt games.
- Gyroscope: measures how fast the phone is turning.
- GPS: finds position using satellites. It uses a lot of battery.
- Camera and microphone: pictures, scanning codes, voice.
- Light sensor: adjusts screen brightness.
Sensor readings are noisy, so apps smooth them (average a few readings) and read them only when needed to save battery.
Storage and networking
Local storage keeps data on the phone: small settings (key and value), files (photos), and a small database (for example SQLite) for lists. It is fast and works offline, but it is lost if the phone is lost, and other devices cannot see it.
Network storage (cloud) keeps data on a server. Many devices can share it, but it needs internet.
How an app talks to a server: the app sends a request (for example, 'give me the bus list') to an API address using HTTP or HTTPS, and the server sends back a response, often in JSON text.
Offline-first design: save to the phone first, then sync to the server when the internet comes back. Also mind mobile data cost: send small data and cache what does not change.
Security of mobile apps
A phone holds private things: photos, messages, location and money apps. Apps must protect them.
- Permissions: the app asks the user before using the camera, location or contacts. Ask only for what you really need, and explain why.
- Encryption: turns data into unreadable code using a secret key. Use it for stored private data and for data in transit (HTTPS).
- Authentication: check who the user is with a password, a PIN, a fingerprint or a one-time code (OTP).
- Safe coding: never put secret keys inside the app, check all input, and keep the app updated.
- Privacy: collect little data, tell users what you keep, and let them delete it.
Users should install apps only from trusted stores and read what an app asks for.
Try it: design a small app on paper
Plan a steps-counter app. Draw one screen. Write what the UI, logic and data layers do. Which sensor does it use? Where do you store the steps, and which permission is needed?
In the 3D go to the last step. Switch the internet off and then on: what happens to the data path? Allow the permission and tilt the phone: when does the sensor reading appear?
Key formulas and definitions
- Accelerometer at rest ≈ 9.8 m/s² (gravity)
- Download time (s) = file size (bits) ÷ speed (bits per second)
- 1 byte = 8 bits; 1 MB ≈ 8 megabits
- Key terms: UI, logic, data, sensor, API, request, response, sync, permission, encryption
Worked examples
1. A phone lies flat on a table. About what does the accelerometer z reading show?
About 9.8 m/s² (gravity), and almost 0 on x and y.
2. An app must download a 6 MB file on a 2 Mbps connection. How long does it take?
6 MB = 6 × 8 = 48 megabits. Time = 48 ÷ 2 = 24 seconds.
3. Which layer should hold the rule 'show a red alert if temperature > 40'? The UI, logic or data layer?
The logic layer holds the rule. The UI only shows the red alert.
4. Why should a torch app not ask for contacts permission?
It does not need contacts. Asking for more than needed is a privacy risk, and users will not trust it.
5. A to-do app saves tasks on the phone first and uploads when Wi-Fi is on. Name this design and one benefit.
Offline-first with sync. Benefit: the app works without internet and nothing is lost.
Common mistakes
- Putting rules in the screen code, so the app becomes hard to change.
- Reading the GPS all the time and draining the battery.
- Asking for many permissions the app does not need.
- Sending private data over plain HTTP instead of HTTPS, or keeping secret keys inside the app.