Interfaces Aren’t Overkill — They’re Future-Proofing Your Code Early in my Flutter journey, I tho...Interfaces Aren’t Overkill — They’re Future-Proofing Your Code Early in my Flutter journey, I tho...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Interfaces Aren’t Overkill — They’re Future-Proofing Your Code
Early in my Flutter journey, I thought interfaces were just unnecessary ceremony.
“Why create an abstract class when I can just write a service class for API calls and use it directly?” I asked.
Well, I worked under senior devs then, and I followed their guidance, hoping to understand “why” one day. When I started owning/overseeing projects, the "why" became vidvid to me.
In this project, I was using flutter_secure_storage for auth tokens and some simple user data. Everything worked perfectly.
Then the client said: “We need parts of the app to work offline.”
I needed a local database — Hive. Fortunately, I already had a local storage interface. All I had to do was:
Create HiveLocalStorageServiceImpl implementing the interface, "default" it as a dependency in the offline-specific cubits
Zero breaking changes, zero headaches, everything just worked.
I use to understand interfaces like hosting an event with a strict dress code:
Black shoes ✅
White wristwatch ✅
Green face cap ✅
Every guest must follow the rules (the interface), but each guest can choose their own style:
Guest A: Oxford shoes, Rolex, silk cap
Guest B: Nike sneakers, Casio watch, baseball cap
Guest C: Crocs, Apple Watch, vintage cap
All follow the contract, all do their own thing.
In code, it is the same: one view-model uses FlutterSecureStorage for tokens, another uses Hive for offline meter readings. The interface guarantees the contract; the implementation decides the style.
Why this matters:
✅ Flexibility => Swap Hive, Isar, or any storage without touching dependent code
✅ Testing => Mock any implementation and inject it wherever needed
✅ Clarity => The contract is explicit, separate from the implementation
Two people open the same class. Both screens say one spot left, both tap Reserve, and both get a confirmation. Each app read the counter, saw space, and wrote its booking before the other write landed.
Disabling the button after the first tap does not help, because each phone only knows about its own button. Running the transaction from the Flutter client is the wrong place too: the client would need permission to write the shared counter, and anything that can write it can set it to whatever it likes. Put the check and the claim in one Firestore transaction on a trusted server, which reads capacity, refuses the request when it is full, and otherwise creates a hold and increments the counter in the same commit.
The retry is the easy part to miss. Give each attempt a request ID generated once on the device, so a replay returns the original hold instead of taking a second seat.
https://www.duskolicanin.com/blog/flutter-firestore-transactions-limited-capacity
Worked on Several projects, firstly as a backend Engineer of an Enterprise OS project that turns product development into real life scenario for average users...
Project was paused due to internal issues 🥲... can't explain much on that.
That did not stop me i moved on to work on a Mobile application for Australian Workers.
PayTracc is the name and i built it on Flutter which is a cross native platform that allows developers to build iOS/ Android Apps easily.
Paytracc is an Australian employee‑focused work and pay‑tracking app that consolidates shifts, timesheets, leave, multiple jobs, and estimated pay into one mobile dashboard. It’s designed for shift workers, people with variable schedules, and anyone who wants a clear, private record of their working life before payday.
When i started the discussion with the founder, on our first meeting i did not get anything he said at all cause i wasn't familiar with Australian work life and how it worked.
It took several meetings of him explaining things to me to get the grasp of it.
I worked hand in hand with the Ui designer to bring the vision to life.
It took me 4 months to work on this project and still minor bugs to fix daily, it's just never ending at the point but i am loving every step.
It's been a great journey and i both suffered and enjoyed every step of the way...
The Android Application was launched and approved Last month, while the IOS has been approved for testing, i am still fixing some bugs before we push for launch.
The journey has been a good one from struggling to know how to setup the awards to finding out about Australian Fairworks commission and how they provide an api for you to connect to and pull all the latest australian awards. Fair works really helped ease my job as previously we are aiming to upload the individual awards on the database and guess what? we have over 5000+ awards, imagine how stressful that would have been.
Thankful to God for the strength and wisdom he gave me to push through the entire project.