Откако је Андроид створен, програмери апликација користимо СКЛите за складиштење локалних података. Понекад директно са СКЛ изразима, понекад користећи Објецт-Релатионал Маппер (ОРМ) као слој апстракције, али у сваком случају, СКЛите користимо на крају дана.

Упркос свим предностима СКЛите-а, било је тренутака када смо пожелели да имамо алтернативе релационом моделу: Нешто што би нас могло поштедети потребе за додавањем основног кода за претварање вредности у и из базе података или нам омогућило да прескочимо постављање мапирања између класа и табела, поља и колона, страних кључева итд.

Другим речима, база података са структурама података сличнијим онима које заправо користимо на нивоу апликације. Још боље, ако би дизајн могао да ефикасно користи меморију, омогућавајући боља искуства у уређајима са ограниченим ресурсима, то би било сјајно.

То су, у ствари, неке од готових погодности које имамо са нама Царство , платформа базе података са изразитом архитектуром, која се појавила као нова алтернатива СКЛите-у.

Овај чланак представља неке од главних разлога зашто је Реалм привукао толико пажње и зашто бисте можда желели да покушате да га испробате. У њему се расправља о неким кључним предностима које Реалм пружа Андроид програмери преко СКЛите-а.

Будући да је Реалм доступан на више платформи, нешто од онога што ће бити обрађено у овом чланку има значаја и за друге мобилне платформе, попут иос , Ксамарин и Реацт Нативе.

СКЛите: Ради, али није оно што вам треба већину времена

Већина програмера за мобилне уређаје је вероватно упозната са СКЛите-ом. Постоји од 2000. године, и то је сигурно највише користе механизам релационих база података у свету.

СКЛите има низ предности које сви признајемо, а једна од њих је његова изворна подршка за Андроид.

Чињеница да је то стандардна СКЛ релациона база података такође минимализује криву учења за оне који потичу из позадине релационе базе података. Такође пружа релативно добре перформансе ако се користи у пуном потенцијалу (функције искоришћавања, као што су припремљени извештаји, масовне операције са трансакцијама, итд.). Иако се СКЛите можда неће добро прилагодити свим вашим потребама.

Међутим, директно бављење СКЛ изразима има бројне недостатке.

Према званична Андроид документација , ево корака потребних за почетак читања / писања у СКЛите:

1. Опишите своју шему у смислу класа уговора.
2. Дефинишите наредбе за креирање / испуштање табеле у низовима.
3. Прошири SQLiteOpenHelper за покретање команди за креирање и управљање надоградњама / надоградњама.

Када то учините, бићете спремни за читање и писање у вашу базу података. Међутим, морат ћете претворити напријед-натраг између објеката у вашој апликацији и вриједности у бази података. Укратко: То је пуно шифре!

Друго питање је одрживост. Како се ваш пројекат увећава и јавља потреба за писањем сложенијих упита, на крају ћете добити велике делове сирових СКЛ упита у низовима. Ако касније будете морали да промените логику тих упита, то може бити велика гњаважа.

Упркос негативним странама, постоје случајеви када је употреба сировог СКЛ-а ваша најбоља опција. Један пример је када развијате библиотеку где су перформансе и величина пресудни фактори, а додавање библиотеке треће стране треба избегавати ако је могуће.

Објектно-релационо мапирање: фластер за СКЛ изазове

Да би нас спасили од бављења сировим СКЛ-ом, ОРМ-ови су прискочили у помоћ.

Неки од најпознатијих Андроид ОРМ-ова су ДБФлов , греенДАО , и ОрмЛите .

Највећа вредност коју им доноси је апстракција СКЛите, омогућавајући нам релативно лако мапирање ентитета базе података на Јава објекте.

Између осталих погодности, програмери апликација почињу да раде са објектима, много познатијом структуром података. Такође помаже у одржавању, јер сада рукујемо објектима високог нивоа са јачим куцањем и прљав посао препуштамо библиотекама. Мање муке са изградњом упита спајањем низова или ручним руковањем везом са базом података. Мање грешака у куцању.

Иако је чињеница да су ови ОРМ-ови подигли лествицу Андроид база података, они имају и своје недостатке. У многим случајевима на крају учитате непотребне податке.

Ево примера.

Рецимо да имате табелу са 15 колона, а на одређеном екрану апликације приказује се листа објеката из ове табеле. Ова листа приказује вредности из само три колоне. Стога, учитавањем свих података из реда табеле, на крају доносите пет пута више података него што је заправо било потребно за тај екран.

Истини за вољу, у неким од ових библиотека можете одредити које колоне желите унапред да преузмете, али за то треба да додате још кода, па чак и то, то неће бити довољно у случају да тачно можете знати које ћете колоне користите након што погледате саме податке: неки подаци ће се ионако можда непотребно учитати.

Поред тога, често постоје сценарији у којима морате да направите сложене упите, а ваша ОРМ библиотека вам једноставно не нуди начин да те упите опишете помоћу свог АПИ-ја. То вас може натерати да напишете неефикасне упите који врше више прорачуна него што вам је потребно, на пример.

Последица је губитак перформанси, због чега се прибегавате сировом СКЛ-у. Иако ово многима од нас не прекида посао, то штети главној сврси објектно-релационог мапирања и враћа нас на нека од горе поменутих проблема у вези са СКЛитеом.

Царство: савршена алтернатива

Реалм Мобиле Датабасе је база података дизајнирана за мобилне уређаје од темеља.

Кључна разлика између Реалма и ОРМ-а је та што Реалм није апстракција изграђена на врху СКЛите-а, већ потпуно нови механизам базе података. Уместо на релационом моделу, он се заснива на складишту објеката. Његово језгро се састоји од самосталне библиотеке Ц ++. Тренутно подржава Андроид, иОС (Објецтиве-Ц и Свифт), Ксамарин и Реацт Нативе.

Реалм је покренут у јуну 2014. године, тако да је тренутно стар две и по године (прилично нов!).

Док су технологије база података сервера пролазиле кроз револуцију од 2007. године, с појавом многих нових, технологија база података за мобилне уређаје остала је заглављена у СКЛите-у и његовим омотима. Ово је била једна од кључних мотивација за стварање нечега од нуле. Даље, као што ћемо видети, неке од Реалмових карактеристика захтевале су темељне промене у начину понашања базе података на ниском нивоу, а то једноставно није било могуће изградити нешто на врху СКЛите-а.

Али да ли је Царство заиста вредно тога? Ево главних разлога због којих бисте требали размислити о додавању Реалма на свој појас за алат.

Лако моделирање

Ево примера неких модела креираних са Реалм-ом:

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; }

Ваши модели се шире од РеалмОбјецт-а. Реалм прихвата све примитивне типове и његове уоквирене типове (осим char), String, Date и byte[]. Такође подржава поткласе RealmObject и RealmList за моделирање односа.

Поља могу имати било који ниво приступа (приватни, јавни, заштићени итд.). Сва поља су подразумевано задржана, а ви само треба да означите „посебна“ поља (нпр. @PrimaryKey За поље вашег примарног кључа, @Ignore да бисте поставили поља која се не задржавају итд.).

Занимљивост овог приступа је да он држи класе мање „загађеним“ у поређењу са ОРМ-овима, јер су у већини њих потребне напомене за мапирање класа у табеле, редовна поља у ступце базе података, поља страних кључева у друге табеле итд. на.

Односи

Када су у питању везе, постоје две могућности:

• Додајте модел као поље другог модела. У нашем примеру, Contact класа садржи Address поље и то дефинише њихов однос. Контакт може имати адресу, али ништа не спречава додавање исте адресе у друге контакте. То омогућава односе један-на-један и један-на-много.

• Додајте RealmList модела на које се упућује. RealmLists понашају се као добра стара Јава Lists, делујући као контејнер Реалм објеката. Видимо да је наш Contact модел има RealmList контаката, који су јој у овом примеру пријатељи. Овим приступом могу се моделирати односи један-према-много и много-према-много.

Свиђа ми се овај начин представљања односа јер се нама програмерима Јава чини природним. Додавањем ових објеката (или спискова ових објеката) директно као поља наше класе, баш као што бисмо то радили и за друге класе без модела, не треба да се бавимо СКЛите поставкама за стране кључеве.

Наредба за суспендовање: Не постоји подршка за наслеђивање модела. Тренутно решење је употреба композиције. Па ако, на пример, имате Animal модел и надали су се да ће створити Dog модел који се протеже од Animal, уместо тога ћете морати да додате Animal инстанца као поље у Dog. Постоји велика дебата о саставу наспрам наслеђа. Ако се бавите наследством, ово је дефинитивно нешто што треба да знате о Реалму. Са СКЛите-ом, ово би могло да се примени помоћу две табеле (једна за родитеља и једна за дете) повезане спољним кључем. Неки ОРМ-ови такође не намећу ово ограничење, попут ДБФлов-а.

Преузмите само потребне податке! Дизајн нулте копије

Ово је убилачка карактеристика.

Реалм примењује концепт дизајна без копије, што значи да се подаци никада не копирају у меморију. Резултати које добијете из упита заправо су само показивачи на стварне податке. Подаци сами по себи се лено учитавају док им приступате.

На пример, имате модел са 10 поља (колоне у СКЛ-у). Ако тражите да објекти овог модела прикажу наведене на екрану, а потребна су вам само три од 10 поља за попуњавање ставки листе, то ће бити једина преузета поља.

Као последица тога, упити су запањујуће брзи (види овде и овде за неке референтне резултате).

То је велика предност у односу на ОРМ-ове који обично унапред учитавају све податке из изабраних СКЛ редова.

Учитавање екрана постаје знатно ефикасније као резултат, без потребе за додатним напорима програмера: то је само подразумевано понашање Реалма.

Поред тога, то такође значи да апликације троше мање меморије, а с обзиром на то да говоримо о окружењу ограниченом ресурсима као што су мобилни уређаји, то може направити велику разлику.

Још једна последица приступа са нултом копијом је да се објекти којима управља Реалм аутоматски ажурирају.

Подаци се никада не копирају у меморију. Ако имате резултате из упита, а друга нит је ажурирала ове податке у бази података након вашег упита, резултати које поседујете већ ће одражавати ове промене. Ваши резултати су само показивачи на стварне податке. Дакле, када приступите вредностима из поља, враћају се најсавременији подаци.

Ако сте, на пример, већ прочитали податке из објеката Реалма и приказали их на екрану и желите да примате ажурирања када се основни подаци промене, можете да додате слушалац:

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

То није само омотач

Иако имамо на десетине опција за ОРМ-ове, они су омотачи и све се своди на СКЛите испод, што ограничава колико далеко могу доћи. Насупрот томе, Реалм није само још један СКЛите омот. Има слободу да пружа функције које ОРМ-ови једноставно не могу да понуде.

Једна од основних промена са Реалм-ом је могућност складиштења података као складишта графа објекта.

То значи да су Реалм објекти до краја, од нивоа програмског језика до базе података. Због тога се мање конверзија врши напред-назад док пишете и читате вредности, у поређењу са релационом базом података.

Структуре база података ближе одражавају структуре података које користе програмери апликација. Заправо, ово је један од главних разлога зашто се креће од релационог моделирања ка агрегатним моделима на развоју на страни сервера. Реалм коначно доноси неке од ових идеја у свет мобилног развоја.

Ако размишљамо о компонентама у Реалмовој архитектури, на дну се налази његово језгро са најосновнијом имплементацијом платформе. Поврх тога, имаћемо библиотеке за повезивање за сваку подржану платформу.

Када користите омот за неку технологију над којом немате контролу, на крају ћете морати да обезбедите неку врсту апстрактног слоја око њега.

Либс за везивање царства дизајнирани су да буду што тањи како би се смањила сложеност апстракције. Углавном пропагирају идеју дизајна из компаније Цоре. Имајући контролу над целокупном архитектуром, ове компоненте раде у бољој међусобној синхронизацији.

Један практичан пример је приступ другим референцираним објектима (страни кључеви у СКЛ-у). Структура датотеке Реалма заснива се на изворним везама, па када постављате упите за везе, уместо да преводите ОРМ апстракцију у релацијске и / или спајате више табела, добићете необрађене везе до објеката на нивоу система датотека у формату датотеке.

То су предмети који директно упућују на друге предмете. Према томе, постављање упита за везу је исто што и испитивање целобројне колоне, на пример. Нема потребе за скупим операцијама преласка страних кључева. Све је у слеђењу показивача.

Заједница и подршка

Реалм је у активном развоју и прилично често објављује ажуриране верзије.

Све компоненте из базе података Реалм Мобиле су отвореног кода . Они су врло одзивни на своје трацк трацкер и Стацк Оверфлов , тако да можете очекивати добру и брзу подршку на овим каналима.

Такође, повратне информације из заједнице узимају се у обзир приликом одређивања приоритета за проблеме (грешке, побољшања, захтеви за функције, итд.). Увек је добро знати да можете да учествујете у развоју алата које користите.

Почео сам да користим Реалм 2015. године и од тада сам налетео на неколико постова на вебу са различитим мишљењима о Реалму. Ускоро ћемо разговарати о његовим ограничењима, али једна ствар коју сам приметио је да су многе жалбе у време поста објављене у међувремену.

На пример, када сам упознао Реалм, још увек није постојала подршка за прилагођене методе на моделима и асинхроне позиве. Многи су у то време били прекидачи договора, али обојица су тренутно подржани.

Таква брзина развоја и одзивност нас чине сигурнијима да нећемо дуго чекати важне функције.

Ограничења

Као и у свему у животу, ни Царство нису све руже. Поред претходно поменутог ограничења наслеђа, постоје и други недостаци:

• Иако је могуће имати више нити истовремено које читају и пишу у базу података, Објекти царства не могу се премештати преко нити . Дакле, ако, на пример, преузмете објекат царства помоћу АсинцТаск-овог doInBackground(), који се изводи у позадини нити, не можете проследити ову инстанцу onPostExecute() методе, јер се оне изводе на главној нити. Могућа заобилазна решења у овој ситуацији би била да се направи копија објекта и проследи га или проследи ИД објекта и поново преузме објекат на onPostExecute() Реалм нуди синхроне и асинхроне методе за читање / писање.

• Постоји нема подршке за аутоматско повећање примарних кључева , тако да ћете морати сами да се бавите њиховом генерацијом.

• Његово није могуће приступити бази података из различитих процеса истовремено . Према њиховој документацији, ускоро долази подршка за више процеса.

Царство је будућност решења за мобилне базе података

СКЛите је солидан, робустан и провјерен механизам база података, а релацијске базе података неће ускоро нестати. Постоји читав низ добрих ОРМ-а који ће учинити трик и за многе сценарије.

Међутим, важно је бити у току са тренутним трендовима.

С тим у вези, мислим да је Реалм један од највећих предстојећих трендова у последњих неколико година када је у питању развој мобилне базе података.

Реалм са собом доноси јединствени приступ бављењу подацима који су вредни програмерима, не само зато што могу бити боља опција од постојећих решења, већ и зато што проширују видике у погледу нових могућности и подижу меру на технологији мобилних база података.

Да ли већ имате искуства са Реалм-ом? Слободно поделите своје мисли.