Syed Zubyl N | Software Developer - Mobile

What I Learned Building Flutter Applications Around Real APIs

Syed Zubyl N — Mon, 18 May 2026 00:00:00 +0000

The Problem</h3>
Building a UI in Flutter is relatively straightforward. The real complexity begins when you connect that beautiful UI to a real-world, unpredictable REST API. Handling token expiration, offline states, local caching, and malformed JSON payloads quickly turns a simple app into a debugging nightmare.

Context</h3>
While building a mobile LMS (Learning Management System) application in Flutter, I needed to fetch course catalogs, stream videos, and issue certificates. This required robust communication with a backend API while ensuring the app remained responsive even when the user’s internet connection was spotty.

What I Tried</h3>
I initially relied solely on the network. Every time a user opened a screen, a `FutureBuilder</code> would fire off an HTTP request and display a loading spinner until the data arrived.`

What Failed</h3> Poor UX: Users stared at loading spinners constantly.</li> Offline Experience: If a user boarded a subway, the app became completely useless. It crashed or showed generic error screens.</li> API Rate Limiting: Spamming the backend with requests every time a user switched tabs was highly inefficient.</li> </ol> What Worked & Technical Explanation</h3> I shifted to a Local-First Architecture using SQLite (via the sqflite</code> package). Instead of the UI talking directly to the API, the UI only talks to the local SQLite database. A separate background synchronization engine talks to the API. The Flow: User opens the Course List screen.</li> The UI reads immediately from SQLite and displays cached data (instant load).</li> In the background, the app fires an API request to check for updates.</li> If the API returns new data, it updates the SQLite database.</li> The UI, listening to a stream from the database, automatically rebuilds with the fresh data.</li> </ol> Handling API Failures: If an API request fails (e.g., user is offline, or the server returns a 500 error), the app simply logs the failure silently. The user is still looking at the cached data from SQLite and can continue interacting with the app. Lessons Learned</h3> Never trust the network. The network will fail, it will be slow, and it will return unexpected data.</li> Defensive Parsing: Always wrap JSON parsing in try-catch blocks or use robust code-generation tools. One unexpected null</code> field from the backend can crash the entire Flutter isolate.</li> Local State is King: For an app to feel fast and native, data must be available locally on the device the millisecond the screen renders.</li> </ol> What I Would Do Differently</h3> Instead of writing raw SQL queries for SQLite, I would adopt a higher-level reactive database like Isar or ObjectBox. They provide out-of-the-box stream capabilities that make tying local database updates directly to Flutter’s reactive UI significantly easier than building custom StreamControllers</code> over sqflite</code>.

Designing a Reliable API Layer for a Mobile Application Syed Zubyl N — Sun, 22 Mar 2026 00:00:00 +0000 The Problem</h3> In the early stages of a mobile LMS application, HTTP requests were scattered directly inside UI widgets. Buttons would execute http.get</code>, parse JSON inline, and call setState</code>. This quickly became unmaintainable. Token expiration caused random crashes, error handling was inconsistent, and mocking data for tests was impossible. Context</h3> A robust mobile application requires a strict separation of concerns. The UI should only care about displaying state, not fetching it. The networking layer must handle token injection, timeouts, retries, and error standardization before the data ever reaches the UI. What I Tried</h3> I initially tried to create a single massive ApiService</code> class that contained every single endpoint in the application. What Failed</h3> The ApiService</code> file grew to thousands of lines. When multiple developers worked on different features (Authentication, Courses, User Profile), merge conflicts became a daily nightmare. Furthermore, handling token refreshes on a per-method basis resulted in heavily duplicated code. What Worked & Technical Explanation</h3> I re-architected the API layer into a layered, modular system based on the Repository Pattern and Interceptors. 1. The Base HTTP Client (The Interceptor Layer) Instead of using raw http.Client</code>, I implemented a wrapper (using packages like dio</code> or custom http.BaseClient</code> implementations) that intercepts every request. Request Interceptor: Automatically injects the Authorization: Bearer <token></code> header from secure storage into every outgoing request.</li> Response Interceptor: Global error handling. If a 401 Unauthorized</code> is returned, the interceptor pauses all outgoing requests, silently hits the refresh-token endpoint, updates secure storage, and retries the failed requests.</li> </ul> 2. Domain-Specific Repositories Instead of one massive API class, I created focused repositories: AuthRepository</code>: Handles login, registration, and token management.</li> CourseRepository</code>: Fetches course lists and lesson details.</li> VideoRepository</code>: Manages video streaming URLs and playback telemetry.</li> </ul> 3. Standardized Result Wrappers Instead of throwing exceptions directly into the UI, repositories return a standardized Result type (often using Dart’s Either</code> pattern via the fpdart</code> or dartz</code> package). Future<Either<ApiFailure, Course>> getCourseDetails(String id) async { try { final response = await _client.get('/courses/$id'); return Right(Course.fromJson(response.data)); } on DioError catch (e) { return Left(ApiFailure.fromDioError(e)); } }</code></pre>Lessons Learned</h3> Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean. What I Would Do Differently</h3> I would implement local caching (using SQLite) much earlier in the architecture. While the API layer was robust, relying entirely on network availability resulted in a poor experience on slow connections. Integrating a repository that checks local storage before hitting the API is the next logical step.

Syed Zubyl N | Software Developer - Mobile

What I Learned Building Flutter Applications Around Real APIs

What I Tried</h3>
I initially relied solely on the network. Every time a user opened a screen, a `FutureBuilder</code> would fire off an HTTP request and display a loading spinner until the data arrived.</p>`

Designing a Reliable API Layer for a Mobile Application

Lessons Learned</h3>
Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>

Syed Zubyl N | Software Developer - Mobile

What I Learned Building Flutter Applications Around Real APIs

What I Tried</h3> I initially relied solely on the network. Every time a user opened a screen, a FutureBuilder</code> would fire off an HTTP request and display a loading spinner until the data arrived.</p>

Designing a Reliable API Layer for a Mobile Application

Lessons Learned</h3> Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>

What I Tried</h3>
I initially relied solely on the network. Every time a user opened a screen, a `FutureBuilder</code> would fire off an HTTP request and display a loading spinner until the data arrived.</p>`

Lessons Learned</h3>
Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>