DEV Community: Shakibaenur

A Mind Map for Mobile System Design Preparation

Shakibaenur — Wed, 02 Sep 2026 09:03:17 +0000

Mobile system design interviews can feel overwhelming.

You're asked to design something that sounds simple — a news feed, chat application, ride-sharing app, video platform, or social network — but suddenly you're expected to reason about much more than UI and API calls.

You need to think about application architecture, networking, caching, offline support, synchronization, concurrency, storage, performance, security, observability, and sometimes even how the backend interacts with the mobile client.

The difficult part isn't that any one of these topics is impossible to learn.

The difficult part is knowing which topics matter, how they connect, and how to apply them during an interview.

That's what this guide is about.

We'll build a mental model for mobile system design interviews and walk through the major areas you should prepare.

What Is Mobile System Design?

Mobile system design is an interview format where you're given a product or feature and asked to design the architecture of a mobile application that supports it.

For example, an interviewer might ask:

How would you design a news feed app?
How would you build a chat application?
How would you design a ride-sharing app?
How would you support offline editing in a mobile application?
How would you design a video streaming application?

The answer isn't simply:

"I'll create a UI, call an API, and display the response."

A production mobile application has many layers.

A simplified architecture might look like this:

┌─────────────────────────────┐
│          UI Layer           │
│ SwiftUI / UIKit             │
│ Jetpack Compose / Views     │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│       Domain / Business     │
│          Logic              │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│          Data Layer         │
│ API • Cache • Database      │
└──────────────┬──────────────┘
               │
        ┌──────▼──────┐
        │   Network   │
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │   Backend   │
        └─────────────┘

And that's only the beginning.

The application also has to deal with things that are particularly important on mobile:

unreliable networks
limited battery
limited memory
intermittent connectivity
background execution restrictions
application lifecycle changes
device storage constraints
different screen sizes and hardware
application updates
security of data stored on the device

This is what makes mobile system design different.

A Mind Map for Mobile System Design Preparation

Because mobile system design combines many areas of software engineering, preparing topic-by-topic can quickly become confusing.

You might study caching today, API design tomorrow, and Android lifecycle the next day — without understanding how they fit together.

A better approach is to organize your preparation into a few major areas.

This guide divides mobile system design into nine sections:

Mobile Domain
API Design & Networking
Software Architecture & Design Patterns
Data Storage
Performance & Optimization
Observability & Testing
Privacy & Security
Advanced Topics
Interview Strategy

Think of these as the major branches of your preparation.

1. Mobile Domain

The first area is understanding the mobile platform itself.

You don't necessarily need to memorize every framework API. Instead, you should understand the constraints and architectural decisions that mobile platforms impose.

UI Frameworks

Modern mobile development generally has two broad approaches.

Declarative UI

You describe what the UI should look like for a particular state.

Examples include:

SwiftUI on iOS
Jetpack Compose on Android

For example, a screen might conceptually be:

State
  ↓
UI
  ↓
User Action
  ↓
State Update
  ↓
UI Recomposition

This model is particularly useful when discussing state management and unidirectional data flow.

Imperative UI

The application explicitly creates and modifies UI components.

Examples include:

UIKit on iOS
XML/code-based Views on Android

In an interview, the important question isn't usually which framework you prefer.

It's understanding how UI state flows through your architecture.

Lifecycle Management

Mobile applications don't run continuously like a server.

The operating system can:

move your application to the background
suspend it
terminate it
recreate screens
reclaim memory
restore state later

On iOS, you'll encounter concepts such as:

UIViewController
AppDelegate
SceneDelegate
SwiftUI view lifecycle

On Android, important concepts include:

Activity
Fragment
Application
Jetpack Compose lifecycle

This becomes important when designing features such as:

"What happens if the user starts uploading a file and leaves the application?"

The answer requires much more than UI code.

Threading and Concurrency

Mobile applications have a main thread responsible for responsive UI work.

Blocking that thread with expensive operations can result in a poor user experience or even an application that appears frozen.

A simplified model is:

                ┌───────────────┐
                │   Main Thread │
                │ UI / Events   │
                └───────┬───────┘
                        │
                 Dispatch Work
                        │
              ┌─────────▼─────────┐
              │ Background Workers │
              │ Network / CPU / DB │
              └────────────────────┘

On iOS, you should understand concepts such as:

Grand Central Dispatch (GCD)
OperationQueue
async/await
Tasks
Actors

On Android, important concepts include:

Looper
Handler
thread pools
ThreadPoolExecutor
Kotlin Coroutines

During system design interviews, you should be able to identify work that should not happen on the main thread.

For example:

UI Thread
   │
   ├── Render UI
   ├── Handle user interaction
   │
   └── Dispatch expensive work
              │
              ├── Network request
              ├── Database query
              ├── Image processing
              └── File processing

Navigation

Navigation becomes especially interesting when your application supports deep links.

Imagine a user taps a notification:

Push Notification
       ↓
   Deep Link
       ↓
   Application
       ↓
   Authentication Check
       ↓
   Target Screen

On iOS, common concepts include:

UINavigationController
SwiftUI NavigationStack
Coordinator patterns
Deep Links

On Android:

Navigation Component
Deep Links

The system design question isn't simply:

"How do I navigate to another screen?"

Instead, consider:

What happens when the user isn't logged in?
What happens when the application was terminated?
How do you restore the navigation state?
What happens if the target resource no longer exists?

Data Binding and State Propagation

A mobile application often has several components interested in the same data.

For example:

             Repository
                 │
        ┌────────┼────────┐
        │        │        │
      Home    Profile   Details
        │        │        │
        └────────┴────────┘
                 │
                UI

On iOS, you may encounter:

Combine
KVO
ObservableObject
completion handlers

On Android:

LiveData
Kotlin Flow
StateFlow
Coroutines

The important system-design concept is how state moves through the application without creating inconsistent or duplicated state.

2. API Design and Networking

The mobile client is only one side of a distributed system.

The application communicates with backend services through a network that may be slow, unreliable, or completely unavailable.

This makes networking one of the most important areas of mobile system design.

Communication Protocols

You should understand the tradeoffs between:

REST
GraphQL
WebSockets
gRPC

For example:

Protocol	Common Use Case
REST	General API communication
GraphQL	Flexible client-driven data fetching
WebSockets	Persistent real-time communication
gRPC	Efficient service-to-service communication

The right choice depends on the requirements.

Real-Time Updates

Suppose you're designing a chat application.

How does the client know that a new message has arrived?

There are several possibilities:

Polling
   ↓
"Do I have new messages?"

Long Polling
   ↓
"Tell me when something changes."

SSE
   ↓
Server → Client stream

WebSocket
   ↓
Persistent bidirectional connection

Push Notification
   ↓
Wake/notify the mobile application

Each approach has different implications for battery usage, latency, infrastructure complexity, and reliability.

A strong interview answer explains why you choose one.

Pagination

Mobile applications rarely download unlimited data at once.

A news feed containing 100,000 posts should not return all 100,000 records to the device.

Common pagination strategies include:

Limit/Offset
Page-based pagination
Keyset pagination
Cursor-based pagination

For example:

GET /posts?cursor=abc123&limit=20

        ↓

20 posts

        ↓

nextCursor = xyz789

        ↓

GET /posts?cursor=xyz789&limit=20

Cursor-based pagination is often useful for feeds where data changes while the user is scrolling because it can provide more stable traversal than simple offsets.

API Integration

Your mobile application needs an API layer that handles communication with the backend.

On iOS, common tools include:

URLSession
Alamofire

On Android:

OkHttp
Retrofit

You'll also need serialization and deserialization.

For example:

JSON Response
     ↓
DTO
     ↓
Mapper
     ↓
Domain Model
     ↓
UI

Keeping API DTOs separate from domain models can prevent backend API changes from leaking throughout the application.

Delta Updates

Imagine your application already downloaded 10,000 messages yesterday.

When the user opens the app today, downloading all 10,000 messages again is wasteful.

Instead, the client can ask:

"Give me only what changed since my last synchronization."

For example:

Last Sync
2026-09-01 10:00:00

        ↓

GET /messages?updated_after=2026-09-01T10:00:00

        ↓

Only changed records

Delta updates can use mechanisms such as:

timestamps
sequence IDs
ETags
Last-Modified

This reduces bandwidth, latency, and battery consumption.

Offline Support and Synchronization

This is one of the areas that separates mobile system design from a simple API design exercise.

A mobile device can lose connectivity at any time.

Suppose a user edits a document while offline:

User Edit
   ↓
Local Database
   ↓
Pending Sync Queue
   ↓
Network Available
   ↓
Upload Changes
   ↓
Server

Now you need to answer:

What happens if the same document was modified on another device?

That's a conflict-resolution problem.

You should be prepared to discuss:

conflict resolution
retry queues
background synchronization
batched requests
resumable uploads
resumable downloads
prefetching

Offline-first design is fundamentally about treating the local device as an important part of the distributed system.

Caching

Caching can dramatically improve perceived performance.

A mobile application might have several cache layers:

UI
 │
 ▼
Memory Cache
 │
 ▼
Disk Cache
 │
 ▼
Network
 │
 ▼
Backend

Common mechanisms include:

HTTP caching

Using headers such as:

Cache-Control
ETag
Last-Modified

Memory caching

Examples:

NSCache on iOS
LruCache on Android

Disk caching

Useful for larger or persistent data such as:

images
API responses
downloaded content

But caching introduces another problem:

When does cached data become invalid?

This is the cache invalidation problem.

A strong system design answer should explain:

what you're caching
where you're caching it
how long it remains valid
how it gets invalidated
what happens when stale data is displayed

Authentication

Mobile applications commonly use several authentication mechanisms.

You should understand:

username/password authentication over HTTPS
Sign in with Apple
Google Sign-In
OAuth
OpenID Connect
biometric authentication
multi-factor authentication
access tokens
refresh tokens

A typical token flow looks like:

Login
  ↓
Authorization Server
  ↓
Access Token + Refresh Token
  ↓
Mobile App
  ↓
API Request + Access Token
  ↓
Backend

When the access token expires:

API Request
    ↓
401 Unauthorized
    ↓
Refresh Token
    ↓
New Access Token
    ↓
Retry Original Request

Token storage is also important.

Sensitive credentials should not simply be stored in an arbitrary plaintext file or database.

Retry Policies

Networks fail.

A request might fail because of:

temporary connectivity problems
server overload
timeout
DNS issues
rate limiting

Blindly retrying immediately can make the problem worse.

Instead, applications often use strategies such as:

Exponential Backoff

Attempt 1 → immediately
Attempt 2 → 1 second
Attempt 3 → 2 seconds
Attempt 4 → 4 seconds
Attempt 5 → 8 seconds

Jitter can be added to prevent many clients from retrying at exactly the same time.

You should also understand:

linear backoff
circuit breakers
retry-after responses
retrying after token refresh

The key interview principle is:

Retries should be deliberate, bounded, and aware of whether an operation is safe to repeat.

API Evolution

Mobile applications create a unique API compatibility problem.

A backend can be updated today, but millions of users may still have an older version of the application installed.

Therefore, your backend may need to support multiple client versions simultaneously.

For example:

                    Backend API
                   /     |      \
                  /      |       \
             v1 Client  v2 Client  v3 Client

Good API evolution practices include:

adding fields without breaking old clients
avoiding unnecessary breaking changes
versioning APIs when necessary
maintaining backward compatibility
safely deprecating old fields

This is one reason mobile system design is closely connected to distributed systems.

CDN

For applications serving large amounts of static or media content, a Content Delivery Network (CDN) can move content closer to users.

Instead of:

Mobile App
    ↓
Origin Server

you can have:

Mobile App
    ↓
Nearest CDN Edge
    ↓
Cache Hit → Content
    │
    └── Cache Miss
            ↓
       Origin Server

CDNs are especially useful for:

images
videos
static files
application assets
large downloads

But you should still think about cache invalidation, TTLs, authentication, signed URLs, and regional distribution.

How to Use This Knowledge Map

The goal isn't to memorize every technology listed above.

Instead, use the map to identify your weak areas.

Read through the topics and grade yourself.

For example:

Mobile Domain              4/5
API Design                 3/5
Architecture               5/5
Data Storage               2/5
Performance                3/5
Security                   2/5
Observability              2/5
Advanced Topics            1/5
Interview Strategy         3/5

Now your preparation becomes much more focused.

Instead of saying:

"I need to study mobile system design."

You can say:

"I understand mobile architecture, but I need to improve offline synchronization, caching, and security."

That's a much more actionable preparation plan.

What Mid-Level Engineers Should Focus On

If you're preparing for a mid-level mobile engineering position, focus first on the foundational concepts:

mobile application lifecycle
UI architecture
threading and concurrency
navigation
networking
API design
pagination
caching
authentication
offline support
local storage
performance
basic security
testing

You don't need to master every advanced distributed-systems concept before starting mock interviews.

Learn the fundamentals, then practice applying them.

What Senior and Staff Engineers Should Add

For senior and staff-level interviews, interviewers may expect deeper reasoning around:

large-scale synchronization
conflict resolution
advanced caching
offline-first architecture
real-time systems
observability
privacy
security architecture
scalability
multi-region systems
reliability
advanced performance optimization
complex data consistency problems

The difference isn't simply knowing more technologies.

It's being able to explain tradeoffs.

For example:

"Why did you choose WebSockets instead of polling?"

is a much more important question than:

"Do you know WebSockets?"

How to Practice Mobile System Design Interviews

Reading is only part of the preparation.

You need to practice designing systems yourself.

Solve at Least Five Problems

Choose different types of applications.

For example:

Design a News Feed
Design a Chat Application
Design a Ride-Sharing App
Design a Video Streaming App
Design an Offline Notes Application

Don't immediately look at someone else's solution.

Start with a blank page.

Use the Same Process Every Time

A useful interview structure is:

1. Clarify Requirements
          ↓
2. Define Core User Flows
          ↓
3. Design Mobile Architecture
          ↓
4. Design API / Networking
          ↓
5. Design Local Storage
          ↓
6. Discuss Caching & Offline
          ↓
7. Discuss Performance
          ↓
8. Discuss Security
          ↓
9. Discuss Failure Cases
          ↓
10. Explain Tradeoffs

This gives you a repeatable framework rather than trying to improvise every interview.

Do Mock Interviews

Try to complete at least two mock interviews.

One should happen near the beginning of your preparation.

The second should happen closer to your actual interview.

The goal isn't just to test whether you know the material.

You want to discover whether you can communicate your design clearly under time pressure.

A candidate might know everything about caching but still struggle if they spend 25 minutes discussing UI architecture and have no time left for scalability or failure scenarios.

The Most Important Skill: Connecting the Pieces

The biggest mistake in mobile system design preparation is studying each topic independently.

Knowing caching is useful.

Knowing WebSockets is useful.

Knowing Coroutines is useful.

Knowing SQLite or Core Data is useful.

But the interview asks you to combine them.

Consider a chat application.

You might need:

                Chat Application
                       │
       ┌───────────────┼────────────────┐
       │               │                │
    WebSocket        Local DB         Push
       │               │                │
 Real-time          Offline           Background
 Messages           History           Notification
       │               │                │
       └───────────────┼────────────────┘
                       │
                  Sync Engine
                       │
                 Conflict Logic

That's the real skill.

System design is about understanding how individual engineering concepts work together to solve a product problem.

Final Takeaway

Mobile system design isn't a single technology.

It's the intersection of:

mobile platform knowledge
software architecture
networking
distributed systems
data storage
performance engineering
security
reliability
product requirements

You don't need to learn everything at once.

Start with the fundamentals.

Identify your weak areas.

Practice applying those concepts to real mobile products.

Then gradually move into advanced topics and increasingly difficult system-design problems.

The goal isn't to memorize a perfect architecture.

The goal is to develop the ability to look at a problem and reason about:

requirements → architecture → tradeoffs → failure modes → scalability → user experience.

That's what makes someone strong at mobile system design interviews.

The Complete Mobile System Design Roadmap

This article covers the major concepts you need to understand, but mobile system design is a broad subject. If you want to follow the topics in a structured order, you can use the complete Mobile System Design roadmap on Algonur.

The roadmap brings the topics together so you can see what to learn first, what to study next, and how the different areas of mobile system design connect.

→ Explore the complete Mobile System Design roadmap on Algonur

You can use the roadmap alongside this article to identify gaps in your knowledge and build your preparation step by step.

How to turn on charge only mode programatically if the mode if file transfer in android?

Shakibaenur — Sun, 08 Oct 2023 07:20:23 +0000

I will have to show this type of dialog if my device is connected to usb and I want to access the app. Here this dialog shows -Click to Charge Only will automatically set the USB protocol to Charge only mode and i can not access files from my phone

Can Anyone help me to achieve this feature?

I have used to get device list but device list is empty. But still i dont thing this will solve my problem

for (entry in usbDeviceList.entries) {
            val usbDevice = entry.value

            // Check the USB device's connection mode
            val usbConfiguration = usbDevice.getConfiguration(0)
            val usbInterface = usbConfiguration.getInterface(0)
            val usbInterfaceClass = usbInterface.interfaceClass

            // Check if the interface class indicates MTP (Media Transfer Protocol)
            if (usbInterfaceClass == 6) {
                // The device is in MTP mode (File Transfer mode)
                // You can perform file transfer operations here
                Toast.makeText(applicationContext, "(File Transfer mode)", Toast.LENGTH_LONG).show()
            } else {
                // The device is not in MTP mode
                // Handle the mode accordingly
                Toast.makeText(applicationContext, "MTP mode", Toast.LENGTH_LONG).show()
            }
        }

Android — Drag and Drop

Shakibaenur — Fri, 17 Feb 2023 17:21:00 +0000

Today i want to talk about my one of the most favourite features in android development that is "Drag and Drop".

In modern user interfaces, drag and drop has become an essential interaction pattern for enabling users to move objects around a screen with a touch gesture.

The drag and drop framework in Android Kotlin provides a simple and flexible way to implement drag and drop functionality in your app. It allows users to drag a view or item from one location to another by simply tapping and holding the item, and then dragging it to its desired destination. The drag and drop framework is based on three key components: the DragEvent, the DragShadow, and the ClipData object.

DragEvent:

The DragEvent class is responsible for managing the entire drag and drop lifecycle. It provides a set of constants that represent different states of the drag and drop operation. These states include ACTION_DRAG_STARTED, ACTION_DRAG_ENTERED, ACTION_DRAG_LOCATION, ACTION_DRAG_EXITED, ACTION_DROP, and ACTION_DRAG_ENDED. These states are used to identify when a drag operation is starting, when it's in progress, and when it's completed.

DragShadow:

The DragShadow class is responsible for creating a visual representation of the item being dragged. It is an optional component that can be used to provide a custom visual representation of the item being dragged. It's also possible to use the default drag shadow, which is a simple opaque image of the view being dragged.

ClipData:

The ClipData class is responsible for storing the data associated with the item being dragged. This data can be anything that you want to associate with the item, such as text, images, or other types of data. You can use the ClipData.newPlainText() method to create a new ClipData object that contains plain text data, or you can create a custom ClipData object that contains any type of data.

These were the fundamental parts. Now let's think about a Drag and Drop game you want to built for kids. To built this you must know about View.setOnTouchListener() and View.OnDragEventListener().

Note that i am just sharing the basic concept. Assume i want to match a shape. Let's call it "Match the Shape". I this application I have a triangle shaped object and want to match it with the shape.

Now proceed of making this little application.

Click on File, then New => New Project.
After that include the Kotlin support and click on next.
Select the minimum SDK as per convenience and click the next button.
Then select the Empty activity => next => finish.

View Binding

I have used view binding in this project. To enable view binding in a module, set the viewBinding build option to true in the module-level build.gradle file, as shown in the following example:

buildFeatures {
    viewBinding = true
}

activity_main.xml file

In the xml file we have two ImageView one is for showing the shape ivTriangle and another one ivTriangleDrag to drag it on the shape.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".MainActivity">

    <TextView
        android:id="@+id/tvTitle"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginTop="12dp"
        android:text="Match the Shape"
        android:textAlignment="center"
        android:textSize="24sp" />

    <ImageView
        android:id="@+id/ivTriangle"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_margin="12dp"
        android:layout_gravity="center"
        android:layout_weight="1"
        android:src="@drawable/ic_triangle" />

    <ImageView
        android:id="@+id/ivTriangleDrag"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_margin="12dp"
        android:layout_gravity="center"
        android:layout_weight="1"
        android:src="@drawable/ic_triangle_drag" />

</LinearLayout>

MainActivity.kt

We will implement the onTouch and onDrag functions of View.OnTouchListener and View.OnDragListener correspondingly.

class MainActivity : AppCompatActivity(), View.OnTouchListener, View.OnDragListener{

..........
 override fun onTouch(v: View?, event: MotionEvent?): Boolean {
        ........
  }

 override fun onDrag(v: View?, event: DragEvent?): Boolean {
        .........
  }

}

Here in onCreate function we will initialise the setOnTouchListener to ivTriangleDrag and setOnDragListener to ivTriangle . As we want to touch ivTriangleDrag then drag it over ivTriangle and drop.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    mViewBinding = ActivityMainBinding.inflate(layoutInflater)
    setContentView(mViewBinding.root)

    mViewBinding.ivTriangleDrag.setOnTouchListener(this)
    mViewBinding.ivTriangle.setOnDragListener(this)

}

Now we can see the Motion.ACTION_DOWN event of ivTriangleDrag will trigger when we will touch it and drop it in the screen anywhere.

override fun onTouch(v: View?, event: MotionEvent?): Boolean {
    return if (event!!.action == MotionEvent.ACTION_DOWN) {
        val data = ClipData.newPlainText("", "")
        val shadowBuilder = DragShadowBuilder(v)
        v?.startDragAndDrop(data, shadowBuilder, v, 0)
        true
    } else {
        false
    }
}

And the onDrag function will trigger the DragEvent callbacks. Now when we will drop ivTriangleDrag over ivTriangle then ACTION_DROP will trigger and as we wanted we will change the background ivTriangle and will INVISIBLE ivTriangleDrag Imageview.

override fun onDrag(v: View?, event: DragEvent?): Boolean {
    when (event?.action) {
        ACTION_DRAG_STARTED -> {
            Log.d(msg, "Action is DragEvent.ACTION_DRAG_STARTED");
        }
        ACTION_DRAG_ENTERED -> {
            Log.d(msg, "Action is DragEvent.ACTION_DRAG_ENTERED")
        }
        ACTION_DRAG_EXITED -> {
            Log.d(msg, "Action is DragEvent.ACTION_DRAG_EXITED")
        }
        ACTION_DRAG_LOCATION -> {
            Log.d(msg, "Action is DragEvent.ACTION_DRAG_LOCATION")
        }
        ACTION_DRAG_ENDED -> {
            Log.d(msg, "Action is DragEvent.ACTION_DRAG_ENDED")
        }
        ACTION_DROP -> {
            Log.d(msg, "ACTION_DROP event")
            mViewBinding.ivTriangle.setImageResource(R.drawable.ic_triangle_drag)
            mViewBinding.ivTriangleDrag.visibility = INVISIBLE
            Toast.makeText(this@MainActivity,"You have matched the shape!!",Toast.LENGTH_SHORT).show()
        }

    }
    return true
}

Here is a preview of "Match the Shape" App. And it's Ready.

Hope this article helps you. To check out Full Code, here is the Repository .

If you like the article do follow me for more interesting topics on Android Development.

Happy Coding! :)