Változók: A val (mutable, módosítható), és a var (immutable, nem módosítható) .

Mindkettő ugyanazt jelenti, csak a szintaxis különbözik.

Változók: val (immutable, nem módosítható) és var (mutable, módosítható).

A val csak osztályokban használható, a var pedig csak függvényekben.

Listák: listOf (immutable lista), mutableListOf (mutable lista).

Listák: listOf (mutable lista), mutableListOf (immutable lista).

Csak arrayOf és intArrayOf.

Csak arrayListOf és hashMapOf.

Csak egyetlen paramétert támogatnak.

Kotlinban a függvényeket a fun kulcsszóval deklaráljuk. Támogatják a default paramétereket, névvel megadott paramétereket, vararg paramétereket.

Kotlinban a függvényeket a fun kulcsszóval deklaráljuk. Csak a fix számú paramétereket támogatják.

Csak anonim paramétereket.

Csak feltételként, nem adhat vissza értéket.

Csak ciklusokban használható.

if kifejezésként is használható (visszaad egy értéket).

Csak string értéket adhat vissza.

Egy ciklus, amely addig fut, amíg egy feltétel igaz.

Egy eszköz, amely csak boolean értékekkel működik.

Egy függvény, amely csak számokkal dolgozik.

when egy sokoldalú eszköz, amely a switch-case struktúrát helyettesíti.

for, while, és do..while ciklusok támogatottak.

Csak for és while ciklususok támogatottak.

Ciklusok nem támogatottak, helyette iterátorokat kell használni.

Csak végtelen ciklusok lehetségesek.

A range kulcsszóval.

A ',,'. operátor segítségével hozhatók létre, például 1,,5.

A Range osztály példányosításával.

A '..' operátor segítségével hozhatók létre, például 1..5.

Csak a függvények deklarációjában a throws kulcsszóval.

Automatikusan, a fordító kezeli.

try-catch blokkok kezelik a kivételeket. Nincs throws kulcsszó a függvény deklarációkban.

Csak globálisan, a program elején.

Lehetővé teszik, hogy új metódusokat adjunk hozzá egy meglévő osztályhoz anélkül, hogy örökölnénk tőle.

Csak az alapvető függvények újradefiniálására használhatók.

Lehetővé teszik az osztályok közötti kommunikációt.

Segítenek az új osztályok létrehozásában, öröklődés folyamatával.

Csak ArrayList, függvények: add, remove.

Queue, Stack, függvények: push, pop.

Vector, Hashtable, függvények: insert, delete.

Kotlinban a list, set, és map kollekciókat alapértelmezés szerint immutable és mutable formában használhatjuk. Ezek a kollekciók számos bővítő függvénnyel rendelkeznek, mint például filter, map, count, any.

A null értékek kezelése automatikusan történik a fordító által.

A ?. (safe call) operátor, ?: (Elvis operátor), és !!. (non-null assertion/null-biztos hivatkozás) segítségével kezelhetjük a null értékeket.

Kizárólag ?. (safe call) operátorral.

Kizárólag ?: (Elvis) operátorral.

Anonim funkciók, amelyeket változókhoz rendelhetünk, vagy paraméterként átadhatunk.

Anonim funkciók, csak a ciklusokban használhatóak, paraméterként kell átadni őket.

Anonim funkciók, csak új osztályok definiálására szolgálnak.

A program futási idejének csökkentésére szolgálnak.

Az osztályok csak Java-ban definiálhatók, majd Kotlinban használhatók.

Kotlinban nincs szükség osztályokra, csak objektumokra.

Kotlinban az osztályokat a class kulcsszóval hozzuk létre. Objektumokat az osztály példányosításával hozhatunk létre.

Csak a már meglévő osztályokból lehet objektumokat létrehozni.

Csak a konstruktorban lehet deklarálni őket.

Az osztályok tulajdonságai közvetlenül az osztályon belül deklarálhatók.

Csak interfészekben használhatók.

Tulajdonságok csak statikus módon deklarálhatók.

Csak egy típusú konstruktor van, az elsődleges.

Nincsenek konstruktorok, helyette factory metódusokat használunk.

Konstruktorokat csak a Java interop miatt használunk.

Az osztályoknak lehet elsődleges konstruktoruk és egy vagy több másodlagos konstruktoruk.

Mindkettő ugyanazt a célt szolgálja, csak más szintaxisú.

A by lazy csak osztály szinten használható, lateinit pedig csak metódusokban.

A by lazy nem támogatott, csak a lateinit.

Késleltetett inicializálási technikák, amelyek segítségével csak akkor hozzuk létre az objektumokat, amikor először szükség van rájuk.

Csak a számadatok kezelésére szolgálnak.

Az adatbázis kapcsolatok kezelésére használatosak. Automatikusan generál equals(), hashCode(), toString() metódusokat.

Olyan osztályok, amelyek célja az adatok tárolása. Automatikusan generál equals(), hashCode(), toString() metódusokat, valamint copy() függvényt.

Csak a tesztelés megkönnyítésére szolgálnak.

Az object kulcsszóval singleton objektumokat hozhatunk létre. A companion object lehetővé teszi statikus tagok (metódusok és változók) deklarálását az osztályokban.

Az object új osztályokat hoz létre, companion object pedig csak metódusokat.

Mindkettő ugyanazt jelenti, csak más kontextusban használják.

Az object csak az interface-eknél használható, companion object pedig nem létező fogalom.

A SOLID elvek az objektumorientált programozás alternatív szabályai, amelyek a futási idő minimalizálására koncentrálnak:

• Simple Object Rule

• Optimization Principle

• Limited Inheritance Rule

• Indirect Dependency Rule

• Dynamic Interface Usage

A SOLID elvek az objektumorientált programozás speciális struktúráit írják le, amelyek célja a szoftver egyszerűsítése:

• Single Optimization Principle

• Open Framework Model

• Layered Substitution Principle

• Interface Limitation Principle

• Direct Dependency Model

A SOLID elvek az objektumorientált programozás és tervezés öt alapelvét foglalják össze, amelyek a szoftverfejlesztés során a karbantarthatóságot, rugalmasságot és bővíthetőséget segítik elő:

• Single Responsibility Principle (Egyetlen felelősség elve)

• Open/Closed Principle (Nyitott/Zárt elv)

• Liskov Substitution Principle (Liskov helyettesítési elv)

• Interface Segregation Principle (Interfész szegregáció elve)

• Dependency Inversion Principle (Függőségi fordítás elve)
  
  

A SOLID elvek az adatbázis-kezelés tervezési mintáira vonatkoznak, amelyek az adattárolás hatékonyságát javítják:

• Standardized Storage Rule

• Object-oriented Access Design

• Layered Dependency Principle

• Indexed Segmentation Rule

• Database Interaction Optimization

A létrehozási minták az objektum létrehozásának módját abstrahálják el, hogy az ne közvetlenül az osztály példányosításával történjen:

• Singleton: Biztosítja, hogy egy osztálynak csak egy példánya legyen, és globális hozzáférési pontot biztosít ehhez a példányhoz.

• Factory Method: Egy interfész létrehozására szolgál objektumok számára, de hagyja, hogy az alaposztályok döntsék el, mely osztály példányát hozzák létre.

• Builder: Leegyszerűsíti egy komplex objektum összetett összeállítását, lehetővé téve, hogy különböző reprezentációkat generáljunk ugyanazokkal a konstrukciós folyamatokkal.

A létrehozási minták az objektumok interakcióit és viselkedését definiálják a rendszerben:

• Proxy: Egy közvetítő objektumot hoz létre, amely a hozzáférést szabályozza az igazi objektumhoz.

• Adapter: Az interfészek közötti különbségeket kezeli, hogy különböző rendszerek kommunikálhassanak egymással.

• Composite: Lehetővé teszi, hogy egy objektum hierarchikus szerkezetekben dolgozzon más objektumokkal.

A létrehozási minták a rendszerek dinamikus működésére koncentrálnak, hogy a végrehajtás során hatékonyabbá váljanak:

• Strategy: A viselkedésmódok változtatásának lehetőségét biztosítja anélkül, hogy a kliens osztály módosulna.

• State: Lehetővé teszi, hogy egy objektum állapota dinamikusan változzon.

• Observer: Egy objektumot figyelő rendszert biztosít, amely az értesítéseket különböző osztályoknak küldi.

A létrehozási minták az objektumok adatkezelését és tárolását optimalizálják:

• Iterator: Lehetővé teszi, hogy végigiteráljunk egy objektumkollekción.

• Command: Egyesíti a kéréseket objektumokká, amelyeket késleltetett módon hajtunk végre.

• Decorator: Az objektum viselkedését módosítja anélkül, hogy megváltoztatná annak osztályát.

A viselkedési minták az objektumok tárolására és kezelésére összpontosítanak:

• Singleton: Biztosítja, hogy egy osztálynak csak egy példánya legyen, és globális hozzáférési pontot biztosít ehhez a példányhoz.

• Factory Method: Egy interfész létrehozására szolgál objektumok számára, de hagyja, hogy az alaposztályok döntsék el, mely osztály példányát hozzák létre.

• Builder: Leegyszerűsíti egy komplex objektum összetett összeállítását, lehetővé téve, hogy különböző reprezentációkat generáljunk ugyanazokkal a konstrukciós folyamatokkal.

• Prototype: Lehetővé teszi egy objektum klónozását, hogy ne kelljen újra létrehozni ugyanazt.

A viselkedési minták az objektumok állapotát és viselkedését módosítják:

• State: Lehetővé teszi, hogy egy objektum állapota dinamikusan változzon.

• Decorator: Az objektum viselkedését módosítja anélkül, hogy megváltoztatná annak osztályát.

• Chain of Responsibility: Különböző objektumoknak ad lehetőséget arra, hogy egy kérésre válaszoljanak, azzal a lehetőséggel, hogy továbbadják azt a következő objektumnak.

• Mediator: A kommunikációt egy központi objektum irányítja, amely elvonja a résztvevő objektumok közvetlen kapcsolatát.

A viselkedési minták az objektumok adatkezelésére és tárolására összpontosítanak:

• Adapter: Az interfészek közötti különbségeket kezeli, hogy különböző rendszerek kommunikálhassanak egymással.

• Bridge: Az absztrakció és a megvalósítás közötti kapcsolatot biztosítja.

• Composite: Lehetővé teszi, hogy egy objektum hierarchikus szerkezetekben dolgozzon más objektumokkal.

• Flyweight: Lehetővé teszi, hogy megoszthassuk a hasonló objektumok adatait anélkül, hogy több példányt kellene létrehozni.

A viselkedési minták az objektumok közötti kommunikációra összpontosítanak:

• Observer: Egy-egy kapcsolatot hoz létre objektumok között úgy, hogy ha egy objektum állapota megváltozik, minden függő része automatikusan értesítést kap.

• Iterator: Lehetővé teszi egy kollekció elemeinek sorozatos elérését anélkül, hogy felfednénk a kollekció belső reprezentációját.

• Strategy: Lehetővé teszi, hogy egy algoritmus futási idejű választását egy algoritmus család közül.

• Template Method: Meghatároz egy algoritmus vázát egy metódusban, hagyva az alaposztályokat, hogy implementálják a művelet egyes lépéseit.

A szerkezeti minták az objektumok viselkedését és működését befolyásolják:

• Strategy: A viselkedési minták része, amely lehetővé teszi az algoritmusok futásidejű választását.

• State: Lehetővé teszi, hogy egy objektum állapota dinamikusan változzon.

• Command: Egy kérés végrehajtásának késleltetett módját biztosítja.

• Observer: Egy-egy kapcsolatot hoz létre objektumok között, hogy értesítéseket küldjenek az állapotváltozásokról.

A szerkezeti minták arra összpontosítanak, hogy hogyan lehet osztályokat és objektumokat összeállítani nagyobb struktúrákba:

• Composite: Egy csoport objektumot úgy kezel, mintha egyetlen objektum lenne.

• Proxy: Egy helyettesítő vagy helyőrző objektumot biztosít egy másik objektumhoz való hozzáféréshez.

• Adapter: Egy interfész átalakítására szolgál, hogy kompatibilis legyen egy másik interfésszel.

• Decorator: Dinamikusan hozzáad vagy felülír felelősségeket egy objektumhoz anélkül, hogy megváltoztatná annak szerkezetét.

A szerkezeti minták a kommunikációt és adatátvitelt optimalizálják:

• Mediator: A kommunikációt egy központi objektum irányítja, amely elvonja a résztvevő objektumok közvetlen kapcsolatát.

• Flyweight: Lehetővé teszi a megosztott objektumok hatékony kezelését, csökkentve a memóriát.

• Facade: Egy egyszerűsített interfészt biztosít egy komplex rendszerhez.

• Bridge: Az absztrakció és a megvalósítás közötti kapcsolatot biztosítja.

A szerkezeti minták a rendszerek működését optimalizálják és az adatkezelést javítják:

• Singleton: Biztosítja, hogy egy osztálynak csak egy példánya legyen, és globális hozzáférési pontot biztosít ehhez a példányhoz.

• Factory Method: Egy interfész létrehozására szolgál objektumok számára, de hagyja, hogy az alaposztályok döntsék el, mely osztály példányát hozzák létre.

• Builder: Leegyszerűsíti egy komplex objektum összetett összeállítását.

• Prototype: Lehetővé teszi egy objektum klónozását, hogy ne kelljen újra létrehozni ugyanazt.

A Dependency Injection (DI) célja, hogy minden osztály teljes mértékben független legyen a többi osztálytól, és ne osztozzanak közös erőforrásokon:

• Az osztályoknak teljesen maguknak kell létrehozniuk a szükséges függőségeiket.

• Az osztályok közvetlenül példányosítják a szükséges objektumokat.

• A kód közvetlenül hivatkozik a függőségekre anélkül, hogy külső rendszert használnának.

Egy tervezési minta és technika, amely csökkenti a kód függőségeit azáltal, hogy a függőségeket (például objektum példányokat) külső forrásból (pl. keretrendszertől) injektálja az osztályokba, így növelve a kód moduláris felépítését és tesztelhetőségét.

A Dependency Injection (DI) célja a kód teljesítményének maximalizálása azáltal, hogy a leggyorsabb elérhető függőségeket választja:

• A DI a függőségeket a teljesítmény szempontjából optimalizálja.

• A kódot a leggyorsabban betöltődő objektumok alapján konfigurálja.

• A DI technika lehetővé teszi az osztályok gyors példányosítását.

A Dependency Injection (DI) célja, hogy minden osztály automatikusan hozzáférjen az összes más osztályhoz és azok erőforrásaihoz:

• Minden osztály közvetlenül elérheti más osztályok minden funkcióját.

• Az osztályok közvetlenül manipulálják és hozzák létre más osztályok példányait.

• A kód nem igényel külön konfigurációt a függőségek kezelésére.

A Repository Pattern célja, hogy közvetlen hozzáférést biztosítson az adatbázishoz, és minden adatkezelési műveletet az alkalmazás többi része végezzen.

A Repository Pattern célja, hogy az adatokat kizárólag memóriában tárolja, így elkerülve a fájlok és adatbázisok használatát.

Az adatelérési logikát egy központi interfész mögé rejti, lehetővé téve az adatok egységes kezelését és elérését az alkalmazás többi része számára, függetlenül az adatok fizikai tárolásától.

A Repository Pattern célja, hogy a lekérdezéseket gyorsítja és optimalizálja az adatbázisban a rendszer erőforrásainak takarékos használatával:

• Az adatbázis lekérdezéseket a Repository Pattern optimalizálja a teljesítmény érdekében.

• A pattern közvetlenül az adatbázis gyorsítótárazására és optimalizálására összpontosít.

• A lekérdezések gyorsaságát az alkalmazás logikáján belül végzi el.

Framework: Egy átfogó munkakörnyezet, amely meghatározott keretek között végzi a szoftverfejlesztést, gyakran meghatározva az alkalmazás szerkezetét és az életciklusát. A framework "hív", azaz meghatározza a kontroll folyamát.
Library: Gyűjteménye funkcióknak és eszközöknek, amelyeket a fejlesztők hívhatnak és használhatnak saját alkalmazásaikban anélkül, hogy az befolyásolná az alkalmazás szerkezetét. A fejlesztő "hívja" a könyvtárat, amikor szüksége van rá.

A framework és a library ugyanazt a célt szolgálja, csak a használatuk eltérő:

• A framework és a library is ugyanúgy befolyásolja az alkalmazás szerkezetét.

• A fejlesztő nem irányítja a kontroll folyamatát sem a framework, sem a library használata során.

• A két fogalom nem különbözik a működésükben, csak a kód szerkezetének elnevezése más.

A framework az alkalmazás összes logikáját és szerkezetét meghatározza, míg a library csak a vizuális elemeket kezeli. A framework kizárólag a vizuális felület kezelésére van kialakítva. A library csak a háttérszolgáltatásokat biztosít, és nem szabályozza az alkalmazás struktúráját.

A framework lehetővé teszi a kód másolását és beillesztését, míg a library kód generálását végez.

• Zárt forráskódú és Unix-alapú.

• Csak egy érintéses interakciókat támogat.

• Nincs támogatás a hardvereszközök számára, és nem képes kezelni érzékelőket.

• Alkalmazásközi kommunikációs képességek nem elérhetők.

• Nyílt forráskódú és Windows-alapú.

• Támogatja a több érintéses interakciókat, de csak alapvető funkciókhoz.

• Széles körű támogatás a hardvereszközök számára, de nem támogatja a kamerát vagy a GPS-t.

• Alkalmazásközi kommunikációs képességek gyengék.

• Nyílt forráskódú és MacOS-alapú.

• Csak a billentyűzetet és az egérhasználatot támogatja.

• Nem támogatja a hardvereszközöket, és nem képes érzékelők kezelésére.

• Erős alkalmazásközi kommunikációs képességek nem elérhetők.

• Nyílt forráskódú és Linux-alapú.

• Támogatja a több érintéses interakciókat.

• Széles körű támogatás a hardvereszközök számára, beleértve a kamerát, a GPS-t, a gyorsulásmérőt stb.

• Erős alkalmazásközi kommunikációs képességek.

Csak a tesztelést támogatja.

Csak a dokumentációt biztosítja.

Az Android Software Development Kit (SDK) az eszközök és API-k gyűjteménye, amely lehetővé teszi a fejlesztők számára, hogy alkalmazásokat írjanak az Android platformra. Tartalmazza a kompilátorokat, eszközöket, emulátorokat és a szükséges API-kat.

Az Android SDK csak a felhasználói felület tervezésére szolgál, és nem tartalmaz eszközöket a háttérlogika fejlesztéséhez.
Csak vizuális elemek tervezésére van szükség.

• Nem tartalmaz semmilyen API-t vagy eszközt a kód futtatásához.

• Nincs lehetőség emulátor használatára.

• Erőforrások: Képek, szövegek és layout fájlok.

• Komponensek: Activity-k, szolgáltatások (Services), tartalom szolgáltatók (Content Providers), és broadcast fogadók (Broadcast Receivers).

• Manifest fájl: Deklarálja az alkalmazás komponenseit, jogosultságait, minimum SDK verziót, stb.

• Build scripts: Gradle scripteket használnak az alkalmazás építéséhez és csomagolásához.

• Erőforrások: Csak szöveges fájlok és adatbázisok.

• Komponensek: Csak Activity-k és egyéb vizuális elemek.

• Manifest fájl: Nem tartalmaz információkat az alkalmazás jogosultságairól.

• Build scripts: Az alkalmazás csak manuálisan építhető, scriptek használata nem szükséges.

• Erőforrások: Csak a programkód és a Java osztályok.

• Komponensek: Activity-k, de nem tartalmaznak más típusú komponenseket.

• Manifest fájl: Csak az alkalmazás verzióját és nevét deklarálja.

• Build scripts: Az alkalmazás építése csak a parancssorból történik, Gradle használata nem ajánlott.

• Erőforrások: Csak a felhasználói felületre vonatkozó fájlok (layoutok és dizájn elemek).

• Komponensek: Csak statikus fájlok, mint képek és szövegek.

• Manifest fájl: Nem szükséges, ha az alkalmazás nem használ harmadik fél által fejlesztett könyvtárakat.

• Build scripts: Az alkalmazás automatikus építése nem történhet meg.

Egy programozási nyelv.

Az Android alkalmazások csomagolási formátuma, amely tartalmazza az alkalmazás összes komponensét és erőforrását.

Egy adatbázis formátum.

Egy hálózati protokoll.

Egy háttérszolgáltatás, amely folyamatosan fut a háttérben és nem tartalmaz felhasználói felületet.

Egy olyan komponens, amely kizárólag az alkalmazás betöltési idejét kezeli, és nem tartalmaz felhasználói interakciót.

Egy alkalmazáson belüli egyetlen képernyő, amely felhasználói interakciót tesz lehetővé.

Egy adatbázis-kezelő komponens, amely az alkalmazás adatainak tárolásáért felelős.

Fontos metódusok, mint például onCreate(), onStart(), onResume(), onPause(), onStop(), és onDestroy(), amelyek kezelik az Activity életciklusát.

Az Activity életciklus metódusai kizárólag az alkalmazás betöltésekor és bezárásakor hívódnak meg. Nincs szükség további metódusokra az Activity futása közben.

Az Activity életciklus metódusai csak az alkalmazás felhasználói felületének megjelenítésekor és eltüntetésekor futnak le.

• Az onCreate() és onDestroy() metódusok az egyetlenek, amelyek fontosak az életciklusban.

Az Activity életciklus metódusai az alkalmazás adatkezelésére vonatkoznak, és nem kapcsolódnak az Activity vizuális kezeléséhez. Az életciklus metódusok nem befolyásolják a felhasználói interakciókat vagy a képernyő frissítését.

Egy rendszerkomponens, amely kizárólag a háttérszolgáltatások futtatására szolgál, nem használható az Activity-k közötti kommunikációra.

Egy üzenet objektum, amely komponensek közötti kommunikációra szolgál, például egy Activity indítására vagy adatátvitelre.

Egy objektum, amely az alkalmazás adatbázisainak kezeléséért felelős.

Egy olyan objektum, amely csak a vizuális elemek megjelenítésére szolgál, és nem befolyásolja az alkalmazás működését. Az Intent nem kapcsolódik a felhasználói felület kezeléséhez, hanem az alkalmazás működésének irányításához és adatátvitelhez.

Az Activity-k csak egyetlen állapotban létezhetnek, és a back stack nem befolyásolja a működésüket.

• Az Activity-k nem rendelkeznek különböző állapotokkal, és a back stack csak a legutolsó Activity-t tárolja.

A back stack az Activity-k közötti adatátvitelt kezeli, nem a sorrendet.

A back stack minden Activity-t tartalmaz, még azokat is, amelyek már nem aktívak.

Az Activity-k különböző állapotokban lehetnek (pl. futó, szüneteltetett), és a back stack tartja nyilván az aktív Activity-k sorrendjét.

• View: Az UI alapeleme, mint egy gomb vagy szövegmező.

• ViewGroup: Konténerek, mint például LinearLayout és RelativeLayout, amelyek View-kat tartalmaznak.

• Layout: Az XML fájlok, amelyek meghatározzák az UI elrendezését.

• View: Csak a háttérszolgáltatásokat tartalmazó objektum.

• ViewGroup: Csak adatbázis-kezelésre szolgáló objektumok.

• Layout: Az alkalmazás kódjának logikai elrendezését határozza meg, nem a felhasználói felületet.

• View: Csak interaktív elemeket tartalmazó objektumok, mint gombok és szövegmezők.

• ViewGroup: Az összes vizuális elem elhelyezésére szolgáló objektumok, de nem tartalmaznak alárendelt View-kat.

• Layout: Csak a háttérszolgáltatások és logikai folyamatok szervezésére használatos.

• View: Csak a felhasználói interakciók kezelésére szolgál, mint az animációk.

• ViewGroup: Minden egyes alkalmazás komponensének kezelése.

• Layout: Az XML fájlok, de nem az UI elrendezését határozzák meg, hanem az alkalmazás működését.

A View binding csak a ViewGroup-ok, például LinearLayout és RelativeLayout kezelésére használható, nem az egyes View-khoz.

A View binding lehetővé teszi, hogy a felhasználói felület elemeit dinamikusan módosítsuk kód futás közben, de nem biztosít biztonságos hivatkozást az XML-ben definiált View-kra.

Egy eszköz, amely biztosítja a biztonságos és közvetlen hivatkozást az XML-ben definiált View-kra a kódban.

A View binding kizárólag a háttérszolgáltatások kezelésére szolgál, és nem kapcsolódik a felhasználói felülethez.

A Fragmentek kizárólag egyetlen Activity-n belül használhatók, és nem rendelkeznek saját layoutokkal.

A Fragmentek nem rendelkeznek saját életciklussal és nem használhatók különböző aktivitásokban.

A Fragmentek kizárólag háttérszolgáltatásokat kezelnek, és nem tartalmaznak felhasználói felületet.

Újrafelhasználható UI komponensek, amelyek saját életciklussal, bemenetekkel és layoutokkal rendelkeznek.

A Navigation component segít az alkalmazások navigációs logikájának kezelésében, a Navigation graph segítségével definiálva az egyes navigációs műveleteket.

A Navigation component csak a háttérszolgáltatások kezelésére szolgál, és nem kapcsolódik a felhasználói felület navigációs kezeléséhez.

A Navigation component kizárólag a statikus navigációs elemek kezelésére szolgál, nem kezeli dinamikusan az alkalmazás logikáját.

A Navigation graph nem szükséges az alkalmazás navigációjához, és a navigációs műveletek kézi vezérlése elegendő.

A RecyclerView nem képes újrahasznosítani az elemeket, és minden elemhez új példányokat hoz létre a memóriahatékonyság érdekében.

A RecyclerView kizárólag szöveges adatok megjelenítésére alkalmas, nem támogat egyéb típusú adatokat, mint például képek.

A RecyclerView egy statikus lista megjelenítésére szolgáló eszköz, amely nem képes kezelni nagy adatokat.

Egy rugalmas widget az elemek listájának megjelenítésére, amely hatékonyan kezeli a nagy adatkészleteket.

A hosszú műveleteket a UI szálon kell végrehajtani, mivel a külön szálak használata lassítja az alkalmazást.

Fontos, hogy a hosszú műveleteket, mint például hálózati hívásokat, külön szálakon kezeljük, hogy ne blokkoljuk a UI szálat.

A szálkezelés nem szükséges az Android alkalmazásokban, mivel a rendszer automatikusan kezeli a hosszú műveleteket a háttérben.

A hálózati műveletek nem igényelnek külön szálat, mivel azok automatikusan gyorsan végrehajtódnak az UI szálon.

A Kotlin korutinok nem támogatják az aszinkron műveletek kezelését, és a szálak kezelésére van szükség a párhuzamos műveletek végrehajtásához.

A Kotlin korutinok lehetővé teszik az aszinkron műveletek egyszerűbb kezelését a suspend kulcsszóval, Dispatchers-el, amely meghatározza a művelet végrehajtásának kontextusát, és a scope-okkal, amelyek meghatározzák a korutinok élettartamát.

A Kotlin korutinok csak szinkron műveletekhez használhatók, mivel nem támogatják az aszinkron programozást.

• A korutinok kifejezetten az aszinkron műveletek kezelésére lettek tervezve.

A Kotlin korutinok nem rendelkeznek Dispatchers-el vagy scope-okkal, mivel ezek nem szükségesek az aszinkron műveletekhez.

• A korutinok Dispatchers-ekkel és scope-okkal dolgoznak a műveletek hatékony és kontrollált végrehajtásához.

Egy olyan osztály, amely adatokat tárol és kezel az UI-hoz kapcsolódóan, és túléli a konfigurációs változásokat, mint például a képernyő elforgatását.

A ViewModel kizárólag a felhasználói felület megjelenítésére szolgál, és nem tárol adatokat.

A ViewModel elveszíti az adatokat, ha a képernyő elforgatásra kerül, és újra kell inicializálni.

A ViewModel nem használható együtt a LiveData-val, mivel azok nem kompatibilisek egymással.

• A ViewModel és a LiveData gyakran együtt használatosak az adatkezelés és UI frissítések hatékony kezelésére.

Egy adat tartó osztály, amely figyeli az adatváltozásokat, lehetővé téve az UI számára, hogy reagáljon ezekre.

A LiveData kizárólag statikus adatokat tárol, és nem frissíti az UI-t az adatok változása esetén.

A LiveData nem képes figyelni az adatokat, csak egyszeri adatlekérést biztosít.

• A LiveData folyamatosan figyeli az adatváltozásokat és reagál azokra.

A LiveData nem működik jól a ViewModel-lel, mivel nem képes adatokat megosztani az UI és a ViewModel között.

• A LiveData és a ViewModel gyakran együtt használatosak, mivel lehetővé teszik az adatkezelés és UI frissítések szétválasztását.

A perzisztencia csak a hálózaton keresztüli adatátvitelt biztosít, nem tárol adatokat lokálisan.

Kizárólag az alkalmazás indítási beállításait tárolja, nem a felhasználói adatokat.

Adatok tárolása a lokális adattárolóban, mint például SharedPreferences vagy adatbázis.

Nem biztosít hosszú távú adatmegőrzést, mivel az adatok csak az alkalmazás életciklusáig érhetők el.

Egy absztrakciós réteg az SQLite adatbázis felett, amely könnyebb adatkezelést tesz lehetővé ORM (Object-Relational Mapping) segítségével.

Kizárólag a fájlok kezelésére használható, nem kapcsolódik adatbázisokhoz.

• A Room egy adatbázis-kezelési könyvtár, nem fájlok kezelésére való.

Nem támogatja az SQLite adatbázisokat, és kizárólag a dokumentum alapú tárolást használja.

• A Room kifejezetten az SQLite adatbázisokkal dolgozik.

A Room library nem használ ORM-t, hanem manuálisan kell lekérdezni az adatokat.

• A Room automatikusan használ ORM-et, hogy egyszerűsítse az adatbázis kezelését.

A REST kizárólag szinkron kommunikációt támogat és nem alkalmazható aszinkron kérésekhez.

• A REST támogatja az állapotmentes kommunikációt, és lehet szinkron vagy aszinkron.

Egy architekturális stílus webes szolgáltatásokhoz, amely kommunikációt tesz lehetővé kliens és szerver között állapotmentes kérések és válaszok segítségével.

A REST kifejezetten webes szolgáltatások közötti adatcserét tesz lehetővé.

Nem használ HTTP-t, és nem alkalmaz HTTP metódusokat a kérésekhez.

• A REST HTTP-t és annak metódusait használja, mint például GET, POST, PUT, DELETE.

A Retrofit nem támogatja a REST API-kat, és nem biztosít eszközöket azok kezelésére.

Kizárólag egyetlen HTTP metódust támogat, és nem használható más HTTP műveletekhez.

Nem biztosít típusbiztos válaszokat, és csak szöveges adatokat képes kezelni.

• A Retrofit típusbiztos válaszokat biztosít, és különféle adatokat képes kezelni, például JSON-t.

Egy típusbiztos HTTP kliens az Android és Java számára, amely a REST API-kkal való kommunikációt egyszerűsíti.

Az Android jogosultságok nem szükségesek az érzékeny adatokhoz való hozzáféréshez, mivel azokat alapértelmezetten elérhetők.

A jogosultságokat nem kell kérni az alkalmazás telepítésekor, hanem csak futás közben.

Az Android rendszer megköveteli, hogy az alkalmazások kéréseket tegyenek bizonyos jogosultságokra az érzékeny adatokhoz vagy rendszerfunkciókhoz való hozzáférés előtt.

A jogosultságok csak a rendszerbeállítások módosításához szükségesek, nem kapcsolódnak a felhasználói adatokhoz.