Mobile App Architecture, Frameworks & Design Patterns

TAKEAWAYS:

• Mobile apps follow a 4-layer architecture (hardware → OS → middleware → apps), where the OS (Android/iOS) provides APIs for sensors, networking, and UI components.
• Cross-platform frameworks (Flutter, React Native) share 60–90% of code but sacrifice some native performance, while native frameworks (Swift/Kotlin) offer full device access at the cost of higher development effort.
• Design patterns like MVC and MVVM separate concerns: MVC splits logic into Model-View-Controller, while MVVM uses Data Binding to update UI automatically (critical for real-time apps like live traffic updates).
• Middleware (Firebase, Parse) handles cloud sync, authentication, and push notifications—used by eSewa for secure payments and Pathao for driver tracking.
• Performance trade-offs: Native apps load faster (e.g., WhatsApp’s 100ms response time) but require separate codebases; cross-platform apps reduce costs but may lag (e.g., Daraz’s hybrid app vs. its native iOS version).
• Exam focus: Compare frameworks in a table, trace data flow in MVC/MVVM diagrams, and explain how middleware solves offline-first challenges (e.g., Ncell’s app caching messages when no signal).

Mobile System Architecture: Layers and Components

Mobile apps don’t run in isolation—they interact with hardware, operating systems, middleware, and networks. The 4-layer architecture defines how these components communicate:

1. Hardware Layer

• Components: CPU, GPU, sensors (GPS, accelerometer), battery, storage.
• Role: Provides raw input/output (e.g., a Pathao driver’s GPS location or a user’s fingerprint for eSewa login).
• Key APIs: Android’s SensorManager, iOS’s CoreLocation framework.
• Example: When you open the NTC Electricity Bill app, it reads your SIM card’s IMEI to fetch your consumer number—this happens at the hardware layer via the OS’s telephony API.

2. Operating System Layer

• Android (Linux kernel): Uses Java/Kotlin (via Android Runtime) and NDK for C/C++.
• iOS (Darwin kernel): Uses Swift/Objective-C and Metal for GPU acceleration.
• Key Services:
  • Activity Manager: Handles app lifecycle (e.g., pausing WhatsApp when you switch to a call).
  • Content Providers: Secure data sharing (e.g., Contacts app accessed by Pathao for driver profiles).
  • Broadcast Receiver: System-wide events (e.g., low battery alerts).

flowchart TD
    A["Hardware\n(CPU, Sensors)"] --> B["OS Kernel\n(Android: Linux, iOS: Darwin)"]
    B --> C["Android Runtime\n(ART/Dalvik)"]
    B --> D["iOS Runtime\n(Swift/Obj-C)"]
    C --> E["Java/Kotlin APIs"]
    D --> F["Swift/Obj-C APIs"]
    E & F --> G["Middleware\n(Firebase, Google Play Services)"]
    G --> H["Mobile Apps\n(eSewa, Pathao)"]

3. Middleware Layer

Middleware acts as a bridge between apps and cloud services. Nepalese apps rely heavily on:

• Firebase (used by eSewa for real-time transaction status, Khalti for payment gateways).
• Google Play Services (used by Pathao for maps and location tracking).
• Parse Server (open-source alternative for offline data sync).

Example: When you book a ride on Pathao, the app:

1. Sends your location to Firebase via Google Maps API.
2. Firebase matches you with the nearest driver (using geohashing).
3. The driver’s app receives a push notification (via Firebase Cloud Messaging).

sequenceDiagram
    participant User
    participant PathaoApp
    participant Firebase
    participant DriverApp
    User->>PathaoApp: Request ride (GPS on)
    PathaoApp->>Firebase: Send location (geohash)
    Firebase->>Firebase: Query nearest driver
    Firebase->>DriverApp: Push notification (new ride)
    DriverApp->>User: Accept/reject

4. Application Layer

This is where your code runs. Apps are built using:

• Native frameworks: Swift (iOS), Kotlin (Android).
• Cross-platform frameworks: Flutter (Dart), React Native (JavaScript), Xamarin (C#).

Native vs. Cross-Platform Frameworks: Comparison

Worked Example: eSewa’s Payment Flow

1. Native Code (Kotlin/Swift):
   • Uses Android’s PaymentRequest API or iOS’s PassKit for secure transactions.
   • Direct access to the device’s biometric scanner (fingerprint/Face ID).
2. Cross-Platform Limitation:
   • If eSewa used Flutter, it would need a plugin like flutter_secure_storage for OTP handling, adding latency.

flowchart LR
    A["User Opens eSewa\n(Kotlin/Swift)"] --> B["Checks Biometric\n(Hardware Layer)"]
    B --> C["Validates OTP\n(Firebase Auth)"]
    C --> D["Debits Account\n(Nepal Rastra Bank API)"]
    D --> E["Updates UI\n(Native Widgets)"]

Design Patterns for Mobile Apps

Design patterns organize code to handle common problems like state management, networking, and UI updates.

1. Model-View-Controller (MVC)

• Structure:
  • Model: Data (e.g., user profile in eSewa).
  • View: UI (e.g., payment screen).
  • Controller: Logic (e.g., validate OTP before payment).
• Data Flow: View → Controller → Model → View (updates UI).
• Example: Khalti’s Payment Screen
  • View: Dropdown for bank selection.
  • Controller: Validates bank code before proceeding.
  • Model: Fetches bank details from API.

classDiagram
    class Model {
        +fetchUserData()
        +updateBalance()
    }
    class View {
        +renderPaymentScreen()
        +showError(message)
    }
    class Controller {
        +validateOTP()
        +processPayment()
    }
    Model --> Controller : updates
    Controller --> View : notifies
    View --> Controller : user input

2. Model-View-ViewModel (MVVM)

• Key Idea: Data Binding (ViewModel → View) reduces boilerplate.
• Used in: Android (Jetpack), iOS (SwiftUI).
• Example: Pathao’s Live Location Tracking
  • ViewModel: Polls driver location every 2 seconds.
  • View: Automatically updates the map (no manual setState calls).

flowchart TD
    A["Driver Moves\n(GPS Update)"] --> B["ViewModel\n(Polling Loop)"]
    B --> C["Observable Data\n(RxJava/Kotlin Flow)"]
    C --> D["View\n(Map Updates Automatically)"]

Comparison Table:

In the Real World

1. eSewa (Nepal):

   • Architecture: Uses native Kotlin/Swift for performance-critical tasks (biometric auth, payment processing) and Firebase for real-time transaction updates.
   • Design Pattern: MVC for the payment flow (View = UI buttons, Controller = OTP validation, Model = user balance).

2. Pathao (Nepal/Global):

   • Middleware: Relies on Google Maps API (via Firebase) to match riders/drivers in real-time.
   • Cross-Platform: Uses React Native for iOS/Android, but critical features (e.g., in-app calls) are native modules.

3. Google Maps (Global):

   • Native Performance: Uses Swift/Kotlin for smooth animations (e.g., 3D buildings).
   • Middleware: Google Play Services handles location updates even when the app is in the background.

Wireless Connectivity in Mobile Apps

Mobile apps use HTTP/HTTPS, WebSockets, and MQTT for real-time data. Nepalese apps often face high latency (e.g., Ncell’s slow API responses), so optimizations like caching (e.g., Daraz’s offline mode) are critical.

Example: NTC Electricity Bill App

1. Fetches consumer data via REST API (HTTP).
2. Uses local SQLite database to cache bills for offline viewing.
3. Syncs changes when connectivity resumes.

sequenceDiagram
    participant App
    participant NTCServer
    participant LocalDB
    App->>NTCServer: GET /bills/{consumer_id}
    NTCServer-->>App: JSON response
    App->>LocalDB: Cache response
    loop Offline Use
        App->>LocalDB: GET cached_bill
    end
    App->>NTCServer: POST /sync (when online)

Exam Tip

1. Diagrams are mandatory:
   • Draw the 4-layer architecture and label each layer’s role.
   • Trace data flow in MVC/MVVM (e.g., "How does Pathao update the map when the driver moves?").
2. Compare frameworks:
   • Memorize the trade-offs table (native vs. cross-platform) and give one Nepalese example (e.g., "eSewa uses native code for security").
3. Real-world scenarios:
   • Explain how Firebase solves offline-first challenges (e.g., Khalti’s payment queue when no internet).
   • Describe one app’s architecture (e.g., "Daraz’s hybrid app uses React Native for 80% features but native modules for checkout").
4. Common pitfalls:
   • Don’t confuse MVC (Controller updates Model) with MVVM (ViewModel binds to View).
   • Avoid vague answers like "Flutter is fast"—specify 60 FPS vs. native’s 60–120 FPS.

Practice Questions (Self-Check)

1. Draw the Android architecture layers and explain how eSewa’s biometric login interacts with each layer.
2. Compare MVC and MVVM using Pathao’s live tracking as an example. Which pattern would you choose and why?
3. Why does Ncell’s app use local caching? What middleware could it use for push notifications?
4. If you were building a Khalti-like app, would you choose Flutter or native code? Justify with performance and development time trade-offs.