Androidin täydellisessä maailmassa Java-kieli on todella moderni, selkeä ja tyylikäs. Voit kirjoittaa vähemmän tekemällä enemmän ja joka kerta kun uusi toiminto tulee näkyviin, kehittäjät voivat käyttää sitä lisäämällä versiota Gradle . Luomalla mukavan sovelluksen ominaisuus näyttää olevan täysin testattava, laajennettavissa ja ylläpidettävissä. Toimintamme ei ole liian iso ja monimutkainen, voimme vaihtaa tietolähteet tietokannasta verkkoon ilman liikaa eroja ja niin edelleen. Kuulostaa hyvältä? Valitettavasti Android-maailmassa tämä ei ole ihanteellinen. Google pyrkii edelleen täydellisyyteen, mutta me kaikki tiedämme, että ihanteellisia maailmoja ei ole olemassa. Siksi meidän on autettava itseämme tällä suurella matkalla Android-maailmassa.

Kotlin on merkittävä toimija Android-maailmassa. Mutta voiko se korvata Java? Mikä on Kotlin ja miksi sinun pitäisi käyttää sitä?

Joten, ensimmäinen kieli. Mielestäni Java ei ole eleganssin tai selkeyden mestari, eikä se ole nykyaikainen eikä ilmeikäs (ja oletan, että olet samaa mieltä). Haittapuoli on, että Android N: n alapuolella olemme edelleen rajoitettu Java 6: een (mukaan lukien joitain pieniä osia Java 7: stä). Kehittäjät voivat myös liittää RetroLambda käyttää lambda-lausekkeita koodissasi, mikä on erittäin hyödyllistä käytettäessä RxJava . Android N: n lisäksi voimme käyttää joitain uudempia Java 8 -toimintoja, mutta se on silti vanha raskas Java. Hyvin usein kuulen [Android-kehittäjien] (https://www.toptal.com/android) sanovan 'Toivon, että Android tukisi mukavampaa kieltä, kuten iOS tekee Swiftin kanssa.' Entä jos sanoisin, että voit käyttää erittäin mukavaa ja yksinkertaista kieltä ilman turvatarkastuksia, lambdoja ja monia muita uusia ominaisuuksia? Tervetuloa Kotliniin.

Mikä on Kotlin?

Kotlin on uusi kieli (tunnetaan joskus nimellä Swift for Android), jonka on kehittänyt JetBrains ja nyt se on versiossa 1.0.2. Mikä tekee siitä hyödyllisen Android-kehityksessä, on se, että se kääntyy JVM-tavukoodiksi ja voi myös kääntää JavaScriptillä. Se on täysin yhteensopiva Java: n kanssa, ja Kotlin-koodi voidaan muuntaa yksinkertaisesti Java-koodiksi ja päinvastoin (on olemassa kytkeä kirjoittanut JetBrains). Tämä tarkoittaa, että Kotlin voi käyttää mitä tahansa Java-kielellä kirjoitettua kehystä, kirjastoa jne. Androidissa sen on integroinut Gradle. Jos sinulla on jo Android-sovellus ja haluat ottaa uuden ominaisuuden käyttöön Kotlinissa kirjoittamatta koko sovellusta uudelleen, aloita kirjoittaminen Kotlinissa ja se toimii.

Mutta mitkä ovat 'upeita uusia ominaisuuksia'? Haluan luetella muutamia:

Nimetyt ja valinnaiset toimintoparametrit

Fecha de crear Diversión(day: Int, month: Int, year: Int, hour: Int = 0, minute: Int = 0, second: Int = 0) { print('TEST', '$day-$month-$year $hour:$minute:$second') }

Voimme kutsua menetelmää Luomispäivä Eri tavoin

Fechacreación(1,2,2016) prints: ‘1-2-2016 0:0:0’ Fechacreación(1,2,2016, 12) prints: ‘1-2-2016 12:0:0’ Fechacreación(1,2,2016, minute = 30) prints: ‘1-2-2016 0:30:0’

Nulliturva

Jos muuttuja voi olla nolla, koodia ei käännetä, ellemme pakota sitä. Seuraavassa koodissa on virhe: tyhjä Var voi olla tyhjä:

var nullableVar: String? = “”; nullableVar.length;

Koonnettaessa meidän on tarkistettava, onko se tyhjä vai ei:

if(nullableVar){ nullableVar.length }

Tai jopa lyhyempi:

nullableVar?.length

Tällä tavalla, jos nullableVar on nolla, mitään ei tapahdu. Muuten voimme merkitä muuttujan mitätöimättömäksi ilman kysymysmerkkiä tyypin jälkeen:

var nonNullableVar: String = “”; nonNullableVar.length;

Tämä koodi on käännetty ja jos haluamme määrittää nollan muulle kuin NullableVar-arvolle, kääntäjä näyttää virheen.

Elvis-operaattori on myös erittäin hyödyllinen:

var stringLength = nullableVar?.length ?: 0

Joten kun nullableVar on null (niin nullableVar?. Pituus johtaa nollaan), merkkijonolla pituus on arvo 0.

Vaihtuvat ja muuttamattomat muuttujat

Yllä olevassa esimerkissä käytän missä määritettäessä muuttujaa. Tämä on muuttuva, voimme nimetä sen uudelleen milloin tahansa. Jos haluamme muuttujan olevan muuttumaton (monissa tapauksissa meidän pitäisi), käytämme tuntia (arvona, ei muuttuvana):

val immutable: Int = 1

Tämän jälkeen kääntäjä ei salli meidän tehdä muutoksia muuttumattomiin.

Lambdas

Me kaikki tiedämme mikä lambda on, joten tässä aion näyttää kuinka voimme käyttää sitä Kotlinissa:

button.setOnClickListener({ view -> Log.d('Kotlin','Click')})

Tai jos funktio on ainoa tai viimeinen argumentti:

button.setOnClickListener { Log.d('Kotlin','Click')}

Laajennukset

Laajennukset ovat erittäin hyödyllinen kieliominaisuus, jonka ansiosta voimme 'laajentaa' olemassa olevia luokkia, vaikka ne olisivat lopullisia tai meillä ei ole pääsyä niiden lähdekoodiin.

Esimerkiksi muokkaustekstimerkkijonon arvon saamiseksi sen sijaan, että kirjoittaisimme editText.text.toString () joka kerta, voimme kirjoittaa funktion:

fun EditText.textValue(): String{ return text.toString() }

Tai jopa lyhyempi:

fun EditText.textValue() = text.toString()

Ja nyt, jokaisen tapauksen kanssa EditText :

editText.textValue()

Tai voimme lisätä ominaisuuden, joka palauttaa saman:

var EditText.textValue: String get() = text.toString() set(v) {setText(v)}

Käyttäjän ylikuormitus

Joskus on hyödyllistä, jos haluamme lisätä, kertoa tai vertailla objekteja. Kotlin sallii ylikuormituksen: binäärioperaattoreille (plus, miinus, plusAssign, alue jne.), Matriisioperaattoreille (get, set, get range, set range) ja yhtäläisille ja unary-operaatioille (+ a, -a jne.) .

Tietoluokka

Kuinka monta koodiriviä tarvitset Java-luokan käyttäjäluokan toteuttamiseksi, jolla on kolme ominaisuutta: copy, yhtäsuuri, hash koodin Y merkkijono ? Kotlinissa tarvitset vain yhden rivin:

Usuario de Clase de Datos(nombre del val: String, apellido del val: String, edad del val: Int)

Tämä tietoluokka tarjoaa yhtäläiset (), hashCode () ja copy () -menetelmät ja myös merkkijono (), joka tulostaa käyttäjän seuraavasti:

Usuario(nombre=John, apellido=Doe, edad=23)

Dataluokat tarjoavat myös joitain muita hyödyllisiä toimintoja ja ominaisuuksia, jotka näkyvät Kotlinin dokumentaatiossa.

Anko-pidennykset

Käyttää Voiveitsi tai Android-laajennukset, eikö? Entä jos sinun ei tarvitse edes käyttää tätä kirjastoa ja ilmoitettuasi näkymät XML: ssä, sinun tarvitsee vain käyttää sitä koodista sen ID: llä (kuten XAML: llä C #: ssä):

loginBtn.setOnClickListener{} import kotlinx.android.synthetic.main.activity_main.*

Kotlinilla on erittäin hyödyllisiä [Anko-laajennukset] (https://github.com/Kotlin/anko), eikä sinun tarvitse kertoa sen toiminnalle, mikä se on KirjauduBtn , tiedät sen yksinkertaisesti 'tuomalla' xml:

interface CreateUserView : View { fun showEmptyNameError() /* show error when name is empty */ fun showEmptySurnameError() /* show error when surname is empty */ fun showUserSaved() /* show user saved info */ fun showUserDetails(user: User) /* show user details */ }

Ankossa on monia muita hyödyllisiä asioita, kuten alkutoiminta, keskiaktiviteetit ja niin edelleen. Tämä ei ole Ankon päätavoite - se on suunniteltu luomaan helposti koodiasettelut. Joten jos haluat luoda ohjelmointiasettelun, tämä on paras tapa.

Tämä on vain lyhyt katsaus Kotliniin. Suosittelen lukemaan Antonio Leivan blogin ja hänen kirjansa - Kotlin Android-kehittäjille , ja tietysti virallinen Kotlin-sivusto.

Mikä on MVP ja miksi?

Mukava, tehokas ja selkeä kieli ei riitä. On erittäin helppoa kirjoittaa sotkuisia sovelluksia kaikilla kielillä ilman hyvää arkkitehtuuria. Android-kehittäjät (lähinnä vasta aloittelevat, mutta myös edistyneemmät) antavat Activitylle usein vastuun kaikesta ympärillään olevasta. Aktiviteetti (tai katkelma tai muu näkymä) lataa tietoja, tallentaa lähetettäväksi, esittelee ne, reagoi käyttäjien vuorovaikutuksiin, muokkaa tietoja ja hallinnoi kaikkia lapsenäkymiä. . . Ja monta kertaa paljon enemmän. Se on liikaa kohteille, jotka ovat yhtä epävakaita kuin aktiviteetit tai fragmentit (kierrä vain näyttöä ja toiminto sanoo 'Hei ...').

Erittäin hyvä idea on eristää mielipiteiden vastuut ja tehdä niistä mahdollisimman typeriä. Näkymien (aktiviteetit, katkelmat, mukautetut näkymät tai mikä tahansa data, joka näyttää tietoja näytöllä) pitäisi olla yksin vastuussa alikatselujensa hallinnasta. Näkemyksissä tulisi olla esittäjiä, jotka kommunikoivat mallin kanssa ja kertovat heille, mitä tehdä. Tämä on lyhyesti sanottuna malli Model-View-Presenter (Minulle se pitäisi nimetä Model-Presenter-View näyttää kerrosten väliset yhteydet).

'Hei, tiedän jotain sellaista, ja sitä kutsutaan MVC: ksi!' - etkö ajattele? Ei, MVP ei ole sama kuin MVC. MVC-mallissa näkymäsi voi olla yhteydessä malliin. MVP: n käytön aikana et salli mitään viestintää näiden kahden kerroksen välillä, ainoa tapa Näytä voi kommunikoida Malli on läpi Juontaja . Ainoa Näytä tietää Malli se voi olla tietorakenne. Näytä osaa esimerkiksi näyttää Käyttäjä , mutta ei tiedä milloin. Tässä on yksinkertainen esimerkki:

Näky tietää, että 'Olen toimintaa, minulla on kaksi EditTexts ja painike. Kun joku napsauttaa painiketta, minun on kerrottava esittäjällesi, ja välitän arvon EditTexts . Ja siinä kaikki, voin nukkua seuraavaan napsautukseen asti tai juontaja kertoo minulle, mitä tehdä.

Juontaja se tietää, että jonnekin on näkymä, ja tietää mitä toimintoja tämä näkymä voi suorittaa. Tiedät myös, että kun saat kaksi merkkijonoa, sinun on luotava käyttäjä näistä kahdesta merkkijonosta ja lähetettävä tiedot malliin tallennettavaksi, ja jos se tallentaa onnistuneesti, kerro näkymälle 'Näytä menestystiedot'.

Malli tietää vain, missä data on, missä se on tallennettava ja mitkä tiedot on suoritettava.

MVP: llä kirjoitetut sovellukset on helppo testata, ylläpitää ja käyttää uudelleen. Puhtaan esittäjän ei pitäisi tietää mitään Android-alustasta. Sen on oltava puhdas Java (tai Kotlin, meidän tapauksessamme) Java-luokka. Tämän ansiosta voimme käyttää esittäjäämme uudelleen muissa projekteissa. Voimme myös helposti kirjoittaa yksikkötestit, testaamalla erikseen Malli , Näytä Y Juontaja .

MVP-malli johtaa parempaan ja vähemmän monimutkaiseen koodipohjaan pitämällä käyttöliittymän ja liiketoimintalogiikan todella erillään.

Pieni poikkeama: MVP: n pitäisi olla osa Bob-setän puhdas arkkitehtuuri tehdä sovelluksista entistä joustavampia ja hyvin suunniteltuja. Yritän kirjoittaa siitä ensi kerralla.

Esimerkkisovellus MVP: n ja Kotlinin kanssa

Tämä on tarpeeksi teoriaa, katsotaanpa koodi! Yritetään luoda yksinkertainen sovellus. Tämän sovelluksen päätavoitteena on luoda käyttäjä. Ensimmäisessä näytössä on kaksi EditTxt-tekstiä (ensimmäinen ja viimeinen) ja (Save) -painike. Kun olet kirjoittanut etu- ja sukunimen ja napsauttanut 'Tallenna', sovelluksen pitäisi näyttää 'Käyttäjä on tallennettu' ja siirtyä seuraavaan näyttöön, jossa tallennettu etu- ja sukunimi näytetään. Kun etu- tai sukunimi on tyhjä, sovelluksen ei pitäisi tallentaa käyttäjää, ja sitten siinä näkyy virhe, joka ilmoittaa vikasta.

Ensimmäinen tehtävä projektin luomisen jälkeen Android Studio on määrittää Kotlin. Sinun pitäisi asenna Kotlin-laajennus ja uudelleenkäynnistyksen jälkeen voit valita Työkalut> Kotlin -kohdassa Määritä Kotlin projektissa. IDE lisää Kotlin-riippuvuudet Gradleen. Jos sinulla on olemassa olevaa koodia, voit muuntaa sen helposti Kotliniksi (Ctrl + Vaihto + Alt + K tai Koodaa> Muunna Java-tiedosto Kotliniksi). Jos jokin ei toimi ja projekti ei käänny tai Gradle ei näe Kotlinia, voit tarkistaa GitHubissa olevan sovelluskoodin.

Kotlin ei ole vain yhteensopiva Java-kehysten ja kirjastojen kanssa, vaan voit jatkaa useimpien jo tunnettujen työkalujen käyttöä.

Nyt kun meillä on projekti, aloitetaan luomalla ensimmäinen näkymä: Luo käyttäjänäkymä . Tällä näkymällä on oltava yllä mainitut toiminnot, joten voimme kirjoittaa siihen käyttöliittymän:

interface View

Kuten näette, Kotlin on samanlainen kuin Java toimintojen ilmoittamisessa. Kaikki ovat toimintoja, jotka eivät palauta mitään, ja viimeisillä on parametri. Tämä on ero, parametrityyppi tulee nimen jälkeen. View-käyttöliittymä ei ole Android: se on yksinkertainen, tyhjä käyttöliittymä:

interface Presenter { var view: T? fun onDestroy(){ view = null } }

Rajapinta Juontaja Basicilla on oltava tyypinäkymän ominaisuus ja ainakin menetelmässä (esimerkiksi onDestroy), jossa tämä ominaisuus asetetaan nollaksi:

interface CreateUserPresenter: Presenter { fun saveUser(name: String, surname: String) }

Täällä voit nähdä toisen Kotlinin ominaisuuden: voit ilmoittaa ominaisuuksista rajapinnoissa ja myös toteuttaa menetelmiä siellä.

Meidän CreateUserView täytyy kommunikoida CreateUserPresenter . Ainoa lisäominaisuus, jonka tämä esittäjä tarvitsee, on saveUser kahdella merkkijono-argumentilla:

data class User(val name: String, val surname: String)

Tarvitsemme myös mallin määritelmän - se mainittiin aiemmin luokkatyypissä:

class CreateUserPresenterImpl(override var view: CreateUserView?): CreateUserPresenter { override fun saveUser(name: String, surname: String) { } }

Kun kaikki liitännät on ilmoitettu, voimme aloittaa toteuttamisen.

CreateUserPresenter toteutetaan vuonna CreateUserPresenterImpl :

CreateUserPresenterImpl(override var view: CreateUserView?)

Ensimmäinen rivi luokan määritelmällä:

class MainActivity : AppCompatActivity(), CreateUserView { private val presenter: CreateUserPresenter by lazy { CreateUserPresenterImpl(this) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) saveUserBtn.setOnClickListener{ presenter.saveUser(userName.textValue(), userSurname.textValue()) /*use of textValue() extension, mentioned earlier */ } } override fun showEmptyNameError() { userName.error = getString(R.string.name_empty_error) /* it's equal to userName.setError() - Kotlin allows us to use property */ } override fun showEmptySurnameError() { userSurname.error = getString(R.string.surname_empty_error) } override fun showUserSaved() { toast(R.string.user_saved) /* anko extension - equal to Toast.makeText(this, R.string.user_saved, Toast.LENGTH_LONG) */ } override fun showUserDetails(user: User) { } override fun onDestroy() { presenter.onDestroy() } }

Se on konstruktori, käytämme sitä käyttöliittymässä määritetyn näkymäominaisuuden osoittamiseen.

Pääaktiviteetti , mikä on meidän CreateUserView täytäntöönpanoon, on viitattava CreateUserPresenter :

private val presenter: CreateUserPresenter by lazy { CreateUserPresenterImpl(this) }

Esimerkin alussa määritellään juontajamme:

override fun saveUser(name: String, surname: String) { val user = User(name, surname) when(UserValidator.validateUser(user)){ UserError.EMPTY_NAME -> view?.showEmptyNameError() UserError.EMPTY_SURNAME -> view?.showEmptySurnameError() UserError.NO_ERROR -> { UserStore.saveUser(user) view?.showUserSaved() view?.showUserDetails(user) } } }

Se on määritelty muuttumattomaksi (val), ja sen on luonut laiska edustaja, joka nimitetään ensimmäistä kertaa sitä tarvita. Toisaalta olemme varmoja, että se ei ole tyhjä (ei kysymysmerkkiä määritelmän jälkeen).

Kun käyttäjä napsauttaa Tallenna-painiketta, View lähettää tiedot esittäjälle EditTexts-arvoilla. Kun näin tapahtuu, käyttäjä on tallennettava, joten meidän on toteutettava saveUser-menetelmä Presenterissä (ja jotkut mallitoiminnot):

enum class UserError { EMPTY_NAME, EMPTY_SURNAME, NO_ERROR } object UserStore { fun saveUser(user: User){ //Save user somewhere: Database, SharedPreferences, send to web... } } object UserValidator { fun validateUser(user: User): UserError { with(user){ if(name.isNullOrEmpty()) return UserError.EMPTY_NAME if(surname.isNullOrEmpty()) return UserError.EMPTY_SURNAME } return UserError.NO_ERROR } } Lo más interesante aquí es *UserValidator.* Mediante el uso de la palabra objeto, podemos crear una clase *Singleton*, sin preocupaciones de hilos, constructores privados y así sucesivamente. Adicionalmente: en el método validateUser (usuario), existe con (usuario) {} expresión. El código dentro de dicho bloque se ejecuta en contexto de objeto, se pasa con el nombre y el apellido son las propiedades del Usuario. También hay otra pequeña cosa. Todo el código anterior, de enum a *UserValidator*, la definición se coloca en un archivo (la definición de clase de usuario también está aquí). Kotlin no te obliga a tener cada clase pública en un solo archivo (o nombre de la clase exactamente como archivo). Por lo tanto, si tienes algunos fragmentos cortos de código relacionados con (clases de datos, extensiones, funciones, constantes - Kotlin no requiere clase para función o constante), puedes colocarlos en un solo archivo en lugar de propagarlos a través de todos los archivos del proyecto. Cuando un usuario se guarda, nuestra aplicación debería mostrarlo. Necesitamos otra vista: puede ser cualquier vista de Android, vista personalizada, fragmento o actividad. Elige la Actividad. Por lo tanto, vamos a definir la interfaz de*UserDetailsView*. Puede mostrar al usuario, pero también debe mostrar un error cuando el usuario no está presente: ~~~ kotlin interface UserDetailsView { fun showUserDetails(user: User) fun showNoUserError() }

Kun käyttäjä luodaan, se lähetetään UserValidator tarkistaa sen pätevyys. Sitten validointituloksen perusteella kutsutaan sopivaa menetelmää. When () {} -rakenne on sama kuin Java / switch / case. Mutta se on tehokkaampaa - Kotlin sallii enumin tai int: n käytön myös tapauksissa, mutta myös alueiden, merkkijonojen tai objektityyppien. Sen on sisällettävä kaikki mahdollisuudet tai oltava lauseke. Peitä sitten kaikki UserError-arvot.

Käytettäessä näkymää? .showEmptyNameError () (kysymysmerkillä Näkymän jälkeen) suojaamme itsemme NullPointer Näkymä voidaan ohittaa menetelmässä tuhota , ja tällä rakenteella mitään ei tapahdu.

Kun käyttäjämallissa ei ole virheitä, se kertoo UserStore tallenna se ja käske sitten näkymässä näyttää menestys ja näyttää yksityiskohdat.

Kuten edellä mainittiin, meidän on toteutettava joitain olennaisia ​​asioita:

interface UserDetailsPresenter: Presenter { var user: User? }

Seuraavaksi UserDetailsPresenter. Sillä tulisi olla käyttäjän ominaisuus:

class UserDetailsPresenterImpl(override var view: UserDetailsView?): UserDetailsPresenter { override var user: User? = null set(value) { field = value if(field != null){ view?.showUserDetails(field!!) } else { view?.showNoUserError() } } }

Tämä käyttöliittymä otetaan käyttöön vuonna UserDetailsPresenterImpl . Sinun on korvattava käyttäjän omaisuus. Aina kun tämä ominaisuus määritetään, käyttäjä on päivitettävä näkymässä. Voimme käyttää a asettaja ominaisuus tälle:

class UserDetailsActivity: AppCompatActivity(), UserDetailsView { private val presenter: UserDetailsPresenter by lazy { UserDetailsPresenterImpl(this) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_user_details) val user = intent.getParcelableExtra(USER_KEY) presenter.user = user } override fun showUserDetails(user: User) { userFullName.text = '${user.name} ${user.surname}' } override fun showNoUserError() { toast(R.string.no_user_error) finish() } override fun onDestroy() { presenter.onDestroy() } }

Toimeenpano UserDetailsView , UserDetailsActivity , Se on hyvin yksinkertaista. Kuten aiemmin, meillä on laiska latauksella luotu esitysobjekti. Käyttäjä näytettäessä on läpäistävä tarkoituksella. Tässä on tällä hetkellä pieni ongelma, ja me ratkaisemme sen hetken kuluttua. Kun meillä on tarkoituksellinen käyttäjä, View pitää määrittää se esittäjälleen. Sen jälkeen käyttäjä päivitetään näytölle tai jos se on tyhjä, virhe ilmestyy (ja toiminta päättyy, mutta esittäjä ei tiedä):

anular divertido showUserDetails(usuario: Usuario) { startActivity(USER_KEY to user) /* extensión anko – empieza UserDetailsActivity y pasa el usuario a USER_KEY in intent */ }

Objektien välittäminen tarkoitusten kautta edellyttää, että tämä objekti toteuttaa Parcelable-käyttöliittymän. Tämä on hyvin 'likaa' työtä. Henkilökohtaisesti inhoan tämän tekemistä kaikkien tekijöiden, ominaisuuksien, säästöjen, restauroinnin ja niin edelleen vuoksi. Onneksi on olemassa kytkeä sopiva, Paklin Kotlinille. Asennuksen jälkeen voimme luoda paketin yhdellä napsautuksella.

Viimeinen asia, joka meidän on tehtävä, on toteuttaa showUserDetails (käyttäjä: käyttäjä) päätoiminnassamme:

|_+_|

Ja siinä se.

Meillä on yksinkertainen sovellus, joka tallentaa käyttäjän (ei itse tallennettu, mutta voimme lisätä tämän toiminnon koskematta esittäjää tai näkymää) ja esitellä sen näytöllä. Jos haluamme tulevaisuudessa muuttaa tapaa, jolla käyttäjä esitetään näytöllä, kuten: kaksi aktiviteettia kahteen fragmenttiin yhdessä toiminnossa tai kaksi mukautettua näkymää; muutokset näkyvät vain Näytä-luokissa. Tietenkin, jos emme muuta mallin toimivuutta tai rakennetta. Esittäjä, joka ei tiedä tarkalleen mitä View on, ei tarvitse muutoksia.

Onko sinulla ongelmia Android-sovellusten kehittämisessä? Tutustu näihin optimointivihjeisiin ja -tekniikoihin.

Mitä seuraavaksi?

Sovelluksessamme Presenter luodaan joka kerta, kun toiminto luodaan. Tämä lähestymistapa tai sen päinvastainen, jos esittäjä haluaa jatkaa toimintaansa, on keskustelunaihe Internetissä. Minulle se riippuu sovelluksesta, sen tarpeista ja kehittäjästä. Joskus on parempi tuhota esittäjä, joskus ei. Jos päätät jatkaa yhtä, on käytettävä erittäin mielenkiintoista tekniikkaa LoaderManager Sen vuoksi.

Kuten edellä mainittiin, MVP: n on oltava osa Bob-setän puhdas arkkitehtuuri . Toisaalta hyvien kehittäjien tulisi käyttää Tikari pistää esittäjäriippuvuuksia toimintaan. Se auttaa myös ylläpitämään, testaamaan ja käyttämään koodiasi jatkossa. Tällä hetkellä Kotlin toimii erittäin hyvin Daggerin kanssa (ennen virallista julkaisua se ei ollut niin helppoa) ja myös muiden hyödyllisten Android-kirjastojen kanssa.

johtopäätös

Minulle Kotlin on hieno kieli. Se on moderni, selkeä ja ilmeikäs, mutta suuret ihmiset kehittävät sitä edelleen. Ja voimme käyttää mitä tahansa uutta versiota millä tahansa Android-laitteella ja -versiolla. Mikä saa minut vihaamaan Javassa, Kotlin tekee siitä paremman.

Tietenkin, kuten sanoin, mikään ei ole ihanteellista. Kotlinilla on myös joitain haittoja. Gradle-laajennusten uudemmat versiot (lähinnä alfa- tai beetaversiot) eivät toimi hyvin tällä kielellä. Monet ihmiset valittavat, että koontiaika on vähän pidempi kuin puhdas Java, ja apkeilla on muutama ylimääräinen MB. Tästä huolimatta, Android Studio Y Gradle He paranevat jatkuvasti, ja puhelimissa on yhä enemmän tilaa sovelluksille. Siksi mielestäni Kotlin voi olla erittäin mukava kieli kaikille Android-kehittäjille. Kokeile vain ja jaa mielipiteesi alla olevassa kommenttiosassa.

Näytesovelluksen lähdekoodi on saatavilla osoitteessa Github .