Closed wideking closed 6 years ago
Pogledao sam zadnji commit : https://github.com/gkovac42/mvp-demo/commit/4cda56eea43418c75138bd50736317c36145ccf1
Tu uošće nemaš ništa od daggera. I koliko sam vidio koristiš jako staru verziju daggera, ali za sada ostani na njoj. Nemoj ići na verziju 2.11. kada prođmo i implementiramo ovu veziju onda ću ti objasniti zašto.
Idemo prvo sa pitanjima. Što znači dependency injection?
Što je dagger?
Koji su dijelovi daggera?
Što je module?
Što je component?
Kako možemo spojiti više modula?
Kako dagger radi?
Pardon, zaboravio sam push-ati nove klase :)
Odgovori:
Dependency Injection je postupak kojim objektu dajemo njegove ovisnosti tj. instance varijable. Znači da se ovisnosti ne stvaraju u samoj klasi već ih inject-amo negdje iz vana, kroz konstruktor ili setter metode.
Dagger je alat koji automatizira dependency injection tako što generira kod za nas pomoću dependency graph-a.
Glavni djelovi su module i component i scope. Module je klasa u kojoj definiramo ovisnosti, tj. koja sadrži metode koje vraćaju objekte koji nam trebaju da zadovoljimo ovisnost. Component je interface koji služi kao poveznica između Modula i klase u koju se ovisnosti inject-aju.
Spojiti ih možemo tako da u Componentu definiramo koje Module obuhvaća ili možemo u pojedinom Modulu odrediti da obuhvaća drugi Modul.
Ovo zadnje još nisam do kraja shvatio ali radim na tome :)
U ovoj verziji ti spajanje treba ići preko subcomponenta.
Ključ shvaćanja kako dagger radi je slijedećim. Dagger sve stvari generira u compile time-u, na temelju određenih veza. Znaš i sam da u compile timeu si ograničen sa informacijama, tada ti djeluje da svaka klasa može biti pozvana od svuda sto bi značilo da parametri koje prima moraju biti dostupni tako. Dobra stvar me sto to nije slučaj, uspijela su dagger napraviti pametnijim, pa on može shvatiti koji objekt kad treba biti dostupan. Kako to radi? Dagger pri compileanju napravi nešto se se zove Dependecy Graph ili dagger injection graph. Nisam 100 siguran u naziv. Graf sluzi daggeru da točno odredi zavisnost klasa i da odredi kako injectati stvari. Zamisli Graf kao binarno stablo, gdje su u tvojoj grani dostupne samo stvari iz tvoj čvora te stvari iz tvoje grane. Paralelno ne možeš ništa dobiti.
Kao sto sam na početku ovog dijela spomenio, compile time je jako neodređeno vrijeme. Tu u priču dolaze Component i subcomponente.
Na njih gledaj kao grane grafa. U pravilu ( taj dio me kod tebe buni) trebao bi imati app component. ( 1 glavna komponenta) i pomoćne subcomponente.
App componenta je tvoj cijeli app. I iz njega radiš dagger injection.
App component sadrži ostale subcomponente. Njih povezujes sa papom tako da injectati subcomponenetu i app component - to si radio kada si u activityu radio componentu pa pozivao metodu inject().
Drugi način je da se subcomponent anotaciji (možda se drugačije zove, kasnije ces skuziti zašto ne znam točne nazive )navedu subcomponente. Ovo se obicno koristi za singleton subcomponente jer oni traju kao i app.
Dakle, kada ti napraviš takve grane grafa, ti si daggeru objasnio tko je on (app component) sto on može imati ( subcomponente) te kako da injecta dinamične stvari kao sto su activity-i ( kada napišeš onaj inject funkciju ) . Sada je Graf baja, u compile timeu on lijepo pogleda ovisnosti za tvoj article activity i utvrdi da mu trebaju samo stvari iz article componenta te njih injecta.
Dok recimo na list screenu, utvrdi da treba restInterface i stvari iz list componenta. Rest interface je pronašao odmah na početku grafa jer je on dostupan svima budući da je on u singleton componenti.
Reci da li ti je ovo pomoglo.
Postao ti uskoro tutorijal po kojem želim da napraviš zadatak. Ali prije izrade pitaj pitanja da vidimo da li se razumijemo
Radi mi kod, ne bi push-ao da ne radi. Gledao sam neki tutorial gdje nisu koristili subcomponent i po tome radio. Shvaćam teoretski kako bi to trebalo funkcionirati. U biti mi je jasno i kako da napravim pojedine module i povežem ih ali me buni to s componentom na razini aplikacije i kako se to onda grana prema dolje. Možda da pošalješ taj tutorial ili neki primjer koda gdje je to na taj način obavljeno pa će mi biti jasnije.
Ovdje imaš zanimljivo napisano to sve. Google je nekad na svojoj stranici imao crteže grafa i kak to sve radi ali ja to vise ne mogu naći. U ovom primjeru dodaju i activity componentu kao subcomponent sve je stvar prakse
https://android.jlelse.eu/dagger-2-part-i-basic-principles-graph-dependencies-scopes-3dfd032ccd82
Ovdje ima i crtež i bliži kod tome sto si pisao
E hvala! Pročitat ću članke pa ću probati ponovo, ovaj put malo bolje to posložiti.
Meni je trebalo mjesec dana korištenja daggera da zapravo skužim sto se tu događa. Čujemo se ako budeš imao pitanja, moram odmoriti oci, dosta za dns :D
Moram pitati - koja je zapravo svrha daggera? Jer trenutno ne mogu skuziti benefite svega ovoga. Sa obicnim dep injection-om kroz konstruktor mi je sve bilo jednostabno i gotovo u cas posla. S daggerom pravim hrpu novih klasa, imam masu novog koda, kompliciram si stvari na n-tu...zasto? :D
On 15 Dec 2017, at 11:40, Goran Kovač notifications@github.com wrote:
Moram pitati - koja je zapravo svrha daggera? Jer trenutno ne mogu skuziti benefite svega ovoga. Sa obicnim dep injection-om kroz konstruktor mi je sve bilo jednostabno i gotovo u cas posla. S daggerom pravim hrpu novih klasa, imam masu novog koda, kompliciram si stvari na n-tu...zasto? :D
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gkovac42/mvp-demo/issues/13#issuecomment-351973570, or mute the thread https://github.com/notifications/unsubscribe-auth/AIr--jGM6-jTMFMKXBKCG8MNVQq0GaNMks5tAky3gaJpZM4RCUn4.
Da pojednostavis generiranje objekata. Trenutno ti djeluje kompliciranije jer radis na jednostavnom projektu gdje zapravo za svaki activity injectas njegove stvari. Kada budes radio na slozenijem projektu imati ces puno pomocnih stvari kao sto su razni interactori, ultis klase. Da nemoras uvijek misliti kako da dodes do njih - a nekada ti nije to jednostavno, jednostavno ih omogucis sa daggerom.
Trenutno nisi bio u kodu napravio injectanje view-a i presentera pa nisi imao prilike viditi da ti vec tu dagger pomazer jer sve one helper klase ( recimo restInterface) ce on injectati za tebe jer ce ga naci u singleton modulu.
Dobro, ako ti tako kazes :D Valjda ce biti jednostavnije kad skuzim kako radi.
Pogledao sam implementaciju. Djeluje mi da si shvatio, samo ti ostaje shvatiti razliku između componenta i subcomponente. Napisao sam ti u drugom tasku sto je nezgodno sa izvedbom koju trenutno imaš i čemu bi trebao težiti.
Ne mogu trenutno do maila pa pitaj tu nejasnoće :) ako se dobro sjećam, napisao si da ti je i dalje tesko shvatiti benefite dependency injectiona, tj. Da bi bilo jednostavnije bez.
U tvom konkretnom primjeru, da, bilo bi jednostavnije. Ti trenutno u kodu nemaš klase koje se reusaju, tj. Koriste na vise od dva mjesta. Ovo je zapravo više izuzetak nego pravilo, obično imaš hrpu takvih klasa. Na primjer helpere kao sti je shared pref. Ili Data manipulatori kao sto su interactori.
Zamisli scenarij da imaš recimo 5 screeova i svi zbog nekog razloga moraju imati interactori za istu podatkovnu klasu. Napišeš normalni kod, gdje sam kreiraš interactore, dakle u svakoj klasi imaš new ... to je 5 stvaranja objekata sa parametrima.
Promotrimo slučaj sa daggerom. 5 klasa, recimo da to bude najgori slučaj pa da imamo i 5 modula. Iz gornjeg primjera vidimo da je scope lifecycle dependent pa će se za svako stvaranje screena raditi novi interactor. Long story short 5 modula, 5 dependency providera.
Usporedba oba slučaja - nema razlike, u oba slučaja smo kod zapisali 5 puta samo u različitom obliku.
Idemo sad promotriti slučaj izmjene interactori, recimo dodamo u konstruktor parametar.
U prvom slučaju moramo na svih pet mjesta izmjeniti poziv konstruktoru. Pretpostavimo da imamo taj dependency, dakle samo ćemo ga dodati kao parametar.
U drugom slučaju morati ćemo napraviti samo jednu izmjenu! Kako to, kada smo imali 5 provideva? Lijepo, u provide metodi injectamo konstruktor presentera ( to sam ti napisao u jednom issueu) Samom izmjenom tog konstruktora utječemo na sve provideve :) naravno i tu smo napravili preptpostavku da imamo dependency :)
Evo i posebnog slučaja koji dodatno olakšava benefite. Slučaj kao prošli, samo nemaš dependency. U prvom slučaju se moraš boraviti da si dovučeš taj dependency u željenu klasu, raditi izmjene na vise mjesta i komplicirati objekte.
U slučaju kad imamo dagger, samo u modulu provideamo i taj dependency, na već neki od načina koji možemo :) nužno ne utječemo na druge klase
Ma ok mi je dagger. Još mi nije sasvim legao ali što više radim to stvari postaju razumljivije pa i uviđam neke benefite. Sutra ću se još fokusirati na subcomponent i pokušati rješiti issue.
Poslao sam ti na mail, ali evo i ovdje - naletio sam na ovaj API: https://developers.themoviedb.org/3/ . Nudi dosta mogućnosti pa sam mislio oko toga osmisliti neku aplikaciju. Za početak kao preglednik i pretraživač, tj. uglavnom GET request-ovi, a ako to bude išlo i bude bilo vremena, kasnije proširiti i dodavati funkcionalnosti. Hoće to biti ok?
Raspišem novi task za zadatak, pogledao sam api i biti će vrhunsku. Na tom projektu ćeš malo drugačije raditi. Pokušati ću te naučiti da odradiš pripremu zadatka, analiziraš sve pa onda kreneš sa implementacijom. Što se tiče zadatka, plan mi je da unutra ubacimo dosta android stvari kao što su fragmenti, korištenje resursa, prijevoda i sl. stvari koje koriste u developmentu a nisi imao prilike to koristiti. Dostavim ti zadatak pod bor 🥇
Haha, može! Jedva čekam :). Ja ću u međuvremenu još ponoviti sve što smo prošli.
Prijevod sam radio (ako misliš na extractanje stringova i korištenje različitih resursa ovino o default jeziku sustava). Ako mogu predložiti neke stvari s kojima se nisam još stigao najbolje upoznati a mislim da su važne: save/restore instance state-a, notifikacije, oni različiti folderi za resurse, teme i stilovi. Ne znam koliko se često koriste service, broadcast reciver i content provider. Meni nisu do sada trebali pa ih nisam ni koristio.
Naravno! Bas na takve stvari sam mislio. Budeš radio app da podržava tablete i orijentaciju, tamo ćeš morati koristi sve te trikove
Sent from my iPhone
On 21 Dec 2017, at 20:53, Goran Kovač notifications@github.com wrote:
Haha, može! Jedva čekam :). Ja ću u međuvremenu još ponoviti sve što smo prošli.
Prijevod sam radio (ako misliš na extractanje stringova i korištenje različitih resursa ovino o default jeziku sustava). Ako mogu predložiti neke stvari s kojima se nisam još stigao najbolje upoznati a mislim da su važne: save/restore instance state-a, notifikacije, oni različiti folderi za resurse, teme i stilovi. Ne znam koliko se često koriste service, broadcast reciver i content provider. Meni nisu do sada trebali pa ih nisam ni koristio.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Ovaj tjedan sam dosta zauzet, pa ti neću uspijeti napraviti pripremu za dagger. Ti si sam rekao da si nešto proučavao? Kada budeš radio dalje, možeš li otvoriti novi task pa napiasti u njemu što znaš o daggeru, kako radi i postaviti pitanja koja ti nisu jasna pa ja odgovorim?
@gkovac42 Owner gkovac42 commented 3 days ago Bio sam na Android Talks-u u Osijeku gdje je bilo predavanje o Daggeru, a i pogledao sam neke stvari na yt. Znam onako opcenito neke osnove ali nisam jos primjenjivao.
Ok, onda cu ja jos eksperimentirati s lifecycle-om i detaljnije prouciti Dagger. Ima dosta o tome na netu pa mislim da nece biti problem naci dobar materijal. Kad skuzim probat cu implementirati pa ce te onda malo ugnjaviti oko nejasnoca, neci ti u medjuvremenu dosadjivati :)
@wideking
wideking commented 3 days ago Slobodno pitaj ako imaš nejasnoća. Bolje ih je prije riješiti nego se mučiti i krivo naučiti :)