Alkalmazásfejlesztés HTML tartalmak változásainak követésére Android és ios platformon

Átírás

1 Alkalmazásfejlesztés HTML tartalmak változásainak követésére Android és ios platformon Készítette: Hunyady Márton Konzulensek: Dr. Oláh András, Tornai Kálmán Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar Mérnök informatikus BSc Budapest, 2013.

2

3 PÁZMÁNY PÉTER KATOLIKUS EGYETEM INFORMÁCIÓS TECHNOLÓGIAI KAR SZAKDOLGOZAT TÉMA BEJELENTÉS Név: Tagozat: nappali Témavezető neve: A dolgozat címe: Hunyady Márton Szak: Mérnök informatikus BSc (IANI-MI) Tornai Kálmán, dr. Oláh András Alkalmazásfejlesztés HTML tartalmak változásainak követésére Android és ios platformon A dolgozat témája Az internet hihetetlen volumenű adatforrás, ugyanakkor a több mint 110 milliárd weboldal közül egy átlagos felhasználó weboldal meglátogatásával fér hozzá a számára értékes információhoz. A weboldalakon hozzáférhető tartalmak időről időre bővülnek, megváltoznak. A változások manuális detekciója nehézkes, monoton és időigényes (mivel periodikusan kell az egyes weboldalakat látogatni), és könnyű elsiklani a változások felett, melynek következtében a felhasználó fontos információk megismerésétől eshet el. A mérnökjelölt feladata a manuális detekció kiváltására egy olyan mobil alkalmazás elkészítése (Android és ios mobil platfomra egyaránt), amely képes a felhasználó által megadott weboldalakat adott időközönként ellenőrizni, az oldalak különböző változatait letárolni és az azok közötti eltéréseket megjeleníteni egy már létező vagy új összehasonlító algoritmus felhasználásával. További feladat egy olyan az implementált alkalmazásokkal együttműködő rendszer tervezése és fejlesztése, amelynek segítségével megoldható a különböző készülékek által ellenőrzött oldalak megosztása egymással. Feladatok: - Ismerkedjen meg a szakirodalomban a leggyakrabban használt összehasonlító algoritmusok működésével, illetve térjen ki a szöveges, XML és HTML összehasonlítások különbségére! - Tanulmányozza több nyílt forráskódú weboldal-összehasonlító algoritmus működését! - Fejlesszen ki egy weboldal-összehasonlító algoritmust, és implementálja egy tetszőleges programnyelven! - Tekintse át a létező, mobil platformokon működő weboldalfigyelő alkalmazásokat! - A kifejlesztett algoritmust implementálja egy weboldalfigyelő mobilalkalmazásba Android ill. ios platformokon! - Tervezzen és valósítson meg egy rendszert, amelynek segítségével a különböző rendszerű készülékek között megosztható az ellenőrzött oldalak listája és az ellenőrzés állapota!

4 A témavezetést vállalom:... Tornai Kálmán... dr. Oláh András Kérem a szakdolgozat témájának jóváhagyását. Budapest, április Hunyady Márton A szakdolgozat-témát az Információs Technológiai Kar jóváhagyta. Budapest, Dr. Szolgay Péter dékán A Hallgató a konzultációkon részt vett: Budapest, Tornai Kálmán... dr. Oláh András

5 Alulírott Hunyady Márton, a Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Karának hallgatója kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, és a szakdolgozatban csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Szakdolgozatot más szakon még nem nyújtottam be. Budapest, december Hunyady Márton

6

7 Tartalomjegyzék 1. Bevezetés és célkitűzések Technológiai háttér Feladat és célkitűzés A szakdolgozat felépítése Elérhető megoldások Weboldalfigyelő alkalmazások Desktop platformon elérhető alkalmazások Online, platformfüggetlen szolgáltatások Android platformra elérhető alkalmazások ios platformra elérhető szolgáltatások Összehasonlító alkalmazások és algoritmusok Összehasonlítási szempontok Szöveges fájlok összehasonlítása XML fájlok összehasonlítása HTML fájlok összehasonlítása Az algoritmusok összehasonlítása A megvalósításhoz használt technológiák Mobil operációs rendszerek Android ios Felhőszolgáltatások Felhőszolgáltatások felosztása szolgáltatásaik alapján Felhőszolgáltatások felosztása elérhetőségük alapján Elérhető felhőszolgáltatások Szerveroldali adattárolás a Google App Engine-en Rendszerarchitektúra Készülékállapotok Aktív állapot Passzív állapot Offline állapot Szerver Megoldások a feladatok kiosztására Rendszerszintű funkcionális specifikáció Szerver által nyújtott funkcionalitás Ellenőrizendő oldalak listája megváltozik Életjel jellegű üzenetek Állapotváltozások jelzése a szervernek

8 Figyelt oldalak listájának módosítása Adminisztráció Szerveroldali adattárolás Kliens funkciói Összehasonlító algoritmus Specifikáció A WatchThisSite összehasonlító algoritmusa Értelmezés Azonos részek és mozgatások keresése A dokumentumok összefésülése Összefésült HTML előállítása A WatchThisSite implementációja Szerver Android implementáció Az androidos alkalmazás architektúrája Az androidos alkalmazás felhasználói felülete Az androidos alkalmazás életciklusa ios implementáció Az alkalmazás felépítése Az alkalmazás felhasználói felülete Kliens-szerver interfész REST Authentikáció Összehasonlító algoritmus Androidos implementáció Használt adatszerkezetek Architekturális modell Eredmények Az implementáció előnyei Eredmények összefoglalása Elvégzett feladatok Elért eredmények Továbbfejlesztési lehetőségek...75 Irodalomjegyzék...77 Melléklet: Az implementáció elérhetősége

9 Tartalmi összefoglaló Az internet létrejöttével, azaz az adatforrások hálózatszintű összekapcsolásával rengeteg adat vált hozzáférhetővé, ugyanakkor a felhasználóknak specifikus információkra van szükségük. Annak feladatát, hogy az adatokból megtalálják a számukra fontos információt, a keresőmotorok látják el. Viszont vannak olyan felhasználók, akiknek ez nem elég, mert nem egy meglévő információra van szükségük, hanem minél gyorsabban szeretnének értesülni arról, ha egy új információ elérhetővé válik. A feladat megoldására több weboldalfigyelő számítógépes program is létezik. Viszont az emberek többsége nem szeretne egész nap a számítógép előtt ülni, hogy értesülhessen az esetleges új információról, az okostelefonjuk ellenben mindig kéznél van, és az idő nagy részében internetkapcsolattal is rendelkezik. Ezekre azonban eddig nem volt jól használható weboldalfigyelő alkalmazás, az oldalakat a telefon böngészőjében kézzel frissítgetni és azokon manuálisan változtatásokat keresni pedig nagyon időigényes és megbízhatatlan dolog. A szakdolgozatban megoldott feladat egy olyan rendszer megtervezése és kifejlesztése volt, amelynek segítségével annak felhasználói egy mobilalkalmazáson keresztül jelezhetik, hogy mely oldalak megváltozására kíváncsiak. Ezután a mobil készülékeik elvégzik ezen oldalak folyamatos ellenőrzését, és amennyiben megváltozott egy weboldal, arról értesítik az érdeklődő felhasználókat. Az elkészített WatchThisSite rendszer egy felhőszolgáltatáson futó szerverből, valamint egy androidos és egy ios-es mobil alkalmazáskliensből áll. A kifejlesztett alkalmazások a szükséges feladatok megoldása mellett figyelmet fordítanak arra is, hogy az ellenőrzés a felhasználóknak a lehető legkevesebb költséget jelentse. Egyrészt csökkenti az ellenőrzések számát és ezáltal a mobil eszközök energiafogyasztását is azzal, hogy a különböző készülékek ugyanazt az oldalt csak egyszer figyelik; másrészt azáltal, hogy a mobilinternetet használó okostelefonok vagy táblagépek ellenőrzési feladatait a WiFi kapcsolattal rendelkezők végzik el. Mindkét esetben a változást észlelő alkalmazások értesítik az eredeti felhasználót is, így az ugyanolyan hamar értesül a változásról, mintha az ő készüléke végezte volna el az ellenőrzést. Sok esetben a felhasználót nem csak az érdekli, hogy megváltozott-e az oldal, hanem az is, hogy mi változott meg. A feladat megoldására a szakdolgozatban bemutatásra kerül a WatchThisSite összehasonlító algoritmus, valamint annak androidos implementációja. Ennek segítségével az oldal két változatának ismeretében az alkalmazás színnel kijelölve megmutatja a felhasználónak a változtatás tartalmát. 9

10

11 Abstract When the Internet was created and the sources of data have been connected to a network, a huge amount of data became available. However, users need specific information. The task of finding the important information amongst the data has already been solved by search engines. But for some users that is not enough: they do not only need certain existing information, they also want to be notified when new information becomes available. There are numerous website watcher applications for the PC to solve this problem. However, most people do not want to sit in front of the computer all day to get notified about new information, while they have their smartphones with them all day, which also has an internet connection in most cases. There has not been an adequately functioning website watcher application for mobile devices, so the user had to check every webpage in the browser of the mobile, which is a very monotone and time-consuming task. The task solved in this thesis was to plan and develop a system, which gives the opportunity to the users to manage pages which they are interested in. Afterwards the devices check the pages and detect changes in order to notify the users about them. The implemented WatchThisSite system contains a cloud-based server and both an Android and an ios mobile client application. The developed system, in addition to solving these tasks, pays attention to minimize the cost of the checks by reducing the number of them and thus the energy consumption of the devices, by checking every webpage only once in the system, and also by sending the check tasks to the devices with a WiFi connection instead of the ones with mobile internet connection. In both cases, the devices executing the check immediately notify the original user when detecting changes, so they get notified at the same time as if they would use their own devices. In many cases the user is not only interested in whether the page has changed or not but they also want to know what has changed on the website. To solve this problem the thesis introduces the WatchThisSite comparison algorithm and its implementation in the Android application. Using this module the application can show the user the differences between the last seen and the most recent version of the website. 11

12

13 1. Bevezetés és célkitűzések Manapság mindenkinek pontos információra van szüksége, lehetőleg minél gyorsabban. Az internetet böngészve, a keresőprogramokat használva ehhez a legtöbb esetben szinte azonnal, ingyen hozzá lehet jutni, ha valaki tudja, hogy hol keresse azokat. Azonban az interneten emellett rengeteg felesleges adat is található. Ha valaki rendszeresen mindig meglátogat néhány weboldalt, csak egy-két érdekes új dolgot talál. A naponta feldolgozott adatmennyiség óriási mennyiségű, és ezeknek az adatoknak csupán a töredéke hasznos információ az illető számára. Ez a feldolgozás, az oldalak átnézése, az új információk keresése időigényes feladat, olyan, mint a tű keresése a szénakazalban. Csak a magyarországi híroldalakat és a leglátogatottabb blogokat tekintve is látszik, hogy rengeteg új cikk kerül ki naponta a címlapokra; ezek mindegyikét követni és elolvasni lehetetlen feladat sokkal több tartalom keletkezik adott idő alatt az interneten, mint amennyit egy ember képes ezalatt értelmezni. Sokszor azonban szükség lehet arra, hogy bizonyos fontos, specifikusabb változások ne kerülhessék el az ember figyelmét, azokról szinte azonnal értesüljön az érdeklődő. Ez megoldható úgy, hogy naponta többször ránéz azokra a weboldalakra, amelyeken a fontos információt várja. Ez viszont nem egy hatékony megoldás: egyrészt elkerülhetik a figyelmét bizonyos változások, másrészt feleslegesen sok időt vesz igénybe, illetve gyakran nem talál rá elég hamar az új információra. Az alábbi alfejezetek bemutatják a probléma megoldásának technológiai hátterét, ismertetik a szakdolgozatban a probléma megoldására kitűzött feladatokat, valamint a szakdolgozat felépítését Technológiai háttér A weblapok változásairól történő értesítésre találták ki az RSS (Rich Site Summary) szolgáltatást. Ennek segítségével az oldal készítője tudatja, hogy valamilyen új hírt vagy cikket tettek közzé. Ennek hátránya viszont, hogy csak akkor működik, ha ezt a fejlesztő elkészítette és azt a rendszer minden alkalommal frissíti. A változások keresése viszont megoldható úgy is, ha egy megfelelő program időnként a felhasználó helyett megvizsgálja az oldalt, és eldönti, hogy az megváltozott-e, ez esetben pedig meg is mutatja neki, hogy hol és milyen módosítások történtek. 13

14 Mivel az okostelefonok manapság folyamatosan kéznél vannak és a felhasználók rendelkezésére állnak, valamint az idő nagy részében általában internetkapcsolattal is rendelkeznek, ezért magától adódik, hogy alkalmasak lennének arra is, hogy elvégezzék e módosítások keresését, és megmutassák azokat a tulajdonosuknak. Mivel nem csak az lehet érdekes a felhasználó számára, hogy megváltozott-e egy oldal, hanem az is, hogy mi változott (nagyobb weblapok esetében bonyolult megtalálni, hogy melyik bekezdésben módosult valami, vagy milyen új információ került fel az oldalra), hasznos funkció a korábbi és a jelenlegi változat összehasonlításának lehetősége is. Asztali rendszerekre már létezik több fizetős és ingyenes alkalmazás is a fenti probléma megoldására. A legelterjedtebb mobil rendszerekre (Android, ios) azonban jelenleg nem található ilyen, az ellenőrzést és az összehasonlítást is támogató program Feladat és célkitűzés A szakdolgozatban megoldandó feladat egy olyan rendszer megtervezése és kifejlesztése, amely mobil eszközök segítségével képes a felhasználót érdeklő weboldalakat folyamatosan ellenőrizni, hogy megváltoztak-e. A rendszer része egy androidos és egy ios-es mobilalkalmazás, amelyen keresztül a felhasználó kezeli a figyelendő oldalak listáját, valamint értesül azok megváltozásáról. A feladat megoldása előtt a szakdolgozat ismerteti a létező weboldalfigyelő programokat és szolgáltatásokat, azok funkcionalitását. Azért, hogy a felhasználó ne csak azt tudja, hogy egy oldal megváltozott, hanem azt is, hogy mi volt az, ami módosítva lett az oldalon, mióta utoljára látta, az alkalmazásnak össze kell tudnia hasonlítani az utoljára megtekintett és a legfrissebb ellenőrzött változatot. A szakdolgozat ismerteti a létező weboldalakat összehasonlító algoritmusokat, majd bemutat egy hatékonyabb algoritmust, amely az alkalmazásban implementálásra kerül. A mobil alkalmazásra támaszkodva a komplett rendszer erőforrás-allokációt is végez: a készülékek az ellenőrzési feladatokat nem önállóan, hanem összehangoltan, az ellenőrzési eredményeket egymással megosztva küldenek értesítést az oldalak változásairól, ezáltal tehermentesítve mind a webszervereket, mind pedig az ellenőrzést végző készülékeket. 14

15 1.3. A szakdolgozat felépítése A szakdolgozat az alábbiak szerint épül fel: az 1. fejezet (Bevezetés és célkitűzések) bemutatja a szakdolgozat témáját és a megoldandó problémát; a 2. fejezet (Elérhető megoldások) megvizsgálja a már létező megoldásokat mind a weboldalfigyelés problémájára, mind pedig a HTML weboldalak összehasonlítására; a 3. fejezet (A megvalósításhoz használt technológiák) ismerteti a felhasznált technológiákat: bemutatja a legnépszerűbb mobil operációs rendszereket, valamint a felhasználható felhőszolgáltatásokat; a 4. fejezet (Rendszerarchitektúra) ismerteti a megtervezett rendszer architektúráját; az 5. fejezet (Rendszerszintű funkcionális specifikáció) bemutatja az egyes részek funkcionalitását, valamint a kliens-szerver kommunikáció folyamatát; a 6. fejezet (Összehasonlító algoritmus) ismerteti a WatchThisSite összehasonlító algoritmusának működését; a 7. fejezet (A WatchThisSite implementációja) bemutatja az elkészített modulok, azaz az alkalmazásszerver, az androidos és az ios-es kliens, valamint az összehasonlító modul implementációját, illetve a megvalósított kliens-szerver kommunikációs interfészt; a 8. fejezet (Eredmények összefoglalása) bemutatja a szakdolgozatban elért eredményeket, valamint felvázolja a főbb továbbfejlesztési lehetőségeket. 15

16

17 2. Elérhető megoldások A fejezet bemutatja az elérhető megoldásokat a szakdolgozatban felvetett problémákra, ezen belül a 2.1-es alfejezet ismerteti a különböző platformokon létező weboldalfigyelő alkalmazásokat és szolgáltatásokat, a 2.2-es alfejezet pedig áttekinti a jelenleg használt összehasonlító algoritmusokat Weboldalfigyelő alkalmazások A weboldalfigyelő alkalmazás egy olyan program, ami adott időközönként megnézi egy weboldal tartalmát, és összehasonlítja egy korábbi változattal, így megállapítva, hogy megváltozott-e annak tartalma. Több olyan, elsősorban webmestereknek szánt alkalmazás is van, ami hasonló elven működik, de csak annyit vizsgál, hogy válaszol-e egy weboldal a kérésére, azaz elérhető-e. Ezek közül bár nem tartoznak közvetlenül a szakdolgozat témájába néhány ismertebbet bemutat a fejezet Desktop platformon elérhető alkalmazások Desktop platformon sok weboldalfigyelő program elérhető, az alábbiakban megtalálható néhány fontosabb alkalmazás bemutatása: Page monitor: egy népszerű, több mint felhasználóval rendelkező nyílt forráskódú Google Chrome böngészőkiegészítő. A bővítmény folyamatosan ellenőrzi a beállított weboldalakat, és értesít, ha változás történt egy figyelt lapon. A felhasználó kérésére az aktuális változatot összehasonlítja az utolsó megtekintett változattal. A weboldal korábbi változatait nem tárolja el. [1] WebSite-Watcher: Fizetős (funkcionalitástól függően euró) weboldalfigyelő program. Képes weboldalakat összehasonlítani is, valamint jelszóval védett oldalak ellenőrzésére is használható. [2] NotiPage: Ingyenes desktop alkalmazás Windows rendszerekre. Figyelmeztet, ha az oldal megváltozik, elérhetetlen lesz, vagy egy adott szó vagy kifejezés feltűnik a honlapon. A program össze is tudja hasonlítani a weboldalak tartalmát. [3] Copernic Tracker: Fizetős (30$-os) alkalmazás. A többi hasonló programhoz képest előnye, hogy eltárolja a weboldalak régebbi változatait is. Képes a különböző változatok összehasonlítására is. [4] 17

18 Online, platformfüggetlen szolgáltatások Az alábbi alkalmazások webes felületről érhetők el, így tetszőleges platformról kezelhetők, ugyanakkor hátrányuk, hogy ritka (általában csak óránkénti vagy még ritkább) ellenőrzést tesznek lehetővé. A legnépszerűbb szolgáltatások a következők: ChangeDetection.com: Az egyik legrégebbi (1999-ben indult) online weboldalfigyelő szolgáltatás. Használatához meg kell adni neki a figyelendő webcímet, valamint az címet, amire a változtatásokról értesítő t küld. Legsűrűbben naponta figyeli az oldalakat. [5] Google Reader: A Google RSS olvasója tudott tetszőleges weboldalak változataiból is feedet készíteni, és ezáltal a változásait követni. [6] A Google Reader szolgáltatást azonban a Google 2013 februárjában megszüntette, így ez már nem elérhető. Versionista: A Versionista egy online weboldalfigyelő szolgáltatás. 5 oldalig ingyenesen használható, utána $/hó áron használható. Az oldalakat fizetős csomag esetén óránként ellenőrzi. Az ellenőrzött változatokat lementi, ezeket össze is tudja hasonlítani. [7] Android platformra elérhető alkalmazások Androidos mobil készülékekre (okostelefonra, illetve táblagépre) is vannak elérhető alkalmazások, amik weboldalfigyelést végeznek. Ezek közül a fontosabbak az alábbiak: SiteWatcher: Ingyenes alkalmazás, az egyik legnépszerűbb jelenleg. A Google Play Store-on 4,0-s értékeléssel és ezer letöltéssel rendelkezik. Hátránya, hogy a fejlesztését abbahagyták, 2011 óta nem frissült, így nem követi a legújabb rendszerek funkcióit és kinézetét, valamint weboldalakat sem tud összehasonlítani. [8] Webpage Update Detector: Ingyenes androidos alkalmazás. Viszonylag új, viszont vannak gyermekbetegségei, a tesztelése során gyakran kifagyott. Nem tud oldalakat összehasonlítani. A Google Play Store-on 3,5-ös értékelése van, letöltéssel. [9] WebPage Alerts: A webpagealerts.com webes szolgáltatás androidos alkalmazása mobiltelefonokra (a táblagépeket nem támogatja) letöltéssel rendelkezik. A szolgáltatás 20 ellenőrzött oldalig ingyenes. Leggyakrabban óránként ellenőrzi az oldalakat, az ingyenes verzió csak hetente. [10] 18

19 Website Watcher: Weboldalfigyelő alkalmazás, letöltéssel. Nem használható jól, és emellett nagyon gyorsan meríti a készülékek akkumulátorát. 2,5- ös értékeléssel rendelkezik. Nyílt forráskódú projektként indult, de a fejlesztése abbamaradt, jelenleg a forráskódja sem érhető el. [11] Website Checker: Ingyenes, letöltéssel rendelkező androidos alkalmazás. Különbség az eddigi alkalmazásokhoz képest, hogy csak azt tudja ellenőrizni, hogy működik-e az oldal, a tartalom megváltozását nem nézi. [12] Emellett még több, csak az oldal elérhetőségét ellenőrző alkalmazás is letölthető androidos készülékekre; tényleges összehasonlítást végző, jól működő alkalmazást viszont nem sikerült találni ios platformra elérhető szolgáltatások ios-es készülékekre az alábbi alkalmazások elérhetők: Site Tracker: Weboldalak elérhetőségét monitorozó ipad alkalmazás. Csak azt ellenőrzi, hogy él-e az oldal, illetve hogy egy beállított kifejezés szerepel-e rajta. Nem képes a háttérben ellenőrizni, csak ha előtérben van. [13] Webpage monitor: Egyszerű weboldalfigyelő alkalmazás ios rendszerre. Csak manuális ellenőrzési lehetőséget biztosít. Az ingyenes verzióval maximum 5 oldal ellenőriztethető, 0,9 euró a korlátlan számú ellenőrzést biztosító változat. Nem tud összehasonlítani régebbi változatokkal. [14] WebChanges: Ingyenes, alap funkciókkal rendelkező weboldalfigyelő alkalmazás, kizárólag manuális ellenőrzéssel. Beállítható, hogy mekkora eltéréseket jelezzen. Nincs összehasonlítási lehetőség. Fejlesztése abbamaradt, 2010-ben frissült utoljára. [15] 19

20 1. táblázat: Az ismertetett weboldalfigyelő alkalmazások Program neve Rendszer Ár Automatikus működés Összehasonlítás Régebbi változatok mentése Minimális ellenőrzési időköz Megjegyzés Page monitor Desktop (Chrome) ingyenes igen igen nem nincs WebSite-Watcher NotiPage Copernic Tracker Desktop (Windows) Desktop (Windows) Desktop (Windows) igen +30 nincs ingyenes igen igen nem nincs 30$ igen igen igen nincs ChangeDetection.com Online ( ) ingyenes igen igen nem naponta Google Reader Online (web) ingyenes igen igen igen figyelők számától függ Megszűnt Versionista Online (web) 5 oldalig ingyenes oldalig $/hó igen igen 4 változat (ingyenes) változat (fizetős) naponta (ingyenes) óránként (fizetős) SiteWatcher Android ingyenes igen nem nem nincs Webpage Update Detector Android ingyenes igen nem nem 5 perc Gyakran kifagy WebPage Alerts Android ( ) 20 oldalig ingyenes igen igen nem óránként Tabletre nincs Website Watcher Android ingyenes igen nem nem nincs Nem működik Website Checker Android ingyenes igen nem nem nincs Csak azt nézi, él-e az oldal Site Tracker ios (ipad) ingyenes csak előtérben nem nem nincs Csak azt nézi, él-e az oldal Webpage monitor ios 5 oldalig ingyenes utána 0,9 nem nem nem nincs WebChanges ios ingyenes nem nem nem nincs

21 2.2. Összehasonlító alkalmazások és algoritmusok Az összehasonlító algoritmusok és ennek megfelelően az ezeket felhasználó alkalmazások is alapvetően három csoportra bonthatók: szöveges összehasonlító algoritmusok és alkalmazások, XML összehasonlító algoritmusok és alkalmazások, HTML összehasonlító algoritmusok és alkalmazások. Az egyszerű szöveges összehasonlító algoritmusok nem használhatók HTML vagy XML dokumentumok összehasonlítására, mivel nem veszik figyelembe azoknak a struktúráját, így az általuk adott összefésült dokumentum nagy valószínűséggel használhatatlan megjelenítésre. Az XML dokumentumok célja adatok leírása. Emiatt itt nagyon fontos információ, hogy az adat melyik tagben (XML-elemben) található. Például egy könyvadatbázis esetében nem szabad az összehasonlításnál a szerző és a cím mezőt egymással összevetni, mivel más az adat jelentése. XML esetén emellett sokszor de nem mindig az adatok sorrendje sem lényeges, csak azok tartalma, illetve az XML tagek egymásba ágyazottsága, szülő-gyermek viszonya. Az XML dokumentumok szinte minden esetben szabványosak. A HTML formátum elsődleges célja ezzel szemben weblapok megjelenésének leírása. A HTML-oldalak nagy része (az XML-lel ellentétben) nem szabványos (egy 2008-as felmérés szerint az 500 leglátogatottabb oldalnak mindössze 6,57%-a ment át a W3C HTML ellenőrzésén [16]). A HTML szabvány hasonlít az XML szabványhoz, azonban nem követeli meg, hogy az szabályos XML legyen: például bizonyos tagek esetében nem kötelező kitenni a záró taget (<br></br>), de az XML-ben ilyenkor kötelező önlezáró taget (<br />) sem kötelező használni [17]. Emiatt nem használható XML parser a HTML dokumentum beolvasására. Az XHTML szabványt az XML és a HTML egyesítésének céljából hozták létre. Ebben az esetben a weboldal elméletileg megfelel az XML szabványnak, és kötelező önlezáró tageket használni [17]. Gyakorlatban viszont (a HTML-hez hasonlóan) az XHTML oldalak nagy része sem szabványos (2008-ban 13,14%-uk ment át az ellenőrzésen [16]). Emellett, bár az XHTML még jelenleg is nagy százalékát teszi ki a weboldalaknak, manapság egyre jobban elterjed a HTML5, ami nem követi ezt az útvonalat. Ennek a kettőnek az egyesítése 21

22 az úgynevezett polyglot markup, ami, bár nem eredményez szabványos XML-t, viszonylag közel van hozzá. [18] 1. ábra: Különböző HTML változatok elterjedtsége [19] Összehasonlítási szempontok Minden összehasonlító algoritmusnál alapkövetelmény, hogy képes legyen felismerni szövegrészletek törlését, illetve hozzáadását. Azonban fontos szempont a vizsgálat során, hogy képes-e áthelyezett szövegeket is megtalálni. Ez például híroldalak összehasonlításakor hasznos lehet, mivel észreveszi, ha egy hír nem eltűnt, majd újra megjelent, hanem csak átkerült másik helyre. HTML dokumentumok összehasonlításánál külön feladat, hogy hogyan lehet az összehasonlítás eredményét egyazon HTML dokumentumban megjeleníteni, összefésülni a két dokumentumot, jelezve az egyes oldalrészletek forrását. Ennek a folyamatnak az eredményeként gyakran keletkeznek érvénytelen, a webböngészők által nem, vagy csak hibásan feldolgozható oldalak. Emellett fontos megnézni az egyes algoritmusok futási idejét is, ha ez túl hosszú, akkor a felhasználónak nem lesz türelme kivárni. Alacsony (másodpercen belüli) futási idők között azonban sok különbséget nem kell tenni mobil alkalmazások esetén, mivel maga az oldal megjelenítése is sokszor jóval hosszabb feladat Szöveges fájlok összehasonlítása A szöveges összehasonlító algoritmusok nem foglalkoznak a dokumentumok struktúrájával, a szöveget darabokra bontják (az implementált programok leggyakrabban a sorok szintjén működnek, de vannak karakteres szintig működő implementációk is), és ezek között keresnek összefüggéseket, így elvégezve az összehasonlítást. A legfontosabb szöveges összehasonlító algoritmusok a következők: 22

23 Leghosszabb közös részsorozat algoritmus: A leghosszabb közös részsorozat (angolul longest common subsequence, rövidítve LCS) probléma arról szól, hogy ha van két sorozat, amiből kihagyhatók elemek, akkor melyeket kell kihagyni ahhoz, hogy ugyanaz a lehető leghosszabb sorozat legyen az eredmény. A feladat dinamikus programozási módszer segítségével hatékonyan megoldható. [20] Az ezt a feladatot megoldó algoritmus használható szövegek összehasonlítására is: a leghosszabb közös részsorozat tekinthető a szövegek közös részének, a régi változat azon részei, amelyek törlésével el lehet jutni ide, a törölt; az új változat ezen részei pedig a beszúrt szövegrészletek lesznek. Az algoritmus ebből fakadóan csak beszúrás és törlés kezelésére képes, szövegrészletek mozgatását nem képes észrevenni. Ratcliff/Obershelp algoritmus: A Ratcliff/Obershelp algoritmus az LCS problémát megoldó algoritmusnak egy továbbfejlesztett változata. Az algoritmus először megkeresi az LCS-t, majd ebből kiindulva a szöveg eleje és vége felé is ugyanígy LCS-t keres, a folyamatot rekurzívan ismételve. [21] GNU diffutils: A GNU diffutils programcsomag része a Unix rendszerek beépített szöveges összehasonlító programja, a diff. Ez a program két bemeneti fájlból készít egy kimeneti patch fájlt, ami a változásokat tartalmazza. Csak sorok változását mutatja ki, soron belüli eltéréseket nem keres, mozgatásokat nem ismer fel. A programot C nyelven írták, GPL licenc alatt elérhető a forráskódja. Egy egyszerűsített változata a BusyBox alkalmazáscsomagnak is része, ennek pedig létezik Android rendszerekre fordított változata is, ezáltal a parancs natívan futtatható androidos konzolból. A diffutils algoritmusa az LCS probléma megoldásának egy módosított, heurisztikus módszerekkel bővített változatát használja. [22] [23] XML fájlok összehasonlítása Az XML-összehasonlító algoritmusok a két bemeneti XML-ből egy, általában szintén XML alapú patch fájlt állítanak elő, ami tartalmazza az eltéréseket. HTML-hez hasonló vizuális megjelenítést nem nyújtanak. A legelterjedtebben használt XML összehasonlító algoritmusok a következők: X-Diff algoritmus: Az X-Diff algoritmus szabványos XML fájlokban képes eltéréseket keresni. Az összehasonlítás során az elemek szülő-gyermek viszonya számít, az egy szülőben található gyerekek sorrendje viszont nem. Az XML 23

24 dokumentumból először két rendezetlen fát épít fel (olyan fa, ahol csak a szülőgyermek kapcsolat számít), majd egy hash értéket állít elő minden részfára, aminek segítségével felgyorsítható az eltérések keresése. A különböző részfák között minimum költségű eltérést keres rekurzívan. Az eltérésből az algoritmus futása végén előállítja a kimeneti patch fájlt. [24] Microsoft XML diff and patch tool: A Microsoft által kifejlesztett programmodul, amelynek segítségével két XML fájl összehasonlítható, és egy XML patch fájl, az úgynevezett XML DiffGram állítható elő belőlük. [25] DiffXML: A DiffXML egy nyílt forráskódú, Java nyelven implementált, a diff programhoz hasonló egyszerű eszköz, amelynek segítségével XML dokumentumok közötti különbségekből saját formátumú patch fájlt lehet készíteni. Figyelembe veszi a dokumentum fastruktúráját, majd két rendezetlen fát épít a dokumentumokból. Ezután egy gráf csúcsaiként tekinti ezeket a fákat, amelyekből a beszúrás, törlés, csere és mozgatás műveletek eredményeként elérhető fákba van út, és ebben a gráfban keres legrövidebb utat a két változat között. [26] A program csak szabványos XML fájlokat fogad el, HTML összehasonlításra emiatt nem alkalmas HTML fájlok összehasonlítása A HTML dokumentumokban fontos, hogy milyen sorrendben szerepelnek az adatok, viszont a fastruktúra sem elhanyagolható. A végeredmény egy harmadik HTML fájlként jön létre, amelyet megjelenítve látszódnak a változások. Az alkalmazások általában egyszerű szöveges összehasonlításokat végeznek, és ez alapján próbálják előállítani a közös dokumentumot. A mozgatott szövegrészletek felismerését egyik, az alábbiakban tárgyalt alkalmazás sem támogatja. A legfontosabb HTML összehasonlító algoritmusok a következők: HTMLdiff: A HTMLdiff egy eredetileg Ruby nyelven implementált HTML összehasonlító algoritmus, amit a későbbiekben más programozási nyelveken is megvalósítottak. Lényege, hogy a két HTML fájlt szavakra bontja, majd ezekben heurisztikus módszerekkel egyező részleteket keres. Az algoritmus egyszerű módszereket használ, nem garantálja, hogy a végén szabványos HTML-t ad vissza. A mozgatásokat nem kezeli. [27] DaisyDiff: A DaisyDiff egy nyílt forráskódú, Java nyelven implementált HTML összehasonlító könyvtár. Többek között a Wikipédiát kiszolgáló MediaWiki szoftverhez is készült PHP nyelven implementációja VisualDiff néven, azonban azt a későbbiekben eltávolították a rendszerből kompatibilitási gondok miatt. Szöveg alapú 24

25 összehasonlítást végez a dokumentum egyes részei között, melyeket heurisztikák segítségével választ ki. Mozgatott szövegeket nem kezel. [28] Aaron Swartz s diff.py: A diff.py egy egyszerű, nyílt forráskódú, Python nyelven írt program, amely, miután szöveggé alakította a HTML fájlt, a Python beépített Obershelp algoritmus alapján működik. [29]) Mivel egyszerű szöveges összehasonlítást használ, bonyolultabb oldalaknál rendszeresen előfordul, hogy érvénytelen HTML kimenetet ad. Mozgatott szövegeket nem kezel. [30] Page monitor: A Page monitor egy böngészőkiegészítő a Google Chrome böngészőhöz, amely rendszeres időközönként megvizsgálja a beállított weboldalakat, hogy megváltoztak-e. Amennyiben igen, akkor megmutatja az oldal régi és új verziója közötti különbségeket is. Az alkalmazást Javascript nyelven írták, nyílt forráskódú. A HTML összehasonlító modul szöveges alapú, de figyelembe veszi a dokumentum hierarchiáját is. Mozgatott szövegeket nem kezel. [31] Az algoritmusok összehasonlítása A 2. táblázat összefoglalja a 2.2. alfejezetben ismertetett algoritmusokat azok típusa, az implementációjuk nyelve, valamint funkcionalitásuk alapján. 2. táblázat: Az ismertetett összehasonlító algoritmusok funkcionalitása Algoritmus/ program Leghosszabb közös részsorozat összehasonlító modulját használja az egyezések megtalálására. (Ez a modul a Ratcliff- Összehasonlítás Nyelv Mozgatások detekciója Szöveges nem Ratcliff/Obershelp Szöveges nem GNU diffutils Szöveges C nem X-Diff XML igen Microsoft XML diff and patch tool XML zárt igen DiffXML XML Java igen HTMLdiff HTML Ruby nem nem DaisyDiff HTML Java, PHP nem igen Aaron Swartz s diff.py HTML Python nem nem Page monitor HTML Javascript nem igen Szabványos HTML A táblázatban látható, hogy nincsen olyan ismert algoritmus, amely mindig szabványos HTML-t állít elő, miközben képes a mozgatások detekciójára is. 25

26

27 A megvalósításhoz használt technológiák Ez a fejezet bemutatja az elkészített alkalmazás fejlesztéséhez felhasznált technológiákat: a 3.1- es alfejezet ismerteti azokat a mobil operációs rendszereket, amelyeken a kliensek futnak, a 3.2- es alfejezet pedig bemutatja az elérhető felhőszolgáltatásokat, majd specifikusan a Google App Engine-t is, amelyen a szerver működik Mobil operációs rendszerek A mobil operációs rendszerek a mobil eszközökön (például okostelefon, táblagép, PDA) futó operációs rendszerek. 80% 70% 60% 50% 40% 30% 20% 10% 0% Android ios SymbianOS Samsung Windows Phone Sony Ericsson Egyéb 2. ábra: Mobil operációs rendszerek elterjedtsége Magyarországon december december [32] A 2. ábra bemutatja a különböző mobil operációs rendszerek használóinak arányát Magyarországon. Látható, hogy az egyes rendszerek részesedései nagyon gyorsan megváltozhatnak: négy évvel ezelőtt az Android még teljesen ismeretlen volt, jelentéktelen piaci részesedéssel, ma pedig a magyar mobil eszközök 69%-án ez az operációs rendszer működik. Ezzel szemben a Symbian akkoriban az egyik legjelentősebb volt az ios mellett, ma pedig már kifutóban van: a Nokia 2013 nyarán bejelentette, hogy abbahagyja a Symbian rendszert futtató készülékek gyártását. A szakdolgozat tárgyát képező mobilalkalmazások a jelenlegi két legelterjedtebb mobil operációs rendszerre, az Androidra és az ios-re készültek el. 27

28 Android Az Android a Google nyílt forráskódú mobil operációs rendszere. Jelenleg mind Magyarországon, mind pedig az egész világon ez a legelterjedtebb mobil operációs rendszer, Magyarországon a mobil készülékek 69%-án ez a rendszer fut (2013. december, [32]). Az Android rendszert nyíltsága miatt sok gyártó használja készülékein operációs rendszernek (legnagyobbak a Samsung, az LG, a Huawei, a HTC, a Motorola és a Sony, valamint táblagépek között az Asus). Bár ugyanaz a rendszer fut az olcsó mobiltelefonokon, mint a csúcskategóriás táblagépeken, az alkalmazások fejlesztésénél figyelembe kell venni a hardverek eltérő tulajdonságait is (különböző képernyőméret, hardveres gombok jelenléte, szenzorok elérhetősége), hogy az alkalmazások minden eszközön problémamentesen működjenek. Az Android rendszer legnagyobb alkalmazásboltja a Google Play Store, de a készülékekre tetszőleges más forrásból telepíthető androidos alkalmazás a telepítő apk fájl birtokában. Az Android rendszer módosított Linux alapokon működik. Alkalmazásokat Java nyelven lehet fejleszteni rá, melyek a Dalvik virtuális gépen futnak, de lehetőséget biztosít a rendszer natív kódú programok, programrészletek végrehajtására is. Ezeket általában C/C++ nyelven fejlesztik. 3. ábra: Az Android rendszer architekturális modellje [33] 28

29 ios Az ios az Apple mobil eszközeinek, az iphone-nak, az ipad-nek és az ipod Touch-nak a kizárólagos operációs rendszere, más eszközökre nem telepíthető. Az első változata 2007-ben jelent meg az első iphone-nal együtt, jelenleg a 7-es verziójánál tart, amelyet 2013 szeptemberében adták ki. A rendszer az Androiddal szemben zárt forráskódú. Alkalmazásokat általában Objective-C nyelven fejlesztenek rá. Az egységes hardver (fix képernyőméretek, funkcionalitás) miatt a fejlesztés ezek kezelése szempontjából egyszerűbb rá, mint az androidos készülékekre. Alkalmazásboltja az Apple App Store, végfelhasználóknak csak innen lehet alkalmazást telepíteni a készülékekre. Mivel az App Store-ba feltöltött alkalmazások a Google Play Storeral ellentétben minden esetben ellenőrizve vannak, így a rendszer biztonságosabb, mint az Android. Ennek a módszernek viszont hátránya, hogy az alkalmazások csak hetekkel a kifejlesztés után lesznek elérhető a végfelhasználók számára. Az ios rendszer rétegzett architektúrájú, minden réteg az alatta található rétegeket éri el. Legalsó szinten található a hardver, amihez a Core OS-nek van közvetlen hozzáférése. Erre épül a Core Services és a Media réteg, ezek biztosítanak alapszintű interfészt a rendszerszolgáltatások elérésére. Ezekre épül rá a Cocoa Touch réteg, ami magas szintű API-t biztosít az alacsonyabb rétegek által biztosított funkciókhoz. Ezekre épülnek rá a felhasználók által használt alkalmazások (mind az Apple, mind pedig a külső fejlesztők által készítettek). [34] 4. ábra: Az ios rendszer architektúrája [35] 29

30 3.2. Felhőszolgáltatások A felhőszolgáltatások különböző számítástechnikai erőforrásokat biztosítanak azok felhasználói számára. Ilyen erőforrások lehetnek a számítási kapacitás vagy a tárhely biztosítása, alkalmazások üzemeltetése, valamint különböző informatikai szolgáltatások nyújtása is. Ezeket a felhasználóik számítógépes hálózaton, leggyakrabban az interneten keresztül érhetik el. A biztosított erőforrások folyamatosan elérhetőek, és szükség esetén több számítógépen elosztva, illetve a nem használt erőforrásokat egymással megosztva biztosítja azokat a szolgáltató. [36] Felhőszolgáltatások felosztása szolgáltatásaik alapján A felhőszolgáltatások csoportosíthatók az alapján, hogy milyen szolgáltatásokat biztosítanak azok vásárlói számára: Infrastructure as a Service (IaaS): Ezek a szolgáltatások egy vagy több teljes virtuális gépet adnak a vásárló számára. Ezen általában megtalálható egy előre telepített operációs rendszer, amivel a vásárló utána szabadon rendelkezhet, a szolgáltató csak a hálózat, illetve a virtuális gép mögötti hardverek elérését korlátozza. Platform as a Service (PaaS): Ezeket a szolgáltatásokat elsősorban fejlesztőknek szánják. Ezek a szolgáltatások a vásárló rendelkezésére bocsátanak fejlesztőrendszereket és fejlesztőeszközöket, amelyek segítségével elkészíthetnek egy alkalmazást, amely a szolgáltatás futtatási környezetén végrehajtódik. Software as a Service (SaaS): Ezeket a szolgáltatásokat végfelhasználók számára készítik. A vásárlók egy használatra kész szoftvert kapnak Felhőszolgáltatások felosztása elérhetőségük alapján A felhőszolgáltatások csoportosíthatók az alapján is, hogy kik használhatják azt. Eszerint az alábbi négy csoport különböztethető meg: Nyilvános felhő: A nyilvános felhőszolgáltatások bárki számára szabadon elérhetők és megvásárolhatók az azt üzemeltető vállalattól. Privát felhő: A privát felhőszolgáltatásokat kizárólag egy vállalat, a felhő tulajdonosa használja, kívülről történő elérése korlátozva van. 30

31 Közösségi felhő: A közösségi felhőt több, hasonló céllal vagy hasonló igényekkel rendelkező vállalat közösen használja és tartja fent. Ilyenek például a kormányzati vagy egyetemi felhők. Hibrid felhő: A hibrid felhő több különböző típusú felhő összekapcsolásakor jön létre Elérhető felhőszolgáltatások A szakdolgozatban elkészített WatchThisSite rendszer szerverének futtatására egy nyilvános, PaaS felhő optimális, mivel nincs szüksége a teljes virtuális számítógépre, csak egy webes elérhetőséget és alkalmazásfejlesztési lehetőséget biztosító platformra. Jelenleg többféle ingyenes és fizetős, a feltételeknek megfelelő felhőszolgáltatás is elérhető. A legfontosabbak ezek közül a következők: Amazon Web Services Elastic Beanstalk: Az Amazon EC2 IaaS szolgáltatásán futó PaaS webszerver-szolgáltatás. Windows Azure Web Sites: A Microsoft cloud rendszerének, a Windows Azure-nak a webszerver szolgáltatása. Google App Engine: A Google PaaS felhőszolgáltatása. Elsősorban Java és Python, kísérleti szinten Go és PHP nyelven lehet alkalmazásokat fejleszteni a platformra. AppScale: Az AppScale egy nyílt forráskódú rendszer, aminek segítségével a Google App Engine platformja tetszőleges számítógépekre telepíthető, és így egy saját PaaS szolgáltatás alakítható ki. Heroku: A Heroku elsősorban Java, NodeJs, Python és Ruby on Rails webes alkalmazások futtatását teszi lehetővé, de ezen kívül futtatható rajta Clojure és Scala nyelven írt program is. Kis forgalmú weboldalak számára ingyenes, emiatt kedvelt, főleg a Rails és a NodeJs alkalmazások fejlesztői körében. A felsorolt szolgáltatások közül a WatchThisSite szervere számára a Google App Engine szolgáltatás tűnt a legmegfelelőbbnek, mivel a fejlesztés és a tesztelés idejére (alacsony használat mellett) ingyenes elérést biztosít valamennyi, az alkalmazás számára szükséges modulhoz. 31

32 Szerveroldali adattárolás a Google App Engine-en A szerveroldali adattárolás kisméretű, rendszerezett információk esetén a Google App Engine saját Datastore megoldásával, nagyobb méret esetén pedig a Blobstore szolgáltatás segítségével oldható meg egyszerűen. A Google Cloud Datastore elsősorban a Google App Engine alkalmazások számára biztosít NoSQL alapú adattárolást. A NoSQL (Not Only SQL) lényege, hogy a relációs adatbázisok esetén megszokott rekordokat (melyek egy-egy nagy táblának a sorai) felváltják az úgynevezett entitások (entity). Ezek tulajdonságaikban (property) lehet a tényleges adatokat eltárolni, illetve szükség esetén indexelni, hogy a későbbiekben gyorsan kereshetők legyenek. Az eltérő megközelítés miatt a Datastore-ban nem lehet olyan, a hagyományos relációs adatbázisokban megszokott műveleteket használni, mint például táblák összekapcsolása vagy az adatok allekérdezés alapján történő szűrése. Cserébe a Datastore jobban skálázható, mivel a rajta végrehajtott lekérdezések futási ideje és költsége csak az eredményhalmaz méretétől függ teljesen mindegy, hogy azt 100 vagy entitás közül keresi ki. A Google jelenleg az úgynevezett High Replication Datastore használatát ajánlja ennek lényege, hogy az adatok a világon területileg szétosztva, sok helyen találhatók meg, és a módosítások folyamatosan kerülnek átvezetésre a különböző adatközpontokban tárolt másolatok között. Ennek előnye a nagy sebesség és a folyamatos elérhetőség nem fordulhat elő, hogy ha kiesik az egyik adatközpont, akkor az adatok elérhetetlenné válnak. Hátránya, hogy külön figyelmet kell fordítani az adatok konzisztenciájára, mivel lehet, hogy egy másik adatközpontban történt módosítás után még nem értek el a szükséges adatok a lekérdezés helyére. Ennek megoldására a Datastore úgynevezett entitáscsoportokat (entity groupokat) használ az egy entitáscsoportba tartalmazó entitások biztosan konzisztensek egymással. Emellett a módosítások során előforduló ütközések kezelésére és a műveletek együttes végrehajtására a Datastore-ban tranzakciókat lehet használni. A Datastore esetében is mint általában a felhőszolgáltatások többségében az erőforrások használata után pay-per-use modellben kell fizetni: a tárolt adatmennyiség és az elvégzett írási, olvasási és indexelési műveleteket száma alapján alakul a szolgáltatás használatának költsége. Jelenleg írási és olvasási művelet, valamint 1 GB tárkapacitás ingyenes, efelett az adatbázis-műveletek 0,06-0,09$/100 ezer művelet áron, a tárhely pedig 0,18$/GB/hónap költséggel érhető el. Ez az árképzés lehetővé teszi azt, hogy az alkalmazás ingyenesen lefejleszthető legyen, és csak nagyobb forgalom esetén kelljen fizetni a szolgáltatásért, illetve emellett ösztönzi is a fejlesztőt a minél hatékonyabb programozásra. 32

33 A Blobstore a Google App Engine szolgáltatása, amelynek segítségével nagyobb méretű dinamikus adatokat lehet tárolni. Az adatok egy BlobKey típusú kulccsal azonosíthatók, ennek segítségével kérhető le a tartalom, valamint a feltöltés után egy ilyen kulcsot kap a szerver. A futtatott szerveralkalmazásból közvetlenül nem lehet bejegyzést létrehozni a Blobstore-ban, csak kívülről érkező POST kéréssel. 33

34

35 4. Rendszerarchitektúra A rendszer két fő logikai komponensből áll össze: az ellenőrzést végző és a felhasználóval kommunikáló mobil készülékekből, valamint a felhőszolgáltatáson futó alkalmazásszerverből. Az alkalmazás architektúrája az 5. ábrán látható Készülékállapotok 5. ábra: Az alkalmazás architektúrája Egy készülék háromféle állapotban lehet: az aktív online készülékek a háttérben tudnak ellenőrzéseket végezni, és ezekről a felhasználót értesíteni; a passzív online készülékek ellenőrzést nem végeznek, csak értesíteni tudnak, ha megváltozott valami a figyelt honlapokon; az offline készülékek nem rendelkeznek internetkapcsolattal, így nem tudnak sem ellenőrizni, sem értesíteni a változásokról. 35

36 Tipikusan aktív online állapotban vannak az androidos készülékek WiFi hozzáférés esetén, passzív online állapotban pedig az androidos készülékek mobilinternetes hozzáférés esetén, illetve az ios készülékek Aktív állapot Aktív állapotban a készülék adott időközönként maga ellenőrzi a számára kiosztott oldalakat. Minden ellenőrzés után értesíti a szervert, hogy ellenőrzött, és hogy talált-e eltérést. Ha talált eltérést, akkor az eltérést is felküldi a szervernek, hogy ha később másnak lesz kiosztva az ellenőrzés feladata, akkor a legutóbbi ellenőrzött változathoz tudja hasonlítani azt. Erre az életjelre szükség van akkor is, ha talált a weboldalon módosítást, és akkor is, ha nem. Előbbi esetben azért, mert ha változás történt az egyik ellenőrzött oldalon, akkor ezt a változást a szervernek közölnie kell a többi, az oldalt figyelő felhasználóval is, utóbbi esetben pedig azért, mert a szervernek értesülnie kell arról, ha megszűnik egy eszköz internetkapcsolata, és nem képes tovább ellenőrizni a számára kiosztott feladatokat. Ezt az értesítést pedig a készülék nem tudja megtenni, mivel már nem áll rendelkezésre az internetkapcsolata. Amennyiben nem érkezik életjel egy készüléktől adott időköz alatt, abban az esetben a készüléket a szerver offline-nak tekinti. Azokat az oldalakat, amelyek csak őt érdeklik, nem fogja ellenőrizni, mivel értesíteni sem tudná róla, azokat viszont, amiket eddig ő ellenőrzött, kiosztja másik klienseknek Passzív állapot Passzív állapotban a készülék nem ellenőriz, viszont a szervertől a Google Cloud Messaging (GCM) vagy az Apple Push Notification service (APNs) segítségével fogadja az értesítést a változásokról, és azt megjeleníti a felhasználónak. Adott időközönként (ritkábban, mint az aktív állapotú kliensek) jelzi a szervernek, hogy még online állapotban van, és még ellenőriznie kell az általa érdekelt oldalakat. Ez az ios alapú eszközöknél nem szükséges, azok folyamatosan passzív állapotúként jelennek meg a rendszerben Offline állapot Offline állapotban a kliens nem tud semmilyen módon kommunikálni a szerverrel, így sem ellenőrzést nem végez, sem értesíteni nem értesíti a felhasználót a változásokról. 36

37 4.2. Szerver A szerver konkrét feladatai a következők: kliensek állapotának kezelése: a szerver nyomon követi, hogy melyik kliens milyen állapotban van; felhasználók oldalainak szinkronizálása: a szerver eltárolja, hogy melyik felhasználó milyen oldalakat milyen beállításokkal szeretne ellenőrizni, és ezeket szinkronizálja maga, illetve a kliensek között; feladatok kiosztása a klienseknek: a szerver kiosztja az ellenőrzési feladatokat az egyes klienseknek, hogy minden weboldalt, amihez tartozik online kliens, valamelyik aktív készülék ellenőrizze Megoldások a feladatok kiosztására A feladatokat, azaz hogy melyik oldalakat melyik kliens figyelje, a szerver osztja ki az egyes készülékeknek. Ennek megoldására több különböző lehetőség is felmerült: Szerverközpontú megoldás: a szerver a feladatkiosztásnak egy egyszerűsített módja. A megoldásban minden aktív állapotú kliens a saját oldalait ellenőrzi, a passzív állapotú kliensek helyett pedig egy központi kliens ellenőriz. Az offline kliensek helyett nem ellenőriz senki. Elosztott megoldás: a szerver az összes aktív vagy passzív készülék által ellenőrizendő oldalt egyenletesen szétosztja az aktív kliensek között. Ekkor minden oldalt csak egy-egy kliens figyel, így az ellenőrizendő oldalak kiszolgálói számára is sávszélesség takarítható meg. A jelenlegi implementáció ezt valósítja meg. Skálázott elosztott megosztás: ez a megoldás egy továbbfejlesztett változata az elosztott megoldásnak. Itt a passzív kliensek attól függően oszthatják ki ellenőrzésre a weboldalaikat, hogy aktívként mennyi weboldalt ellenőriztek. Az extra passzív ellenőrzési igény alkalmazáson belüli vásárlással külön megvásárolható lenne, így azok számára, akik vissza is adnak valamit a közösségnek, olcsóbb, megfelelő aktív tevékenység esetén ingyenes lenne az alkalmazás használata, azoknak viszont, akik más kapacitását használják fel, fizetős. 37

38 A rendszer úgy lett kialakítva, hogy könnyen tovább lehessen fejleszteni. A feladatkiosztási módszer egyszerűen cserélhető, ez nem jár a kliensek módosításával, csak a szerverben kell a megfelelő modult átalakítani. Ezen kívül a későbbiekben bevezethetők lennének a desktop kliensek is, amelyek így levehetik a terhet a mobil eszközökről, valamint akár szerver jellegű, csak ellenőrzési feladatok megoldásával foglalkozó klienseket is lehetne készíteni, így elosztottan növelve az ellenőrzési és összehasonlítási kapacitást. 38

39 5. Rendszerszintű funkcionális specifikáció A fejezet bemutatja a WatchThisSite rendszer számára megtervezett rendszerszintű funkcionalitást. Az 5.1-es alfejezet bemutatja a szerver által a klienseknek kínált funkcionalitást, majd az 5.2-es alfejezet bemutatja, hogy ezek biztosításához a szerveroldalon milyen adattárolási megoldások szükségesek. Az 5.3-as alfejezet ezek után ismerteti, hogy hogyan illeszkednek a kliensek a szervernél már specifikált rendszerbe Szerver által nyújtott funkcionalitás Az alábbiakban az egyes eseményekre adott válaszok, valamint különböző kommunikációval kapcsolatos programrészek specifikációja található Ellenőrizendő oldalak listája megváltozik Ha megváltozik egy aktív készülék által ellenőrizendő oldalak listája, akkor erről a szerver Google Cloud Messaging üzenetben értesíti (ios rendszerű aktív kliens nem lehetséges). A kliens ennek hatására lekéri a szervertől az új ellenőrizendő listát. A kiküldött GCM üzenet formátuma: action: pages_to_inspect_changed A kliens, miután fogadta az értesítést, lekéri az ellenőrizendő oldalak listáját, majd még az egyes weblapok ellenőrzésének megkezdése előtt le kell kérnie azok utolsó ellenőrzött tartalmát a szervertől, hogy legyen mivel összehasonlítania az általa ellenőrzött változatot, és el tudja dönteni, hogy megváltozott-e az oldal. 3. táblázat: Az ellenőrizendő oldalak listájának megváltozása esetén használt kérések Lekérés típusa Ellenőrizendő oldalak listája Oldal utolsó ellenőrzött változata Leírás URL Módszer Paraméter Visszaadja az ellenőrizendő oldalak listáját Visszaadja az adott oldal utolsó ellenőrzött változatát /devices/ <deviceid>/ pages /pages/ <url>/ content GET GET nincs nincs 39

40 Életjel jellegű üzenetek A klienseknek szükséges megadott időközönként életjelet küldeniük a szervernek, hogy a szerver tudja, hogy még bekapcsolva, a hálózathoz kapcsolódva vannak-e, vagy ki kell osztani másik kliensnek a korábban általa ellenőrzött oldalakat. A készülék állapota alapján kétféle életjel különböztethető meg: aktív és passzív (offline készülék életjelet sem tud küldeni). Az életjel jellegű üzenetek közé tartoznak ezeken kívül az oldal ellenőrzését jelző üzenetek is: ezeket aktív állapotban, a megtörtént ellenőrzés után küldik a kliensek a szervernek, hogy közöljék az ellenőrzés eredményét. Ezeket a jelzéseket a szerver automatikusan életjelnek tekinti. 4. táblázat: Életjel jellegű kliens üzenetek Életjel típusa Leírás URL Módszer Paraméter Rögzíti az életjel POST nincs Aktív életjel időpontját. Passzív életjel Van változás Nincs változás Rögzíti az életjel időpontját. Rögzíti a változtatott oldal tartalmát, életjelnek tekinti, értesíti a klienseket. Rögzíti az ellenőrzés időpontját, valamint aktív életjelnek tekinti a jelzést. /devices/ <deviceid>/ activeheartbeat /devices/ <deviceid>/ passiveheartbeat /devices/ <deviceid>/ changed/ <pageurl> /devices/ <deviceid>/ checked/ <pageurl> POST POST POST nincs nincs nincs A fent felsorolt funkciók közül a figyelt oldal megváltozásának jelzése összetettebb a leírtaknál. Ekkor ugyanis a szerver az életjel jellegű üzeneten és az ellenőrzés időpontjának rögzítésén kívül fogadja és el is tárolja az utolsó változatát is az oldalnak. A /devices/<deviceid>/changed/<pageurl> oldalra küldött POST kérés visszaad egy urlt, ahová szintén POST módszerrel kell elküldeni a tartalmat. Ez a sikeres feltöltés után átirányít a /pages/<pageurl>/update oldalra. Ekkor a szerver Google Cloud Messaging vagy Apple Push Notification segítségével értesíti az összes aktív, passzív, illetve offline klienst, ami figyeli az adott weboldalt. 40

41 Az androidos készülékek kiértesítéshez használt GCM üzenet formátuma: action: page_changed url: <url> time: <timestamp> Az ios készülékekre pedig az Apple Push Notification üzenet formátuma: aps.alert: <megjelenítendő üzenet szövege> url: <url> 6. ábra: Tevékenységek oldal megváltozása esetén 41

42 Állapotváltozások jelzése a szervernek A kliensek közlik a szerverrel, ha aktív vagy passzív állapotba váltanak. A szerver ekkor rögzíti a kliens állapotváltását, valamint ezt az akciót életjelnek tekinti. Aktív állapotba kerülő kliens esetén a szerver az oldalakat újraoszthatja ebben az esetben értesíti a klienst is az es pont alapján, hogy kérje le az általa ellenőrizendő oldalak listáját. Passzív állapotba kerülő kliens esetén, ha a kliens korábban aktív vagy offline állapotban volt, akkor az általa figyelt oldalakat kiosztja másoknak, a frissített figyelendő oldalakat pedig az összes érintett kliens számára kiküldi az es pont alapján. 5. táblázat: Állapotváltást jelző kliens üzenetek Állapotváltás típusa Aktív állapotba Passzív állapotba Offline állapotba Leírás URL Módszer Paraméter Állapotot vált, rögzíti az életjelet, frissíti az ellenőrizendő oldalakat. Állapotot vált, rögzíti az életjelet, frissíti az ellenőrizendő oldalakat. Ellenőrzi, hogy melyik kliens küldött olyan régen életjelet, hogy állapotot kell váltania. /devices/ <deviceid>/ state /devices/ <deviceid>/ state /cron/ detectoffline (csak automatikusan hívható) POST POST GET state=active state=passive nincs A szerver időnként megnézi, hogy melyik online kliens nem küldött életjelet az utóbbi időben, ezeket innentől kezdve offline-nak tekinti: rögzíti az állapotváltásukat, és áttekinti, hogy kell-e módosítani az aktív klienseknek kiosztott figyelendő oldalak listáján: Ha a kliens aktív volt, akkor az általa korábban aktívan ellenőrzött oldalakat kiosztja másoknak. Ha a kliens passzív volt, akkor azokat az oldalakat, amelyeket nem figyelt más, csak ő, kiveszi az aktív kliensek figyelendő oldalai közül. Ezeket összesíti az összes offline-ná váló kliensre, majd a frissített figyelendő oldalakat az összes érintett kliens számára kiküldi az es pont alapján. 42

43 Figyelt oldalak listájának módosítása Amikor a felhasználó a kliensen módosítja az által figyelt oldalak listáját, akkor azt továbbítja a szervernek, ahol az is végrehajtja az adott felhasználó módosítását. 6. táblázat: Figyelt oldalak listájának módosításához használt kérések Művelet Leírás URL Módszer Paraméter A szerver eltárolja a /users/ Oldal POST nincs figyelés igényét az <user >/ hozzáadása adatbázisában. Ha még pages/ vagy nem létezett, hozzáadja <pageurl> módosítása az oldalak listájához. Oldal törlése Figyelt oldalak listája A szerver törli az oldalt a felhasználó oldalai közül. Visszaadja a figyelt oldalak listáját. /users/ <user >/ pages/ <pageurl> /users/ < >/ pages DELETE GET nincs nincs A figyelt oldalak listájának módosítása esetén a szerver a Google Cloud Messaging segítségével értesíti az adott felhasználó összes androidos kliensét, hogy frissíteniük kell az oldalak listáját. Az ios-es klienseket mivel passzívak nem kell értesíteni, ők indításkor, illetve indítás után periodikusan szinkronizálják az oldalak listáját. A frissítési kérésről szóló GCM üzenet formátuma: action: page_list_changed A módosítások alapján a szerver szükség esetén újraosztja az aktív kliensek számára kiküldött ellenőrizendő oldalak listáját, és ezeket az összes érintett kliens számára kiküldi az es pont alapján Adminisztráció A klienseknek szükséges beregisztrálniuk magukat, illetve a használt eszközeiket, mielőtt használatba vennék a szolgáltatást. Ez automatikusan, a felhasználótól való információkérés nélkül végbemegy. Az alábbi lépések szükségesek ahhoz, hogy a kliens használni tudja a szolgáltatást: Felhasználó beregisztrálása: Ha még nem tette meg korábban másik készülékkel, akkor a kérés hatására beregisztrálja a felhasználót, egyébként Already exists hibaüzenetet ad a szerver, ezt megkapva a kliens tudja, hogy be van regisztrálva. 43

44 Készülék beregisztrálása: A készüléket szükséges beregisztrálni a felhasználóhoz, hogy a rendszer tudja, melyik készülékeket kell kiértesíteni a felhasználó által figyelt oldalak megváltozásakor. Készülék push azonosítójának elküldése: Ahhoz, hogy a készülék fogadni tudja a GCM vagy APNs üzeneteket, a szervernek ismernie kell a kliens készülék push azonosítóját. 7. táblázat: Az adminisztrációhoz használt kérések listája Adminisztrációs feladat Felhasználó regisztráció Felhasználók listázása Készülék regisztráció Készülék push id beállítása Készülékek listázása Felhasználó készülékeinek listázása Leírás URL Módszer Paraméter Új felhasználót hoz létre a megadott -címmel. Listázza az összes regisztrált felhasználót. Csak adminisztrátoroknak. Adott felhasználóhoz hozzácsatol egy készüléket. Beállítja a készüléknek a push id-t. Listázza az összes készüléket. Csak adminisztrátoroknak. Listázza a felhasználó összes készülékét. /users POST a felhasználó e- mail címe /users GET nincs /devices POST owner- tulajdonos e- mail címe id: készülékazonosító /devices/ POST pushid: a <id>/ beállítandó id push type: apn/gcm /devices GET nincs /users/ < >/ devices GET nincs 5.2. Szerveroldali adattárolás A szervernek szükséges eltárolnia a felhasználók, a készülékek és az oldalak adatait, ezt a Google Cloud Datastore használatával teszi meg. Emellett el kell mentenie az oldalak utolsó ellenőrzött változatát is, mivel ha az ellenőrzési feladat egy másik felhasználóhoz kerül át, akkor neki szüksége lesz erre, hogy el tudja dönteni, hogy megváltozott-e az oldal, amíg senki nem nézett rá. Az oldal tartalmát annak esetleges nagy mérete (a Datastore-ban egy tulajdonság maximális mérete 1 MB lehet), illetve a tárolás alacsonyabb költségei miatt a Blobstore-ban érdemes eltárolni. 44

45 7. ábra: A szerveroldali adattárolás UML diagramja A Datastore-ban tárolt adatok szerkezete a 7. ábrán látható. Három típusú entitást kell eltárolnia a szervernek: a felhasználók, a készülékek és az oldalak adatait. Mivel a Datastore egy tulajdonságában több értéket is el tud tárolni, ezért a hagyományos relációs adatbázisokétól eltérő módszert használ az alkalmazás az egy-a-többhöz kapcsolatok létrehozására: a kapcsolat egy oldala tárolja egy tömb típusú tulajdonságában a több oldala elemeinek kulcsát. Emellett a felhasználók által figyelt oldalak listájánál nem elég az oldalra mutató kulcsot tárolni, hanem egy összetett tulajdonságra van szüksége: az oldal URL-jét és annak nevét is eltárolja a szerver. A Blobstore-ban tárolja az alkalmazás az ellenőrzött weboldalak utolsó változatát. A Blobstore-hoz a szerver közvetlenül nem fér hozzá, ezért a Blobstore-ba való feltöltés menete a következő: Az alkalmazás jelzi a szerver felé, hogy megváltozott egy weboldal tartalma Erre válaszul a szerver generál egy Blobstore URL-t, amelyre feltölthető az új weboldal tartalma A kliens feltölti erre az URL-re a weboldal új tartalmát, majd az App Engine eltárolja az új Blobstore kulcsot a Datastore-ban, a régi Blobstore bejegyzést pedig törli. A Blobstore-ban tárolt tartalmat az App Engine akkor adja vissza a kliens számára, ha egy speciális fejléc paramétert beállít a szerver a kliensnek küldött válaszában. Így a lekérés megoldható egy egyszerű API hívással (bővebben az fejezetben). 45

46 5.3. Kliens funkciói A kliens az internetkapcsolata állapotától, valamint a beállításaitól függően eldönti, hogy aktív, passzív vagy offline állapotú-e. Aktív állapot: Ebben az állapotban lehetnek az androidos készülékek, általában WiFi kapcsolat esetén. ios 6.1-es készülékek nem lehetnek aktív állapotban a rendszer korlátozásai miatt (bővebben erről a 8.1. fejezetben). Aktív állapotban az alábbi eseményeket kell kezelnie a klienseknek: Aktív állapotba lépés: Aktív állapotba lépéskor a kliens közli a szerverrel, hogy aktív állapotba lépett. Ezt a szerver fogadja az es pont szerint. Figyelendő oldalak listájának fogadása: A kliens Google Cloud Messaging segítségével kapja meg a szervertől a figyelendő oldalak listáját (bővebben az es fejezetben). Miután ezeket megkapta, eltárolja, és elkezdi az ellenőrzést. Ellenőrzés: Ezeket a weboldalakat adott időközönként ellenőrzi. Minden ellenőrzés után elküldi a szervernek, hogy mi lett az ellenőrzés eredménye. Három lehetőség van: i) ellenőrzés sikeres, nincs változás; ii) ellenőrzés sikeres, van változás ekkor elküldi a szervernek az oldal új tartalmát is (bővebben az es fejezetben és a 6. ábrán); iii) ellenőrzés sikertelen, hiba oka. Oldalak kézi ellenőrzése: A felhasználó kérheti az oldalai soron kívüli kézi ellenőrzését is. Ekkor az alkalmazás ellenőrzi a neki kiosztott feladatokat és a felhasználó saját oldalait is, majd az eredményt közli a szerverrel az szakasz szerint. Passzív állapot: Passzív állapotban vannak általában az ios-es készülékek, valamint az androidos készülékek mobilinternetes kapcsolat esetén. Ekkor az alábbi funkciókat kell biztosítania a klienseknek: Passzív állapotba lépés: Ha passzív állapotba lépett a kliens, akkor ezt közli a szerverrel ( pont). Életjel: Adott időközönként közli a szerverrel, hogy még online állapotban van (passzív életjel az es pont szerint). Oldalak kézi ellenőrzése: Passzív állapotban a kézi ellenőrzés csak a felhasználó saját oldalait fogja ellenőrizni, mivel ilyenkor nincsenek számára kiosztott 46

47 ellenőrizendő oldalak. Az ellenőrzés után ilyenkor is közli a szerverrel az ellenőrzés eredményét az szakaszban leírtak alapján. Offline állapot: Ebben az állapotban a kliens a hálózati kommunikáció hiánya miatt nem tud ellenőrzést végezni egészen addig, amíg az alkalmazás újra online állapotba nem kerül. A készülékre lementett korábbi változatokat viszont ekkor is el tudja érni és össze is tudja hasonlítani egymással. Az állapotfüggő működésen kívül a klienseknek az alábbiak alapján kell reagálniuk a felsorolt eseményekre: A felhasználó módosítja az oldallistát: Ekkor a kliens elküldi a szervernek az oldallista módosításait: melyik oldalak lettek törölve és melyek hozzáadva az új oldallistához (az URL módosítása két műveletben történik: először törli a régi, majd hozzáadja az új oldalt). Ha offline van a készülék a módosításkor, akkor ezt a legközelebbi online állapotba váltáskor teszi meg. Szerver jelzi, hogy módosult az oldallista (Csak Android rendszeren): Ha van a kliensnél elküldetlen módosítás, akkor azokat elküldi a szervernek az pontban leírtak szerint. Ha nincs ilyen, akkor a szervertől elkéri az ott megtalálható oldallistát. (Ha volt elküldetlen módosítás, akkor a kliens nem csinál semmit, mert a szerver majd újból értesíti, ha rögzítve lettek a most elküldött módosítások.) Szerver jelzi, hogy megváltozott egy weboldal: Egy weboldal megváltozásakor a szerver Google Cloud Messaging vagy Apple Push Notification segítségével értesíti a klienst az pontban leírtaknak megfelelően. Erről a kliensnek értesítést kell megjelenítenie a felhasználó beállításai alapján. 47

48

49 6. Összehasonlító algoritmus A fejezet specifikálja egy összehasonlító algoritmus szükséges funkcióit (6.1. alfejezet), majd bemutatja az alkalmazás számára kifejlesztett algoritmus működését (6.2. alfejezet) Specifikáció Egy közel optimális HTML összehasonlító algoritmus követelményei: Működik két tetszőleges HTML fájlra: az algoritmus lefut és szabványos HTML kimenetet ad tetszőleges szabványos HTML bemenetre, valamint működik akkor is, ha egy oldal teljes tartalma megváltozik. Amennyiben nincsen semmilyen közös pont a két változat között, abban az esetben úgy tekinti, hogy a régi oldal teljes tartalma törölve lett, ami után az új oldal teljes tartalma be lett szúrva. Nem vár szabványos XML-t: mivel a weboldalak többsége nem teljesíti az XHTML, de gyakran még a HTML szabványokat sem, ezért az algoritmus nem várja el, hogy teljesen szabványos XHTML-t vagy HTML-t kapjon (pl. hogy minden tag le legyen zárva), igyekszik kitalálni azt, hogy hogyan jelenik meg a böngészőben az oldal. Szövegek összehasonlítása a szavak szintjéig: az algoritmus képes eltérést keresni bekezdések, mondatok, szavak szintjén is. A betűk szintjén viszont ezt nem teszi, hogy kiszűrje két teljesen különböző szó összehasonlítását. Figyelembe veszi a hasonlóság mértékét is, két bekezdés nem hasonló, amennyiben csak néhány közös szó szerepel azonos sorrendben, viszont szavak szintjén hasonlít össze, ha csak egy-két szó különbözik a két mondatban. Whitespace-ek helyes kezelése: nem használ felesleges whitespace-eket ott, ahol a megjelenítésnek nincs szüksége rá, viszont bizonyos helyeken (pl. <pre> tagen belül) megtartja. Nem helyez el whitespace-t olyan helyen, ahol eredetileg nem szerepelt. Módosíthatatlan részek kezelése: A HTML dokumentumok bizonyos részeit (például a <script>, <style> tagek tartalmát) változatlan formában megtartja az összehasonlított dokumentumban is. Ezek nem szerepelhetnek többször a dokumentumban, így amennyiben változás történik ezek között, abban az esetben csak a későbbi változatot helyezi el az összefésült fájlban. 49

50 Táblázatok helyes kezelése: Táblázatoknál fontos, hogy a cellák felosztása azonos maradjon, ne csússzanak el az oszlopok, amikor megjelenik a változás. Ehhez az alábbi feltételek szükségesek: Ha a táblázat mérete és az adatok nagy része azonos marad, akkor csak cellaszinten vizsgálja a változásokat Ha sorok vagy oszlopok lettek hozzáadva, akkor ezeket beszúrásként jeleníti meg Ha sorok vagy oszlopok lettek törölve, akkor ezeket törlésként jeleníti meg Ha változott a sorok sorrendje, akkor ezt áthelyezésként jeleníti meg Ha az oszlopok sorrendje változott, akkor ezt szintén áthelyezésként jeleníti meg (itt külön kezelni kell azt, ha összevont cellák szerepelnek a táblázatban) Ha cellák lettek összevonva vagy szétbontva, akkor a szétbontott cellákat jeleníti meg, és az egyik cellában szerepel a régi érték Mobiltelefonon is gyorsan, alacsony memóriahasználat mellett működik: a legtöbb algoritmus DOM-fát épít, ami sokszor feleslegesen sok processzoridő- és memóriahasználattal jár. Mivel a memóriahasználat erősen korlátozott és emiatt gyakran lassú folyamat gyengébb androidos készülékek esetén, ezért ezt a szempontot a tervezés folyamán fontos figyelembe venni. Áthelyezések felismerése: az áthelyezett szövegek általában nem adnak új információt (de nem mindig, pl. rangsor esetén), ezért külön szükséges jelölni a törölt/beszúrt szöveghez képest. Megjelenítés vizuálisan: az összehasonlítás eredményét egy új, összefésült HTML fájlban jeleníti meg. A szövegrészletek beszúrását, törlését a háttér színezésével jelzi. A megváltozott képekhez pedig színes keretet ad annak érdekében, hogy látszódjon, melyik a régi és melyik az új verzió. 50

51 6.2. A WatchThisSite összehasonlító algoritmusa Az algoritmus főbb lépései a következők: HTML dokumentum beolvasása és értelmezése (6.2.1-es alfejezet), azonos részletek és mozgatások keresése ( alfejezet), dokumentumok összefésülése ( alfejezet), összefésült dokumentum kiemeléssel bővített HTML formára alakítása ( alfejezet) Ezek egymáshoz kapcsolódását a 8. ábrán látható adatfolyam-diagram szemlélteti. Korábbi HTML Későbbi HTML értelmezés értelmezés Korábbi dokumentum Későbbi dokumentum Azonos részletek, mozgatások keresése Korábbi dokumentum Későbbi dokumentum Összefésült dokumentum Összefésült HTML 8. ábra: Adatfolyam-diagram 51

52 Értelmezés Az értelmezés során az algoritmus beolvassa a HTML dokumentumot, majd szétbontja azt a HTML tagek mentén, a szövegeket pedig a szóközök mentén. Így egy olyan formátumba lehet hozni a dokumentumot, amelyben az egyes elemek tartalma ezután nem fog már megváltozni. A bemeneti HTML dokumentumot és az ebből értelmezett elemeket a következő példa szemlélteti: HTML dokumentum: A <b>kék bálna</b> <i>(balaenoptera musculus)</i> az <a href="/wiki/eml%c5%91s%c3%b6k" title="emlősök">emlősök</a> <a href="/wiki/oszt%c3%a1ly_(rendszertan)" title="osztály (rendszertan)">osztályába</a> tartozó <a href="/wiki/faj" title="faj">faj</a>. Értelmezett elemek: A <b> kék bálna </b> <i> (Balaenoptera musculus) </i> az <a href="/wiki/emlősök" title="emlősök"> emlősök </a> <a href="/wiki/osztály_(rendszertan)" title="osztály (rendszertan)"> osztályába </a> tartozó <a href="/wiki/faj" title="faj"> faj </a>. Az értelmezés során az algoritmus elhagyja a felesleges szóközöket, amelyeknek a HTML formátumban nincsen szerepe. Ebben a lépésben eltávolítja a felesleges megjegyzéseket is a HTML dokumentumból, a nem HTML részleteket tartalmazó, megőrizendő szövegeket (például <script> vagy <style> tagek tartalma) pedig egy hashértéket tartalmazó önlezáró taggel helyettesíti (pl. <hash value=" d8658cd1a3a66bf8261f17" />). Ezután az algoritmus összepárosítja a HTML tagek összetartozó nyitó és záró példányait. Ezt úgy teszi meg, hogy sorban végigmegy az egyes bejegyzéseken, és amennyiben záró taget talál, 52

53 akkor visszafelé elindulva megkeresi a legközelebbi, azonos nevű nyitó taget, és ezzel összepárosítja. Amennyiben a visszafelé keresés során egy már előzőleg leellenőrzött záró taghez ér, akkor annak az elejére ugrik a keresésben, mivel a tagek nem lapolhatják át egymást. A módszer szabványos HTML és XHTML esetén is működik, emellett a nem szabványos dokumentumokat is többnyire helyesen tudja értelmezni, mindezt anélkül, hogy figyelembe venné a konkrét tagek nevét Azonos részek és mozgatások keresése Az algoritmus ebben a részben olyan azonos részeket keres a két dokumentumban, amelyek pontosan ugyanazt a részletet tartalmazzák, és pontosan egyszer szerepelnek mindkét dokumentumban. Ezeket az összetartozó részleteket összepárosítja, és megnézi, hogy milyen mozgatásokra van szükség ahhoz, hogy ugyanabban a sorrendben szerepeljenek mindkét dokumentumban. A mozgatások megtalálhatók tetszőleges egyszerű szöveges összehasonlító algoritmus használatával. Ahhoz, hogy az összehasonlítás egyszerűen megoldható legyen, az algoritmus veszi az egyes elemeknek a gyermekelemeivel együtt vett hashértékét, valamint az őseinek összesített hashértékét. Ez utóbbi azért szükséges, hogy ne párosíthasson össze két, a dokumentumfában különböző mélységben található elemet. A hashértékek jelentését az alábbi példa szemlélteti: Elemek Ős hash érték Saját hash érték A <b> kék bálna </b> <i> (Balaenoptera musculus) </i> az <a href="/wiki/emlősök" title="emlősök"> emlősök </a> 9ee6c5b1 9ee6c5b1 506b b9865 9ee6c5b1 e216753f e216753f 9ee6c5b1 9ee6c5b1 47a37dd1 2eacbe29 521bb373 bb5fa98c 4dc6cfdd 13b92d61 ecc9793c 34eb787a 65aa39e2 a741b02f 7d8be4ae Ezekből a hashértékekből veszi az algoritmus az egyedieket, majd egy egyszerű szöveges összehasonlítást lefuttatva megkapja azoknak a blokkoknak a hashértékeit, amelyek mozgatva lettek: a kiindulási pozíción törlésként, a végpozíción beszúrásként fognak szerepelni. A többi 53

54 az összehasonlításban részt vevő, de a kimenetben nem szereplő blokk helyben marad, ezek megegyeznek mindkét dokumentumban. Az alábbi példán látható az összehasonlítás kimenetének egy -924,2 -9ee6c5b1# ,0 +9ee6c5b1# cfc95292#e61f A dokumentumok összefésülése A két beolvasott dokumentumot ezután szükséges összefésülni. Ehhez az algoritmus segítségként felhasználja az előző pontban meghatározott megegyező szövegrészleteket, és ezek alapján részekre bontja az oldalt. 9. ábra: A dokumentumok részekre bontása összefésüléshez A megegyező részleteket nem, csak az azok között található, nem egyező szövegrészleteket kell páronként vizsgálni (a 9. ábrán vastag fekete vonallal összekötve). Ezeken a részleteken az algoritmus felülről lefelé halad végig. A két dokumentum az egyesítés során mindig biztosan ugyanabban a mélységben fog állni, nem fordulhat elő, hogy az egyik különböző tagben legyen, mint a másik. Ekkor az aktuális sor feldolgozásakor az alábbi lehetőségei vannak az algoritmusnak: Mindkét dokumentumban ugyanaz az aktuális sor: ekkor a közös, összefésült dokumentumhoz hozzáadja az aktuális sort. 54

55 Az egyik dokumentum feljebb akar lépni, a másik még nem: mivel mindkettőnek azonos szinten kell lennie, ezért ekkor addig, amíg a nem visszalépő dokumentum is vissza akar lépni, átmásolható minden a közös dokumentumba. Az egyik dokumentumszakasz véget ért, megegyező részlet következik: minden átmásolható a közös dokumentumba addig, amíg a megegyező (a 3. ábrán kékkel jelölt) rész el nem kezdődik a másik dokumentumban is. Egyik dokumentum sem akar visszalépni, de nem ugyanaz következik: ekkor az algoritmus figyelembe veszi egy szöveges összehasonlító program kimenetét is a maradék szövegrészletre, és ennek kimenetétől függően választ a két dokumentum közül Összefésült HTML előállítása Amikor az algoritmus hozzáad egy új elemet a közös dokumentumhoz, akkor jelzi, hogy az melyik dokumentumból (a korábbiból, a későbbiből vagy mindkettőből) származik, illetve a mozgatott blokkok esetén azt, hogy az mozgatva lett. A végleges HTML dokumentum létrehozása közben az algoritmus folyamatosan követi, hogy éppen milyen blokkban van (beszúrás, törlés, mozgatás innen, mozgatás ide). Mivel biztosan úgy kell váltania a két funkció között, hogy azok nem lapolódnak át, és a szintek is ugyanazok maradnak (mivel az előző pont során így állította elő azokat: csak akkor lépett szintet, amikor azt mindkettő dokumentum megtehette, minden más esetben teljes blokkokat másolt), ezért váltáskor elhelyezheti az előző állapot lezáró tagét, majd az új állapotot megjelölő nyitó taget. A színes megjelenítés megoldható például egy <span> tag segítségével, amelynek a háttérszíne megfelelően be van állítva, vagy használható a HTML5-ben erre a célra bevezetett <ins> és <del> tagje is. 55

56

57 7. A WatchThisSite implementációja A fejezet bemutatja az elkészített alkalmazások implementációját. A 7.1-es alfejezet ismerteti a szerver implementációját, majd a 7.2-es fejezet az androidos, a 7.3-as pedig az ios-es alkalmazást mutatja be. A 7.4-es alfejezet WatchThisSite kliensek és a szerver közti kommunikációt és annak hitelesítését írja le, a 7.5-ös alfejezet pedig ismerteti a WatchThisSite összehasonlító algoritmus működésének lényegét Szerver Az alkalmazás központi szervere végzi az ellenőrizendő oldalak kezelését, a feladatok kiosztását, valamint a felhasználók kiértesítését a változásokról. A szerver elkészítéséhez az alábbi eszközök lettek felhasználva: Google App Engine: A szerver a Google App Engine felhőszolgáltatásán fut. Adattárolásra a Google Cloud Datastore szolgáltatást használja, itt tárolja a felhasználók, a készülékek, valamint az oldalak adatait az 5.2. pontban leírtak alapján. Az adattárolást a szerver az Objectify framework segítségével oldja meg, ennek lényege, hogy táblaszerű lekérdezéseket biztosít a Google Cloud Datastore-on. Az ellenőrizett oldalak utolsó változatát a Blobstore szolgáltatásba töltik fel, valamint innen töltik le az ellenőrzést végző kliensek. Java EE: A Google App Engine többféle programozási nyelven (Python, Java, PHP, Go) kínál alkalmazásfejlesztési lehetőségeket. A lefejlesztett alkalmazásszerver Java nyelven készült. A Google App Engine által kínált Java nyelv és keretrendszer nem felel meg teljes mértékben a Java Enterprise Edition specifikációjának, azonban nagyon sok elemet felhasznál belőle, sok helyen pedig nagyon hasonló megoldásokat kínál. A Java EE, valamint az App Engine alkalmazások is servleteken keresztül kommunikálnak a kliensekkel. RESTEasy: Az alkalmazásszerver a REST stílusú URL-ek biztosításához és könnyű kezeléséhez a JBoss RESTEasy frameworkjét használja. Ez a framework Java annotációk használatával egyszerűvé teszi az egyes funkciók különválasztását, valamint a kérésekhez csatolt paraméterek kinyerését mind az URL-ből, mind pedig a fejlécekből és a tartalomból. 57

58 Unit tesztek: A szerver funkcionalitásának tesztelése a JUnit framework segítségével történik, az implementáció elkészítése a tesztvezérelt fejlesztés alapelveinek figyelembevételével történt. A tesztek megírásakor külön figyelmet kellett fordítani az adatbázis helyes kezelésére. A Google App Engine Datastore-ja az elosztott NoSQL adatbázisokhoz hasonlóan nem mindig azonnal végzi el a módosításokat az összes adatbázispéldányban. Az egységtesztek felkészíthetők arra is, hogy ezeket az esetleges inkonzisztenciákat kezelje. A szerver architekturális felépítése a 10. ábrán látható. 10. ábra: A szerver architekturális felépítése A kliensek a szerverrel közvetlenül servleteken keresztül kommunikálnak. A servletek minden kérés során először authentikálják a felhasználót, majd sikeres engedélyeztetés esetén a modellen keresztül férnek hozzá az adatbázishoz. 58

59 Amikor a szervernek kell értesítenie a klienseket, akkor azt Google Cloud Messaging vagy Apple Push Notification segítségével teszi meg. Ezek az üzenetek az adott szolgáltatás szerverén keresztül jutnak el a készülékekhez. A Blobstore-t a készülékek feltöltés céljából közvetlenül használják a servletek által megadott URL-ek segítségével, a letöltés viszont csak a servletek használatával működik Android implementáció Az androidos alkalmazás Android 2.2-es (Froyo) rendszertől kezdve egészen a jelenlegi legfrissebb, 4.4-es (KitKat) rendszerig támogatva van, mind mobiltelefonon, mind pedig táblagépen Az androidos alkalmazás architektúrája Az alkalmazás mögöttes logikáját és kommunikációját egy service (WatchThisSiteService) kezeli. Ez a service az alkalmazás első indításakor, valamint megfelelő beállítás esetén a készülék elindítása után is automatikusan elindul. 11. ábra: Az Androidos alkalmazás architektúrája A service elindítása után lekérdezi, hogy be van-e jelentkezve valamelyik felhasználó. Ha igen, akkor authentikációt kezdeményez a rendszer felé, és azonosítja, hogy tényleg az ő készülékee. Mindez a felhasználó számára láthatatlan módon történik meg, neki elég egyszer belépnie, nem kell minden indítás után. Az authentikáció működése a es fejezetben van részletezve. 59

60 A szerverrel a hálózati kommunikációs modulon keresztül kommunikál az alkalmazás. Minden bejelentkezett felhasználó számára létrejön egy-egy adatbázis, amelyben lokálisan tárolja az alkalmazás a szerveren is eltárolt adatokat. Minden helyi módosítás először ebben az adatbázisban történik meg, és innen szinkronizálódik fel a szerverre. Ezen kívül a weboldalak korábbi változatai is csak a helyi adatbázisban találhatók meg, a szerver csak a legfrissebb verzióját tárolja minden oldalnak. Az ellenőrzések végrehajtásához az alkalmazás egy HTTP GET kérést küld a megadott URLre, és a visszaérkező választ hasonlítja össze az adatbázisában eltárolt legfrissebb változattal. A lekérésben a User Agent HTTP fejrészt beállítja, hogy a webkiszolgálók mobil weboldalt adjanak az alkalmazásnak Az androidos alkalmazás felhasználói felülete Az androidos alkalmazás az alábbi képernyőket tartalmazza: Oldalak listája: Felsorolja a felhasználó által figyelt oldalak listáját. Minden oldal leírása tartalmazza az utolsó változat időpontját, valamint egy csillaggal jelzi, ha az oldal megváltozott. Beállítások: A beállítások menüben lehetséges az alkalmazás beállításait módosítani. Oldal beállításai: Az oldal beállításaiban lehet megadni az ellenőrizendő oldal URLjét, valamint a megjelenítendő nevet. Oldal korábbi változatai: Itt tekinthetők meg egy oldal korábbi változatai. Változat megtekintése: Ez a nézet megjeleníti egy beépített webböngészőben az oldalnak egy megadott változatát. Változatok összehasonlítása: Ez a nézet összehasonlítja két különböző változatát az ellenőrzött weboldalnak. Bejelentkező képernyő: A bejelentkező képernyőn lehet kiválasztani, hogy melyik felhasználót szeretné használni a felhasználó az ellenőrizendő oldalak kezeléséhez. 60

61 12. ábra: A WatchThisSite Android képernyőképei Ezek a képernyők alapvetően egy-egy androidos képernyőként (úgynevezett activity-ként) valósulnak meg az alkalmazásban, kivéve a változat megtekintése és két változat összehasonlítása, mert ezek technikailag ugyanabban az activity-ben jelennek meg, csak eltérő tartalommal. Az alkalmazás felülete lokalizálva van, mindig a rendszerbeállításokban megadott nyelven jelenik meg a felhasználónak, ha le van fordítva arra a nyelvre. Jelenleg az angol és a magyar nyelv érhető el, egyéb beállított nyelv esetén az angolt használja Az androidos alkalmazás életciklusa A 13. ábrán látható egy példa az androidos alkalmazás életciklusára. A grafikon bemutatja, hogy mi történik az egyes események hatására. Az ábrán az alábbi eseménysorozat hatása követhető végig: A készüléket az 1. időpillanatban bekapcsolják, és mivel engedélyezve van az alkalmazás automatikus indítása, ezért elindul a szolgáltatás. Mivel WiFi hálózaton van a készülék, elkezdődik a kiosztott oldalak ellenőrzése. 61

62 13. ábra: Egy példa az androidos alkalmazás életciklusára Megváltozik az egyik figyelt oldal, ezt az ellenőrzésekor észreveszi a készülék. Ezt közli a szerverrel, ami ennek hatására visszajelez a készüléknek, az pedig megjeleníti az értesítést a felhasználó készülékén. Amikor később még egyszer megváltozik a weboldal, arról is értesíti a készülék a szervert, azonban nem jelenik meg új értesítés (szükség esetén a meglévő értesítés frissítésre kerül). A 2. időpillanatban a felhasználó az értesítésre bökve elindítja az alkalmazást, az előtérbe kerül. Ekkor az értesítés eltűnik, az alkalmazás a háttérben ilyenkor is folyamatosan végzi az ellenőrzéseket. Kicsivel később megszűnik a készülék minden hálózati kapcsolata. Eközben módosítás történik a weboldalon, amit nem tud a készülék észlelni. Időközben egy másik készülék elvégzi az oldal ellenőrzését, a szerver értesíti a készüléket Google Cloud Messaging segítségével. A 3. időpillanatban a készülék újra kapcsolódik a hálózathoz. Ekkor megérkezik számára a már korábban kiküldött GCM üzenet, és az értesítést a módosításról megjeleníti a felhasználónak. Ezt az értesítést a 4. időpillanatban megnyitja a felhasználó, így az eltűnik. Az 5. időpillanatban a felhasználó kézzel leállítja az alkalmazás futását. Ezután a készülék nem végez ellenőrzést, valamint nem értesít a megváltozó oldalakról sem olyan, mintha offline állapotban lenne. 62

63 A 6. időpillanatban az alkalmazás elindításával újra bekapcsolódik az alkalmazás. A készülék ekkor értesít az esetlegesen korábbi módosításokról a példában ilyen nem volt. A készülék újra végez aktív ellenőrzéseket. Ezután a készülék WiFi kapcsolatról mobilinternetes kapcsolatra vált. Mobilinternetes kapcsolat alatt a készülékek passzív állapotban vannak, nem ellenőrzik a weboldalakat. Az ellenőrzési feladat viszont kiosztásra kerül egy másik, aktív készülékre. A szerver GCM üzeneten keresztül mobilinternetes kapcsolat esetén is értesíteni tudja a felhasználót a változásokról. Az értesítéseket a felhasználó azok megtekintése nélkül is törölni tudja az értesítési felületről. A 7. időpillanatban a felhasználó kikapcsolja a készüléket, ezután nem történik több ellenőrzés, a szerver rövid idő után az életjelek hiányában a készüléket offline állapotba teszi ios implementáció Az ios-es alkalmazás az ios 6.1-es SDK használatával készült. Ez azt jelenti, hogy iphone 3GS, ipod touch 4 és ipad 2, vagy ezeknél újabb készülékeken a megfelelő rendszerfrissítések telepítése után használható az alkalmazás Az alkalmazás felépítése Az alkalmazás az ios-es konvencióknak megfelelően az MVC (Model-View-Controller) konvenciók figyelembe vételével készült el. A módszer lényege, hogy különválasztja az adatokat és az alkalmazás logikáját (modell) az alkalmazás felületétől (nézet), ezek között pedig a kontroller biztosítja a megfelelő kommunikációt. Modell: Az alkalmazás az offline lementendő adatokat egy Core Data adatbázisban tárolja. Ide tartoznak a weboldalak adatai, valamint azoknak az egyes változatai. Az oldalak és a változatok között egy-a-többhöz kapcsolat van, ezt a Core Data a megfelelő kapcsolat beállítása után automatikusan kezeli. Nézet: Az alkalmazás nézete az ios 5-tel együtt megjelent storyboard módszerrel lett elkészítve. Ennek a segítségével egyszerűsíthető a felhasználói felület összeállítása. Az elkészített storyboard vázlata a 14. ábrán látható. Kontroller: A kontroller köti össze a modellt a nézettel, kezeli a felhasználói felület eseményeit, azok hatását a modellre, illetve a kliens-szerver kommunikációra. 63

64 14. ábra: Az ios alkalmazás storyboardja Az alkalmazás felhasználói felülete Az ios-es WatchThisSite alkalmazás az alábbi képernyőkkel rendelkezik: Oldalak listája: itt lehet oldalakat hozzáadni, törölni, valamint innen elindulva lehet azokat manuálisan ellenőrizni. Oldal beállításai: Itt lehet beállítani az oldal nevét és URL-jét. Bejelentkező képernyő: Itt lehet megadni a Google login adatokat, ami alapján bejelentkeztet az alkalmazás. Változatok listája: Megjeleníti a készülékre lementett változatok listáját. Adott változat megtekintése: Megmutatja a készülékre mentett változatát az oldalnak. Változatok összehasonlítása: Ezzel a képernyővel össze lehet hasonlítani két korábban lementett változatot egymással. 64

65 15. ábra: Képernyőképek a WatchThisSite ios alkalmazásból A képernyők mindegyike egy-egy önálló ViewControllerrel van megvalósítva, az egyes képernyők egymással való kapcsolata a 14. ábrán, az alkalmazás storyboardján látható Kliens-szerver interfész A kliens és a szerver kommunikációja az 5. fejezetben megtervezett specifikációnak megfelelően lett implementálva, REST alapokon. A teljes kommunikáció titkosított (HTTPS) csatornán közlekedik, mivel minden kérés tartalmaz egy authentikációs tokent (erről bővebben a es szakaszban) REST A rendszer a kliens-szerver kommunikációhoz egy RESTful interfészt használ. A REST (Representational State Transfer) egy architekturális konvenció interfészek tervezésére. Azt, hogy egy interfész megfelel-e a REST architektúrának (azaz RESTful-e), az alábbi tulajdonságok határozzák meg: Kliens-szerver architektúra: a rendszerben mobil kliensek, valamint egy felhő alapú szerver van. Állapotmentes: a szervernek nem szükséges állapotot tárolni a kommunikáció során, minden szükséges adatot minden kérésben elküld a kliens a szerver felé. Gyorsítótárazhatóság: a kérések tartalmazzák, hogy melyik gyorsítótárazható (ahol régebbi adat is megfelelő), és melyik nem. 65

66 Réteges felépítés: a kliensnek nem kell tudnia, hogy közvetlenül a szerverrel kommunikál-e. Egységes interfész: az interfészen keresztül elérhető erőforrások az URL-ben egységes módon vannak leírva, és az egy szöveges választ ad vissza (a kifejlesztett rendszerben JSON objektumokat) Authentikáció A szerveroldali szolgáltatásnak szüksége van arra, hogy a felhasználókat egyértelműen beazonosítsa, így kezelve az általuk figyelt oldalak listáját, valamint kiosztva a szükséges feladatokat. Az authentikációhoz a rendszer az OAuth 2 rendszert használja [37], a Google szolgáltatásán keresztül. Emiatt a felhasználóknak rendelkezniük kell Google azonosítóval. A rendszerek az alábbiakban részletezett módon az authentikációt követően beszerzik a tokent, majd ezt elküldik az alkalmazásszervernek, ami ott ellenőrizni tudja annak hitelességét. A token beszerzése Android és ios rendszereken különböző módon történik: Android rendszer használatakor az alkalmazás a készüléken beállított Google fiókok segítségével azonosítja a felhasználót a szerver felé. Működésének lényege, hogy az alkalmazás lekér a Google Play Services szolgáltatástól egy egy óráig érvényes tokent a felhasználó által kiválasztott saját címére. Ezt a tokent ezután minden, a szerver felé irányuló kéréshez csatolja. Mivel a token digitálisan alá van írva a Google szolgáltatása által, így szerveroldalon ellenőrizhető, hogy tényleg a megadott cím tulajdonosa kezdeményezte-e az adott kérést. Emellett az is biztosítható, hogy a szolgáltatást hagyományos módon csak a megadott alkalmazáson keresztül lehessen elérni, más ne készíthessen a szervert használó alkalmazást. [38] Így egyedileg lehet azonosítani az egyes felhasználókat, anélkül, hogy külön felhasználói fiókot kellene az alkalmazás számára létrehozni, és annak hitelesítési adatait biztonságosan tárolni mind kliens, mind szerveroldalon. A tokenek kiállításához az androidos alkalmazásnak annak telepítésekor engedélyt kell kérnie a felhasználótól. ios-es készülékek esetén, mivel nincsenek beépített Google authentikációs lehetőségek, így manuális belépés szükséges. Ezt a Google által biztosított OAuth 2 szolgáltatáson keresztül lehet megtenni. Ez az authentikáció után egy ugyanolyan tokent biztosít az alkalmazás számára, mint amilyet az Android rendszer, így az is használható ezentúl hitelesítésre. Az OAuth authentikáció egyszerűsítésére ios rendszer alatt a Google Toolbox for Mac OAuth 2 Contollers csomagja használható. [39] A könyvtár biztosítja egyrészt az authentikációt a bejelentkezési adatok egy weboldalon keresztül közvetlenül a Google számára jutnak el, az 66

67 alkalmazás nem kezeli azokat, valamint az authorizációt is bejelentkezés után a Google engedélyt kér a felhasználótól, hogy továbbadja a fiókinformációkat az alkalmazás számára. Az egyszeri manuális bejelentkeztetés után az alkalmazás tárolja a hitelesítési adatokat (de nem a felhasználónevet és a jelszót), ezáltal több bejelentkezésre nincs szükség, viszont a Google rendszerétől mindig új token kérhető le. Erre azért van szükség, mivel a kapott tokenek biztonsági okokból ebben az esetben is csak 1 óráig érvényesek. Az authentikációs token elküldése minden egyes kérésben megtörténik (így marad RESTful a kommunikáció). A tokent a HTTP X-Auth-Token paraméterében küldi el a kliens a szervernek. Mivel a tokent megszerezve a kliens megszemélyesíthető lenne, ezért az összes kliens-szerver kommunikációt titkosított HTTPS kapcsolaton keresztül kell végrehajtani Összehasonlító algoritmus Mobil platformra történő programozás során fontos szempont, hogy az algoritmus ne használjon sok memóriát és processzoridőt. Ez egyrészt azért lényeges, mivel a mobil készülékek ma még általában lassabbak, gyengébbek az asztali számítógépeknél, másrészt mert az intenzív processzorhasználat gyorsabban meríti a készülék akkumulátorát. Mivel a mai okostelefonok többsége normál használat mellett sem bírja 1-2 napnál hosszabb ideig, az alacsony fogyasztás alapkövetelmény a mobil alkalmazásoknál, különösen azoknál, amelyek a háttérben futnak. Mivel az összehasonlító algoritmus viszonylag bonyolult művelet, itt különösen fontos volt az, hogy nagyobb weboldalakat is kevés erősforrást felhasználva tudjon összehasonlítani. Emiatt több optimalizációt is végre kellett hajtani: például a meglévő HTML DOM fát építő könyvtárak helyett saját algoritmust kellett írni a dokumentum értelmezésére, mivel azok túl sok memóriát foglaltak le már egy-egy bonyolultabb híroldal esetén is, ami miatt az Android rendszer leállította az alkalmazást Androidos implementáció A megtervezett összehasonlító algoritmus implementálásához szükség van egy egyszerű szöveges összehasonlító modulra, amely a GNU diffutils alkalmazáshoz hasonló módon képes összehasonlítani két szöveget. A rootolt androidos készülékek többségén megtalálható a BusyBox nevű alkalmazáscsomag, amelynek segítségével különböző unixos programok futtathatók a virtuális gépet kikerülve, közvetlenül a kernelszint felett. Ez a csomag tartalmazza a diff parancsot is, ami így natív módon képes egyszerű szöveges összehasonlítást végezni. Kézenfekvőnek tűnik ezt az implementációt használni az összehasonlításra, mivel gyors, és több mint 20 éve gond nélkül 67

68 használják a unixos implementációját. Az implementáció open source, GNU GPL v3 licenc alatt szabadon elérhető. [22] Viszont mivel a készülékeknek csak töredéke rootolt, szükséges egy minden eszközön használható külső könyvtárat használni az összehasonlításra. A natív, nyílt forrású GNU Diffutils egyik Java portja, a java-diff-utils szabadon elérhető és használható androidos alkalmazásokban, ezt használja az alkalmazás a szöveges összehasonlításra. [40] Használt adatszerkezetek Az egyes dokumentumok az Android rendszer részét képező SparseArray adatszerkezetben tárolják az elemeket. Erre azért van szükség, hogy gyorsan meg lehessen találni az egyes elemek párját, de könnyen végig is lehessen járni az elemeken. A hashértékekből az elemekhez egy hashtábla segítségével lehet visszajutni. Ennek előnye, hogy miután az algoritmus megkapja az eredményeket a mozgatáskereső modultól, gyorsan meg lehet jelölni a megfelelő elemet Architekturális modell A 16. ábra bemutatja az alkalmazás implementációjának architekturális modelljét. A szöveges összehasonlító mód szükség esetén könnyen lecserélhető, akár az eredeti diff-es megoldásra, akár egy másik könyvtárra. java-diff-utils WatchThisSite Java SE 6 HTML feldolgozó Hashelő Mozgatáskereső diff Összefésülő HTML előállító 16. ábra: Az androidos implementáció architekturális modellje 68

69 Eredmények Az alábbiakban látható az algoritmus futási eredménye két tesztelt weboldalra. 17. ábra: Az oldal korábbi változata [41] 18. ábra: Az oldal későbbi változata 19. ábra: A két változat összehasonlítása a kifejlesztett algoritmussal 69

70 20. ábra: Az oldal a változtatás előtt 21. ábra: Az oldal a változtatás után 22. ábra: Az eltéréseket megjelenítő oldal. Sötétebb színnel a változás, világosabb színnel a mozgatás jelenik meg. 70