Bloc (Cubit) ning super kuchlari, kubitchilar bormi?

Tutvoling: https://medium.com/flutter-community/bloc-superpowers-2ef9262ed962

@flutterdevuz

Meta’ning Ray-Ban smart ko’zoynaklari foydalanuvchilarning suratlari, videolari va ovozli yozuvlarini serverlarga yuboradi. Keniyalik xodimlar bu ma’lumotlarni AI o’rgatish uchun qo’lda ko’rib chiqishadi — va ular orasida yalang’och odamlar, intim sahnalar, bank kartalari, shaxsiy suhbatlar ham bor. Yuzlarni avtomatik xiralash tizimi ko’pincha ishlamaydi. Foydalanuvchilarga “ma’lumotlarni nazorat qilasiz” deyilgan, lekin amalda bu shartdan voz kechish imkoni yo’q.

Aslida bu smart qurilmalar bozorida keng tarqalgan muammo — har qanday AI xizmat “cloud processing” talab qilganda, ma’lumotlar albatta serverga ketadi. Foydalanuvchilar buni ko’pincha anglamaydi, chunki marketing “privacy” va “control” so’zlarini ko’p ishlatadi. Bu holat yana bir bor shuni ko’rsatadi — foydalanuvchi shartnomani oxirigacha o’qishi kerak, ayniqsa kamerali qurilmalarda.​​​​​​​​​​​​​​​​

Element-dagi dirty yohud setState qanday ishlaydi.

Flutter-da dirty parametr (Element sinfida mavjud) elementni qayta qurish kerakligi haqida framework-ga signal beruvchi bayroqdir (flag).

Vidjet daraxtidagi har bir elementda hayot sikli holati mavjud. Agar element dirty deb belgilangan bo'lsa, bu konfiguratsiya (Vidjet) o'zgarganligini yoki holat (StatefulWidget'da) setState() orqali yangilanganligini anglatadi.

Flutter butun ekranni har bir kadrda qayta render qilmaydi. Buning o'rniga, faqat Qurilish bosqichida (build phase) dirty = true deb belgilangan elementlarga tashrif buyuradi.

setState metodini chaqirish orqali Element-ning dirty qiymati true deb belgilanadi.

void markNeedsBuild() {
if (_lifecycleState != _ElementLifecycle.active)
return;
if (dirty) // If already dirty, do nothing
return;

_dirty = true; // The flag is set here
owner!.scheduleBuildFor(this); // Register with the BuildOwner
}

Manba (framework.dart)
Element sinfida markNeedsBuild() metodi dirty holatni boshqaradi:

void markNeedsBuild() {
if (_lifecycleState != _ElementLifecycle.active)
return;
if (dirty) // If already dirty, do nothing
return;

_dirty = true; // The flag is set here
owner!.scheduleBuildFor(this); // Register with the BuildOwner
}

BuildOwner barcha elementlarning ro'yxatini dirt == true bo'lgan holda saqlaydi.

Keyingi freym ishga tushirilganda, BuildOwner buildScope() ni chaqiradi. Bu metod daraxtning yuqori qismidan pastga dirty elementlar orqali takrorlanadi (ota-ona vidjet bola vidjetdan oldin qayta qurishni ta'minlash uchun).

Nima uchun bunday tartiblash kerak?
Agar ota-ona va bola ikkalasi ham dirty bo'lsa, ota-ona avval qayta quriladi. Ota-onaning qurilishi baribir Bolaning yangi versiyasini yaratishi mumkin, bu esa Bolaning individual qayta qurilishini oldi olinadi.

Element rebuild() metodi chaqirilgunga qadar dirty bo'lib qoladi. performRebuild() ichida, freymvork bayroqni qayta o'rnatadi:

@override
void performRebuild() {
// ... build logic happens here ...
_dirty = false; // The element is now "clean"
}

Manbalar:
1. dirty doc: Link
2. Medium: Link
3. Medium: Link
4. Element doc: Link
5. Telegram post: Link

#Flutter

Kimgadir Flutter bo’yicha darsliklar kerak bo’lsa, kursimni to’liq bepul qilib qo’ydim.


P.S: Kursdagi ayrim versiyalar hozirgi versiyalar bilan mos kelmasligi mumkin. Ammo asosiy mantiq va o’rganish uchun roadmap hali ham usha usha.

Flutter kursim shu yerda:
https://t.me/bepul_flutter

Initially, it may surprise vou to learn that widgets, in the traditional sense, don't have a lifecycle. Widgets are immutable; they cannot be altered once they are created. Thus, when discussing the widget lifecvcle.' we refer to a broader concept that extends to Elements, State objects, and Render objects.

Dastlab, an'anaviy ma'noda vidjetlarning hayot sikli yo'qligini bilib hayron qolishingiz mumkin. Vidjetlar o'zgarmasdir; ular yaratilgandan so'ng ularni o'zgartirib bo'lmaydi. Shunday qilib, vidjetning hayot sikli haqida gap ketganda, biz Elements, State obyektlari va Render obyektlariga oid kengroq tushunchaga ishora qilamiz.

Majid Hajian "Flutter Engineering" kitobidan

Element hayot sikli.

Element bu Widget va RenderObject o'rtasidagi muhim vositachi.

StatefulWidget-da 2 ta metod mavjud: createElement va createState.

createElement - Element obyektini yaratish va uni vidjet daraxtiga o'rnatish (mount) uchun javobgar.

createState - State obyektini element bilan bog'laydi.

Endi esa Element hayot sikli enum-lari bilan tanishamiz.

1. initial - bu holatda, Element obyekti endigina yaratilgan va ishga tushayotgan bo'ladi.

2. active - bu holatda element to'liq ishga tushgan va vidjet daraxtiga integratsiya qilingan bo'ladi. Bu fazada element joylashish (layout) va chizish (painting) jarayonida bo'ladi.

3. inactive - element bu holatga o'tishi bilan vidjet daraxtidan olib tashlanadi ammo xotirada qoladi.

4. defunct - bu elementning so'nggi fazasi. Bu fazada element vidjet daraxtidan olib tashlangan va xotiradan tozalanishga tayyor bo'ladi (garbage collection).

5. failed - Element aktiv bo'lganida yoki daraxtga qo'shilganda qayta tiklanmaydigan xatoga duch kelganda elementning deactivate metodi chaqiriladi.

Manbalar:
1. Github: Link
2. Book: Link

#Flutter

AI haqida shaxsiy fikr va maslahat.

AI ko'p ishlarni qila olayotgan bir davrda, ayniqsa dasturlashda uning rivojlanishi yaxshi bir paytda dasturlashni o'rganish kerakmi ?

Shaxsiy fikr: Albatta va tezroq. Dasturlashni tezroq o'rganib murakkabroq mavzu va yo'nalishlarni ham o'rganish kerak.

Ya'ni Developer-dan Engineer-ga tezroq o'tish kerak.

Developer - kod yozuvchi.
Engineer - loyihalashtiruvchi.

Deylik mobil dasturlashni olaylik, Engineer shunchaki kod yozmaydi, u mobil eko-tizimini yaxshi tushunadi, AI yozgan kodlarni tahlil va tahrir qila oladi, Arxitektura quradi va hokazo.

AI bilan ishlang, unga suyaning, ammo uni sizdan olib qo'yganda yiqilib tushmaydigan darajada suyaning.

AI bu vosita, huddi ustaning bolg'asi kabi, bolg'a bo'lmasa tesha bilan ham ishni bitirib ketaverish kerak.

Flutterda Gestures qanday ishlaydi.

Flutter-da gesture-larni aniqlash va boshqarish ko'p qatlamli jarayon hisoblanadi va u GestureArena mexanizm tomonidan boshqariladi.

Flutterda gesture-lar 3 ta asosiy bosqichga bo'linadi.

1 bosqich: Ko'rsatkichlar (Pointers).
Barmoq ekranga tegsa, asosiy operatsion tizim Flutter engine-ga ma'lumotlar paketini yuboradi. Bu ma'lumotlar PointerEvent-ga o'ralgan bo'ladi (masalan, PointerDownEvent, PointerMoveEvent).

Bu hodisalar jismoniy holatni tavsiflaydi: koordinata, bosim va pointer id. Bu bosqichda Flutter aynan "nima" ga tegilganini bilmaydi, faqat "qayeriga" tegilganini biladi.

2 bosqich: Hit testing.
PointerDownEvent sodir bo'lganda, Flutter shu koordinatada qaysi vidjetlar joylashganligini aniqlash uchun Hit Testini o'tkazadi.

RendererBinding hit-test jarayonini boshlaydi. Tekshiruv oxirgi farzanddan ildizga qarab (leaf-to-root) amalga oshiriladi. Muvofiq kelgan barcha Render obyektlari HitTestResult listiga qo'shiladi.

3 bosqich: Gesture Arena (Ziddiyatlarni hal qilish).
Deylik ListView ichida Button bo'lsa, va ikkalasi ham bir xil gesture-ni kutayotgan bo'lsa, bu konflikt Gesture Arena orqali hal qilinadi. U quyidagicha ishlaydi:

Arena-ga barcha GestureRecognizer-lar qo'shiladi. Har bir recognizer o'z algoritmi bilan harakatni kuzatadi. Masalan, agar barmoq 10 pikseldan ortiq surilsa, VerticalDragGestureRecognizer g'olibligini e'lon qiladi. Bir g'olib aniqlangach, qolgan barcha recognizer-lar arenadan chiqarib yuboriladi va ularning callback-lari ishlamaydi.

Asosiy instrumentlar:
GestureDetector - bu StatelessWidget wrapper vazifasida, o'z holicha gesture-larni aniqlamaydi, balki GestureRecognizer obyektlarini boshqaradi. Siz taqdim etgan callback-larga asoslanib, mos keluvchi recognizer-ni yaratadi.

Listener - Agar sizga Arena mexanizmi kerak bo'lmasa va to'g'ridan-to'g'ri xom koordinatalar bilan ishlamoqchi bo'lsangiz, shu vidjetdan foydalansiz.

Manbalar:
1. Doc: Link
2. Video: Link

#Flutter

Yangilik.

Bugundan boshlab Flutter framework ichidagi (flutter/flutter) Material va Cupertino kutubxonalari uchun yangilanishlar to'xtatildi. Yangi o'zgarishlar framework-dan ajratilgan quyidagi paketlarda davom etadi:

material_ui va cupertino_ui.

Flutter-ning 3.44 stabil versiyasi chiqarilgandan keyin, yuqoridagi paketlarning ham yangi versiyalari (1.0.0) chiqariladi va dasturchilar migratsiya qilishlari kerak bo'ladi.

Albatta migratsiya uchun qo'llanma taqdim etiladi.

Batafsil: Link

#News

Flutter-da Layout protocol.

Asosiy qoida:

"Constraints go down. Sizes go up. Parent sets position."

1. Constraints go down (Cheklovlar pastga o'tadi).
Ota (parent) vidjeti o'zining bolasiga (children) bir qator cheklovlarni o'tkazadi. Cheklov 4 xil ko'rinishda: minimum width/height va maximum width/height.

Ota bolasiga: sen kamida 100px va 300px dan oshmagan holatda bo'la olasan.

2. Sizes go up (Hajm tepaga o'tadi).
Bola vidjet cheklovlarga qaraydi, qanday kattalikda bo'lishga qaror qiladi va Ota vidjetga aytadi. Bola vidjet Ota tomonidan qo'yilgan cheklovlardan tashqari bo'lgan hajmni tanlay olmaydi. Agar bola 500px bo'lishni istasa lekin Ota 300px-ga ruhsat bersa, bola vidjet 300px bo'lishga majbur bo'ladi.

3. Parent sets position.
Ota hajmni oladi va bolani qayerga joylashtirishni hal qiladi. Bola ekrandagi o'z koordinatalari haqida bilmaydi, faqatgina hajminigina biladi xolos.

Tight vs Loose constraints.
Tight constraints: Ota vidjet min va max qiymatlarni bir xil qilib qo'yadi (misol: minWidth=300, maxWidth=300). Dasturingizdagi runApp ichidagi eng 1-chi vidjet ham tizim tomonidan ekran o'lchamichalik kattalikda bo'lishga majburlanadi.

Loose constraints: Ota max-ga qiymat qo'yadi lekin min 0 ga teng (misol: minWidth=0, maxWidth=300).

Unbounded constraints (cheksiz cheklovlar).
Bazi vidjetlar (ListView, Column) o'z bola vidjetlariga istaganicha kattalikda (infinity) bo'la olishini aytadi. Agar siz bu vidjet ichiga cheksiz katta bo'lishni istaydigan vidjetni (ListView yoki LayoutBuilder) qo'ysangiz, Flutter error beradi, sababi chegarasi yo'q vidjetni chizish imkonsiz.

Align va Center: Agar ota vidjet (masalan, Container) boladan kattaroq bo'lsa, Align yoki Center ishlatilmasa, Flutter bolani qayerga qo'yishni bilmaydi va odatda yuqori chap burchakka (top-left) qo'yadi.

LayoutBuilder: Agar bolaga otasi qanday cheklovlar berayotganini ko'rmoqchi bo'lsangiz, shundan foydalanasiz.


Manbalar:
1. Medium: Link
2. Medium: Link

#Flutter

Dasturchi 300$ ga maxsus ovozi uchun mexanik klaviatura sotib oladi va uni 400$ lik shovqin to'suvchi quloqchin bilan ishlatadi 😄

Stack qanday ishlaydi.

Stack ham Layout protocol qoidasiga amal qiladi lekin Stack bir emas ikki turdagi bola vidjetlar bilan ishlaydi: Non-positioned (oddiy) va Positioned (joylangan).

Stack o'z hajmini qanday aniqlaydi ?
Stack o'zining hajmini ichidagi Non-positioned bo'lgan vidjetlarga (Container, Text, etc) qarab belgilaydi.

Stack barcha oddiy bolalaridan so'raydi: "Senga qancha joy kerak". Eng katta hajmni egallagan bola Stack-ning umumiy hajmini belgilaydi. Masalan agar bir bola vidjet 100x100, 2-chisi 200x200 bo'lsa, Stack o'zini 200x200 deb e'lon qiladi.

Positioned children.
Positioned vidjeti bilan o'ralgan bola vidjetlar Stack-ning hajmini belgilashda qatnashmaydi. Ular: "Ota (Stack), sen o'zingni hajmingni aniqlab ol, men keyin senga nisbatan qayerdadir turib olaman", deydi.

Agar Stack-da faqat Positioned vidjetlar bo'lsa va ota vidjet cheklov qo'ymasa, Stack imkon qadar kichik bo'lib qoladi.

Stack-dagi cheklovlar (StackFit).
StackFit.loose (Standart): Ota vidjet Stack-ga bergan cheklovlar bolalarga ham o'tadi.

StackFit.expand: Stack o'zining barcha bolalariga: "Men egallagan butun joyni (max constraints) egallashingiz shart" deydi.

Manbalar:
1. Stack: Link
2. RenderStack: Link
3. Github: Link

#Flutter

Daraxtning eng tepasida nima bor ?

Flutterda 3 ta asosiy daraxt (tree) mavjud: Widget, Element, RenderObject. Lekin hech o'ylab ko'rganmisiz, bu 3 tizimning 'ildizi' (root) nima va ular qanday bog'langan ?

1. WidgetsBinding: Hammasini bog'lovchi.
Ilova ishga tushishi bilan (runApp), WidgetsBinding uyg'onadi. U o'zida BuildOwner (elementlar boshqaruvchisi) va PipelineOwner (render boshqaruvchisi) kabi muhim 'xo'jayinlarni' saqlaydi.

2. RootWidget vs RootElement. (Non-rendering zone)
Siz runApp(MyApp()) ni chaqirganingizda, Flutter sizning MyApp vidjetingizni darhol ekranga chizmaydi. Avval u RootWidget-ni yaratadi.

RootWidget: bu vidjet daraxtining otasi, vazifasi ilovani tizimga ulash.

RootElement: bu element daraxtining otasi. Uning o'ziga xosligi shundaki, u "Non-rendering zone"da joylashgan. Ya'ni, RootElement-ning bevosita o'ziga biriktirilgan RenderObjecti yo'q. U shunchaki boshqaruvchi. Unda build() metodi yo'q, u shunchaki mount() bo'ladi va updateChild orqali MyApp-ni 'hayotga keltirib', pastga qarab zanjirni davom ettiradi.

3. RenderView (Rendering zone).
Bu Render daraxtining otasi hisoblanadi. U bevosita FlutterView (engine oynasi) bilan gaplashadi. RenderView uch bosqichda amalga oshadi:

1. configuration (ekran o'lchami, piksel nisbati) o'rnatiladi.
2. PipelineOwner-ga ulanadi (renderlashni boshqarish uchun).
3. prepareInitialFrame orqali birinchi Layout va Paint jarayoniga start beriladi.

CompositeFrame: Barcha chizish ishlari tugagach, aynan RenderView tayyor tasvirni (ui.Scene) engine-ga va GPU-ga topshiradi.

View widget (o'tkazgich).
RootWidget va MyApp o'rtasida shu vidjeti turadi. U xuddi elektr uzatuvchi kabellar kabi ishlaydi: engine-dan kelayotgan fizik oyna (FlutterView) ma'lumotlarini framework ichiga olib kiradi.


Manbalar:
1. RootWidget: Link
2. RootElement: Link
3. RenderView: Link

#Flutter

Nima uchun Flutterda Key kerak?

Barchaga ma'lum Flutterda hamma narsa Widget va har bir vidjetda key maydoni mavjud. Key nima uchun kerak va qachon ishlatamiz.

Keling 2 ta holatni ko'rib chiqamiz, vidjetdagi qiymat o'zgarishi va vidjetning turi o'zgarishi.

1-Holat: Qiymat o'zgarishi (Rebuild).
Deylik, Text("Hello") vidjeti Text("Goodbye") ga o'zgardi. Flutterda Element sinf Widget sinfining statik metodi canUpdate-ni ishga tushiradi:

static bool canUpdate(Widget oldWidget, Widget newWidget) {
return oldWidget.runtimeType == newWidget.runtimeType && oldWidget.key == newWidget.key;
}

Bu yerda runtimeType bir xil (Text), key esa ikkala holatda ham null. Natija: true.

Natija: Element o'rnida qoladi ya'ni tree-da, u shunchaki yangi vidjetdagi "Goodbye" matnini olib, ekrandagi RenderObject-ni yangilaydi. Bu yerda Key ishlatish shart emas.

2-Holat: Joylashuv o'zgarishi (Swap).
Agar ListView ichida ikkita bir xil turdagi StatefulWidget o'rni almashsa:

1. Flutter index bo'yicha solishtiradi.
2. Tree-da 1-o'rindagi eski Element obyekti yangi kelgan 1-o'rindagi Vidjet bilan solishtiriladi.
3. canUpdate yana true qaytaradi (turi bir xil, keylar null).

Muammo: Element o'rnida qolgani uchun unga bog'langan State obyekti ham qimirlamaydi. Natijada siz 2-vidjetni 1-o'ringa qo'ysangiz ham, ekranda 1-vidjetning eski holati (masalan, yozilgan matni) ko'rinib turaveradi.

Yechim: Vidjetlarga Key (masalan, ValueKey(id)) bersak, canUpdate metodida Key-lar mos kelmaydi (false qaytadi). Flutter shunda Elementlar orasidan mos Key-ni qidiradi va Elementni o'zining State obyekti bilan birga yangi o'ringa ko'chiradi (Grafting).

Key-dan keraksiz joyda foydalanmaslik kerak. canUpdate-ning true qaytarishi Flutter uchun eng arzon va tezkor operatsiyadir. Key-larni noto'g'ri ishlatish (masalan, har safar yangi UniqueKey berish) Flutterni har safar Elementni o'chirib, yangidan qurishga majbur qiladi va bu ilovani sekinlashtiradi.

Batafsil tushunish uchun : Link

GetX haqida mish-mishlar yuribdi, yaxshiyamki loyihalarim getX-da ko'tarilmagan )

https://t.me/DiaryFlutterDev/863

Xayr Javascript va Salom Jaspr.

Flutter jamoasi Jaspr-ni asrab olishdi va Flutter web sahifalarini jaspr-da qayta yozib chiqishdi.

Manbalar:
1. Medium: Link
2. Blog: Link

#Flutter

Android Developer Verification.

Google Play barcha dasturchilar (ham jismoniy shaxslar, ham kompaniyalar) uchun shaxsni tasdiqlash (Verification) jarayonini majburiy qilib belgiladi. Bu foydalanuvchilar xavfsizligini oshirish va "fishing" yoki firibgar ilovalarning oldini olishga qaratilgan.

Yangi dasturchilar uchun akkaunt ochishda shaxsni tasdiqlash majburiy.

Mavjud dasturchilar esa Google Play Console-dagi app-larga bir qarab qo'ying, tasdiqlanmagan dasturlaringizni 2027 yil boshigacha tasdiqlab olishingiz kerak.

Google Play-dan tashqarida app chiqargan bo'lsangiz, package nomini tasdiqlashingiz kerak bo'ladi.

Batafsil:
1. Blog: Link
2. Blog: Link

#Flutter

runApp vs runWidget.

runApp(Widget app).
Asosiy vazifasi siz bergan vidjetni (masalan MaterialApp) olib, uni wrapWithDefaultView metodi orqali View vidjetiga o'raydi va qurilmaning asosiy ekrani (PlatformDispatcher.implicitView) ichiga joylashtiradi.

runWidget(Widget app).
runApp-dan farqli o'laroq u avtomatik ravishda vidjetni View bilan o'ramaydi. Siz o'zingiz qaysi vidjet qaysi ekranga chiqishini belgilaysiz. Bu ayniqsa bir necha oyna (multi-window) bilan ishlash uchun. Masalan, Android studio va Emulator bir-biridan alohida oynada birgalikda ishlaydi, runWidget asosan shunday logika uchun foydali.

Har ikkala funksiya ham quyidagi qatordan keyin oxir-oqibat ichki holatda _runWidget metodini chaqiradi.

final WidgetsBinding binding = WidgetsFlutterBinding.ensureInitialized();

Agar yuqoridagi funksiyalarni ikkinchi marta boshqa vidjet bilan chaqirsangiz, u butun ilovani o'chirib qayta qurmaydi. Buning o'rniga u yangi vidjetni eskisiga solishtiradi (diffing) va faqat o'zgargan qismlarini yangilaydi (xuddi setState kabi).

Doc-da aytilishicha, Flutter ilova yopilayotganda vidjetlarni avtomatik ravishda dispose qilmaydi. Sababi telefon quvvatdan uzilishi yoki ilova crash bo'lishi mumkin va Flutter buni oldindan bilmaydi.

Agar resurslarni yopish kerak bo'lsa (masalan fayl yoki kamera), AppLifecycleListener-dan foydalanish kerak.

Qo'shimcha manbalar:
1. runApp: Link
2. runWidget: Link

#Flutter