Jak jsem slíbil, dnes se podíváme na praktické použití. Jako příklad nám poslouží 2 třídy, jež jsem programoval nějaký čas zpátky. Třída “DatCore.cs“ a třída “SyncHandler.cs“. Tyto 2 třídy slouží v aplikaci pro cloudové poznámky (synchronizace mezi zařízeními s Windows 8.1). V DatCore nalezneme veškerou potřebnou algoritmizaci a SyncHandler je jen pomocná třída pro řešení (jak název napovídá) kolizí apod. Třídy jsou ke stažení zde.
Začněme třídou SyncHandler, která dědí od IMobileServiceSyncHandler interface. Vidíme v ní dva “virtual“ Tasky. Virtuální protože to dovoluje Entity Frameworku například tzv. lazy loading a zefektivňuje sledování změn. Na začátku si můžeme povšimnout třech globálních proměnných. Dva stringy a náš MobileServiceClient, jež inicializujeme a deklarujeme v App.xaml.cs
(MobileServiceClient NasKlient = new MobileServiceClient("https://projekt.azure-mobile.net/", "AppKey"); )
ve třídě SyncHandler ho jen přebíráme a pracujeme s ním jako s odkazem (předání objektu v konstruktoru třídy). Dále veřejný, “virtual Task <JObject> OnPushCompleteAsync“ a privátní “async Task<IUICommand> ShowConflictDialog“, které předpokládám, není třeba vysvětlovat. Co nás zajímá nejvíce je veřejný “virtual async Task<JObject> ExecuteTableOperationAsync“. Tento task je to, co nám konflikty řeší. Tady si můžeme přizpůsobit chování algoritmu v případě, že se naskytne nějaký konflikt například, nebo můžeme (tak jak je to v tomto případě) dát na výběr uživateli (ve většině případů preferovaný postup).
To by byla tedy kompletní třída SyncHandler, nyní se můžeme posunout ke tříde DatCore. Ta je mnou vytvořená třída, obstarávající algoritmus v pozadí, tedy takové jádro, core. Na začátku můžeme opět vidět dvě globální proměnné, naší tabulku a datovou kolekci objektů typu Table, tedy veškerý obsah z tabulky v jednom “listu“. Dále máme region s veřejnými metodami, které nám slouží k: počáteční inicializaci, obnově kolekce, či přidání / smazání / editace záznamu.
Dále region s našemi Tasks. Zde můžeme vydět logiku přidávání / mazání / editace položek, či obnovu kolekce již v privátní podobě. Pozastavíme se nad Taskem “RefreshNoteItems“. Zde se inicializují naše _items. Protože nepotřebujeme vytvořit list položek z databáze všech uživatelů, filtrujeme výběr tzv. výrazem λ (lambda) jen na položky s ID našeho uživatele.
Další region nám řeší offline synchronizaci. Máme tu task, který inicializuje naší lokální databázi, ve kterém i přiřazujeme naší SyncHandler třídu pro řešení konfliktů synchronizace. A task synchronizace, ve které nejdříve provedeme push a po sléze pull.
Toť k dnešnímu dílu vše. Doufám, že se mi podařilo alespoň někomu vnést trochu světla do algoritmizace synchronizace cloudového backendu Azure M.S. a těším se na vaše ohlasy. Pokud něco potřebuje ještě víc osvětlení, nebo máte připomínky jakéhokoliv typu, nebojte se ozvat. Uvítám i kritiku a popřípadě článek ještě doupravím.
V příštím, posledním díle se můžeme těšit na shrnutí a pár připomínek / prohlášení, které bych ještě rád udělal (popřípadě pokud bude třeba obsáhlejší vysvětlení).
Rád bych také připomenul, že tato mini-série nemá sloužit jako návod k implementaci. Od toho tu jsou oficiální zdroje Azure (link v prvním dílu).
Budu se těšit a jako vždy přeji hodně štěstí a málo bugů! :)