Alexander Stigsen je spoluzakladatel a generální ředitel společnosti Realm.
Je všeobecně uznávanou pravdou, že uživatel, který má smartphone, musí mít lepší spojení. Navzdory investicím do infrastruktury v řádu miliard dolarů a neúnavným technologickým inovacím nezabere podstatnou realitu propojené éry nic víc než krátkou jízdu: Nemůžete předpokládat, že síťové připojení bude k dispozici, kdykoli budete chtít. Jako mobilní vývojáři je pravda, kterou je vhodné ignorovat.
Stavy offline v aplikacích mohou být matoucí, ale problém začíná základním a nesprávným předpokladem - že offline je ve výchozím nastavení chybový stav. To dávalo smysl, když jsme vytvářeli aplikace pro stolní počítače s vyhrazenými ethernetovými uplinky. Nemá smysl, když zavření dveří výtahu způsobí, že aplikace bude zcela k ničemu, nebo když je rozumné očekávat, že vaše aplikace bude použita na místech, kde chybí spolehlivá mobilní infrastruktura.
Nemůžeme pokrývat svět pokrytím, takže musíme nabídnout alternativu. Nejprve musíme myslet offline. Musíme navrhovat aplikace, aby byly užitečné offline. Musíme vytvářet aplikace, které plně využívají výhod internetu, pokud je k dispozici, ale musíme si uvědomit, že přístup k internetu je vždy dočasný. Musíme dělat inteligentní designová rozhodnutí zahrnující offline stavy a zajistit, aby tyto offline stavy byly pro uživatele srozumitelné.
Spousta práce se vynakládá na definování budoucnosti offline. Realm, společnost, kde pracuji, již nějakou dobu buduje platformu v reálném čase pro mobilní aplikace, které jsou první v režimu offline. Naše mobilní databáze a mobilní platforma Realm usnadňují vytváření inteligentních offline aplikací téměř na jakémkoli mobilním zařízení. Lidé v A List Apart enormně přispěli k první offline literatuře, zejména pro webové aplikace. A vývojářské komunity hlavních mobilních ekosystémů strávily mnoho hodin nabízením působivých vlastních řešení open source.
Následuje stručný úvod do toho, jak můžete vytvořit mobilní aplikaci, která je první offline. Nakonec nakreslím několik jednoduchých ukázkových kódů Swift, abych ukázal, jak vypadá minimální offline aplikace, ale zde nabízené principy a problémy jsou relevantní pro každého, kdo pracuje na vývoji mobilních aplikací.
Design pro offline
Než vytvoříte první offline aplikaci, kterou jste vždy chtěli, musíme se znovu podívat na designová řešení, která měla smysl pro stolní počítače s velmi vysokou pravděpodobností online. Pokud vaše aplikace dokáže zpracovat offline a online stavy, máme otázky k zodpovězení toho, co dokáže a jak ukážeme uživateli, co je možné.
Definujte, co je možné offline
Vezměme si jako příklad Twitter. Pokud jste offline a zveřejňujete tweet, mohl by se klient Twitteru, který je první v režimu offline, vydat dvěma cestami. Mohlo by to zařadit do fronty tweet, dokud nezískalo konektivitu. Nebo by vás mohlo odmítnout nechat tweetovat - i když vám to umožní zařadit do fronty další akce, například oblíbené, jako to dělá Tweetbot.
Proč by vám Tweetbot zabránil tweetovat offline? Možná proto, že v době, kdy se vrátíte zpět online, vaše tweety už nemusí být relevantní. Řešení tohoto problému by zahrnovalo vytvoření nového uživatelského rozhraní pro seznam tweetů, které jste dosud nezveřejnili, ale které možná budete muset upravit nebo smazat, než se připojí online. Na druhou stranu, pokud jste slyšeli tweet, je nepravděpodobné, že byste jej zrušili, pokud budete konfrontováni s více informacemi - a mnohem méně problematické jednoduše naznačit, že je ve frontě na zveřejnění příspěvku.
Offline aplikaci nemůžete udělat vše, co online aplikace může, ale můžete to udělat užitečným.
Navrhněte konflikty
Bez ohledu na strategii, kterou na zadní straně používáte k sladění změn, bude vaše aplikace čelit bodu, kdy máte dvě konfliktní data. Možná je to proto, že došlo k selhání serveru, nebo proto, že jste vy a jiná osoba provedli změny offline a nyní je chcete synchronizovat. Může se stát cokoliv!
Předvídejte tedy konflikty a snažte se je řešit předvídatelným způsobem. Nabídka možností. A snažte se především vyhnout konfliktům.
Být předvídatelný znamená, že vaši uživatelé vědí, co se může stát. Pokud může dojít ke konfliktu, když uživatelé upravují na dvou místech najednou, když jsou offline, měli by na to být upozorněni, když jsou offline.
Nabídka možností znamená nejen jednoduše přijmout poslední zápis nebo zřetězit změny nebo odstranit nejstarší kopii. Znamená to nechat uživatele rozhodnout, co je vhodné.
Konečně nejlepším řešením je nikdy nenechat konflikty na prvním místě. Možná to znamená sestavení aplikace tak, aby nová a podivná data z mnoha zdrojů nevedla ke konfliktu a místo toho se zobrazovala přesně tak, jak byste chtěli. To může být těžké udělat v psací aplikaci, která jde online a offline, ale sdílená aplikace pro kreslení může být navržena tak, aby přidávala nové cesty do výkresu, kdykoli se synchronizují.
Buďte explicitní
Jedna věc je definovat, co může uživatel dělat offline. Celkem další problém spočívá v tom, aby tato rozhodnutí byla pro vaše uživatele srozumitelná. Pokud se vám nepodaří úspěšně sdělit stav vašich dat a připojení nebo dostupnost daných funkcí, to se rovná selhání v tom, že jste na prvním místě vytvořili první offline aplikaci.
Problém ilustruje sdílená aplikace pro psaní poznámek. Pokud přejdete do režimu offline, ale očekáváte, že spolupracovníci budou pokračovat v úpravách aplikace i ve vaší nepřítomnosti, nestačí jednoduše umožnit uživateli pokračovat v psaní, dokud nebude spokojený. Když se znovu připojí, budou překvapeni vzniklými konflikty.
Místo toho pomozte svému uživateli učinit správné rozhodnutí. Pokud zjistíte, že vaše připojení k serveru bylo přerušeno, protože horní lišta aplikace mění barvu, víte, co by mohlo přijít: konflikty sloučení! To může být většinou v pořádku a uživatelské rozhraní vaší aplikace může pomoci napravit neočekávané konflikty, když se vrátíte zpět online. Pokud ale při úpravě aplikace více lidí ztratíte konektivitu, nebylo by užitečné vědět, že riziko konfliktů je mnohem větší? "Ztratil jsi spojení, ale ostatní upravovali." Pokračování v úpravách by mohlo způsobit konflikty. “ Uživatel může pokračovat, ale zná riziko.
Je snadné do nekonečna psát o problémech a řešeních týkajících se designu, ale než se dostaneme příliš daleko od nástrojů, které budeme muset použít, mohlo by být užitečné zjistit, jaké to je vytvořit mobilní aplikaci první offline.
Vytvořte si offline aplikaci s Realm
Architektura základní offline aplikace není fantastická. Potřebujete způsob, jak přetrvávat data v aplikaci (pomocí databáze v zařízení), protokol pro komunikaci se serverem (v případě potřeby včetně kódu pro serializaci a deserializaci) a server, kde budou synchronizovaná data žít, aby mohla být distribuován komukoli, kdo má svolení.
Nejprve vás provedu tím, jak začít s mobilní databází Realm v aplikaci pro iOS (ačkoli by se kód v aplikaci pro Android příliš nelišil). Poté představím strategii pro serializaci a deserializaci kódu, který získáte ze serveru a uložíte do místní databáze Realm. Nakonec vám ukážu, jak to vše zajistit společně v aplikaci pro seznam úkolů, která se synchronizuje v reálném čase.
Realm Mobile Database
Je snadné začít s Realm. Nainstalujete si Realm Mobile Database a poté definujete své schéma vytvořením tříd. Protože Realm je databáze objektů, je to opravdu tak jednoduché jako vytváření tříd, vytváření instancí některých objektů a předávání těchto objektů do a napsat blok je přetrvávat na disk. Není vyžadována žádná serializace ani ORM, navíc je rychlejší než Core Data společnosti Apple.
Tady je jádro našeho modelu a nejzákladnější možná seznam úkolů (kterou musíte překompilovat pokaždé, když chcete vytvořit nový úkol):
importovat RealmSwift
třída Úkol: Objekt {
název dynamické var
}
třída TaskList: Object {
let tasks = List ()
}
nech myTask = Task ()
myTask.task
nech myTaskList = TaskList ()
myTaskList.tasks.append (myTask)
let realm = Realm ()
Snaž se! realm.write {
realm.add ([myTask, myTaskList])
}
Odtamtud už netrvá moc, abychom vytvořili plně funkční aplikaci kolem a TableViewController:
importovat UIKit
importovat RealmSwift
třída TaskListTableViewController: UITableViewController {
var realm = vyzkoušet! Oblast()
var taskList = TaskList ()
přepsat func viewDidLoad () {
super.viewDidLoad ()
tisk (Realm.Configuration.defaultConfiguration.fileURL!) // Zde můžete nahradit self.taskList dříve uloženým objektem TaskList Snaž se! realm.write { realm.add (self.taskList) } // přidat navbar +
navigationItem.setRightBarButton (UIBarButtonItem.init (barButtonSystemItem: UIBarButtonSystemItem.add, target: self, action: #selector (displayTaskAlert)), animated: false)
}
func displayTaskAlert () {
// vytvořit a zobrazit upozornění, které vezme jméno a vytvoří úkol.
let alert = UIAlertController (název: „Provést úkol“, zpráva: „Jak jej chcete nazvat?“, preferovaný styl: UIAlertControllerStyle.alert)
alert.addTextField (configurationHandler: nil)
alert.addAction (UIAlertAction (název: „Zrušit“, styl: UIAlertActionStyle.cancel, obslužný program: nil))
alert.addAction (UIAlertAction (název: „Vytvořit úkol“, styl: UIAlertActionStyle.default, obslužná rutina: {(akce) v
let task = Task ()
task.name = (alert.textFields? [0] .text)!
Snaž se! self.realm.write {
self.realm.add (úkol)
self.taskList.tasks.append (úkol)
}
self.tableView.reloadData ()
}))
self.present (upozornění, animované: true, dokončení: žádné)
} přepsat funkci didReceiveMemoryWarning () { super.didReceiveMemoryWarning () } přepsat func numberOfSections (in tableView: UITableView) -> Int { návrat 1 } přepsat func tableView (_ tableView: UITableView, numberOfRowsInSection sekce: Int) -> Int { vrátit self.taskList.tasks.count } přepsat func tableView (_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell (withIdentifier: “reuseIdentifier”, pro: indexPath) cell.textLabel? .text = self.taskList.tasks [indexPath.row] .name návratová buňka }}
To je vše, co potřebujete, abyste mohli začít! Díky realmské sbírce a oznámení o objektech můžete být mnohem chytřejší, abyste mohli inteligentně znovu načíst tableView když je objekt přidán nebo odstraněn, ale zatím máme vytrvalost - základ offline offline aplikace.
Serializace a deserializace
Offline-first aplikace není moc offline-first aplikace, pokud se také nemůže připojit online, a získávání dat do a z Realmu může být trochu složité.
Nejprve je zásadní sladit klientské schéma se schématem vašeho serveru. Vzhledem k tomu, jak funguje většina back-endových databází, bude to pravděpodobně zahrnovat přidání pole primárního klíče do vaší třídy Realmu, protože objekty Realmu ve výchozím nastavení nemají primární klíč.
Jakmile budete mít své schéma dobře uzavřeno, potřebujete způsob deserializace dat přicházejících ze serveru do Realmu a serializaci dat do JSON a jejich odeslání zpět na server. Nejjednodušší způsob, jak to udělat, je vybrat si svou oblíbenou knihovnu mapování modelů a nechat ji dělat těžké zvedání. Swift má Argo, Decodable, ObjectMapper a Mapper. Nyní, když dostanete odpověď ze svého serveru, jednoduše necháte mapovač modelu dekódovat ji do nativního RealmObject.
Přesto to není tak skvělé řešení. Stále musíte napsat spoustu síťového kódu, abyste mohli bezpečně dostat JSON na server a ze serveru, a váš model mapovacího kódu bude potřebovat přepis a ladění kdykoli se změní vaše schéma. Měl by existovat lepší způsob a myslíme si, že Realm Mobile Platform je přesně to.
Práce s mobilní platformou Realm
Realm Mobile Platform (RMP) vám poskytuje synchronizaci v reálném čase, abyste se mohli soustředit na vytváření mobilní aplikace a ne bojovat za to, aby server a aplikace mohly mluvit. Jednoduše si vezmete svůj model Realm výše, přidáte ověřování uživatelů RMP a necháte RMP postarat se o synchronizaci dat mezi serverem a sféry vaší aplikace. Pak jednoduše pokračujete v práci s nativními objekty Swift.
Nejprve si stáhněte a nainstalujte balíček Realm Mobile Platform MacOS, který vám umožní rychle spustit instanci Realm Object Server na vašem Macu. Poté přidáme několik položek do naší aplikace seznam úkolů, abychom se připojili k Realm Object Server.
Jakmile dokončíte postupování podle výše uvedených pokynů k instalaci, měli byste mít spuštěný server a uživatele správce na adrese //127.0.0.1:9080. Pamatujte si tato pověření a my se vrátíme k našemu kódu Swift.
Než napíšeme další kód, musíme v projektu provést dvě drobné změny. Nejprve musíme přejít do cílového editoru naší aplikace v Xcode a na kartě Možnosti povolit přepínač Sdílení klíčenky.
Poté budeme muset povolit síťové požadavky jiné než TLS. Přejít na soubor Info.plist projektu a přidat následující uvnitř tagy:
NSAppTransportSecurity
NSAllowsArbitraryLoads
