Abdulkabir Adekanye

1.6K posts

Abdulkabir Adekanye banner
Abdulkabir Adekanye

Abdulkabir Adekanye

@_KanyeDev

Flutter App Developer | CEO @CyrexTech_

Katılım Ocak 2020
84 Takip Edilen223 Takipçiler
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Local LLMs running fully on device means user data never hits a server. No API calls, no logs, no third party agreements. For devs building sensitive apps, this isn't just a trend. It's the architecture shift we actually needed.
English
1
1
5
607
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Not every widget needs its own file, fam. Splitting obsessively kills context. Sometimes keeping related widgets together is just cleaner code. Read the room, not the rulebook.
English
1
3
8
1.6K
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Clean Architecture in Flutter is mid for most apps. You're not building Google Maps. The extra layers just mean more files, more boilerplate, and slower shipping. Sometimes the real move is knowing when NOT to over-engineer.
English
11
2
51
2.6K
Chidiebube ⌘ Iroezindu
Chidiebube ⌘ Iroezindu@thedevwriter·
@_KanyeDev Totally. Every dev who said they’d add flavors after they were done building the app never did 😂
English
2
0
1
12
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
@thedevwriter Ha, the graveyard of good intentions. I've seen so many 'we'll refactor it later' promises evaporate. Starting right pays dividends fast.
English
1
0
1
11
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Stop copy-pasting try-catch across every Flutter service. A Dio interceptor catches network and HTTP errors (timeouts, 401s, 404s) in one place. Just remember: it's your first line of defense, not the only one.
English
0
0
5
147
Marvito
Marvito@larrybson21·
@_KanyeDev Absolutely, can never be to careful when creating a Flutter app
English
1
0
2
23
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
@thedevwriter Exactly. Setting it up from the start saves so much friction down the line. The pain of retrofitting flavors later is real.
English
1
0
1
17
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
@michaelbushe Same here. Setting them up early saves so much refactoring pain down the road. Plus it forces you to think about your app structure from day one instead of bolting it on later.
English
0
0
1
13
Iwarifgha
Iwarifgha@Iwarifgha1·
@_KanyeDev Better not to use it at all. Especially for enterprise apps
English
1
0
2
105
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Putting your Future inside FutureBuilder's build method restarts the task on every rebuild. Each build call creates a new Future object, and FutureBuilder compares by reference, so a new instance means a fresh start. Fix: initialize it once in initState(), store it in a field
English
2
0
8
4.3K
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
@Shahood Neat part: that's the one nesting case that doesn't need slivers. Horizontal-in-vertical is just nested ListViews, inner gets a fixed height. Even in a CustomScrollView it'd sit in a SliverToBoxAdapter as a plain box. Slivers earn their keep composing the same axis.
English
0
0
1
21
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
SliverList shines in CustomScrollView for complex UIs. But for a simple list? ListView.builder is easier and wraps SliverList internally anyway. Use Slivers directly when composing SliverAppBar, SliverGrid, or SliverPersistentHeader combos.
English
1
0
0
77
Alessio Salvadorini 💙
Alessio Salvadorini 💙@ASalvadorini·
Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. Don't use FutureBuilder. #Flutter #Flutterdev
Abdulkabir Adekanye@_KanyeDev

Putting your Future inside FutureBuilder's build method restarts the task on every rebuild. Each build call creates a new Future object, and FutureBuilder compares by reference, so a new instance means a fresh start. Fix: initialize it once in initState(), store it in a field

English
5
0
30
8.3K
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Skipping dispose() on controllers and un-cancel()ed stream subs is how leaks hit prod. The order matters: dispose/cancel everything you own first, then super.dispose() last, never touch this after super runs. leak_tracker in tests catches the rest.
English
0
0
0
210
Abdulkabir Adekanye
Abdulkabir Adekanye@_KanyeDev·
Using BuildContext after an async gap without a mounted check ships crashes to prod. Debug catches it; release burns users. The fix: if (!mounted) return in State, if (!context.mounted) return elsewhere (Flutter 3.7+). Better yet: don't pass context across async
English
0
0
0
67