Alexander Stigsen on Realmin perustaja ja toimitusjohtaja.
On totta, että yleisesti tunnustetaan, että älypuhelimen hallussa olevan käyttäjän on kaipattava parempaa yhteyttä. Miljardeista dollareista infrastruktuuri-investoinneista ja säälimättömästä teknologisesta innovaatiosta huolimatta verkkoyhteyden olennaisen todellisuuden havaitseminen ei vie muutakin kuin lyhyen ajomatkan: Et voi olettaa, että verkkoyhteys on käytettävissä aina, kun haluat. Mobiilikehittäjinä se on totuus, joka on kätevä jättää huomiotta.
Sovellusten offline-tilojen käsittely voi olla hämmentävää, mutta ongelma alkaa perus- ja virheellisestä oletuksesta - offline-tila on oletuksena virhetila. Se oli järkevää, kun rakensimme sovelluksia pöytätietokoneille, joissa oli oma Ethernet-uplink-linkki. Sillä ei ole järkeä, kun hissin ovien sulkeminen tekee sovelluksesta täysin hyödyttömän tai kun on kohtuullista olettaa, että sovellustasi käytetään paikoissa, joissa ei ole luotettavaa soluinfrastruktuuria.
Emme voi peittää maailmaa kattavuudessa, joten meidän on tarjottava vaihtoehto. Meidän on ensin ajateltava offline-tilassa. Meidän on suunniteltava sovellukset hyödyllisiksi offline-tilassa. Meidän on rakennettava sovelluksia, jotka hyödyntävät Internetiä täysimääräisesti, kun se on käytettävissä, mutta ymmärrämme, että Internet-yhteys on aina väliaikainen. Meidän on tehtävä älykkäitä suunnittelupäätöksiä, joihin liittyy offline-tiloja, ja tehtävä niistä offline-tilat ymmärrettäviksi käyttäjille.
Paljon työtä tehdään offline-ensimmäisen tulevaisuuden määrittelemiseksi. Realm, yritys, jossa työskentelen, on rakentanut reaaliaikaista alustaa offline-ensimmäisille mobiilisovelluksille jo jonkin aikaa. Mobiilitietokanta ja Realm Mobile Platform helpottavat älykkäiden, offline-sovellusten luomista melkein mihin tahansa mobiililaitteeseen. A List Apartin ihmiset ovat vaikuttaneet valtavasti offline-ensimmäiseen kirjallisuuteen, etenkin verkkosovelluksissa. Suurimpien mobiilien ekosysteemien kehittäjäyhteisöt ovat käyttäneet useita tunteja tarjotessaan vaikuttavia omia avoimen lähdekoodin ratkaisuja.
Seuraavassa on lyhyt esittely siitä, miten voit rakentaa offline-ensimmäisen mobiilisovelluksen. Käytän lopuksi yksinkertaista Swift-mallikoodia osoittaakseni, miltä minimaalinen offline-ensimmäinen sovellus näyttää, mutta tässä esitetyt periaatteet ja ongelmat ovat merkityksellisiä kaikille mobiilisovellusten kehittämisessä työskenteleville.
Suunnittelu offline-ensin
Ennen kuin rakennat offline-ensimmäisen sovelluksen, jota olet aina halunnut, meidän on tarkasteltava uudelleen suunnitteluratkaisuja, jotka olivat järkeviä työasemille, joilla on erittäin suuri todennäköisyys olla verkossa. Jos sovelluksesi pystyy käsittelemään offline- ja online-tiloja, meillä on vastauksia kysymyksiin siitä, mitä se voi tehdä ja miten näytämme käyttäjälle mahdollisuuden.
Määritä, mikä on mahdollista offline-tilassa
Otetaan esimerkiksi Twitter. Jos olet offline-tilassa ja lähetät twiitin, offline-ensimmäinen Twitter-asiakas voi kulkea kahdella polulla. Se saattaa jonottaa tweetin, kunnes se palauttaa yhteyden. Tai se voi kieltäytyä antamasta sinulle tweetata - vaikka sen avulla voit jonottaa muita toimintoja, kuten faveja, kuten Tweetbot tekee.
Miksi Tweetbot estää sinua tweetoimasta offline-tilassa? Ehkä siksi, että kun palaat takaisin verkkoon, twiitit eivät ehkä ole enää merkityksellisiä. Tämän ongelman ratkaiseminen edellyttäisi uuden käyttöliittymän tekemistä luettelolle tweeteistä, joita et ole vielä lähettänyt, mutta joita sinun on ehkä muokattava tai poistettava ennen niiden siirtymistä verkkoon. Jos toisaalta miellyttäisit twiittiä, on epätodennäköistä, että kumoaisit sen, jos kohtaat enemmän tietoa - ja paljon vähemmän ongelmallista osoittaa vain, että se on jonossa lähettämistä varten.
Et voi saada offline-sovellusta tekemään kaikkea, mitä online-sovellus voi tehdä, mutta voit tehdä siitä hyödyllisen.
Suunnittele konfliktit
Riippumatta strategiasta, jota käytät takapäässä muutosten sovittamiseksi, sovelluksesi kohtaavat pisteen, jossa sinulla on kaksi ristiriitaista tietoa. Ehkä se johtuu palvelimen kaatumisesta tai siitä, että sinä ja toinen henkilö teitte offline-muutoksia ja haluatte nyt synkronoida ne. Mitä vaan voi tapahtua!
Ennakoi siis konflikteja ja yritä ratkaista ne ennustettavalla tavalla. Tarjoa valintoja. Ja yritä välttää ensin konflikteja.
Ennakoitavuus tarkoittaa, että käyttäjät tietävät mitä voi tapahtua. Jos ristiriita voi syntyä, kun käyttäjät muokkaavat kahdessa paikassa kerralla, kun he ovat offline-tilassa, heille on varoitettava siitä, kun he ovat offline-tilassa.
Valintojen tarjoaminen tarkoittaa sitä, että ei yksinkertaisesti hyväksytä viimeistä kirjoitusta tai liitetä muutoksia tai vanhimman kopion poistamista. Se tarkoittaa sitä, että annat käyttäjän päättää sopivasta.
Lopuksi, paras ratkaisu on olla koskaan antamatta konfliktien kehittyä ensinnäkin. Ehkä se tarkoittaa sovelluksesi rakentamista siten, että uusi ja outo data monista lähteistä ei aiheuta ristiriitaa ja näyttää sen sijaan juuri niin kuin haluat. Tätä voi olla vaikea tehdä online- ja offline-tilassa olevassa kirjoitussovelluksessa, mutta jaetun piirustussovelluksen voi suunnitella lisäävän uusia polkuja piirustukseen aina, kun ne synkronoidaan.
Ole selkeä
Yksi asia on määritellä, mitä käyttäjä voi tehdä offline-tilassa. Toinen ongelma on tehdä päätöksistä ymmärrettäviä käyttäjillesi. Tietojen ja yhteyksien tilan tai tiettyjen ominaisuuksien saatavuuden välittämättä jättäminen merkitsee epäonnistumista ensimmäisen offline-sovelluksen rakentamisessa.
Jaettu muistiinpanosovellus kuvaa ongelmaa. Jos siirryt offline-tilaan, mutta odotat, että yhteistyökumppanit jatkavat muokkaamista sovelluksessa poissaollessasi, ei riitä, että annat vain käyttäjän jatkaa kirjoittamista, kunnes hän on tyytyväinen. Kun he muodostavat yhteyden uudelleen, he ovat yllättyneitä kehittyvistä konflikteista.
Auta sen sijaan käyttäjää tekemään oikea päätös. Jos huomaat, että palvelinyhteytesi on katkennut, koska sovelluksesi yläpalkki muuttaa väriä, tiedät mitä voi olla tulossa: yhdistä ristiriidat! Se voi olla hienoa suurimman osan ajasta, ja sovelluksesi käyttöliittymä voi auttaa korjaamaan odottamattomat ristiriidat, kun palaat takaisin verkkoon. Mutta jos menetät yhteyden, kun useita ihmisiä muokkaa sovellustasi, eikö olisikaan hyödyllistä tietää, että konfliktien riski on paljon suurempi? "Yhteys katkesi, mutta muut olivat muokkaamassa. Muokkaamisen jatkaminen voi aiheuttaa ristiriitoja. " Käyttäjä voi jatkaa, mutta tietää riskin.
Suunnittelun ongelmista ja ratkaisuista on helppo kirjoittaa loputtomasti, mutta ennen kuin pääsemme liian kauas työkaluista, joita meidän on käytettävä, voi olla hyödyllistä nähdä, millaista on rakentaa offline-ensimmäinen mobiilisovellus.
Rakenna offline-ensimmäinen sovellus Realmilla
Perus offline-ensin -sovelluksen arkkitehtuuri ei ole hieno. Tarvitset tavan säilyttää sovelluksen tiedot (laitteen tietokannan avulla), yhteyskäytäntö palvelimen kanssa (mukaan lukien tarvittaessa sarjallisuus- ja deserialisointikoodi) ja palvelin, jossa synkronoidut tiedot elävät, jotta ne voidaan jaetaan kenelle tahansa lupa.
Ensinnäkin opastan sinut aloittamaan Realm Mobile -tietokannan käytön iOS-sovelluksessa (vaikka koodi ei näyttäisi paljon erilaiselta Android-sovelluksessa). Sitten esittelen strategian palvelimelta saamiesi ja paikalliseen Realm-tietokantaan tallennettujen koodien sarjoitukseen ja esivalinnan poistamiseen. Lopuksi näytän sinulle, miten saat kaiken toimimaan yhdessä reaaliajassa synkronoitavassa tehtäväluettelosovelluksessa.
Realm Mobile -tietokanta
Realmin käytön aloittaminen on helppoa. Asennat Realm Mobile -tietokannan ja määrität sitten mallisi luomalla luokkia. Koska Realm on objektitietokanta, se on todella yhtä yksinkertaista kuin luokkien luominen, joidenkin objektien ilmentäminen ja näiden objektien siirtäminen kirjoittaa estäksesi ne levylle. Sarjausta tai ORM: ää ei tarvita, ja se on nopeampi kuin Applen perustiedot.
Tässä on mallimme ydin ja yksinkertaisin mahdollinen tehtäväluettelosovellus (joka sinun on käännettävä uudelleen aina, kun haluat tehdä uuden tehtävän):
tuo RealmSwift
luokan tehtävä: objekti {
dynaaminen muuttujan nimi
}
class TaskList: Object {
anna tehtävien = Luettelo ()
}
anna myTask = Tehtävä ()
myTask.task
anna myTaskList = Tehtävälista ()
myTaskList.tasks.append (myTask)
anna valtakunta = Realm ()
yrittää! realm.write {
realm.add ([myTask, myTaskList])
}
Sieltä ei tarvitse paljon rakentaa tehokkaamman sovelluksen ympärille TableViewController:
tuoda UIKit
tuo RealmSwift
class TaskListTableViewController: UITableViewController {
var valtakunta = kokeile! Valtakunta()
var taskList = Tehtävälista ()
ohita func viewDidLoad () {
super.viewDidLoad ()
tulosta (Realm.Configuration.defaultConfiguration.fileURL!) // Tässä voit korvata self.taskList aiemmin tallennetulla TaskList-objektilla yrittää! realm.write { realm.add (self.taskList) } // lisää navbar +
navigationItem.setRightBarButton (UIBarButtonItem.init (barButtonSystemItem: UIBarButtonSystemItem.add, target: self, action: #selector (displayTaskAlert)), animoitu: false)
}
func displayTaskAlert () {
// tee ja näytä hälytys, joka ottaa nimen ja tekee tehtävän.
anna hälytys = UIAlertController (otsikko: "Tee tehtävä", viesti: "Mitä haluat kutsua sille?", PreferredStyle: UIAlertControllerStyle.alert)
alert.addTextField (configurationHandler: nolla)
alert.addAction (UIAlertAction (nimi: "Peruuta", tyyli: UIAlertActionStyle.cancel, käsittelijä: nolla))
alert.addAction (UIAlertAction (otsikko: "Luo tehtävä", tyyli: UIAlertActionStyle.default, käsittelijä: {(action)
anna tehtävä = Tehtävä ()
task.name = (hälytys.tekstiKentät? [0] .teksti)!
yrittää! self.realm.write {
self.realm.add (tehtävä)
self.taskList.tasks.append (tehtävä)
}
self.tableView.reloadData ()
}))
itse. läsnä (hälytys, animoitu: tosi, täydennys: nolla)
} ohita funktio didReceiveMemoryWarning () { super.didReceiveMemoryWarning () } ohita funktion numeroOfSections (taulukonView: UITableView) -> Int { paluu 1 } ohita func tableView (_ tableView: UITableView, numberOfRowsInSection-osio: Int) -> Int { palauta self.taskList.tasks.count } ohita func tableView (_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { anna solun = tableView.dequeueReusableCell (withIdentifier: "reuseIdentifier", for: indexPath) cell.textLabel? .text = self.taskList.tasks [indexPath.row] .nimi paluu solu }}
Se on kaikki mitä tarvitset aloittamiseen! Realmin kokoelma- ja objekti-ilmoitusten avulla voit saada paljon älykkäämpiä, joten voit ladata älykkäästi älykkäästi tableView kun objekti lisätään tai poistetaan, mutta toistaiseksi meillä on pysyvyys - offline-ensimmäisen sovelluksen perusta.
Sarjallisuus ja deserialisaatio
Offline-ensin -sovellus ei ole paljoa offline-ensin -sovellus, ellei se voi myös siirtyä verkkoon, ja tietojen saaminen Realmiin ja sieltä voi olla hieman hankalaa.
Ensinnäkin asiakasmallin sovittaminen lähelle palvelimen mallia on ratkaisevan tärkeää. Ottaen huomioon, kuinka useimmat taustatietokannat toimivat, siihen liittyy todennäköisesti ensisijaisen avainkentän lisääminen Realm-luokkaan, koska Realm-objekteilla ei ole oletusarvoisesti ensisijaista avainta.
Kun skeema on sovitettu hyvin yhteen, tarvitset tavan deserialisoida palvelimelta tulevat tiedot Realm-alueelle ja sarjoittaa tiedot JSON-tiedostoksi lähettääksesi palvelimelle. Helpoin tapa tehdä se on valita suosikkikarttakirjastosi ja antaa sen suorittaa raskas nosto. Swiftillä on Argo, Decodable, ObjectMapper ja Mapper. Nyt kun saat vastauksen palvelimeltasi, annat mallikarttajan purkaa sen alkuperäiseksi RealmObjectiksi.
Silti se ei ole niin hieno ratkaisu. Sinun on vielä kirjoitettava tonnia verkkokoodia saadaksesi JSON: n palvelimellesi ja palvelimeltasi turvallisesti ensinnäkin, ja mallikarttakoodisi tarvitsee uudelleenkirjoittamisen ja virheenkorjauksen aina, kun skeema muuttuu. Paremman tavan pitäisi olla, ja mielestämme Realm Mobile Platform on juuri se.
Työskentely Realm Mobile -alustan kanssa
Realm Mobile Platform (RMP) antaa sinulle reaaliaikaisen synkronoinnin, jotta voit keskittyä mobiilisovelluksen rakentamiseen, ei taistelemaan palvelimen ja sovelluksen saamiseksi puhumaan. Sinun tarvitsee vain ottaa yllä oleva Realm-mallisi, lisätä RMP: n käyttäjän todennus ja antaa RMP: n huolehtia tietojen synkronoinnista palvelimen ja sovelluksesi alueiden välillä. Sitten jatkat työskentelyä alkuperäisten Swift-objektien kanssa.
Aloita lataamalla ja asentamalla Realm Mobile Platform MacOS -paketti, jonka avulla saat Realm Object Server -esiintymän Maciin todella nopeasti. Sitten lisätään muutama kohde tehtäväluettelosovellukseemme, jotta se voidaan muodostaa yhteys Realm Object Server -palvelimeen.
Kun olet noudattanut yllä olevia asennusohjeita, palvelimen on oltava käynnissä ja järjestelmänvalvojan käyttäjä osoitteessa //127.0.0.1:9080. Muista nämä tunnistetiedot, niin palaamme Swift-koodiin.
Ennen kuin kirjoitamme lisää koodia, meidän on tehtävä kaksi pientä muutosta projektiin. Ensin meidän on mentävä sovelluksemme kohdeditoriin Xcodessa ja Ota ominaisuudet-välilehdessä käyttöön Avainnipun jakaminen -kytkin.
Sitten meidän on sallittava muut kuin TLS-verkkopyynnöt. Siirry projektin Info.plist-tiedostoon ja lisää seuraava Tunnisteet:
NSAppTransportSecurity
NSAllowsArbitraryLoads
