Android Notes


Channel's geo and language: not specified, not specified
Category: not specified


Avval bajaring.
Keyin to'g'ri bajaring.
Undan keyin esa yaxshiroq bajaring.
Flutter Notes : @flutter_notes_bek
Muallif : @Otabek_Nabijonov

Related channels

Channel's geo and language
not specified, not specified
Category
not specified
Statistics
Posts filter


Android-da Hilt annotatsiyalari haqida.

@android_bek/android-da-hilt-annotatsiyalari-haqida-046de842ede0' rel='nofollow'>https://medium.com/@android_bek/android-da-hilt-annotatsiyalari-haqida-046de842ede0

#Android


Androidda Dalvik, ART, JIT va AOT haqida.

@android_bek/androidda-dalvik-art-jit-va-aot-haqida-182ef93d7aed' rel='nofollow'>https://medium.com/@android_bek/androidda-dalvik-art-jit-va-aot-haqida-182ef93d7aed

#Android


Androidda Screenshot-larni aniqlash.

Skrinshotlarni aniqlashning standartlashtirilgan tajribasini yaratish uchun Android 14 maxfiylikni saqlaydigan skrinshotni aniqlash API-ni taqdim etadi. Bu API ilovalarga har bir faoliyat asosida callback-larni ro‘yxatdan o‘tkazish imkonini beradi. Ushbu callback-lar chaqiriladi va Activity ko'rinib turganda, user skrinshot olganida user-ga xabar beriladi.

Callback haqiqiy skrinshotning rasmini bermaydi. User skrinshot olganida ekranda nima paydo bo‘lganini aniqlash ilovangizga bog‘liq.

Android 14 da, tizim API faqat, agar user qurilma tugmachalarini bosishning ma'lum kombinatsiyasini bajarsa, skrinshotni aniqlaydi. API skrinshotlar, jumladan, ADB bilan bog‘liq test buyruqlari bajarilganda yoki qurilmaning joriy ekranni yozib oladigan asbob-uskunalar testlarida olingan skrinshotlarni aniqlamaydi.

Buni qanday amalga oshiramiz :

1. Manifest faylga permission qo'shish.


2. Callback-ni qayta yozamiz.
val screenCaptureCallback = Activity.ScreenCaptureCallback {
// Add logic to take action in your app.
}

3. Activity-ning onStart metodi ichida screenshot callback-ni ro'yxatdan o'tkazamiz.
override fun onStart() {
super.onStart()
// Pass in the callback created in the previous step
// and the intended callback executor (e.g. Activity's mainExecutor).
registerScreenCaptureCallback(mainExecutor, screenCaptureCallback)
}

4. Activity-ning onStop metodi ichida screenshot callback-ni ro'yxatdan o'chiramiz.
override fun onStop() {
super.onStop()
unregisterScreenCaptureCallback(screenCaptureCallback)
}

Agar dasturingizda screenshot olish yoki ekranni yozib olish (screen recording)-ni o'chirib qo'ymoqchi bo'lsangiz, Activity-da quyidagi kodni yozasiz.
activity.getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE)


Manba : Link

#Android


Android UI-ni qanday render qiladi.

@android_bek/android-ui-ni-qanday-render-qiladi-84aa2c45b96d' rel='nofollow'>https://medium.com/@android_bek/android-ui-ni-qanday-render-qiladi-84aa2c45b96d

#Android


Androidda APK va AAB farqlari haqida.

APK (Android Package).
APK - bu Android tomonidan ishlatiladigan fayl formati bo'lib, o'zida dasturning kompilyatsiya bo'lgan versiyasini saqlaydi. APK huddi "zip" fayl kabi o'z ichida, dastur haqidagi malumotni o'z ichiga olgan Manifest fayl, dastur ichida ishlatilgan barcha resurslarni saqlaydi.

AAB (Android App Bundle).
AAB - bu 2018-yil Google tomonidan taqdim etilgan fayl formati bo'lib, Google Play Store-ga dasturni publish qilish uchun ishlatiladi. AAB, kompilyatsiya bo'lgan kod, resurslar, asset-lar va qurilma konfiguratsiyalari (ekran hajmi, til va boshqalar)-ni o'z ichiga oladi, lekin APK-ga qaraganda paketlashning samarali usuli deb ham qaraladi.

AAB-ning APK-ga nisbatan asosiy afzalliklari shundan iboratki, AAB hajmi kichikroq, yuklab olish tezroq va dinamik xususiyatlarni yetkazib berishga imkon beradi. Biroq, AAB-ni yaratish uchun APK-ga qaraganda ko'proq mehnat talab etiladi va hozirda Google Play Store-da qo'llab-quvvatlanadigan yagona formatdir.

APK va AAB o'rtasidagi farqlardan yana biri shuki, Google Play Store-dan dastur yuklab olsangiz, Store, foydalanuvchi qurilmasiga kerakli bo'lgan resurslarga ega bo'lgan "Custom APK" generatsiya qiladi. Bu esa dasturning hajmi kichikroq bo'lishi bilan foydalidir.

Manba : Link

#Android


Jetpack Compose-da screen orientation o'zgarishlarini aniqlash.

Landscape rejimni o'chirish uchun AndroidManifest faylga screenOrientation attribut qo'shish mumkin.

Manba : Link

#Android


Android-da Notification haqida.

@android_bek/android-da-notification-haqida-628f67f726c2' rel='nofollow'>https://medium.com/@android_bek/android-da-notification-haqida-628f67f726c2

#Android


Android-da Content Provider haqida.

@android_bek/android-da-content-provider-haqida-279ba1328f4a' rel='nofollow'>https://medium.com/@android_bek/android-da-content-provider-haqida-279ba1328f4a

#Android




Juda ajoyib maslahat.

Tarjima : "Agar yangi narsalarni o'rganishni yomon ko'rsang, dasturchi bo'lma".

Manba : Linkedin


Jetpack Compose-da margin va padding haqida.

Compose-da margin modifikatori yo'qligi sababli, margin va padding-ga erishish uchun padding() modifikatoridan foydalanamiz.

padding() modifikatorini har qanday modifikatordan oldin ishlatsak "margin", aks holda "padding" xususiyatiga erishamiz.

Qo'shimcha manbalar :
1. Link
2. Link

#Android


Kotlinda o’zgaruvchanlik (mutability) va o’zgarmaslik (immutability) haqida.

@android_bek/kotlinda-ozgaruvchanlik-mutability-va-o-zgarmaslik-immutability-haqida-d9138be70267' rel='nofollow'>https://medium.com/@android_bek/kotlinda-ozgaruvchanlik-mutability-va-o-zgarmaslik-immutability-haqida-d9138be70267

#Kotlin


Imperative, Functional va OOP farqlari.

Dasturiy ta'minotni ishlab chiqishda turli xil dasturlash paradigmalari kodni tuzishning o'ziga xos usullarini taklif qiladi. Uchta asosiy paradigma - bu Imperativ, Funksional va Obyektga yo'naltirilgan dasturlash, ularning har biri muammoni hal qilishda alohida yondashuvlarga ega.

1. Imperativ dasturlash:
- Buyruqlar ketma-ketligi orqali dastur holatini o'zgartirish orqali ishlaydi.
- Bajarish oqimi uchun sikllar va shartli bayonotlar kabi boshqaruv tuzilmalaridan foydalanadi.
- O'zgaruvchan ma'lumotlarga va vazifani bajarish uchun aniq qadamlarga urg'u beradi.
- Misollar: C, Python va ko'pgina protsedura tillari.

2. Funksional dasturlash:
- Nojo'ya ta'sirlarsiz (side effect) hisoblashni ta'kidlab, sof funksiyalarga tayanadi.
- o'zgarmaslikni va o'zgaruvchan holatdan qochishga yordam beradi.
- Yuqori tartibli funksiyalar, rekursiya va deklarativ dasturlashni qo'llab-quvvatlaydi.
- Misollar: Haskell, Lisp, Scala va JavaScript kabi tillardagi funksional xususiyatlar.

3. Obyektga yo'naltirilgan dasturlash:
- Ma'lumotlar va metodlarni o'z ichiga olgan real entity-larni obyektlar sifatida modellashtirishga e'tibor qaratadi.
- Meros (inheritance), inkapsulyatsiya va polimorfizm kabi tushunchalarni rag'batlantiradi.
- Kodni tuzish uchun class-lar, obyektlar va interfeyslardan foydalanadi.
- Misollar: Java, C++, Python va Ruby.

Manba : Link


AlarmManager vs JobScheduler vs WorkManager.

🚀 Alarm Manager.
Signal menejeri Android tizimidagi tizim xizmati bo'lib, ilovangizni ma'lum bir vaqtda yoki ma'lum vaqt oralig'idan keyin ishga tushirishni rejalashtirish uchun foydalaniladi.

Ilovangiz ishlamayotgan bo'lsa ham ishlaydi va vazifani bajarish uchun ilovangizni belgilangan vaqtda uyg'otadi.

Nomidan ko'rinib turibdiki, u tizimni voqea haqida aniq vaqtda xabardor qilish uchun mo'ljallangan. Odam uxlayotgan bo'lsa ham, odamni uyg'otadigan jismoniy signal kabi, AlarmManager qurilmani uyqu rejimidan uyg'otadi, bu esa ko'proq quvvat sarflanishiga olib keladi.

Qachon foydalanamiz ?
Foydalanuvchiga davriy bildirishnoma (notification) yoki eslatma yuborish.
Ilovani yangilash yoki zaxiralash (backup)-ni rejalashtirish.

🚀 Job Scheduler.
JobScheduler - bu task-larning qachon va qanday bajarilishi ustidan ko'proq nazoratni ta'minlovchi yanada rivojlangan variant.

Bu tarmoq mavjudligi, qurilmaning zaryadlash holati yoki foydalanuvchi faoliyati asosida vazifalarni rejalashtirish imkonini beradi.

JobScheduler Alarm Manager-ga qaraganda samaraliroq, chunki u task-larni to'plashi va ularni batareyaga qulayroq tarzda bajarishi mumkin.

JobScheduler qat'iy muddatlarni talab qiladigan vazifalar uchun mos emas, chunki tizim aniq bajarilish vaqtini kafolatlamasligi mumkin.

Qachon foydalanamiz ?
→ Qurilma internetga ulanganda ma'lumotlarni masofaviy server bilan sinxronlash.
→ Background-dagi joylashuvni kuzatish yoki sensor monitoringini amalga oshirish.

🚀 Work Manager.
WorkManager background task-larni bajarish uchun Android platformasiga eng so'nggi qo'shimcha hisoblanadi.

Bu dastur o'chirilgan yoki qurilma qayta ishga tushirilgan taqdirda ham bajarilishi kafolatlangan vazifalarni rejalashtirish va bajarishning moslashuvchan, samarali va ishonchli usulini taqdim etadi.

Work menejeri JobScheduler-ning ustiga qurilgan va vaqt, tarmoq ulanishi yoki qurilmaning zaryadlash holatiga qarab vazifalarni rejalashtirish imkonini beruvchi soddalashtirilgan API taqdim etadi.

WorkManager API barcha oldingi Android background rejalashtirish API-lari, jumladan FirebaseJobDispatcher, GcmNetworkManager va JobScheduler o'rniga tavsiya etilgan.

Qachon foydalanamiz ?
→ Background-da katta ma'lumotlar to'plamlari yoki image-larni qayta ishlash.
→ Tarmoqqa ulanishni talab qiladigan davriy vazifalarni bajarish.

Agar siz aniq vaqtda biror narsa qilishingiz kerak bo'lsa, AlarmManager bu yechimdir. Boshqa barcha holatlarda, WorkManager ishlatish mumkin.

Manba : Link

#Android


Android-da Application class haqida.

@android_bek/android-da-application-class-haqida-3fccc62896c9' rel='nofollow'>https://medium.com/@android_bek/android-da-application-class-haqida-3fccc62896c9

#Android


MVC, MVP, MVVM, MVVM-C va VIPER arxitektura farqlari.

1. MVC (Model-View-Controller).
Bu eng qadimgi va eng ko'p qabul qilingan dizayn naqshlaridan (pattern) biridir. Uning asosiy maqsadi dastur ma'lumotlarini (data), UI-ni va boshqaruv mantig'ini bir-biriga bog'langan uchta komponentga ajratishdir.

Bu yerda Model data va logikani boshqaradi, View ma'lumotni ko'rsatadi, Controller Model va View-ni bog'laydi va user kiritgan ma'lumotlarni boshqaradi.

2. MVP (Model-View-Presenter).
MVC-ning yaxshilangan versiyasi bo'lib, u hodisaga asoslangan muhitdagi kamchiliklarini Model-dan View-ni ajratish yo'li bilan bartaraf etishga qaratilgan va Presenter o'rtada vositachi sifatida ishlaydi.

Bu yerda Model ma'lumotlarni boshqaradi, View ma'lumotlarni ko'rsatadi va user buyruqlarini Presenter-ga yuboradi, Presenter esa Model-dan ma'lumotlarni oladi va uni View-ga taqdim etadi.

3. MVI (Model-View-Intent).
MVI - reaktiv arxitektura bo'lib, bir yo'nalishli ma'lumotlar oqimini o'z ichiga oladi, bu holatda UI barqaror bo'lishini ta'minlaydi.

Bu yerda Model holatni (state), View state-ni aks ettiradi, Intent esa state-ni o'zgartiruvchi user harakatlarini ifodalaydi.

4. MVVM (Model-View-ViewModel).
MVVM, UI komponentlarini bilmagan holda ViewModel view logikasini handle qilish bilan ajratilgan yondashuvni targ'ib qilib, UI yaratishdagi murakkabliklarni hal qilish uchun paydo bo'ldi.

Bu yerda Model ma'lumotlarni boshqaradi va ko'rsatadi, ViewModel esa UI bilan bog'liq ma'lumotlarni saqlaydi va o'z ichiga oladi.

5. MVVM-C (MVVM va Coordinator).
MVVM-C bu MVVM-ga asoslanib, navigatsiyani boshqarish uchun Coordinator-ni tanishtiradi, uni View va ViewModel-dan ajratadi.

Murakkab navigatsiyani, view mantig'idan ajratish kerak bo'lgan kattaroq ilovalar, ayniqsa iOS uchun.

6. VIPER (View-Interactor-Presenter-Entity-Router).
VIPER - toza arxitektura (clean architecture)-ga o'xshash modulli arxitektura. Bu dastur mantig'ini alohida komponentlarga bo'lish orqali testlashga va Yagona javobgarlik (Single Responsibility) printsipiga urg'u beradi.

Bu yerda View, Presenter yuborgan narsalarni ko'rsatadi, Interactor har bir foydalanish holati uchun biznes mantig'ini o'z ichiga oladi, Presenter kontentni tayyorlash uchun view logikasini o'z ichiga oladi, Entity asosiy model obyektini va Router navigatsiya mantiqini o'z ichiga oladi.

Manba : Linkedin


Android-da Multidex haqida.

Java-da, agar biz kodimizni kompilyatsiya qilsak, bu kod kompilyator tomonidan .class fayliga aylanadi, chunki bizning mashinamiz bu .class faylini tushunadi. Android ilovasi uchun ham xuddi shunday jarayon. Android-da kompilyator bizning manba kodimizni DEX (Dalvik Executable) fayliga aylantiradi.

DEX-ga o'tishdan oldin, Android-ning build tizimining ba'zi tushunchalarini qayta ko'rib chiqamiz. Android resurslarni, dasturimiz kodlarini va package-larni APK-ga o'giradi. Loyihamizni APK ga aylantirish, ko'plab vositalarni talab qiladi va ko'plab jarayonlarni o'z ichiga oladi.

Android-da kompilyatorlar source kodingizni DEX fayllariga aylantiradi. Ushbu DEX fayli dasturni ishga tushirish uchun kompilyatsiya qilingan kodni o'z ichiga oladi. Ammo DEX faylida cheklov mavjud.

Bitta DEX faylida havola (reference) qilinishi mumkin bo'lgan metodlarning umumiy sonini 64K, ya'ni 65,536 metod bilan cheklanadi. Shunday qilib, ma'lum bir DEX faylida 64K dan ortiq metodlardan foydalana olmaysiz. Ushbu 64K metodlari Android framework metodlari, kutubxona metodlari va bizning kodimizdagi metodlarni ham o'z ichiga oladi.

Shunday qilib, agar ilovamiz 65 536 ta metod-dan oshsa, ilovamiz Android build arxitekturasi chegarasiga yetganini ko'rsatadigan build error-ga duch kelamiz.

Muammoni hal qilish uchun :
build.gradle faylga dependency qo'shib olamiz va shu fayldagi defaultConfig ichiga "multiDexEnabled true" ni qo'shamiz.

Dependency :

implementation 'androidx:multidex:{latest-version}'

Manba : Link

#Android


Kotlin Flow-da Retry, Take, First va Last funksiyalari haqida.

1. retry (qayta urinib ko'rish) - flow-dan kelayotgan elementlarni, qachonki xatolik (exception) sodir bo'lganda qayta urinib ko'rish imkonini beradi. Berilgan son bo'yicha shuncha marotaba urinib ko'radi. Agar biror son berilmasa, default holatda "Long.MAX_VALUE" ni oladi.

2. take - birinchi N-ta elementdan iborat flow qaytaradi. Agar N negativ bo'lsa, "IllegalArgumentException" xatolik beradi.

3. first - flow-dan emit qilingan 1-chi elementni oladi. Agar flow bo'sh bo'lsa, "NoSuchElementException" xatolik beradi. Bu funksiyaning Overload qilingan versiyasi ham mavjud. Berilgan shart bo'yicha 1-chi uchragan elementni qaytaradi va flow-ni cancel qiladi.

4. last - flow-dan oxirgi emit qilingan elementni qaytaradi, agar flow bo'sh bo'lsa, "NoSuchElementException" xatolik beradi.

Manbalar :
1. Retry : Link
2. Take : Link
3. First : Link
4. Last : Link

#Kotlin


Kotlin Flow-da count, drop va filter funksiyalari haqida.

1. count - flow-dagi elementlar sonini qaytaradi.

2. drop - birinchi N-ta elementni tashlab ketib, qolgan elementlar bilan yangi flow qaytaradi. Agar beriladigan son negativ (minus) bo'lsa "IllegalArgumentException" xatolik qaytadi.

3. filter - berilgan shart bo'yicha flow-dagi elementlarni filterlash imkonini beradi.

Manbalar :
1. Count : Link
2. Drop : Link
3. Filter : Link

#Kotlin


Kotlin Flow-da fold va reduce funksiyalari haqida.

1. reduce - har bir emit qilingan qiymatga akkumulyator funksiyasini qo'llash orqali flow-ni yagona qiymatga kamaytirish (reduce) uchun ishlatiladi. Akkumulyator funksiyasi ikkita parametrni oladi : avvalgi to'plangan qiymat va flow tomonidan emit qilingan joriy qiymat.

Akkumulyator funksiyasining natijasi keyingi emissiya uchun yangi to'plangan qiymatga aylanadi. Bu jarayon oqimdagi barcha qiymatlar qayta ishlanmaguncha davom etadi, natijada bitta qiymat olinadi.

2. fold - reduce-ga o'xshaydi, lekin u akkumulyator uchun boshlang'ich (initial) qiymat berishga imkon beradi. Ushbu boshlang'ich qiymat, flow qiymatlarini qayta ishlashdan oldin birinchi to'plangan qiymat sifatida ishlatiladi.

Keyin akkumulyator funksiyasi flow-dagi dastlabki qiymatga va har bir emit qilingan qiymatga qo'llaniladi.

Manbalar :
1. Link
2. Link

#Kotlin

20 last posts shown.

76

subscribers
Channel statistics