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.
PÁZMÁNY PÉTER KATOLIKUS EGYETEM INFORMÁCIÓS TECHNOLÓGIAI KAR
SZAKDOLGOZAT TÉMA BEJELENTÉS Név:
Hunyady Márton
Tagozat: nappali
Szak: Mérnök informatikus BSc (IANI-MI)
Témavezető neve:
Tornai Kálmán, dr. Oláh András
A dolgozat címe:
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ó 100-150 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!
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, 2013. április 29.
.................................................... Hunyady Márton
A szakdolgozat-témát az Információs Technológiai Kar jóváhagyta. Budapest, 2013…………….. ...................................................... Dr. Szolgay Péter dékán
A Hallgató a konzultációkon részt vett: Budapest, 2013.……………..
.................................................... Tornai Kálmán
.................................................... dr. Oláh András
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, 2013. december 3.
.................................................... Hunyady Márton
Tartalomjegyzék 1.
2.
Bevezetés és célkitűzések ................................................................................................ 13 1.1.
Technológiai háttér ................................................................................................... 13
1.2.
Feladat és célkitűzés ................................................................................................. 14
1.3.
A szakdolgozat felépítése ......................................................................................... 15
Elérhető megoldások........................................................................................................ 17 2.1.
2.1.1.
Desktop platformon elérhető alkalmazások...................................................... 17
2.1.2.
Online, platformfüggetlen szolgáltatások ......................................................... 18
2.1.3.
Android platformra elérhető alkalmazások ...................................................... 18
2.1.4.
iOS platformra elérhető szolgáltatások ............................................................. 19
2.2.
3.
Összehasonlítási szempontok ........................................................................... 22
2.2.2.
Szöveges fájlok összehasonlítása ..................................................................... 22
2.2.3.
XML fájlok összehasonlítása............................................................................ 23
2.2.4.
HTML fájlok összehasonlítása ......................................................................... 24
2.2.5.
Az algoritmusok összehasonlítása .................................................................... 25
A megvalósításhoz használt technológiák ....................................................................... 27 Mobil operációs rendszerek ...................................................................................... 27
3.1.1.
Android ............................................................................................................. 28
3.1.2.
iOS .................................................................................................................... 29
3.2.
Felhőszolgáltatások .................................................................................................. 30
3.2.1.
Felhőszolgáltatások felosztása szolgáltatásaik alapján ..................................... 30
3.2.2.
Felhőszolgáltatások felosztása elérhetőségük alapján ...................................... 30
3.2.3.
Elérhető felhőszolgáltatások ............................................................................. 31
3.2.4.
Szerveroldali adattárolás a Google App Engine-en .......................................... 32
Rendszerarchitektúra ....................................................................................................... 35 4.1.
5.
Összehasonlító alkalmazások és algoritmusok ......................................................... 21
2.2.1.
3.1.
4.
Weboldalfigyelő alkalmazások................................................................................. 17
Készülékállapotok .................................................................................................... 35
4.1.1.
Aktív állapot ..................................................................................................... 36
4.1.2.
Passzív állapot .................................................................................................. 36
4.1.3.
Offline állapot ................................................................................................... 36
4.2.
Szerver ...................................................................................................................... 37
4.3.
Megoldások a feladatok kiosztására ......................................................................... 37
Rendszerszintű funkcionális specifikáció ........................................................................ 39 5.1.
Szerver által nyújtott funkcionalitás ......................................................................... 39
5.1.1.
Ellenőrizendő oldalak listája megváltozik ........................................................ 39
5.1.2.
Életjel jellegű üzenetek ..................................................................................... 40
5.1.3.
Állapotváltozások jelzése a szervernek ............................................................ 42
7
6.
7.
5.1.4.
Figyelt oldalak listájának módosítása ................................................................43
5.1.5.
Adminisztráció ..................................................................................................43
5.2.
Szerveroldali adattárolás ...........................................................................................44
5.3.
Kliens funkciói ..........................................................................................................46
Összehasonlító algoritmus ................................................................................................49 6.1.
Specifikáció ...............................................................................................................49
6.2.
A WatchThisSite összehasonlító algoritmusa ...........................................................51
6.2.1.
Értelmezés .........................................................................................................52
6.2.2.
Azonos részek és mozgatások keresése .............................................................53
6.2.3.
A dokumentumok összefésülése........................................................................54
6.2.4.
Összefésült HTML előállítása ...........................................................................55
A WatchThisSite implementációja ...................................................................................57 7.1.
Szerver .......................................................................................................................57
7.2.
Android implementáció .............................................................................................59
7.2.1.
Az androidos alkalmazás architektúrája ............................................................59
7.2.2.
Az androidos alkalmazás felhasználói felülete ..................................................60
7.2.3.
Az androidos alkalmazás életciklusa .................................................................61
7.3.
7.3.1.
Az alkalmazás felépítése ...................................................................................63
7.3.2.
Az alkalmazás felhasználói felülete ..................................................................64
7.4.
Kliens-szerver interfész .............................................................................................65
7.4.1.
REST .................................................................................................................65
7.4.2.
Authentikáció ....................................................................................................66
7.5.
8.
iOS implementáció ....................................................................................................63
Összehasonlító algoritmus .........................................................................................67
7.5.1.
Androidos implementáció .................................................................................67
7.5.2.
Használt adatszerkezetek ...................................................................................68
7.5.3.
Architekturális modell .......................................................................................68
7.5.4.
Eredmények .......................................................................................................69
7.5.5.
Az implementáció előnyei .................................................................................71
Eredmények összefoglalása ..............................................................................................73 8.1.
Elvégzett feladatok ....................................................................................................73
8.2.
Elért eredmények .......................................................................................................73
8.3.
Továbbfejlesztési lehetőségek ...................................................................................75
Irodalomjegyzék ........................................................................................................................77 Melléklet: Az implementáció elérhetősége ...............................................................................81
8
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
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
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.
1.1. 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
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.
1.2. 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
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
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.
2.1. 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.
2.1.1. 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 100 000 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 30-100 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
2.1.2. 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 e-mail címet, amire a változtatásokról értesítő e-mailt 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 60-380$/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]
2.1.3. 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 10-50 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, 500-1000 letöltéssel. [9]
–
WebPage Alerts: A webpagealerts.com webes szolgáltatás androidos alkalmazása mobiltelefonokra (a táblagépeket nem támogatja). 50-100 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
–
Website Watcher: Weboldalfigyelő alkalmazás, 500-1000 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, 100-500 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.
2.1.4. 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
1. táblázat: Az ismertetett weboldalfigyelő alkalmazások
Program neve
Ár
Rendszer
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
Desktop (Windows)
30€
+20€
igen
+30€
nincs
NotiPage
Desktop (Windows)
ingyenes
igen
igen
nem
nincs
Copernic Tracker
Desktop (Windows)
30$
igen
igen
igen
nincs
ChangeDetection.com
Online (e-mail)
ingyenes
igen
igen
nem
naponta
Google Reader
Online (web)
ingyenes
igen
igen
igen
figyelők számától függ
Versionista
Online (web)
5 oldalig ingyenes 200-2000 oldalig 60-380$/hó
igen
igen
4 változat (ingyenes) 20-50 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 (e-mail)
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
nem
nem
nem
nincs
nem
nem
nem
nincs
utána 0,9€ WebChanges
iOS
ingyenes
Megszűnt
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 (
), de az XML-ben ilyenkor kötelező önlezáró taget (
) 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
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]
2.2.1. Ö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.
2.2.2. 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
–
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]
2.2.3. 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
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.
2.2.4. 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
ö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 összehasonlító modulját használja az egyezések megtalálására. (Ez a modul a RatcliffObershelp
algoritmus
alapján
működik.
Mivel
[29])
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]
2.2.5. 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
Összehasonlítás
Nyelv
Mozgatások detekciója
Szabványos HTML
Leghosszabb közös részsorozat
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
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
3. 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.1es alfejezet ismerteti azokat a mobil operációs rendszereket, amelyeken a kliensek futnak, a 3.2es alfejezet pedig bemutatja az elérhető felhőszolgáltatásokat, majd specifikusan a Google App Engine-t is, amelyen a szerver működik.
3.1. 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%
Android
40%
iOS
30%
SymbianOS Samsung
20%
Windows Phone
10%
Sony Ericsson Egyéb
2013.12.
2013.08.
2013.04.
2012.12.
2012.08.
2012.04.
2011.12.
2011.08.
2011.04.
2010.12.
2010.08.
2010.04.
2009.12.
2009.08.
2009.04.
2008.12.
0%
2. ábra: Mobil operációs rendszerek elterjedtsége Magyarországon 2008. december – 2013. 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
3.1.1. 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
3.1.2. 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
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]
3.2.1. 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.
3.2.2. 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
–
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.
3.2.3. 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
3.2.4. 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 1 000 000 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 50 000 í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
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
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ó.
5. ábra: Az alkalmazás architektúrája
4.1. Készülékállapotok 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
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.
4.1.1. 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.
4.1.2. 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.
4.1.3. 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
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.
4.3. 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
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
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.
5.1. 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ó.
5.1.1. 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
Leírás
Ellenőrizendő oldalak listája
Visszaadja az ellenőrizendő oldalak listáját Visszaadja az adott oldal utolsó ellenőrzött változatát
Oldal utolsó ellenőrzött változata
Módszer
Paraméter
/devices/ <deviceid>/ pages
GET
nincs
/pages/
/ content
GET
nincs
URL
39
5.1.2. É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
Aktív életjel
Rögzíti az életjel időpontját.
Passzív életjel
Rögzíti az életjel időpontját.
Van változás
Nincs változás
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.
URL /devices/ <deviceid>/ activeheartbeat /devices/ <deviceid>/ passiveheartbeat /devices/ <deviceid>/ changed/ <pageurl> /devices/ <deviceid>/ checked/ <pageurl>
Módszer POST
Paraméter nincs
POST
nincs
POST
nincs
POST
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
Az androidos készülékek kiértesítéshez használt GCM üzenet formátuma: action: page_changed url: time: Az iOS készülékekre pedig az Apple Push Notification üzenet formátuma: aps.alert: <megjelenítendő üzenet szövege> url:
6. ábra: Tevékenységek oldal megváltozása esetén
41
5.1.3. Á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 5.1.1-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 5.1.1-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 Á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.
URL /devices/ <deviceid>/
Módszer
Paraméter
POST
state=active
POST
state=passive
GET
nincs
state /devices/ <deviceid>/
state /cron/ detectoffline
(csak automatikusan hívható)
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 5.1.1-es pont alapján.
42
5.1.4. 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 Oldal hozzáadása vagy módosítása Oldal törlése Figyelt oldalak listája
Leírás A szerver eltárolja a figyelés igényét az adatbázisában. Ha még nem létezett, hozzáadja az oldalak listájához. A szerver törli az oldalt a felhasználó oldalai közül. Visszaadja a figyelt oldalak listáját.
URL /users/ <useremail>/ pages/ <pageurl>
/users/ <useremail>/ pages/ <pageurl> /users/ <email>/ pages
Módszer POST
Paraméter nincs
DELETE
nincs
GET
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 5.1.1-es pont alapján.
5.1.5. 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
–
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
POST
email: a
Új felhasználót hoz létre a megadott e-mail-címmel.
/users
Listázza az összes regisztrált felhasználót. Csak adminisztrátoroknak. Adott felhasználóhoz hozzácsatol egy készüléket.
/users
GET
nincs
/devices
POST
owner-email:
Beállítja a készüléknek a push id-t.
/devices/ / push /devices
POST
GET
nincs
/users/ <email>/ devices
GET
nincs
felhasználó email címe
Listázza az összes készüléket. Csak adminisztrátoroknak. Listázza a felhasználó összes készülékét.
tulajdonos email címe id: készülékazonosító pushid: a beállítandó id type: apn/gcm
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
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 5.1.1. fejezetben).
45
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 5.1.3-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 5.1.1-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 5.1.2-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 5.1.2. 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 (5.1.3. pont).
Életjel: Adott időközönként közli a szerverrel, hogy még online állapotban van (passzív életjel az 5.1.2-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
ellenőrizendő oldalak. Az ellenőrzés után ilyenkor is közli a szerverrel az ellenőrzés eredményét az 5.1.2. 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 5.1.4. 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 5.1.2. 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
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).
6.1. 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
–
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
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 (6.2.2. alfejezet),
–
dokumentumok összefésülése (6.2.3. alfejezet),
–
összefésült dokumentum kiemeléssel bővített HTML formára alakítása (6.2.4. 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
6.2.1. É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 kék bálna (Balaenoptera musculus) az emlősök osztályába tartozó faj.
Értelmezett elemek: A kék bálna (Balaenoptera musculus) az emlősök osztályába tartozó faj
. 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. ). 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
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.
6.2.2. 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 kék bálna (Balaenoptera musculus) az emlősök
9ee6c5b1 9ee6c5b1 506b9865 506b9865
2eacbe29 521bb373 bb5fa98c 4dc6cfdd
9ee6c5b1 e216753f e216753f
13b92d61 ecc9793c 34eb787a
9ee6c5b1 9ee6c5b1
65aa39e2 a741b02f
47a37dd1
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
– 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 részlete: @@ -924,2 +920,0 @@ -9ee6c5b1#88818785 -cfc95292#fd1cf52a @@ -962,0 +958,2 @@ +9ee6c5b1#88818785 +cfc95292#e61f6449
6.2.3. 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
–
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.
6.2.4. Ö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 és <del> tagje is.
55
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.
7.1. 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
–
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
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.
7.2. 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.
7.2.1. 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 7.4.2-es fejezetben van részletezve.
59
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.
7.2.2. 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
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.
7.2.3. 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
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
–
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.
7.3. 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.
7.3.1. 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
14. ábra: Az iOS alkalmazás storyboardja
7.3.2. 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
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ó.
7.4. 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 7.4.2-es szakaszban).
7.4.1. 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
–
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).
7.4.2. 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 e-mail 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 e-mail 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
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.
7.5. Ö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.
7.5.1. 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
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]
7.5.2. 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.
7.5.3. 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
7.5.4. 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
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
7.5.5. Az implementáció előnyei A használt algoritmus legnagyobb előnye, hogy amellett, hogy törlésként és beszúrásként ismeri fel a mozgatásokat, felismeri azt is, hogy melyek a mozgatott szövegek. Ez azért hasznos, mivel bizonyos oldalaknál lényeges információ a sorrend megváltozása (például rangsorok), máshol viszont kevésbé fontos (például híroldalak). Ez a megoldás mindkét szempontot figyelembe veszi, de a felhasználó kívánságától függően oldalanként külön-külön is állítható lehet, hogy figyeljen-e a mozgatásokra, vagy csak a hagyományos módon beszúrásként és törlésként érzékelje. Emellett lényeges, hogy az implementáció szabványosabb HTML kódot állít elő, mint sok másik program: nem fordulhat elő, hogy az algoritmus megváltoztatja a <style> vagy a <script> tagek tartalmát.
Az algoritmus nem épít fel az összehasonlításhoz teljes DOM-fát, csak egy saját, egyszerű adatformátumot. Emiatt gyorsabb futást és alacsonyabb memóriahasználatot ér el a program, ami fontos szempont különösen mobil eszközökön, ahol a memória és a processzor is szűk keresztmetszet lehet.
71
8. Eredmények összefoglalása Ez a fejezet bemutatja a szakdolgozat elkészítése során elvégzett feladatokat, összefoglalja az elért eredményeket, valamint felvázolja a legfontosabb továbblépési lehetőségeket.
8.1. Elvégzett feladatok Elkészült a Google App Engine-en futó WatchThisSiteServer alkalmazásszerver. Az alkalmazásszerver jelenleg egy egyszerű változatát használja a feladatkiosztásnak, amelyben az ellenőrizendő weboldalakat sorban osztja ki az aktív készülékeknek. A szerver képes az ellenőrizendő oldalak listájának felhasználónkénti kezelésére, szinkronizációjára, a kliensek állapotának kezelésére, az ellenőrzött weboldalak utolsó változatának eltárolására, valamint az oldalak megváltozása esetén a kliensek kiértesítésére. Elkészült a kliens alkalmazás androidos és iOS-es implementációja is. Mindkét változat képes manuálisan ellenőrizni a felhasználó által figyelt oldalakat, eltárolni a weboldalak korábbi változatait, valamint offline is működni a már ellenőrzött oldalakkal. Emellett mindkét változat képes passzív módon értesülni a felhasználója által figyelt weboldalak változtatásairól. Az androidos alkalmazás emellett aktív módban is tud működni, és képes a számára kiosztott ellenőrzési feladatokat automatikusan, a háttérben futva elvégezni, azok eredményét feltölteni a szerverre. (Mivel iOS 6.1 rendszer alatt ez nem megvalósítható, az azóta erre képes iOS 7 pedig csak a szakdolgozat írása közben jelent meg, így az iOS rendszereken megvalósított aktív ellenőrzés nem része a jelenlegi megvalósításnak.) Megtörtént a szakdolgozatban megtervezett összehasonlító algoritmus implementációja is Android rendszerre. Ennek segítségével a felhasználó az alkalmazásból könnyen meg tudja nézni az oldal utolsó megtekintése óta történt változtatásokat, de az eltárolt korábbi változatokat is össze tudja hasonlítani. A kifejlesztett rendszer segítségével minden weboldalt csak egy kliens ellenőriz, így tehermentesítve mind a mobil készülékeket, mind pedig a weboldalt kiszolgáló szervert. Emellett ennek segítségével megoldhatóvá vált, hogy az iOS-es készülékek is azonnal értesíteni tudjanak a változtatásokról, ne csak az alkalmazás megnyitása után.
8.2. Elért eredmények A kifejlesztett WatchThisSite alkalmazás teljesíti a szakdolgozat elején kikötött feltételeket: képes automatikusan, a háttérben értesíteni a weboldalak módosításairól, képes elmenteni a
73
weboldalak korábbi változatait is, valamint megmutatni a változásokat egyrészt az oldal utolsó látogatása óta, másrészt két tetszőleges korábbi változat között is. A 8. táblázat összehasonlítja a meglévő, mobil platformon működő alkalmazások funkcionalitását a szakdolgozatban kifejlesztett WatchThisSite alkalmazás funkcionalitásával. 8. táblázat: A meglévő weboldalfigyelő alkalmazások és a WatchThisSite alkalmazások összehasonlítása
Program neve
Automatikus háttérben működés
Rendszer
Régebbi változatok mentése
Összehasonlítás
SiteWatcher
Android
X
Webpage Update Detector
Android
X
WebPage Alerts
Android (e-mail)
X
Website Watcher
Android
X
Website Checker
Android
X
Site Tracker
iOS (iPad)
Webpage monitor
iOS
WebChanges
iOS
WatchThisSite Android
Android
X
X
X
WatchThisSite iOS
iOS
X
X
X
X
A weboldalfigyelő alkalmazás funkcionalitása mellett fontos szempont volt az összehasonlító algoritmus működése is: követelmény volt, hogy szabványos HTML-t állítson elő, ne essen szét az oldal az összehasonlítás következtében, valamint hogy képes legyen detektálni a szövegek mozgatását, ezáltal elkerülve a felhasználók felesleges értesítését a módosításokról. A 2.2.4-es pontban ismertetett HTML összehasonlító algoritmusokat hasonlítja össze a 9. táblázat a szakdolgozatban kifejlesztett WatchThisSite összehasonlító algoritmussal. 9. táblázat: A létező összehasonlító algoritmusok és a WatchThisSite algoritmus összehasonlítása Algoritmus/ program
Összehasonlítás
HTMLdiff
HTML
DaisyDiff
HTML
Aaron Swartz’s diff.py
HTML
Page monitor
HTML
WatchThisSite
HTML
Mozgatások detekciója
Szabványos HTML
X
X X
74
X
8.3. Továbbfejlesztési lehetőségek Az alkalmazásnak a szakdolgozatban elkészült változata működőképes és használható rendszert alkot. Emellett azonban – ahogyan minden rendszeren lehet valamit javítani – itt is van még több, eddig – a feladat komplexitása vagy a szükséges technikai háttér hiánya miatt – nem megvalósított feladat. Ezek közül az alábbiak azok, amelyekkel első körben érdemes lehet foglalkozni: –
Feladatok fejlettebb elosztása: A jelenleg implementált feladatelosztó algoritmus elsősorban arra figyel, hogy az ellenőrizendő oldalak egyenletesen legyenek szétosztva a készülékek között. Egy okosabb megoldás, amellett, hogy csökkentené a szerver terhelését (ne kelljen teljesen újraosztani az ellenőrzött oldalakat az aktív készülékeknek egy-két új oldal vagy néhány készülék passzívvá válása miatt), abban is fejlődhetne, hogy a készülékeknek igyekezne a saját felhasználójuk oldalait kiosztani. Ez egyrészt azért lenne célszerű, mivel a felhasználók szívesebben fordítják a telefonjuk kapacitását a saját céljaikra, másrészt ekkor a legfrissebb változat amúgy is le lenne töltve a készülékekre a sikeres ellenőrzés után, nem kellene külön letölteni azt a szerver értesítésére. Emellett érdemes lehet megfontolni az oldalak kötegelt ellenőrzését is: a mai okostelefonok kevesebb energiát fogyasztanak, ha nem pár percenként rövid műveleteket, hanem ritkábban hosszabb műveleteket végeznek. Erre is megoldást kínál az elosztott rendszer: a szerver közreműködésével megoldható, hogy nem minden készülék egy-két weboldalt ellenőriz gyakran, hanem mindig másik készülék ellenőriz egyszerre sok weboldalt.
–
Intelligens változásdetekció: A jelenleg létező weboldalfigyelő alkalmazásoknak hátránya, hogy nehéz megmondani nekik, hogy melyik változtatások azok, amik érdeklik a felhasználókat egy weboldalon. Az elosztott számítási kapacitásnak, és az így elérhető gyakori (kb. 5 percenkénti) ellenőrzéseknek köszönhetően megoldható lenne, hogy a készülékek annak megfelelően detektáljanak változást vagy nem változást, hogy egy adott szövegrész milyen gyakran változik meg. Így a gyakran változó weboldalrészletek (pl. bejelentkezett felhasználók listája fórumoknál, aktuális euró árfolyam pénzügyi híroldalaknál) valószínűleg nem lényeges változások, míg a havonta 2-3 alkalommal módosuló tartalmak sokkal fontosabbak lehetnek. A változtatások fontosságának eldöntése egyrészt történhet automatikusan, másrészt pedig a felhasználók visszajelzései alapján (egyéni, illetve közösségi módon egyaránt), a kliens
75
alkalmazásokban pedig beállítható lenne, hogy mennyire kis vagy nagy változtatásokra kér értesítést a felhasználó. Ezzel összefüggésben továbbfejleszthető az összehasonlító algoritmus, hogy ezek alapján súlyozza és jelenítse meg különböző módon a fontos és a kevésbé fontos módosításokat. –
Aktív iOS-es készülékek: A rendszer struktúrájának kialakításakor az iOS alapú készülékek mind passzív készüléknek lettek tervezve, mivel az akkor legfrissebb iOS 6.1-es rendszer nem támogatta az alkalmazások háttérben futtatását, amire az aktív ellenőrzésnek mindenképpen szüksége van. Az iOS 7 2013 szeptemberi megjelenésével lehetővé vált az iOS-es készülékeken is az aktív, háttérben történő ellenőrzés végrehajtása. Ennek implementálása a szakdolgozat keretében nem történt meg, viszont célszerű lenne a közeljövőben megtenni azt, elsősorban az androidos készülékek tehermentesítése végett. Hasonló célból megfontolandó lehet egy PC-s kliens elkészítése is.
76
Irodalomjegyzék [1] M. Shawabkeh, Page Monitor, 21. Aug. 2013. [Online]. Available: https://chrome.google.com/webstore/detail/pagemonitor/pemhgklkefakciniebenbfclihhmmfcd/. [2] WebSite-Watcher, [Online]. Available: http://aignes.com/. [3] NotiPage, [Online]. Available: http://www.notipage.com/en/index.php. [4] Copernic Tracker, [Online]. Available: https://www.copernic.com/en/products/tracker/. [5] Changedetection.com, [Online]. Available: http://www.changedetection.com/. [6] L. Ma, Follow changes to any website, The official Google Reader Blog, [Online]. Available: http://googlereader.blogspot.hu/2010/01/follow-changes-to-any-website.html. [7] Versionista, [Online]. Available: https://versionista.com/. [8] Google Play Store, Site Watcher [Online]. Available: https://play.google.com/store/apps/details?id=net.amilab.SiteWatcher. [9] Google Play Store, Webpage Update Detector, [Online]. Available: https://play.google.com/store/apps/details?id=com.solid.wud. [10] Google Play Store, WebPage Alerts, [Online]. Available: https://play.google.com/store/apps/details?id=com.tiggzi.project69326. [11] Google Play Store, Website Watcher, [Online]. Available: https://play.google.com/store/apps/details?id=dk.creen.websitewatcher. [12] Google Play Store, Website Checker, [Online]. Available: https://play.google.com/store/apps/details?id=com.omgapps.websitechecker. [13] iTunes App Store, Site Tracker, [Online]. Available: https://itunes.apple.com/hu/app/site-tracker/id455514902?mt=8. [14] iTunes App Store, Webpage Monitor Free, [Online]. Available: https://itunes.apple.com/hu/app/webpage-monitor-free/id551522254?mt=8. [15] iTunes App Store, WebChanges, [Online]. Available: https://itunes.apple.com/hu/app/webchanges/id326079644?mt=8. [16] B. Wilson, MAMA: W3C validator research, [Online]. Available: http://dev.opera.com/articles/view/mama-w3c-validator-research-2/. [17] W3C, HTML5 Reference, [Online]. Available: http://dev.w3.org/html5/htmlauthor/#void-elements-0.
77
[18] W3C, Polyglot Markup: A robust profile of the HTML5 vocabulary, [Online]. Available: http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html. [19] Powermapper, HTML Version Statistics, Sept. 2013. [Online]. Available: http://try.powermapper.com/demo/statsversions.aspx. [20] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. Stein, Új algoritmusok, Scholar Kiadó, 2003, p. 309. [21] J. Ratcliff and D. Metzener, Pattern matching: The gestalt approach, 1988. [22] I. Free Software Foundation, Comparing and Merging Files, GNU Diffutils manual, [Online]. Available: https://www.gnu.org/software/diffutils/manual/diffutils.html#Overview. [23] E. W. Myers, „An O(ND) Difference Algorithm and Its Variations,” Algorithmica 2., pp. 251-266, 1986. [24] Y. Wang, D. J. DeWitt and J.-Y. Cai, X-Diff: An Effective Change Detection Algorithm for XML Documents. [25] M. Corporation, The XML Diff and Patch GUI Tool, Jul. 2004. [Online]. Available: http://msdn.microsoft.com/en-us/library/aa302295.aspx. [26] A. Mouat, XML Diff and Patch Utilities, 2002. [27] GitHub, Myobie's htmldiff project, [Online]. Available: https://github.com/myobie/htmldiff. [28] G. V. d. Broeck, DaisyDiff, [Online]. Available: https://code.google.com/p/daisydiff/. [29] P. Manual, Difflib, [Online]. Available: http://docs.python.org/2/library/difflib.html. [30] A. Swartz, HTML Diff, 2003. [Online]. Available: http://www.aaronsw.com/2002/diff/. [31] Page Monitor Chrome Extension, [Online]. Available: https://code.google.com/p/pagemon-chrome-ext/. [32] Statcounter, Global stats, Top Mobile Operating Systems in Hungary, Dec. 2013. [Online]. Available: http://gs.statcounter.com/#mobile_os-HU-monthly-200812-201312. [33] Android system architecture, [Online]. Available: https://community.freescale.com/servlet/JiveServlet/showImage/38-11351687/android_fig1.png. [34] Apple Inc., iOS Technology Overview – About the iOS Technologies, [Online]. Available: https://developer.apple.com/library/ios/documentation/miscellaneous/ conceptual/iphoneostechoverview/Introduction/Introduction.html. [35] iOS rendszer architektúra, [Online]. Available: http://wiki.inf.utfsm.cl/images/6/65/IOS.jpg.
78
[36] P. Mell and T. Grance, The NIST Definition of Cloud, National Institute of Standards and Technology, U.S. Department of Commerce, 2011. [37] E. D. Hardt, RFC 6749: The OAuth 2.0 Authorization Framework, Microsoft, Oct. 2012. [38] T. Bray, Verifying Back-End Calls from Android Apps – Android Developers Blog, 8. Jan. 2013. [Online]. Available: http://android-developers.blogspot.hu/2013/01/verifyingback-end-calls-from-android.html. [39] Google Toolbox for Mac – OAuth 2 Controllers, 18. Mar. 2013. [Online]. Available: https://code.google.com/p/gtm-oauth2/wiki/Introduction. [40] Java-diff-utils, [Online]. Available: https://code.google.com/p/java-diff-utils/. [41] Wikipédia, Kék bálna, [Online]. Available: https://hu.wikipedia.org/wiki/K%C3%A9k_b%C3%A1lna. [42] Apple Inc., Local and Push Notification Programming Guide – Provisioning and Development, [Online]. Available: https://developer.apple.com/library/ios/documentation/NetworkingInternet/ Conceptual/RemoteNotificationsPG/Chapters/ProvisioningDevelopment.html.
79
Melléklet: Az implementáció elérhetősége Jelen szakdolgozat elektronikus változata, valamint a kifejlesztett androidos alkalmazás telepítője (apk) megtalálható a https://users.itk.ppke.hu/~hunma/watchthissite oldalon. Mivel a rendszer a továbbiakban is folyamatos fejlesztés alatt áll, így előfordulhat, hogy a régebbi kliens nem lesz kompatibilis a szerveren futó változattal, ezért a legfrissebb kliensek is folyamatosan felkerülnek ide. A szakdolgozathoz csatolt lemezmellékleten ezek mellett megtalálható az androidos és az iOSes alkalmazás, valamint a szerver forráskódja is. Az androidos alkalmazás az apk telepítése után működőképes tetszőleges, legalább 2.2-es Android verzióval rendelkező készülékeken. Forrásból fordítva a felhasználó szerveroldali hitelesítése, és emiatt a kliens-szerver kommunikáció nem fog működni, mivel az authentikáció megköveteli, hogy az alkalmazásfájl egy megadott titkos kulccsal legyen aláírva. [38] Az iOS-es alkalmazás Apple fejlesztői fiók birtokában lefordítható tetszőleges, a fejlesztői fiókhoz hozzáadott készülékre, azonban a változásokról való értesítés a rendszer korlátozásai miatt – mivel még nem került ki az Apple App Store-ba – csak az eredeti fejlesztői fiók tulajdonosa (jelen esetben az Egyetem) által jóváhagyott készülékeken tesztelhető, valamint forráskódból is csak a megfelelő titkos kulccsal rendelkezve fordítható le. [42] A lemezmelléklet tartalma: –
Jelen szakdolgozat elektronikus változata (Hunyady Márton szakdolgozat.pdf)
–
A WatchThisSite Android alkalmazás telepítője (WatchThisSiteAndroid.apk)
–
A WatchThisSite Android forráskódja (WatchThisSiteAndroid mappa, Eclipse projekt)
–
A WatchThisSite iOS forráskódja (WatchThisSiteIOS mappa, Xcode projekt)
–
A WatchThisSite Server forráskódja (WatchThisSiteServer mappa, Ecipse projekt)
81
