1 2 Tartalomjegyzék Bevezető... 1 A probléma aszinkronitás... 1 Mi az az Observable?... 1 Mi az a LINQ?... 3 LINQ vs Rx... 8 Hello Rx... 9 Előkészület...
Tartalomjegyzék Bevezető....................................................................................................................................... 1 A probléma – aszinkronitás ............................................................................................................................... 1 Mi az az Observable? ........................................................................................................................................... 1 Mi az a LINQ? ......................................................................................................................................................... 3 LINQ vs Rx................................................................................................................................................................ 8
Bevezető A probléma – aszinkronitás Modern alkalmazások fejlesztésénél (legyen az vékony- vagy vastagkliens, vagy kiszolgáló oldali szoftver) egy bizonyos ponton mindenképpen elérjük a szinkron módon futó kód korlátait – ekkor kerülünk szembe az aszinkron és eseményvezérelt programozás nehézségeivel. Ha az alkalmazás megfelelő minőségének megőrzése érdekében az I/O műveleteket, webszolgáltatás-hívásokat, vagy épp egyéb erőforrás igényes műveleteket aszinkron módon kezeljük, a kód lényegesen bonyolultabbá válik. A megszokottól eltérő módszereket kell használnunk a koordinációra, a kivételkezelésre, és felvetődik a megszakíthatóság, valamint a párhuzamosan futó aszinkron feladatok szinkronizációjának problémája is. A Reactive Extensions (a továbbiakban Rx) egy olyan osztálykönyvtár, melynek segítségével aszinkron és/vagy eseményvezérelt programot készíthetünk úgy, hogy az adatfolyamot úgynevezett megfigyelhető (Observable) szekvenciaként reprezentáljuk, melyen LINQ-jellegű műveleteket hajthatunk végre úgy, hogy az esetleges versenyhelyzeteket úgynevezett ütemezőkkel (Scheduler) oldjuk fel. Röviden: Rx = Observables + LINQ + Schedulers
Mi az az Observable? Ahhoz, hogy eljussunk az Observable fogalmáig, meg kell ismerkednünk az előtte lévő két lépcsőfokkal: a szinkron és az aszinkron programozás fogalmával. Az esetek túlnyomó részében a kódunk “lényegi része” úgynevezett szinkron kód. Azaz olyan utasítások, melyek sorban egymást követve hajtódnak végre. Kiadunk egy utasítást, elvégzi a processzor, majd mikor végzett (ez a fontos része a dolognak) továbblép a következő utasításra, és így tovább. A hagyományos konzol alkalmazások tipikusan szinkron utasításokat tartalmaztak olyannyira, hogy ha épp olyan pontjához értünk az alkalmazásnak, hogy a felhasználótól vártunk valamilyen adatbevitelre, akkor amíg a felhasználó nem írt be valamit, addig az egész program állt egy helyben. Ezzel ellentétben az aszinkronitás alapvetően azt jelenti, hogy valami olyan esemény hatására akarunk műveletet végezni, amiről nem tudjuk, hogy pontosan mikor fog bekövetkezni. 1
Ilyen például egy felhasználói felületre kihelyezett gomb Click eseménye, de ilyen például egy webszolgáltatás-hívás visszatérési értéke is. Ez utóbbi esetben ugyan elképzelhető, hogy az utasítások sorrendje szempontjából pontosan tudjuk, hogy az után akarunk bármit is csinálni, miután a szervizhívásnak visszakaptuk az eredményét, azonban itt számolni kell azzal, hogy ez akár másodpercekbe is kerülhet és ha ez szinkron módon lenne megírva, akkor annak a szálnak a végrehajtása ami elindította a szervizhívást addig nem lépne tovább, amíg a szervizhívás vissza nem tér, azaz az a szál blokkolva lenne. Ez pedig különösen kellemetlenül tudja érinteni a felhasználót, ha a UI szálon történik, mert akkor bizony amíg a hívás nem tér vissza, addig az alkalmazás “megfagy”, válaszképtelenné válik. Tehát annak érdekében, hogy ez ne történjen meg, aszinkron hívást fogunk használni, mely azt jelenti, hogy elindítjuk a hívást, a hívás lényegi része egy külön szálon fut (vagy vár), majd mikor megvan az eredmény értesít egy eseményen keresztül. Ilyenkor a hívás elindítása után rögtön folytatódik az eredeti (hívó) szálon az utasítások végrehajtása, az eredménnyel dolgozó kódunk pedig belekerül a CallBack metódusba vagy Completed eseménykezelőbe. Szerencsére a Microsoft ez utóbbi problémát lényegesen leegyszerűsítette a C# 5.0-ban azzal, hogy bevezette az async és await kulcsszavakat, melyek segítségével úgy tudunk aszinkron hívásokat írni, mintha csak szinkron hívások lennének. Ugyan rengeteg (egyszerű) szituációban ez megkönnyíti az életünket, de amint szeretnénk egy “AutoRetry”, “Timeout”, vagy épp “Paging” funkcionalitást adni egy webszolgáltatás-híváshoz, rögtön állhatunk neki kódolni, mert ez ellen már nem véd meg az, ha elrejtik előlünk a CallBack metódusok megírását. Az eseményeknek azonban van egy komoly problémája, mégpedig, hogy nem „megfoghatóak” és egy adott eseményre feliratkozott „figyelők” nyomonkövetése sem triviális. Ezen segít az Observer design pattern azzal, hogy lényegében explicit módon leimplementálja az eseménykezelést. Ezzel azonban sokkal nagyobb kontrollt kapunk a folyamatban, és ami még fontosabb (később meglátjuk miért), „megfoghatóvá” teszi az eseményeket. Ez a programozási minta alapvetően két interfészből áll. Az egyik az IObservable, mely egy „megfigyelhető” adatforrást reprezentál. Ez az interfész mindösszesen egy Subscribe() metódust definiál, ami lényegében az „eseményes világ” += operátorának felel meg. A másik az IObserver, mely egy megfigyelőt reprezentál, amit átadhatunk egy adatforrásra való feliratkozáskor. Ennek az interfésznek az eredeti programozási minta szerint van egy Notify() metódusa, ezen keresztül értesíti az adatforrás a rá feliratkoztatott megfigyelőket. Rx esetében nem a „szabvány” implementációval kell dolgoznunk, hanem annak egy speciális változatával. Itt az IObserver interfész három metódust definiál, melyek az OnNext(), OnError() és az OnCompleted(). A legelső kerül meghívásra, ha egy új elem jelenik meg az adatfolyamban, a második, ha valami probléma történne, és az utolsó egy lezáró üzenet, melynek hatására a megfigyelés befejeződik, ezzel jelzi az adatforrás, hogy nem fog több értéket szolgáltatni.
2
Az Rx erre a két interfészre épül és ezeknek a segítségével tudja lényegesen leegyszerűsíteni a legkülönfélébb típusú aszinkron adatfolyamok kezelését. Annak érdekében, hogy megértsük miért, meg kell ismerni – legalább alap szinten – a LINQ-t.
Mi az a LINQ? A LINQ (Language Integrated Query) a .NET 3.5 óta könnyíti meg a fejlesztők életét [7][8][9], mikor oda kerül a sor, hogy valamilyen adathalmazzal kell dolgozni. Ez a technológia, illetve talán még inkább az általa bevezetett nyelvi elemek ültetik el a C# (illetve Visual Basic) nyelvben a funkcionális programozás csíráit. Nem megyek bele messzemenő részletekig, hogy mit is takar a funkcionális programozás azonban idéznék egy nagyon jó metaforát, melyet Luca Bolognese mondott a 2008-as PDC-n az F#-ról szóló előadásában. "Funkcionális programozásnál a jelszó az, hogy "mit" és nem az, hogy "hogyan". Erre egy nagyon jó példa, hogy ha bemegyünk egy bárba és kérünk egy kávét, akkor a pultosnak nem fogjuk megmondani, hogy őrölje meg a kávét, forralja fel a vizet, készítse elő a cukrot és a tejet, és tegye mindezt párhuzamosan, hanem csak egyszerűen kérünk egy kávét." Hogy egy kicsit komolyabb példán keresztül szemléltessem a gondolatmenetet, gondoljuk el, hogy hogyan oldanánk meg egy olyan feladatot, amiben egy számsorozatból kell kiválasztanunk a páros számokat, majd össze kell adni a kiválasztott számok négyzeteit? Nagy valószínűséggel első körben az 1-1 kódrészlethez hasonló megoldásra jutnánk.
3
1-1 kódrészlet: Páros számok négyzetének összege – első megközelítés List számok = new List(); számok.Add(1); számok.Add(2); számok.Add(3); számok.Add(4); számok.Add(5); számok.Add(6); számok.Add(7); számok.Add(8); számok.Add(9); számok.Add(10); int akkumulátor = 0; foreach (int szám in számok) { if (szám % 2 == 0) { akkumulátor += (szám * szám); } } return akkumulátor;
Mit lehet ezzel a konkrét kóddal tenni? Hogy tudnánk kicsit tömörebbre, átláthatóbbra varázsolni? Kezdjük például a számok létrehozásánál: 1-2 kódrészlet: Object Initializer var számok = new List() { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
Vegyük sorba milyen érdekességek vannak ebben a sorban. Kezdődik a var kulcsszóval. Mikor egy változót ezzel a kulcsszóval deklarálunk, akkor a fordító a deklaráció egyenlőségjele utáni kifejezésből deríti ki, hogy a változó milyen típusú. Jelen esetben, ha felé vinnénk az egeret, akkor mutatná is rögtön, hogy a számok változó List típusú. Ez a nyelv egy kényelmi kiterjesztése, bár a későbbiekben találkozni fogunk egy olyan képességgel, mely a var kulcsszó nélkül nem volna megvalósítható. Ha továbbmegyünk, egy érdekes szintaktikával találkozunk a példányosításnál. A sor nem ér véget a konstruktorhívással, hanem kapcsos zárójelek között megadjuk a lista elemeit is. Ezt nevezzük “Object Initializer” szintaktikának. Ugyan a példához nem tartozik hozzá, de ha az előző kettő nyelvi elemet összekombináljuk, akkor megkapjuk az úgynevezett névtelen típusokat. Gondoljunk bele abba a szituációba, amikor egy ciklus kellős közepén arra volna szükségünk, hogy egy átmeneti változóba több különböző információt is elmentsünk. A LINQ előtt ilyenkor jött az, hogy mindegyik részinformációnak létrehoztunk egy 4
változót és azokat használtuk ilyen jellegű átmeneti információk tárolására. Ha azonban névtelen típust használunk, megtehetjük, hogy egy ilyen kódot írunk: 1-3 kódrészlet: Névtelen típus var ember = new { Név = név, Életkor = kor };
Itt aztán nézheti a fordító a kifejezés jobb oldalát, nem fogja kitalálni abból sem a változó típusát. Ilyenkor valójában a színfalak mögött a fordító létrehoz egy típust az adott változónak, mely tartalmazza a megadott tulajdonságokat. Menjünk tovább az eredeti példa rövidítésén és tekintsük meg a következő lépést: 1-4 kódrészlet: Páros számok négyzetének összege – LINQ megközelítés return számok .Where(szám => szám % 2 == 0) .Select(szám => szám * szám) .Sum();
Ha kicsit visszalaolvasunk, akkor láthatjuk, hogy a számok változó egy int típusú lista. Hogyan tudunk rajta Where() metódust hívni, mikor nincs is olyan metódusa a List típusnak? Erre a kérdésre a választ az úgynevezett “Extension Method”-ok adják. Ha egy tetszőleges típushoz új funkcionalitást akarunk adni, akkor a triviális megoldás, hogy származtatunk belőle egy osztályt, majd abban definiáljuk az extra funkcionalitást. Ezzel azonban két probléma van. Egyrészről elképzelhető, hogy az eredeti típus sealed, azaz már eleve örököltetni sem tudunk belőle, de még ha ez a probléma nem is áll fenn, akkor is ott van az a kényelmetlen tény, hogy onnantól kezdve mindig a saját típusunkat kell használnunk, vagy konverziós metódusokat definiálnunk, mellyel műveletvégzés előtt az eredeti típusból a mi típusunkká alakítjuk az adatot, majd elvégezzük rajta a műveletet és végül a módosított adatot visszakonvertáljuk az eredeti típusba. Nem kell bonyolult dologra gondolni, elképzelhető, hogy van egy egyéni függvényünk string típusú adatok formázására. Amennyiben ezt a függvényt több helyen is fel akarjuk használni, akkor vagy kirakjuk egy statikus osztályba, vagy készítünk egy saját SuperString típust, mely tartalmazza ezt a függvényt. Ez utóbbit a konkrét példánál maradva pont nem tehetnénk meg, mert a String típus sealed, azaz nem lehet belőle örököltetni. Marad a statikus osztályos megoldás, de gondoljuk el, hogy nézne ki az a kód ahol esetleg megpróbálunk egymás után két ilyen függvényt is használni… Ezen probléma megoldására vezette be a Microsoft az Extension Methodokat, mellyel tetszőleges osztályhoz (sőt akár interfészhez is) definiálhatunk függvényeket a következő szignatúrával:
5
1-5 kódrészlet: Extension Method szignatúrája public static string SpecialFormat(this string s, int spaces)
Ezeket a függvényeket egy statikus osztályba kell beletennünk, és maguknak a függvényeknek is – a szignatúrájuk szerint – statikusnak kell lenniük. Ez után a varázslat az első paraméternél keresendő. A this kulcsszó után következő típus az, amit ki fogunk ezzel a metódussal terjeszteni. Ezt a metódust csak a kiterjesztett osztály egy példányán lehet meghívni, szóval a szignatúrájával ellentétben pont, hogy nem lesz statikus. Ezen példányra kapunk referenciát az s változó által. A metódus meghívásakor ez a paraméter nem fog látszódni a listában, csak az ez utáni paraméterek (esetünkben az spaces). Használata tehát a következőképpen fog kinézni: 1-6 kódrészlet: Extension Method használata defaultString.SpecialFormat(42);
A LINQ egy olyan mintát használ az extension method-jainál, amivel ezt egy szinttel magasabbra helyezi. Hogy az eredeti példánknál maradjunk, nézzük meg, hogy néz ki a Where() metódus szignatúrája: 1-7 kódrészlet: LINQ Where() Extension Method szignatúrája public static IEnumerable Where(this IEnumerable enumerable, Func predicate)
Az egyik, amit érdemes meglátni, hogy az IEnumerable interfészt terjeszti ki és a visszatérési értéke is ugyanilyen típusú. A LINQ szinte mindegyik operátorának szignatúrája így kezdődik, ez pedig azért jó, mert lehetővé teszi a kompozíciót, azaz, hogy az operátorokat tetszőleges hosszan egymás után fűzzük. Ez a jelenlegi példán is jól látszódik, bármiféle köztes változók bevezetése nélkül képesek voltunk egymás után fűzni a Where(), majd a Select() és végül a Sum() függvényeket. A másik jellemző dolog a LINQ operátorokkal kapcsolatban az, hogy a munka lényegi részét ránk bízzák. Ez azt jelenti, hogy például a Where() metódus tartalmazza azt a kódot, hogy végigmenjen a lista elemein, válassza ki valamilyen feltétel alapján, hogy melyik maradjon, melyik ne, és végül adja vissza az eredményül kapott szűrt listát, de egy részét nem tartalmazza a logikának, mégpedig a konkrét feltételvizsgálatot, hogy mi alapján menjen vagy maradjon egy elem. Pontosan ezen okból kifolyólag van a paraméterek között a Func delegált, mely egy olyan metódust reprezentál, ami megkapja a kollekció egy elemét paraméterül, majd csinál vele amit akar és visszaad egy bool értéket, hogy megfelelt, vagy nem felelt meg valamilyen feltételnek. 6
Ha tovább nézzük az eredeti példát, nem is kell sokat olvasnunk máris találunk egy igen érdekes kifejezést a Where() metódusnak (meg a Select()-nek is) paraméterül adva. 1-8 kódrészlet: Lambda kifejezés szám => szám % 2 == 0
Ezt nevezzük Lambda kifejezésnek, vagy névtelen metódusnak. Ezzel a kifejezéssel lehetőségünk van arra, hogy anélkül írjunk egy metódust, hogy írnánk egy metódust. Mint azt az imént említettem, nagyon sok olyan szituáció van, amikor egy metódus paraméterül vár egy delegáltat. Ilyenkor normál esetben azt csináljuk, hogy elkészítjük a szükséges metódust, majd átadjuk azt paraméterül a szóban forgó metódusnak. Ennél azonban lényegesen átláthatóbb lehetőséget nyújt a Lambda kifejezés, mellyel helyben tudjuk megadni a szükséges funkcionalitást. A Lambda kifejezések teljes szintaktikája a következőképpen néz ki: 1-9 kódrészlet: Lambda kifejezés „teljes pompájában” (param_1, param_2, param_n) => { ... return valami; };
A nyíl operátor (=>) előtt zárójelben, vesszővel elválasztva a kifejezés paraméterei, majd a nyíl után kapcsos zárójelek között a kifejezés törzse helyezkedik el. A paramétereknek azért nem kell típust írnunk, mert azt a fordító kitalálja abból, hogy milyen delegáltnak adjuk át a kifejezést. Amennyiben csak egy paraméter van, úgy a zárójel elhagyható, ha viszont nincs paraméter, akkor ki kell írnunk egy üres nyitó-csukó zárójelet. A törzs esetében is van egy rövidítési lehetőségünk. Amennyiben a névtelen metódus mindössze egyetlen sorból áll, amely kifejezésnek az eredménye egyben a visszatérési értéke is a metódusnak, akkor nincs szükség se kapcsos zárójelre, se return kulcsszóra. És persze ne feledkezzünk meg arról sem, hogy ha esetleg mégis megvolna az eredeti delegált szignatúrájának megfelelő metódus, akkor elegendő mindössze a metódus nevét átadnunk, nem kell olyan kifejezést írni, hogy Metodus(x => F(x)), hanem elegendő csak annyit írni, hogy Metodus(F). Végül pedig csupán puszta érdekességként megjegyezném, hogy párhuzamosítása, mindössze egyetlen extra operátor beszúrásából áll:
7
az
aktuális
példánk
1-10 kódrészlet: LINQ párhuzamosítás számok .AsParallel() .Where(szám => szám % 2 == 0) .Select(szám => szám * szám) .Sum();
Az AsParallel() operátornak köszönhetően a teljes lekérdezés párhuzamosan fog futni. Gondoljunk csak bele, ha ezt az újonnan felröppenő igényt az eredeti, hagyományos módon elkészített kódunkban kellene megoldani... A LINQ tehát ezeket a technológiákat és rengeteg előre definiált Extension Methodot jelent több különböző típuson, többek közt például az IEnumerable-n is, mely igazából ugye nem is osztály, hanem interfész, így azonban minden olyan osztály, ami megvalósítja ezt az interfészt, megkapja az extra metódusokat is. Ezen metódusok túlnyomó részének a visszatérési értéke is IEnumerable, azaz kényelmesen egymás után láncolható rengeteg ilyen operátor, melyek egy forráskollekciót szép sorjában egyenként valamilyen logika alapján átalakítanak, átrendeznek vagy szűrnek, majd továbbadják az eredményt a következő operátornak. A LINQ, mint arra utaltam is, nem csak az IEnumerable típushoz ad kiterjesztéseket, hanem egyéb adatforrásokhoz is, mint például relációs adatbázisok (LINQ to SQL) vagy XML dokumentumok (LINQ to XML) és még sok más. Amennyiben pedig az adatforrás történetesen aszinkron események sorozata, akkor eljutunk a LINQ to Events-hez, azaz a Reactive Extensions-höz.
LINQ vs Rx A LINQ meglévő kollekciókon tud dolgozni (konkrétan IEnumerable interfészt megvalósító típusokon) és mélyen az alapját az IEnumerable és IEnumerator interfészpáros adja. Vele ellentétben az Rx olyan adatfolyamokon dolgozik, melynek még nem áll rendelkezésre minden eleme és mélyen az alapját az IObservable és IObserver interfészpáros képzi. Míg a LINQ az úgynevezett “polling” technikával kérdezgeti az IEnumerator objektum MoveNext() metódusán keresztül a listában soron következő elemet, addig az Rx esetében “push” technikát alkalmazva az IObserver objektum OnNext() “eseménye” kerül meghívásra, ha egy új elem érkezik az adatfolyamba. Ugyanúgy, ahogy a LINQ valamilyen bemeneti kollekcióból különböző szelekciós, projekciós, csoportosító, összekapcsoló stb. operátorok használatával egy kimeneti kollekciót készít, az Rx valamilyen bemeneti adatfolyamot áttranszformálva egy kimeneti adatfolyamot készít. És végül, míg a LINQ az IEnumerable interfészhez nyújt kiegészítést, addig az Rx az IObservable-hez. 8
Hello Rx Előkészületek Ebben a fejezetben egy életszerűbb, de egyszerű példán keresztül fogom bemutatni, hogy mennyire megkönnyíti az életünket az Rx használata még az új async-await kulcsszavak mellett is. Egy keresőt fogunk készíteni, mely egy szimulált webszolgáltatással fog dolgozni. Az egyszerűség kedvéért nem egy valódi webszolgáltatáshoz fog kapcsolódni az alkalmazás, hanem egy statikus listából fog javaslatokat és találatokat szolgáltatni mesterséges késleltetéssel és véletlenszerű meghibásodással. Rakjuk össze az alkalmazás alapjait, hogy aztán már csak a lényegre kelljen koncentrálni. Töltsük le és telepítsük fel a legújabb us/download/details.aspx?id=30708 címről.
Rx-et
a
http://www.microsoft.com/en-
Nyissuk meg a Visual Studio 2012-t. Indítsunk egy új projektet (File | New Project), majd a felugró ablakban a baloldali sávban válasszuk ki a Visual C# szekción belül a Windows Store-t, jobboldalon pedig a Blank Application-t. Miután elneveztük a projektet, nyomjunk az Ok gombra. Ezzel van is üres alkalmazásunk. Adjuk hozzá a referenciákhoz az Rx-et. Ezt a Project | Add reference menüpontból tudjuk megtenni, a felugró ablakon belül baloldalt válasszuk a Windows fülön belül az Extensions menüpontot, majd rakjunk egy pipát a Reactive Extensions for Windows 8 mellé. Ezzel hozzá is adtuk az összes szükséges dll-t a referenciákhoz. Szerezzünk egy listát a leggyakrabban használt magyar szavakról – ezekből fogunk keresési javaslatokat komponálni. Egy ilyen lista található például a következő címen: http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists/Hungarian_frequency_list_1-10000. Dolgozzuk fel ezt a listát úgy, hogy eltűnjenek a sorok elejéről a sorszámok és minden sorban csak egy szó legyen! Az ehhez szükséges kód lényegi részét a 2-1-1 kódrészlet mutatja.
A következő lépés az ál-webszolgáltatás elkészítése. Két metódusra lesz szükség. Az egyik keresési javaslatokat fog generálni egy megadott szövegre úgy, hogy megpróbálja az utolsó szót az imént feldolgozott lista alapján valami értelmesre kiegészíteni. A másik metódus pedig statikusan visszaadja, hogy mire kerestünk a következő formában: „Erre kerestél {szöveg}” Az ezt a funkcionalitást megvalósító osztály alapját a 2-1-2 kódrészlet mutatja. 2-1-2 kódrészlet: Ál-webszolgáltatás alapja public class SearchService { private IEnumerable<string> _wordList; public SearchService() { Initialize(); } private async void Initialize() { var txtFile = await StorageFile .GetFileFromApplicationUriAsync(new Uri("ms-appx:///SearchEngine_Core/words.txt")); var txt = await FileIO.ReadTextAsync(txtFile); _wordList = txt.Split(new string[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries) .Select(x => x.ToLower()); } private async Task SimulateTimeOutAndFail() { // Simulating long time execution var random = new Random(); await Task.Delay(random.Next(300)); // Simulating failure if (random.Next(100) < 10) throw new Exception("Error!"); } }
10
Az Initialize() metódus felel azért, hogy a szövegfájl betöltődjön, és aztán készíthessünk belőle javaslatokat, a SimulateTimeOutAndFail() beszédes nevű metódus pedig egy webszolgáltatás viselkedését próbálja szimulálni a mesterséges késleltetéssel és a véletlenszerű meghibásodással. A következő lépés a két lényegi metódus elkészítése. A találatot adó metódus nagyon egyszerű lesz, csak vissza kell adnia az átadott szöveget megformázva (2-1-3 kódrészlet). 2-1-3 kódrészlet: Keresés eredményének visszaadása public async Task> GetResultsForQuery(string query) { await SimulateTimeOutAndFail(); return new string[] { "Erre kerestél: " + query}; }
A javaslatok szolgáltatása már egy fokkal trükkösebb, ezt a 2-1-4 kódrészlet mutatja. 2-1-4 kódrészlet: Keresési javaslatok nyújtása public async Task> GetSuggestionsForQuery(string query) { await SimulateTimeOutAndFail(); if (_wordList != null) { var wordsOfQuery = query.ToLower().Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); var lastWordOfQuery = wordsOfQuery.Last(); var suggestionsForLastWord = _wordList.Where(w => w.StartsWith(lastWordOfQuery)); var headOfQuery = ""; if (wordsOfQuery.Length > 1) headOfQuery = wordsOfQuery .Take(wordsOfQuery.Length - 1) .Aggregate((acc, curr) => acc + ' ' + curr); return suggestionsForLastWord.Select( s => headOfQuery + ' ' + s).Take(10); } else return Enumerable.Empty<string>(); }
11
Kicsomagoljuk a beírt szövegből az utolsó szót
Kikeressük a lehetséges javaslatokat erre – azokat a szavakat a hosszú listánkban, ami azzal a karakterlánccal kezdődik
Ez után összerakjuk az eredeti szöveget úgy, hogy az utolsó szót (amihez épp javaslatokat gyűjtöttük) kihagyjuk belőle
Utolsó lépésként pedig generálunk egy listát, ami a teljes szöveget tartalmazza az összes lehetséges végződéssel
Utolsó lépésként készítsük el az alkalmazás felületét. Helyezzünk el a felületen egy TextBox, egy Button, egy ListView és egy TextBlock vezérlőt és adjuk nekik rendre a SearchBox, SearchButton, Suggestions és ErrorLabel neveket. Ezt a 2-1-5 kódrészlet szemlélteti.
Ezzel meg is van az álszerviz osztály és a felület, most már koncentrálhatunk a lényegre. 13
Hagyományos megközelítés Most, hogy lehelyeztük az alkalmazás alapköveit, vegyük át, hogy mit szeretnénk megvalósítani. Szeretnénk, ha annak hatására, hogy beleír valamit a felhasználó a keresődobozba, elkezdene az alkalmazás nagy erőkkel keresési javaslatokat dobálni neki. Emellett pedig szeretnénk, ha a “Keress” gombra kattintva már egy “valódi” keresés “valódi” találatait adná vissza nekünk. Kis magyarázat az idézőjelekre: a weben található keresőmotorok nem a valódi lehetséges találatok alapján adnak keresési javaslatokat, a javaslatok a felhasználók által beírt kifejezésekből tevődnek össze, míg a találatok már valóban azok az oldalak, melyek a beírt kifejezést valamilyen formában tartalmazzák. Tehát attól még, hogy a kereső egy kifejezésre előhoz nekünk egy keresési javaslatot, az nem jelenti azt, hogy arra fog bármit is találni. Mivel nem egy bonyolult programról van szó, készítsük el a “hagyományos” módon az alkalmazást, és keressük meg benne a hibákat. Rakjuk bele az oldal konstruktorába a 2-2-1 kódrészletet, és próbáljuk ki működés közben. 2-2-1 kódrészlet: Feliratkozás a felület eseményeire SearchBox.TextChanged += async (s, e) => { var query = SearchBox.Text; var service = new SearchService(); var suggestions = await service.GetSuggestionsForQuery(query); Suggestions.ItemsSource = suggestions; }; SearchButton.Click += async (s, e) => { var query = SearchBox.Text; var service = new SearchService(); var results = await searchService.GetResultsForQuery(query); Suggestions.ItemsSource = results; };
Mi történik az alkalmazás futása közben? A véletlenszerű késleltetésnek köszönhetően valószínűleg pillanatok alatt szembetaláljuk magunkat azzal a helyzettel, hogy beírjuk, hogy “Buda”, de mivel minden egyes új karakter leütésekor kérünk az aktuális beírt szövegre keresési javaslatot – ami valamilyen késleltetéssel tér vissza – megeshet, hogy az első karakterhez (“B”) kapcsolódó javaslatok akkor jönnek meg, mikor már rég beírtuk, hogy “Buda”, így aztán nem azokat a szavakat fogjuk látni amik “Buda”-val kezdődnek, hanem azokat, amik “B”-vel. Emellett, ha ez valóban egy webszolgáltatás hívása lenne, akkor gyakorlatilag feleslegesen küldenénk iszonyatos mennyiségű lekérést a szolgáltatás felé minden egyes leütött karakter után. Ezzel felesleges 14
hálózati forgalmat generálunk, ami feleslegesen eszi a felhasználó akkumulátorát, processzorát és adott esetben a fizetős 3G adatforgalmát. Látván a problémákat (azoknak egy részét), gondoljuk át mire van szükségünk. Szeretnénk a szervizhívást hibabiztosra elkészíteni, azaz számolnunk kell azzal, hogy a szerveren történik valami hiba, vagy a kliensről nem tud kimenni a hívás, vagy túl hosszú ideig tart a művelet. Mindezt, annak érdekében, hogy hibatűrő legyen érdemes becsomagolni úgy, hogy akármilyen hiba is történik, próbálja újra a rendszer még kétszer (összesen maximum háromszor) a hívást. Jó volna, ha lenne egy kis fojtás a hívó oldalon, és nem küldenénk el egy-egy hívást minden egyes leütött karakter után, hanem csak akkor, ha már a felhasználó legalább fél másodperce nem nyomott le billentyűt. Az előzőhöz képest apró optimalizálás, de érdemes arra is figyelni, hogy ha valami okból kifolyólag kétszer egymásután ugyanarra a szövegre szeretne keresni, akkor feleslegesen ne küldjük el másodjára is a hívást. Ilyen akkor lehet, ha beírt valamit a felhasználó, várt egy keveset, beírt még valamit, de közben rájött, hogy mégsem az kell neki és visszatörölte az előző állapotig a beírt szöveget. A fentebb említett fojtás miatt lehet, hogy kétszer egymás után ugyanazt a szöveget kapnánk meg. Vagy egyszerűen csak remegő kézzel nyom a Keresés gombra vagy üt az Enter billentyűre és ezért véletlenül többször is elküldi a hívást. Végül pedig meg kell oldani a versenyhelyzet problémát, azaz, hogy biztosítsuk, hogy valóban mindig az utolsó hívás eredményét lássuk a képernyőn és ne történhessen meg, hogy egy korábban elküldött, de a szerveren hosszabb ideig tartó lekérdezés eredményét később visszakapva inkonzisztenciát okozzunk a felhasználónak, és olyan javaslatokat mutassunk, aminek már semmi köze nincs az éppen beírt keresendő szöveghez. Vegyük ezeket a problémákat egyesével, nézzük meg hogyan lehet megoldani őket, majd azt, hogy miképpen lehet összekombinálni őket.
Időtúllépés A C# 5.0-ban bevezetett await kulcsszónak köszönhetően olyan egyszerű, átlátható és rövid kódot tudunk aszinkron műveletekre írni, mintha csak szinkron kódot írnánk. A szervizhívás önmagában csupán egy sor… 2-2-2 kódrészlet: await kulcsszó használata aszinkron hívásnál var suggestions = await service.GetSuggestionsForQuery(query);
… ám amint egy kicsit bonyolultabb műveletet akarunk ezzel az aszinkron hívással végezni, kénytelenek vagyunk elhagyni ezt a kényelmet. Az időtúllépés logikát a legegyszerűbben a 2-2-3 kódrészlettel lehet megvalósítani: 15
2-2-3 kódrészlet: Időtúllépés implementációja public async Task> ServiceCall_Timeout(string query) { var newTask = service.GetSuggestionsForQuery(query); var timeoutTask = Task.Delay(500); var firstTaskToEnd = await Task.WhenAny(newTask, timeoutTask); if (newTask == firstTaskToEnd) return newTask.Result; else throw new Exception("Timeout"); }
Elindítjuk a saját szervizhívásunkat és egy egyszerű aszinkron késleltetést párhuzamosan, megvárjuk amíg valamelyik visszatér, majd leellenőrizzük, hogy a szervizhívás vagy az időzítő tért vissza, azaz, hogy a szervizhívás kifutott e az időből.
Újrapróbálás Bár az await kulcsszó megint sokat segít, de a komolyabb kódolás elkerülhetetlen. 2-2-4 kódrészlet: Újrapróbálás implementációja public async Task> ServiceCall_Retry(string query) { bool errorHappened = false; int tries = 0; IEnumerable<string> suggestions = null; do { errorHappened = false; try { suggestions = await service.GetSuggestionsForQuery(query); } catch { tries++; errorHappened = true; } } while (errorHappened == true && tries < 3); if (!errorHappened) return suggestions; else throw new Exception("Out of retries"); }
Mivel újrapróbálásról van szó, ezért a kiinduló gondolat az kell, hogy legyen, hogy valamilyen ciklust kell készíteni. Mivel értelemszerűen csak akkor kell újrapróbálni, ha valami probléma történt, viszonylag gyorsan leszűkül a kör a while ciklus használatára. Innentől kezdve ízlés kérdése, hogy az 16
elől vagy hátul tesztelő verziót használjuk, én az utóbbit választottam. Két feltétele van annak, hogy a ciklusban maradjunk. Az egyik, hogy valami hiba történjen a cikluson belül, a másik pedig, hogy még a megadott próbák száma alatt legyünk (jelenleg ez 3). A hibát egy try-catch blokkal elnyeljük és jelezzük a ciklusnak, hogy hiba történt és növeljük az próbálkozások számát. Érezhető, hogy ebből még nem tudunk tisztán következtetést levonni, mert azért is túljuthatunk a cikluson, mert nem történt probléma, és azért is, mert már háromszor is volt baj. Tehát le kell ellenőriznünk, hogy volt e hiba vagy nem. A fojtás, az egyezés vizsgálat és a versenyhelyzet kezelése már nem ilyen egyszerű feladat. Ezek szűrő jellegű műveletek, azaz különböző feltételektől függően elnyelnek bizonyos hívásokat. A fojtás például biztosítja, hogy egy gyors gépelésnél ne küldjünk hívást minden egyes billentyűleütésre, hanem csak akkor, ha már a felhasználó fél másodperce nem nyúlt a billentyűzethez. Az egyezés vizsgálat kiszűri az egymás után érkező azonos paraméterű hívásokat. A versenyhelyzet kezelés pedig biztosítja, hogy a korábbi, ám hosszú ideig tartó hívás eredménye már ne kerüljön felszínre, amikor van nála frissebb. Ezeknél a műveleteknél tehát egy olyan mintát fogunk követni, hogy lesz egy void metódus és mellette egy CallBack esemény, amiben az eredményeket kapjuk. Az eseményre csak egyszer fogunk feliratkozni, a metódust azonban értelemszerűen többször hívjuk meg.
Fojtás 2-2-5 kódrészlet: Fojtás implementációja private DateTime lastThrottledParameterDate; private int throttleInterval = 500; public event Action> CallBack_Throttle; public async void ServiceCall_Throttle(string query) { lastThrottledParameterDate = DateTime.Now; await Task.Delay(throttleInterval); if ((DateTime.Now - lastThrottledParameterDate).TotalMilliseconds < throttleInterval) return; var suggestions = await service.GetSuggestionsForQuery(query); if (CallBack_Throttle != null) CallBack_Throttle(suggestions); }
A metódus hívásakor elmentjük az aktuális időpontot, kivárjuk azt a bizonyos fél másodpercet, majd megvizsgáljuk, hogy az új aktuális időpont és a korábban elmentett között megvan e a fél másodperc 17
különbség, azaz, hogy nem hívták e meg idő közben a metódust még egyszer. Ha nem, akkor elküldjük a szervizhívást, majd az eredményével meghívjuk a CallBack eseményt.
Egyezés vizsgálat 2-2-6 kódrészlet: Egyezés vizsgálat implementációja private string lastDistinctParameter; public event Action> CallBack_Distinct; public async void ServiceCall_Distinct(string query) { if (lastDistinctParameter != query) lastDistinctParameter = query; else return; var suggestions = await service.GetSuggestionsForQuery(query); if (CallBack_Distinct != null) CallBack_Distinct(suggestions); }
Ennél a műveletnél egy, a tulajdonságok setterében is gyakran használt módszert alkalmazunk. A metódus hívásakor kimentjük a paraméterét egy globális változóba, majd a következő hívásnál ehhez hasonlítjuk az új paramétert és csak akkor engedjük végre a végrehajtást, ha különböznek.
Versenyhelyzet kezelése 2-2-7 kódrészlet: Versenyhelyzet kezelésének egy lehetséges implementációja private Task> lastCall; public event Action> CallBack_RaceCondition; public async void ServiceCall_RaceCondition(string query) { var newCall = service.GetSuggestionsForQuery(query); lastCall = newCall; await newCall; if (lastCall == newCall) if (CallBack_RaceCondition != null) CallBack_RaceCondition(newCall.Result); }
18
Ennél a műveletnél megint a Task-okat használjuk fel és az await kulcsszó megfelelő helyen történő felhasználásával trükközünk. A „csomagolómetódus” meghívásakor elmentjük a szervizhíváshoz tartozó Task objektumot, bevárjuk a hívás eredményét, majd megvizsgáljuk, hogy a kimentett lastCall Task példány még mindig megegyezik e a bevárt newCall Task példánnyal. Ezzel azt tudjuk megvizsgálni, hogy amíg a szervizhívásunk futott, nem esett e be egy újabb hívás, mely érvényteleníti a korábbi hívást. Ezzel tudjuk biztosítani, hogy az utoljára visszakapott eredmény az valóban az utolsó híváshoz tartozzon. Ezek a műveletek egyenként is jó pár sort elfoglalnak, és sajnos az összekapcsolásuk nem oldható meg könnyen, szóval csak elrettentésképpen szemléltetném a 2-2-8 kódrészlettel, hogy ezek a funkciók összegyúrva hogyan néznének ki:
19
2-2-8 kódrészlet: „A hagyományos megközelítés” // Throttle global variables private DateTime lastThrottledParameterDate; private int throttleInterval = 500; // Distinct global variables private string lastDistinctParameter; // Retry global variables private int retries = 3; // Timeout global variables private int timeoutInterval = 500; // Switch global variables private Task<string> lastCall; // Callback events public event Action> CallBack; public event Action<Exception> ErrorCallBack; public async void GetQuerySuggestionsAsync(string query) { try { // Throttle logic lastThrottledParameterDate = DateTime.Now; await Task.Delay(throttleInterval); if ((DateTime.Now - lastThrottledParameterDate).TotalMilliseconds < throttleInterval) return; // Distinct logic if (lastDistinctParameter != query) lastDistinctParameter = query; else return;
20
var newCall = Task.Run>(async () => { // Retry logic bool errorHappened = false; int tries = 0; IEnumerable<string> suggestions = null; do { errorHappened = false; try { // Timeout logic var newTask = service.GetSuggestionsForQuery(query); var timeoutTask = Task.Delay(timeoutInterval); var firstTaskToEnd = await Task.WhenAny(newTask, timeoutTask); if (newTask == firstTaskToEnd) suggestions = newTask.Result; else throw new Exception("Timeout"); } catch { tries++; errorHappened = true; } } while (errorHappened == true && tries < retries); if (!errorHappened) return suggestions; else throw new Exception("Out of retries"); }); // Switch logic lastCall = newCall; await newCall; if (lastCall == newCall) if (CallBack != null) CallBack(newCall.Result); } catch (Exception ex) { if (ErrorCallBack != null) ErrorCallBack(ex); } }
21
Látható tehát, hogy annak ellenére, hogy nem is szállt el annyira a fantáziánk, rengeteget kellett kódolnunk ezekért az alapvetőnek vehető feladatokért is. Ha ezen túljutottunk, akkor viszont a felhasználás már egész kényelmesnek mondható, ezt a 2-2-9 kódrészlet szemlélteti.
2-2-9 kódrészlet: A 2-2-8-as kód felhasználása public MainPage() { // Initialization this.InitializeComponent(); this.Loaded += (s, e) => SearchBox.Focus(FocusState.Keyboard); var service = new SearchService(); // Helper method var callBack = new Action>>(e => { if (e.Exception != null) ErrorLabel.Text = e.Exception.Message; else Suggestions.ItemsSource = e.Result; }); // Suggestions var getSuggestionsWrapper = new CustomGenericAsyncCall <string, IEnumerable<string>>(service.GetSuggestionsForQuery); SearchBox.TextChanged += (s, e) => getSuggestionsWrapper.WrappedCallAsync(SearchBox.Text); getSuggestionsWrapper.CallBack += callBack; // Results var getResultsWrapper = new CustomGenericAsyncCall <string, IEnumerable<string>>(service.GetResultsForQuery); SearchButton.Click += (s, e) => getResultsWrapper.WrappedCallAsync(SearchBox.Text); Suggestions.ItemClick += (s, e) => getResultsWrapper.WrappedCallAsync(e.ClickedItem as string); SearchBox.KeyDown += (s, e) => { if (e.Key == VirtualKey.Enter) getResultsWrapper.WrappedCallAsync(SearchBox.Text); }; getResultsWrapper.CallBack += callBack; }.
22
Rx megközelítés Keresési javaslatok Rx-nél mindig adatfolyamokban, „csővezetékekben” kell gondolkozni aminek van egy eleje („forrása”), és egy vége ahol „kiesik” belőle az adat. Közben pedig az adatfolyamot megfigyelhetjük, manipulálhatjuk, szűrhetjük, késleltethetjük stb. Jelen esetben a célunk az, hogy ha a felhasználó beír valamit a keresődobozba, induljon el egy szervizhívás javaslatokért, majd az eredménye jelenjen meg a felületen. Azaz a forrás a szövegdoboz, az szolgáltatja a szervizhívás számára a bemeneti paramétereket. Ahhoz, hogy egy eseményből adatfolyamot készítsünk, FromEventPattern() metódusát fogjuk használni.
az
Observable
típus
statikus
2-3-1 kódrészlet: Esemény-feliratkozás Rx módra var queryTextChanged = Observable.FromEventPattern(SearchBox, "TextChanged");
