Siitä lähtien kun Android luotiin, olemme sovelluskehittäjät käyttäneet SQLitea paikallisten tietojen tallentamiseen. Joskus suoraan SQL-käskyjen kanssa, toisinaan Object-Relational Mapper (ORM) abstraktiokerroksena, mutta kumpaakin tapaa, olemme käyttäneet SQLiteä päivän lopussa.

Kaikista SQLiten eduista huolimatta toisinaan toivoimme, että meillä olisi vaihtoehtoja relaatiomallille: Jotain, joka voisi säästää meitä tarvitsematta lisätä kattilakoodia, jotta arvot voidaan muuntaa tietokantaan tai siitä, tai antaa meille mahdollisuuden ohittaa kartoitusten määrittäminen luokkien ja taulukoiden, kenttien ja sarakkeiden, vieraan avaimen jne. välillä

Toisin sanoen tietokanta, jonka tietorakenteet ovat samanlaisia ​​kuin käytämme tosiasiallisesti sovellustasolla. Parempi vielä, jos se voisi olla muistiltaan tehokas suunnittelun avulla, mikä mahdollistaisi paremman kokemuksen resurssirajoitteisissa laitteissa, se olisi mahtavaa.

Nämä ovat itse asiassa joitain tarjoamiamme etuja Valtakunta , tietokanta-alusta, jolla on erillinen arkkitehtuuri ja joka on tullut uudeksi vaihtoehdoksi SQLite-sovellukselle.

Tämä artikkeli esittelee joitain tärkeimpiä syitä, miksi Realm on kiinnittänyt niin paljon huomiota ja miksi haluat ehkä harkita sen kokeilemista. Siinä käsitellään joitain tärkeimpiä etuja, joita Realm tarjoaa Android-kehittäjät SQLite.

Koska Realm on saatavana useilla alustoilla, joillakin tämän artikkelin aiheilla on merkitystä myös muille mobiilialustoille, kuten ios , Xamarin ja React Native.

SQLite: Se toimii, mutta sitä ei tarvita suurimman osan ajasta

Useimmat mobiilikehittäjät tuntevat todennäköisesti SQLiten. Se on ollut olemassa vuodesta 2000, ja se on kiistatta eniten käytetty relaatiotietokantamoottori maailmassa.

SQLitellä on useita etuja, jotka me kaikki tunnustamme, joista yksi on sen alkuperäinen tuki Androidille.

Se, että se on tavallinen SQL-relaatiotietokanta, minimoi myös oppimiskäyrän relaatiotietokannan taustalta tuleville. Se tarjoaa myös kohtuullisen hyvän suorituskyvyn, jos se hyödynnetään täysimääräisesti (vipuvaikutustoiminnot, kuten laaditut lausunnot, joukkotoiminnot tapahtumien kanssa jne.). Vaikka SQLite ei ehkä sovi kovin hyvin kaikkiin tarpeisiisi.

Suoralla SQL-käskyjen käsittelyllä on kuitenkin useita haittoja.

Mukaan virallinen Android-dokumentaatio , tässä ovat vaiheet, joita tarvitaan SQLiten lukemisen / kirjoittamisen aloittamiseen:

1. Kuvaile skeemasi sopimusluokkien mukaan.
2. Määritä luomisen / pudottamisen taulukon komennot merkkijonoina.
3. Pidennä SQLiteOpenHelper suorittaa komentoja luoda ja hallita päivityksiä.

Kun olet tehnyt tämän, olet valmis lukemaan ja kirjoittamaan tietokantaan. Sinun on kuitenkin muunnettava edestakaisin sovelluksen objektien ja tietokannan arvojen välillä. Pitkä tarina lyhyesti: Se on paljon kattilakoodia!

Toinen asia on ylläpidettävyys. Kun projektisi kasvaa ja tarvitsee kirjoittaa monimutkaisempia kyselyjä, päädyt suuriin paloihin raakoja SQL-kyselyjä merkkijonoihin. Jos myöhemmin sinun on muutettava näiden kyselyjen logiikkaa, se voi olla melko hässäkkä.

Haittapuolistaan ​​huolimatta on tapauksia, joissa raaka SQL on paras vaihtoehto. Yksi esimerkki on, kun kehität kirjastoa, jossa suorituskyky ja koko ovat kriittisiä tekijöitä, ja kolmannen osapuolen kirjaston lisäämistä tulisi välttää, jos mahdollista.

Objektisuhdekartoitin: Band-aid SQL-haasteisiin

ORM: t tulivat apuun pelastaakseen meidät käsittelemästä raakaa SQL: ää.

Jotkut tunnetuimmista Android ORM: ista ovat DBFlow , vihreäDAO ja OrmLite .

Suurin niiden tuottama arvo on SQLite-abstraktio, jonka avulla voimme kartoittaa tietokantayksiköt Java-kohteisiin suhteellisen helposti.

Muiden etujen lisäksi sovelluskehittäjät pääsevät työskentelemään esineiden kanssa, mikä on paljon tutumpi tietorakenne. Se auttaa myös ylläpidettävyydessä, koska käsittelemme nyt korkeamman tason esineitä, joissa on vahvempi kirjoitus ja jätämme likainen työ kirjastojen tehtäväksi. Vähemmän kamppailua kyselyjen rakentamisesta ketjutamalla merkkijonoja tai käsittelemällä yhteyttä manuaalisesti tietokantaan. Vähemmän kirjoitusvirheitä.

Vaikka on tosiasia, että nämä ORM: t ovat nostaneet rimaa Android-tietokannoissa, niillä on myös haittoja. Monissa tapauksissa päätät ladata tarpeettomia tietoja.

Tässä on esimerkki.

Oletetaan, että sinulla on taulukko, jossa on 15 saraketta, ja sovelluksesi tietyssä näytössä näkyy luettelo tämän taulukon objekteista. Tämä luettelo näyttää arvot vain kolmesta sarakkeesta. Siksi lataamalla kaikki tiedot taulukkoriviltä tuo lopulta viisi kertaa enemmän tietoa kuin mitä tarvitsit kyseiselle näytölle.

Totta puhuen, joissakin näistä kirjastoista voit määrittää, mitkä sarakkeet haluat hakea etukäteen, mutta sinun on lisättävä lisää koodia, ja silti se ei riitä, jos tiedät vain tarkalleen mitkä sarakkeet aiot Käytä, kun olet tarkastellut itse tietoja: jotkut tiedot saattavat olla tarpeettomasti ladattu joka tapauksessa.

Lisäksi on usein skenaarioita, joissa sinulla on monimutkaisia ​​kyselyitä, ja ORM-kirjasto ei vain tarjoa sinulle tapaa kuvata näitä kyselyitä sovellusliittymänsä kanssa. Tämä voi saada sinut kirjoittamaan tehottomia kyselyitä, jotka tekevät enemmän laskelmia kuin mitä tarvitset esimerkiksi.

Seurauksena on suorituskyvyn menetys, joka johtaa sinut käyttämään raakaa SQL: ää. Vaikka tämä ei ole kaupan katkaisija monille meistä, se vahingoittaa objektisuhdekartoituksen päätarkoitusta ja vie meidät takaisin joihinkin edellä mainittuihin SQLite-ongelmaan.

Valtakunta: täydellinen vaihtoehto

Realm Mobile Database on tietokanta, joka on suunniteltu mobiililaitteille alusta asti.

Keskeinen ero Realm: n ja ORM: ien välillä on, että Realm ei ole SQLiten päälle rakennettu abstraktio, vaan kokonaan uusi tietokantamoottori. Relaatiomallin sijaan se perustuu objektivarastoon. Sen ydin koostuu itsenäisestä C ++ -kirjastosta. Se tukee tällä hetkellä Androidia, iOS: ää (Objective-C ja Swift), Xamarinia ja React Native.

Realm perustettiin kesäkuussa 2014, joten se on tällä hetkellä kaksi ja puoli vuotta vanha (aika uusi!).

Vaikka palvelintietokantateknologiat olivat käyneet läpi vallankumouksen vuodesta 2007 lähtien, kun uusia uusia oli syntymässä, mobiililaitteiden tietokantatekniikka pysyi jumissa SQLiten ja sen kääreiden kanssa. Tämä oli yksi tärkeimmistä motivaatioista luoda jotain tyhjästä. Lisäksi, kuten näemme, jotkut Realmin ominaisuudet edellyttivät perusteellisia muutoksia tapaan, jolla tietokanta käyttäytyy matalalla tasolla, ja se ei vain ollut mahdollista rakentaa jotain SQLiten päälle.

Mutta onko Realm todella sen arvoista? Tässä ovat tärkeimmät syyt, miksi sinun pitäisi harkita Realmin lisäämistä työkaluvyöhön.

Helppo mallinnus

Tässä on esimerkki joistakin Realmilla luotuista malleista:

public class Contact extends RealmObject { @PrimaryKey String id; protected String name; String email; @Ignore public int sessionId; //Relationships private Address address; private RealmList friends; //getters & setter left out for brevity } public class Address extends RealmObject { @PrimaryKey public Long id; public String name; public String address; public String city; public String state; public long phone; }

Mallisi ulottuvat RealmObject-sovelluksesta. Valtakunta hyväksyy kaikki primitiiviset tyypit ja sen laatikkotyypit (paitsi char), String, Date ja byte[]. Se tukee myös RealmObject -alaluokkia ja RealmList mallintaa suhteita.

Kentillä voi olla mikä tahansa käyttöoikeustaso (yksityinen, julkinen, suojattu jne.). Kaikki kentät pysyvät oletusarvoisesti, ja sinun on vain annettava merkinnät 'erikoiskentät' (esim. @PrimaryKey Ensisijaiselle avainkentälle, @Ignore asettaaksesi pysymättömät kentät jne.).

Tämän lähestymistavan mielenkiintoinen asia on, että se pitää luokat vähemmän 'merkinnöissä saastuneina' verrattuna ORM: iin, koska useimmissa niistä tarvitaan merkintöjä luokkien taulukoihin, säännöllisiä kenttiä tietokantasarakkeisiin, ulkomaisia ​​avainkenttiä muihin taulukoihin jne. päällä.

Ihmissuhteet

Suhteiden suhteen on kaksi vaihtoehtoa:

• Lisää malli kentäksi toisesta mallista. Esimerkissämme Contact luokka sisältää Address alalla ja joka määrittelee heidän suhteensa. Yhteyshenkilöllä voi olla osoite, mutta mikään ei estä saman osoitteen lisäämistä muihin kontakteihin. Tämä sallii yksi-yhteen ja yksi-moniin-suhteet.

• Lisää RealmList viitatuista malleista. RealmLists käyttäytyä aivan kuten vanha hyvä Java Lists, joka toimii valtakunnan esineiden säiliönä. Voimme nähdä, että Contact mallilla on RealmList kontakteja, jotka ovat hänen ystäviään tässä esimerkissä. Tällä lähestymistavalla voidaan mallintaa yksi moniin ja monia moniin-suhteita.

Pidän tästä suhteiden esittämistavasta, koska se tuntuu meille Java-kehittäjille hyvin luonnolliselta. Lisäämällä nämä objektit (tai näiden objektien luettelot) suoraan luokkamme kenteiksi, aivan kuten tekisimme muille kuin malliluokille, meidän ei tarvitse käsitellä ulkomaisten avainten SQLite-asetuksia.

Varoitus: Malliperintöä ei tueta. Nykyinen kiertotapa on sommittelun käyttö. Joten jos sinulla on esimerkiksi Animal mallin ja toivoivat luoda Dog mallista, joka ulottuu Animal -kohdasta, sinun on sen sijaan lisättävä Animal esimerkiksi kenttänä Dog Käynnissä on suuri keskustelu sävellys vs. perintö. Jos haluat käyttää perintöä, tämä on ehdottomasti jotain, mitä sinun on tiedettävä valtakunnasta. SQLiten avulla tämä voitaisiin toteuttaa käyttämällä kahta taulukkoa (yksi vanhemmalle ja toinen lapselle), jotka on yhdistetty vieraalla avaimella. Jotkin ORM: t eivät myöskään aseta tätä rajoitusta, kuten DBFlow.

Hae vain tarvitsemasi tiedot! Nollakopiointi

Tämä on tappajaominaisuus.

Realm käyttää nollakopioinnin suunnittelua, mikä tarkoittaa, että tietoja ei koskaan kopioida muistiin. Kyselystä saadut tulokset ovat oikeastaan ​​vain viitteitä todellisiin tietoihin. Itse data ladataan laiskasti, kun sitä käytetään.

Sinulla on esimerkiksi malli, jossa on 10 kenttää (sarakkeet SQL: ssä). Jos kysyt tämän mallin objekteilta, jotta ne näkyvät luettelossa, ja tarvitset vain kolme kenttää 10: stä luettelokohteiden täyttämiseen, ne ovat ainoat haetut kentät.

Tämän seurauksena kyselyt ovat räjähtävän nopeita (ks tässä ja tässä joillekin vertailutuloksille).

Tämä on suuri etu verrattuna ORM-tiedostoihin, jotka yleensä lataavat kaikki tiedot valituista SQL-riveistä etukäteen.

Näytön lataaminen muuttuu huomattavasti tehokkaammaksi ilman kehittäjän lisävaatimuksia: se on vain Realmin oletuskäyttäytyminen.

Lisäksi tämä tarkoittaa myös sitä, että sovellukset kuluttavat vähemmän muistia, ja koska puhumme resurssirajoitteisesta ympäristöstä, kuten mobiililaitteista, sillä voi olla suuri ero.

Toinen nollakopioinnin lähestymistavan seuraus on, että Realmin hallinnoimat objektit päivitetään automaattisesti.

Tietoja ei koskaan kopioida muistiin. Jos sinulla on kyselyn tuloksia ja toinen ketju on päivittänyt nämä tiedot tietokantaan kyselyn jälkeen, hallussaan olevat tulokset heijastavat jo näitä muutoksia. Tuloksesi osoittavat vain todellisia tietoja. Joten kun käytät arvoja kentistä, päivitetyt tiedot palautetaan.

Jos olet jo lukenut tietoja Realm-objekteista ja esittänyt ne esimerkiksi näytöllä ja haluat saada päivityksiä, kun perustiedot muuttuvat, voit lisätä kuuntelijan:

final RealmResults johns = realm.where(Contact.class).beginsWith('name', 'John ').findAll(); johns.addChangeListener(new RealmChangeListener() { @Override public void onChange(RealmResults results) { // UPDATE UI } });

Se ei ole vain kääre

Vaikka meillä on kymmeniä vaihtoehtoja ORM: ille, ne ovat kääreitä, ja kaikki tulee alla olevaan SQLiteen, mikä rajoittaa niiden pääsyä. Sen sijaan Realm ei ole vain yksi SQLite-kääre. Sillä on vapaus tarjota ominaisuuksia, joita ORM: t eivät vain voi tarjota.

Yksi perustavanlaatuisista muutoksista Realmissa on mahdollisuus tallentaa tietoja objektikaavioiden tallentimina.

Tämä tarkoittaa, että valtakunta on objekteja aina alaspäin, ohjelmointikielitasosta tietokantaan. Näin ollen muuntamista tehdään edestakaisin, kun kirjoitat ja luet arvoja, verrattuna relaatiotietokantaan.

Tietokantarakenteet heijastavat tarkemmin sovelluskehittäjien käyttämiä tietorakenteita. Itse asiassa tämä on yksi tärkeimmistä syistä, miksi relaatiomallinnuksesta siirrytään kohti palvelinpuolen kehityksen aggregaattimalleja. Realm tuo vihdoin joitain näistä ideoista mobiilikehitysmaailmaan.

Jos ajattelemme Realmin arkkitehtuurin komponentteja, alareunassa on sen ydin, joka on alustan perustavanlaatuisin toteutus. Sen lisäksi meillä on sitovat kirjastot jokaiselle tuetulle alustalle.

Kun käytät kääriä jollekin tekniikalle, jota et voi hallita, sinun on lopulta tarjottava jonkinlainen abstraktiokerros sen ympärille.

Valtakunnan sitovat libit on suunniteltu mahdollisimman ohuiksi leikkaamaan abstraktion monimutkaisuus. Ne levittävät enimmäkseen Core-suunnittelua. Hallitsemalla koko arkkitehtuuria nämä komponentit toimivat paremmin synkronoituna toistensa kanssa.

Yksi käytännön esimerkki on pääsy muihin viitattuihin objekteihin (vieraat avaimet SQL: ssä). Realm: n tiedostorakenne perustuu natiivilinkkeihin, joten kun kysyt suhteita sen sijaan, että joudut kääntämään ORM-abstraktia relaatioon ja / tai yhdistämään useita taulukoita, saat raakalinkit kohteisiin tiedostojärjestelmätasolla tiedostomuodossa.

Se on esineitä, jotka osoittavat suoraan muihin esineisiin. Suhteen kyseleminen on siis sama kuin esimerkiksi kokonaislukusarakkeen kyseleminen. Ei tarvita kalliita toimintoja, jotka kulkevat ulkomaisten avainten läpi. Kyse on viitteiden seuraamisesta.

Yhteisö ja tuki

Valtakuntaa kehitetään aktiivisesti ja se on julkaissut päivitettyjä versioita melko usein.

Kaikki Realm Mobile -tietokannan komponentit ovat avoin lähdekoodi . He ovat hyvin reagoivia heidän puoleensa ongelman seuranta ja Pino ylivuoto , joten voit odottaa hyvää ja nopeaa tukea näille kanaville.

Myös yhteisön palaute otetaan huomioon priorisoitaessa asioita (vikoja, parannuksia, ominaisuuspyyntöjä jne.). On aina hyvä tietää, että voit sanoa oman mielipiteesi käyttämiesi työkalujen kehittämisessä.

Aloin käyttää Realmia vuonna 2015, ja siitä lähtien olen törmännyt useisiin web-viesteihin, joissa on erilaisia ​​mielipiteitä Realmista. Puhumme sen rajoituksista pian, mutta olen huomannut, että monet postituksen aikaan tehdyistä valituksista on korjattu.

Kun sain tietää esimerkiksi Realmista, malleissa ja asynkronisissa puheluissa ei vielä ollut tukea mukautetuille menetelmille. Nämä olivat kaupan katkaisijoita monille tuolloin, mutta molempia tuetaan tällä hetkellä.

Tällainen kehitysnopeus ja reagointikyky tekevät meistä varmempia siitä, ettemme odota kauan tärkeitä ominaisuuksia.

Rajoitukset

Kuten kaikessa elämässä, valtakunta ei ole kaikki ruusuja. Aiemmin mainitun perintörajoituksen lisäksi on pidettävä mielessä muita puutteita:

• Vaikka tietokannasta voi lukea ja kirjoittaa useita ketjuja samanaikaisesti, Valtakunnan objekteja ei voi siirtää ketjujen yli . Joten jos haet esimerkiksi alueen objektin käyttämällä AsyncTaskin doInBackground() -ohjelmaa, joka toimii taustalangassa, et voi siirtää tätä esiintymää onPostExecute() menetelmiä, koska ne toimivat pääkierteellä. Tämän tilanteen mahdollisia kiertotapoja olisi joko kopioida esine ja siirtää se eteenpäin tai välittää objektin tunnus ja noutaa objekti uudelleen onPostExecute() Realm tarjoaa synkronisia ja asynkronisia menetelmiä lukemiseen / kirjoittamiseen.

• Siellä on ei tukea automaattisen lisäyksen ensisijaisille avaimille , joten sinun on käsiteltävä näiden luominen itse.

• Sen tietokantaan ei ole mahdollista päästä erillisistä prosesseista samanaikaisesti . Heidän asiakirjojensa mukaan moniprosessituki on tulossa pian.

Valtakunta on mobiilitietokantaratkaisujen tulevaisuus

SQLite on vankka, vankka ja todistettu tietokantamoottori, ja relaatiotietokannat eivät häviä milloin tahansa. On olemassa useita hyviä ORM: itä, jotka tekevät temppun myös moniin skenaarioihin.

On kuitenkin tärkeää pysyä ajan tasalla nykyisistä trendeistä.

Mielestäni Realm on yksi viime vuosien suurimmista tulevista trendeistä mobiilitietokantojen kehittämisessä.

Realm tuo mukanaan ainutlaatuisen lähestymistavan kehittäjille arvokkaan datan käsittelyyn paitsi siksi, että se voi olla parempi vaihtoehto kuin olemassa olevat ratkaisut, myös siksi, että se laajentaa näköalojamme uusien mahdollisuuksien suhteen ja nostaa mobiilitietokantatekniikan rimaa.

Onko sinulla jo kokemusta Realmista? Voit vapaasti jakaa ajatuksiasi.