Tudományos Diákköri Dolgozat 2008

Tudományos Diákköri Dolgozat 2008

Intelligens környezet, intelligens iroda – virtuális üzenőfal megvalósítása

Készítették: Sik András Ferenc e-mail: [email protected] Gruber Kristóf e-mail: [email protected] V. éves műszaki informatikus mérnök hallgatók

Konzulens: Dr. Vida Rolland

e-mail: [email protected]

Budapesti Műszaki és Gazdaságtudományi Egyetem, Távközlési és Médiainformatikai tanszék

Sik András, Gruber Kristóf: Intelligens környezet, intelligens iroda – virtuális üzenőfal megvalósítása

Tartalomjegyzék 1. Bevezetés ..................................................................................... 4 1.1. Az intelligens környezetek áttekintése ................................................. 4 Tárgyalótermek lefoglalása intelligens rendszer segítségével ................ 5 Parkolást elősegítő információs rendszer ............................................... 5 Telefonfigyelő szolgáltatás ...................................................................... 5 „Intelligens tábla”, virtuális jelenlét .......................................................... 6 Dokumentumok rendezése, nyomon követése ....................................... 6 Belépőkártyára épülő szolgáltatások ....................................................... 7 1.2. A virtuális üzenőfal ................................................................................. 7 1.3. Felhasználási lehetőségek ..................................................................... 8 1.4. Az alkalmazás hardver oldali követelményeinek kidolgozása ........... 9 1.5. Az alkalmazás szoftver oldali követelményeinek kidolgozása ......... 11 1.6. A választott fejlesztési környezet paraméterei ...................................13 1.7. A Nokia N810, mint terminál .................................................................14

2. A virtuális üzenőfal használata .................................................

16 2.1. A szoftver környezet kialakítása és a program telepítése ................ 16 2.2. A program indítása ............................................................................... 17 2.3. A program főablaka .............................................................................. 19 2.4. Bejelentkezés aktív Bluetooth eszköz jelenléte nélkül ...................... 20 2.5. Jelszóval történő hitelesítés ................................................................ 21 2.6. A felhasználókhoz rendelt ablak .......................................................... 22 2.7. Új üzenet írása ...................................................................................... 23 2.8. Címzettek kiválasztása az elküldendő üzenethez .............................. 25

3. A virtuális üzenőfalat megvalósító szoftver moduláris felépítése .................................................................................... 26 3.1. A programról általánosságban ............................................................ 26 3.2. A program fájljai .................................................................................... 26 3.3. A konfigurációs fájlok formátuma ....................................................... 27 3.4. A program osztályai .............................................................................. 28 VirtualPostIt ........................................................................................... 28 OutgoingHandler ................................................................................... 28 IncomingHandler ................................................................................... 29 MainWindow ......................................................................................... 29 UserWindow .......................................................................................... 29 NewMessageWindow ........................................................................... 30 RecipientWindow .................................................................................. 30 NoDeviceWindow .................................................................................. 31 3.5. A program működése ........................................................................... 31 A kontroller működése .......................................................................... 31 A modell működése ............................................................................... 32 A grafikus felület működése .................................................................. 37 2


3.6. Fejlesztési lehetőségek ........................................................................ 38 Grafikus felület lecserélése ................................................................... 39 Új formátumok támogatása ................................................................... 39 A mobilról küldött üzenetek információtartalmának bővítése ................ 39 3.7. Jövőbeli terveink ................................................................................... 39 Web-es felület elkészítése .................................................................... 39 Áttérés adatbázis alapú tárolásra .......................................................... 40 Bluetooth jelerő információk felhasználása ........................................... 40 SMS értesítő kiküldése ......................................................................... 40 További multimédiás szolgáltatások ...................................................... 40

4. Összefoglalás ............................................................................. 41 5. Köszönetnyilvánítás ..................................................................

41 6. Rövidítéslista .............................................................................. 42 7. Irodalomjegyzék ......................................................................... 43

3


1. Bevezetés Napjainkban egyre inkább elterjed az a nézet, hogy a jövő az intelligens környezeté, a mindenütt jelenlévő hálózatoké. A felhasználót körülvevő intelligens eszközök kommunikációja által számos új, értéknövelt szolgáltatás biztosítására nyílik lehetőség. Dolgozatunkban egy ilyen szolgáltatást nyújtó rendszer megtervezését és megvalósítását tűztük ki célul, mely a manapság sokat emlegetett „intelligens iroda” technikai környezetének egy praktikus részét alkothatja. 1.1. Az intelligens környezetek áttekintése Az elmúlt években az informatikai technológiák nagy léptékű fejlődése és általánosan elérhetővé válása lehetővé tette, hogy az addig az intelligens irodával foglalkozó elképzelések konkrét formát öltsenek. Ezek a megoldások könnyen csoportosíthatóak olyan közérthető és elfogadott szempontok köré, mint a felhasználók kényelmének elősegítése, hatékonyságnövelés, vagy a környezetvédelem. Egy ilyen intelligens irodát intelligens eszközök építik fel, melyek alapvetően három részre oszthatók: érzékelők, döntéshozók, beavatkozók. Az érzékelő részt – mint azt neve is mutatja – legegyszerűbben egy olyan berendezésnek (illetve berendezések hálózatának) képzelhetjük el, mely bizonyos fizikai mennyiségek megfigyelt értékét olyan jelekre fordítja le, ami egy másik eszköz (jelen esetben a döntéshozó), vagy egy (emberi) megfigyelő számára értelmezhető. A döntéshozó egység az érzékelőtől kapott adatok alapján, és egy előre beprogramozott döntési táblát figyelembe véve utasításokat fogalmaz meg, majd az adandó választ elektronikus jelek formájában továbbítja a végrehajtó részeknek. A végrehajtó rész többfajta funkciót láthat el, ugyanis tipikusan több különféle fizikai eszköz, illetve informatikai eljárás építi fel. Ezek a részegységek természetesen különböző jellegű jelekkel vezérelhetők, melyeket a döntéshozó egységtől kapnak. Ezeknek az építőköveknek tekinthető alapelemeknek felhasználásával hozhatjuk létre a legkülönfélébb intelligens eszközöket, betöltve ezekkel „intelligens irodánkat” (tágabb értelemben nézve az „intelligens épületünket / munkahelyünket”). Ugyanezen eszközök felhasználásával számos irodában, munkahelyen felmerült problémát megoldhatunk, illetve súlyosságukon enyhíthetünk számottevő erőforrás felhasználása nélkül. Az alábbi felsorolás a teljesség igénye nélkül említ meg néhány lehetséges alkalmazást (dolgozatunk címadó alkalmazása mellett):

Jelen dolgozat a Mobil Innovációs Központ 2.1. számú projektjének keretében, a Nemzeti Kutatási és Technológiai Hivatal támogatásával készült. (Mobil 01/2004 szerződés)

4


1.1.1. Tárgyalótermek lefoglalása intelligens rendszer segítségével

Manapság a nagyvállalatok által alkalmazott nagyszámú dolgozó munkaköri megbeszéléseit lebonyolítani létszámukból kifolyólag rendkívül nehezen megoldható. Éppen ezért a tárgyalótermekhez való hozzáférés minden vállalatnál szabályozott módon működik, vagyis előre le kell foglalni a használni kívánt tárgyalót, úgy, hogy az adott foglalási időtartam ne ütközzön más foglalások időtartamával. Hasonlóan megfigyelhető jelenség, hogy a tárgyalótermekre érkező foglalások eloszlása nem egyenletes; előfordul, hogy bizonyos napokon a termek nagy része kihasználatlan, míg más időpontokban az igények nagy száma miatt a foglalások egyáltalán nem, vagy csak megszorításokkal és általános megelégedés nélkül kivitelezhetőek. A problémára hatékony megoldás lehet, ha a foglalási rendszerbe bevonjuk az összes szabadon elérhető tárgyalót, majd ezt a rendszert többletfunkciókkal ruházzuk fel: pl. foglalásokkal kapcsolatos értesítések, foglalás megerősítésének kérése, valamely kritériumok alapján történő keresés, foglalások módosítása. Ezt követően a foglalási rendszerre ráépíthetünk egy „intelligens teremelosztót”, melyben konkrét terem keresése helyett valamilyen kívánt kritériumhalmazt adunk meg. Valószínű, hogy az esetek nagy részében a „hagyományos módszer” a fentivel hasonló eredményt hoz, azonban ha a kritériumainknak több terem is megfelel, kiválaszthatjuk a legjobban megfelelőt, ezáltal elérve a lehető legjobb kihasználást. 1.1.2. Parkolást elősegítő információs rendszer

Rengeteg nagyvállalatnál, irodaháznál okoz problémát a dolgozók gépjárműveinek elhelyezése. Előfordulhat például, hogy az épületben az előre tervezettnél több embert foglalkoztatnak, így az épület parkoló része nem lesz alkalmas a dolgozók teljes gépjárműállományának kiszolgálására. Megtörténhet ilyenkor, hogy a dolgozók akkor is behajtanak a parkolóba, ha az már megtelt, ezzel időt pazarolva és a parkoló légterét szennyezve. Ez a probléma orvosolható lenne, ha a mélygarázs bejáratánál elhelyezett számkijelző mutatná a garázsban levő szabad helyek számát; Ez azonban még nem nyújtana garanciát arra, hogy a gépjármű vezetője elfogadható időn belül meg is találja a szabad parkolóhelyeket. Ezt a hiányosságot az egész parkoló, illetve mélygarázs rendszerre kiterjedő szenzorhálózat telepítésével pótolhatjuk. Egy központi számítógépen futó program a szenzorok segítségével figyeli az egyes parkolóhelyek foglaltságát, majd megfelelő útválasztási algoritmus futtatását követően a kihelyezett irányjelző táblák segítségével a megfelelő helyre irányítja a vezetőket. 1.1.3. Telefonfigyelő szolgáltatás

A telefonfigyelő szolgáltatás alkalmazása esetén esetében a vezetékes vagy mobiltelefonon keresztül bonyolított beszélgetések tartalma automatikusan továbbítódik a számítógépre, ahol egy figyelőrendszer dolgozza fel azt. A párbeszédet egy beszédfelismerő program digitalizálja, szöveges formátumúvá alakítja át, majd az így nyert adatot és a hanganyagot egy adatbázisba tárolja el esetleges kiegészítő 5


információkkal együtt. Ezt követően az adatokat feldolgozza, így a dolgozók beszélgetései kereshetővé válnak. Ez jelentős többletszolgáltatást biztosít a hagyományos telefonálással szemben, növeli a telefonon keresztül történő kommunikáció hatékonyságát (a lényeges információ nem csupán szóban hangzik el, hanem rögzítésre is kerül), megelőzi az ugyanazon témával kapcsolatos felesleges telefonhívásokat (kereshető adatbázis az információk számára), valamint rövidíti a hívások időtartamát (nem szükséges jegyzetelnünk, ezt a rendszer „elvégzi” helyettünk). Természetesen ekkora mennyiségű adat rögzítése, tárolása és feldolgozása jelentős erőforrásokat igényel, ezért a teljes rögzítés, illetve a manuális feldolgozás helyett alkalmazhatunk valamilyen mesterséges intelligencián alapuló programot; így a tároláshoz szükséges háttértár mennyisége is csökkenthető. 1.1.4. „Intelligens tábla”, virtuális jelenlét

Az „intelligens tábla” koncepciójának lényege, hogy kiküszöbölje a hagyományos táblák egy óriási hátrányát, a korlátozott kapacitást. A hagyományos táblák hamar betelnek, ekkor tartalmukat törölni kell. Amennyiben nem készült megfelelő jegyzet a felvázolt gondolatokról, az későbbiekben megtörheti a beszélgetés lendületét, és felesleges időhúzást jelenthet az adatok visszakeresése miatt. Az eszköz, mely a táblát szimbolizálja, gyakorlatilag „korlátlan” tárhelyet biztosít a rajta elhelyezett jegyzetek számára, melynek csak a működtető eszköz tároló kapacitása szab határt. A tábla folyamatosan rögzíti a ráírt adatokat, így ezek az adatok jóval azután is olvashatóak maradnak, hogy a tábla felületét törölték. Mivel az adatokat a tábla egy számítógép segítségével rögzíti, lehetővé válik távoli felhasználók bevonása is az előadásba. Ez a megvalósítás növeli a megbeszéléseken folytatott kommunikáció hatékonyságát, és kiküszöböli a „hagyományos” táblák helyhez kötöttségét. A távoli résztvevők jelenlétével felmerülhet az igény egy olyan megoldásra, mely növelné az egyéni komfortérzetüket, ugyanis a távoli résztvevők jobban be tudnának kapcsolódni a beszélgetésbe, ha nem csupán a táblára írt információkat látnák, hanem valamilyen módon tudatában lennének a résztvevőknek és a beszélő személyének. Ezt a jelenlét-érzetet elérhetnénk azzal, hogy a távoli résztvevő számára annak az egyénnek az arcát mutatnánk, aki éppen beszél. Amennyiben felszereljük a felhasznált termet egy olyan eszközzel, amely képes megállapítani, hogy az éppen beszélő személy a terem mely részén ül, valamint telepítünk egy kamerarendszert is, úgy lehetőségünk nyílik megteremteni ezt a komfortérzetet a távoli résztvevőkben. 1.1.5. Dokumentumok rendezése, nyomon követése

Gyakori probléma forrása lehet az is, hogy az egyes dokumentumok mind elektronikus, mind nyomtatott formában is tárolásra kerülnek, ekkor ugyanis az elektronikus dokumentumokkal szemben a papír alapú dokumentumok keresése gyakran sok időt vehet igénybe. A papír alapú dokumentumok helyének megtalálásaát hozzájuk csatolt RFID chipek felhasználásával jelentősen felgyorsíthatjuk, természetesen ekkor a 6


dokumentum elektronikus verziójához szükséges tárolnunk, hogy melyik RFID azonosító tartozik hozzá. Amennyiben egy irodában olyan RFID olvasót helyeznek el, mely azonosítani tudja az összes ott tárolt objektumot, akkor a máshol tárolt dokumentumok a sikertelen keresésére nem fordítódik majd felesleges idő. Az RFID olvasók rendszerbe kapcsolásával pedig a más irodákban levő dokumentumok helye is gyorsan meghatározható. 1.1.6. Belépőkártyára épülő szolgáltatások

Manapság a nagyobb vállalatok szinte mindegyike belépőkártyával azonosítja alkalmazottait. Ezen kártyáknak azonban nem használjuk ki minden lehetőségét, ugyanis rengeteg többletszolgáltatás nyújtására kínálnak még lehetőséget. A belépőkártyák felhasználásával lehetővé válhatna az elektronikus fizetés a cég területén, az egyes személyek azonosítása a különféle rendszerekben, valamint a kártya által kibocsájtott jelek segítségével a dolgozók lokalizálása, biztonságuk fokozása (pl. személyre szabott értesítések tűz esetén). 1.2. A virtuális üzenőfal A korábban bemutatott alkalmazásokhoz hasonló jellegű megoldás a „virtuális üzenőfal” is; ezen dolgozat célja pedig az üzenőfal tervezési és megvalósítási lépéseinek bemutatása. Feladatunk egy elektronikus üzenőfal létrehozása, amely alkalmas úgynevezett „virtuális post-it” üzenetek fogadására és tárolására, személyre szabott megjelenítéssel. Amint a „post-it” kifejezés is sugallja, az elképzelés lényege, hogy esetleges távollét esetén üzenethagyásra szolgáló, az ajtóra ragasztott „kis sárga cédulákat” váltsuk ki egy sokrétű, intelligens elektronikus üzenethagyási megoldással. A virtuális üzenetek a hagyományos „sárga cédulákkal” szemben több előnnyel bírnak: • Személyre szabhatóság: az elektronikus üzenetek megtekintése – szemben a hagyományos üzenetekkel – jogosultságokhoz köthető, személyre szabható, míg egy hagyományos üzenetet bármely, az ajtó előtt elhaladó személy elolvashat. • Helyfüggőség: más módszerekkel ellentétben a címzettek csak akkor kapják meg a nekik szóló üzeneteket, ha az tényleg érdekelheti őket, mivel az eszköz közelében jártak. • Távoli hozzáférhetőség: amennyiben az eszköz rendelkezik Internet-kapcsolattal, az üzenetek hagyása nem lesz többé helyhez kötött. • Esztétikum: a kézzel írott üzenetet olvashatósága néha kívánnivalót hagy maga után. • Jobb helykihasználás: csupán a használt eszközön rendelkezésre álló tárhely szab határt a tárolt üzenetek mennyiségének. • Lehetőség nem csupán szöveges üzenetek átadására: videó és hang üzenetek kezelése is megvalósítható. 7


Egy a fentiekben specifikált üzenőfal megőrzi az eredeti üzenetek funkcionalitását, miszerint nem tudhatjuk, hogy távollétünkben kik szeretnének felkeresni bennünket a szobánkban, épp ezért ragasztunk fel egy „mindenkinek” szóló üzeneteket. Ezt az eredeti funkcionalitást terjeszti ki a felsorolt hatékonyságot, hasznosságot, személyre szabhatóságot és kényelmet növelő funkciókkal. 1.3. Felhasználási lehetőségek A bevezetésben felsorolt felhasználási lehetőségek azonban egy ilyen eszköz, illetve alkalmazás felhasználási területének csupán töredékét jelenthetik. Amennyiben az alkalmazást megvalósító eszköz rendelkezik Internet-kapcsolattal, vagy csupán hálózati kapcsolattal az üzemeltető intézmény belső hálózatán, úgy lehetőségünk van egyéb többlet szolgáltatások megvalósítására, mint például fontos vállalati-üzemeltetői bejelentések továbbítása, időjárás előrejelzések szolgáltatása, stb.[1] A megoldás alkalmas lehet továbbá munkaidő nyilvántartó rendszer üzemeltetésre, akár távoli munkahelyen is pl. szervízelési, karbantartási munkákra való kiszállások kezelésére.[2] Ezen kívül egy ilyen eszköz fontos szerepet játszhat vészhelyzetek kezelésében: egy tűzeset, gázszivárgás esetén a legközelebbi kijárat felé irányíthatná az épületben tartózkodókat.[1] A virtuális üzenőfal kiválthatná a hagyományos névtáblákat is az irodák ajtaján, ezen információkat készenléti állapotában megjelenítve.[1] Az információ megjelenítés ötletére alapozva akár reklámok is megjeleníthetőek lennének az adott üzenőfalon. Az üzenőfal kiterjesztett funkcionalitására alapozva számos könnyebbséggel élhetnek használói. Amennyiben például valaki késésben van a munkahelyéről, minden nehézség nélkül hagyhat üzenetet az irodája ajtaján elhelyezett eszközön, hogy csupán később érkezik (amennyiben az rendelkezik Internet elérhetőséggel). Ha pedig az eszköz felhasználója éppen elfoglalt, és így nem akarja, vagy esetleg nem tudja megszakítani az aktuális munkáját (pl. fontos megbeszélés a kollégákkal) könnyűszerrel hagyhat üzenetet rendelkezésére álló Internetes elérést támogató eszközről (Laptop, PDA1, stb.). Az utóbbi példát általánosítva, lehetséges annak megvalósítása, hogy egy felhasználó a birtokában lévő valamilyen vezeték nélküli adattovábbítást lehetővé tevő technológiával rendelkező eszközről akár bármiféle külön kliens szoftver telepítése nélkül üzenetet hagyjon. Természetesen ez csak abban az esetben elképzelhető, ha az üzenőfal szolgáltatást futtató eszköz is rendelkezik azzal a technológiával, mellyel az adott üzenetet hagyni kívánják. Ekkor ajánlott az üzenőfalat a lehető legtöbb (esetleg akár külön gyártók által specifikált) lehetséges üzenetformátumra felkészíteni, hiszen ez növelheti a készülékfüggetlenséget, illetve a kompatibilitást.

1 Personal Digital Assistant

8


A virtuális üzenőfal akár üzenetkézbesítési funkcióval is felruházható, amennyiben az azt futtató eszköz rendelkezik lehetőség szerint valamilyen vezeték nélküli adattovábbítást lehetővé tevő technológiával. Ennek segítségével az egyes üzenetek kézbesíthetők a különféle felhasználók részére. Napjainkban számos eszköz támogat vezeték nélküli helyi hálózati elérést (WLAN), azonban még szélesebb skálájuk rendelkezik beépített Bluetooth és/vagy Infra modullal. A két utóbbi technológia közül a Bluetooth nem igényel közvetlen rálátást a két eszköz között, így ez a technológia lehet a legcélszerűbb üzenetek kézbesítésére. A Bluetooth kommunikáció további jellemzője, hogy hatótávolsága nem túl nagy (1-100 m típustól függően), ellenben túl távoli eszközök figyelembe vétele egyáltalán nem szükséges, így ez nem jelent problémát. Azonban bármely technológiát választunk is kézbesítésre, lehetőségünk van a virtuális üzenőfal specifikációjában megadott személyre szabhatóságot megvalósítani, ugyanis az egyes címzettek eszközeik egyedi címével azonosíthatók. Amennyiben az üzenőfalat megvalósító eszköz rendelkezik érintőképernyővel, úgy akár az adott eszközről is történhet az üzenethagyás, valamint lehetővé válik az üzenőfalról az üzenetek könnyebb leolvasása. Természetesen a felhasználók hozzáférését jelszóval kell korlátoznunk, megelőzve az illetéktelen hozzáféréseket több egyidejűleg a közelben tartózkodó címzett esetén. Napjainkban a harmadik generációs (3G) mobil eszközök is széles körben elterjedtek. Egy virtuális üzenőfal megvalósításakor tehát észszerű, sőt akár szükségszerű döntés is lehet az ilyen eszközök multimédiás üzeneteinek támogatása a szöveges üzenetekkel együtt. Amennyiben az üzenetek kézbesítésének lehetősége biztosított, ezen üzenetek ugyanolyan módon kézbesíthetők, mint szöveges társaik. TDK munkánk kidolgozása során a fenti irányelveken alapuló rendszer megvalósítását tűztük ki célul. A dolgozat szervesen kapcsolódik a Távközlési és Médiainformatika Tanszék kutatóinak a Mobil Innovációs Központ (MIK) keretein belül végzett munkájához. A kidolgozás fázisairól, az egyes funkciók bővebb ismertetéséről a következő fejezetekben olvashatunk. 1.4. Az alkalmazás hardver oldali követelményeinek kidolgozása Célunk egy üzenethagyó rendszer készítése volt, melynek segítségével üzeneteket lehet hagyni meghatározott embereknek, valamint címzettként üzeneteket lehet kapni valamely vezeték nélküli technológia segítségével. Egy ajtóra, illetve falra szerelhető kis számítógépet (a továbbiakban nevezzük terminálnak) képzeltünk el, amely egy pár inch méretű kijelzővel rendelkezik, ami lehetővé teszi a felhasználókkal való egyszerűbb kommunikációt, valamint vizuális visszajelzéseket jelenít meg a program állapotáról. A konkrét hardvert illetően a következőket tartottuk fontosnak:

9


a. Kis méret

Egyértelműen az egyik legfontosabb szempont a hasznosíthatóság szemszögéből nézve a terminál kompakt mérete, mivel egy asztali PC méretű kiszolgáló hardver elhelyezése ilyen célra egy átlagos irodában nem kívánatos. Alapvetően két architektúrával lehetséges megvalósítani egy hasonló alkalmazást: • A program egy távoli szerveren fut, és a terminál csak egy „buta” eszköz szerepét tölti be, ami megjelenítésre, adatbevitelre és esetlegesen vezeték nélküli adatcserére használható; • A program a terminálon fut, így nincs szükség távoli szerverre és felesleges kommunikációra. Szerencsére manapság már több olyan alaplap és termék is elérhető a piacon, mely alkalmas egy ilyen bonyolultságú program futtatására és megfelelően kis méretű. b. Alacsony fogyasztás

Napjainkban egyre jelentősebb igény, hogy ügyeljünk a környezetünkre, ne fogyasszunk feleslegesen sok energiát, ne használjunk olyan anyagokat melyek nem újrahasznosíthatóak, stb. Munkánk során ezért fokozott figyelmet fordítottunk arra, hogy mivel a terminálnak a nap nagy részében rendelkezésre kell állnia, ne fogyasszon indokolatlanul sok elektromos áramot. Nem feledkezhetünk meg egy asztali PC által keltett nagy zajról sem, ami szintén nem kívánatos jelenség. A napjainkban elérhető SoC (System on a Chip) megoldások kevés energiát fogyasztanak, ugyanakkor számunkra elegendő teljesítményt képesek nyújtani. c. Viszonylag alacsony fogyasztói ár

A terminál ára nem szabad, hogy elérhetetlenül drága legyen, hiszen ideális esetben egy épületben akár minden ajtóra kerülhet egy ilyen eszköz. d. Vezeték nélküli internetes csatlakozás támogatása

További nagy előnyt jelent a kis zajártalom és fogyasztás mellett, ha a terminál felszereléséhez nem szükséges a falba újabb kábelt (pl. Ethernet vezetéket) elvezetni, mégis az Internetre csatlakoztatható pl. Bluetooth vagy WiFi rádió segítségével. Korunk irodái nagyrészt már eleve rendelkeznek WiFi hálózati lefedettséggel, így az Internetre csatlakozás nagyon egyszerűen megoldható feladattá degradálódik. e. Kijelző

Ha a terminál rendelkezik egy kijelzővel is, akkor az üzenetek megjeleníthetőek a kijelzőn (vezeték nélküli továbbítás mellett vagy helyett). Amennyiben a terminál rendelkezik valamilyen beviteli eszközzel is, pl. billentyűzet vagy érintőképernyő, a felhasználók egyszerűbb műveleteket (pl. új üzenet írása, üzenet törlése, beállítások módosítása) magán a terminálon is elvégezhetnek, ami bizonyos esetekben kényelmesebb

10


lehet, mint a saját mobil eszközön keresztül kommunikálni a rendszerrel. A kijelzőnek a könnyű olvashatóság érdekében legalább 3-4 inch képátlójúnak kell lennie. f. Vezeték nélküli üzenetküldési lehetőség

A terminál segítségével a felhasználók és a terminál közti interakció többféleképpen kell hogy lebonyolítható legyen, így mindenki az általa leginkább preferált módon veheti igénybe annak szolgáltatásait. Az egyik lehetőség az, hogy a terminál rendelkezik bizonyos vezeték nélküli rádióval, ami lehetővé teszi, hogy a felhasználó a saját eszközén szerkessze, illetve jelenítse meg az üzenetet. Négy szóba jöhető technológiát vizsgáltunk meg: Bluetooth, IrDA2 , WiFi, valamint egy esetleges saját fejlesztésű rádió. Fontosnak tartottuk, hogy minél több mobil eszközzel elérhetőek legyenek a rendszer által nyújtott szolgáltatások, ezért a fájlküldésre való alkalmassága, valamint a széleskörű támogatottsága miatt a Bluetooth technológiát választottuk (ma már majdnem minden mobiltelefon és PDA beépített Bluetooth adóvevővel kerül forgalomba). IrDA esetében a közvetlen rálátás szükségességét találtuk kizáró tényezőnek, míg WiFi esetén egyrészt körülményes a kapcsolat automatikus kiépítése a legtöbb forgalomban lévő eszközzel, másrészt saját klienst kellene telepíteni a felhasználó készülékére, amit nem tartottunk praktikusnak. g. Egyszerű távoli menedzselhetőség

Gyakori probléma az intelligens eszközök szoftverében felmerült hibák kijavítása kapcsán, hogy az eszköz programja csak közvetlen fizikai kapcsolattal, pl. kábellel frissíthető egy számítógép segítségével. Mi egy olyan rendszert szerettünk volna létrehozni, ami kényelmesen frissíthető az adminisztrátorok számára a termináltól távolról is, annak internetes kapcsolatát kihasználva. 1.5. Az alkalmazás szoftver oldali követelményeinek kidolgozása A kifejlesztésre kerülő szoftver tervezését azzal kezdtük, hogy eldöntöttük, milyen feladatokra kell alkalmasnak lennie, valamint felállítottunk egy sorrendet azok fontosságáról. Ezek a következők: a. Üzenetek tárolása

A szoftvernek képesnek kell lennie felhasználók kezelésére; minden felhasználónak lehetnek üzenetei, a felhasználók egymásnak, illetve előre meg nem határozott címzetteknek is küldhetnek üzeneteket. A tárolás megvalósítását két fázisra bontottuk: az első fázisban egy saját, fájl-alapú adatszerkezetet alakítottunk ki az üzenetek tárolására. A későbbiekben ez a rendszer modulárisan lecserélhető egy nagyobb felhasználói bázis és nagyobb számú üzenet kezelése esetén sokkal hatékonyabb SQL alapú kliens-szerver architektúrájú tárolási formára. Ennek további előnye, hogy központosítható, így akár

2 Infrared Data Association

11


megvalósítható az is, hogy a felhasználóhoz közelebb eső terminál kézbesítse a neki szóló üzenetet, amit egy másik terminálról hagytak neki. b. Felhasználók kezelése

A bevezetőben leírt modell akkor igazán használható, akkor adhatóak hozzá értéknövelt szolgáltatások, ha megvalósítjuk az üzenetet hagyó emberek megkülönböztetését. Ennek segítségével a felhasználók csak a nekik szóló üzeneteket láthatják, azok megtekintése jelszóhoz köthető. A Bluetooth technológia – hasonlóan az Ethernet hálózatokhoz – specifikál egy minden eszköz esetében egyedi azonosítót, melynek segítségével a közelben tartózkodó felhasználók (amennyiben az eszközük nálunk van) könnyedén azonosíthatóak. Ez a helyfüggő információ az üzenetkézbesítés vagy a kijelzőn való megjelenítés alapja is lehet akár. c. Üzenetek vezeték nélküli továbbítása

A felhasználók képesek kell hogy legyenek üzenetek írására és fogadására saját eszközük (pl. mobiltelefonjuk vagy PDA-juk) segítségével. Fontosnak tartottuk, hogy ehhez semmilyen külső alkalmazást ne kelljen telepíteniük erre az eszközre. Szerencsére a forgalomban lévő eszközök majdnem mindegyike képes valamilyen szintű üzenetcserére az általunk választott Bluetooth rádión keresztül (OBEX3 Push illetve OBEX FTP protokollon). Sajnálatos módon a különböző gyártók készülékei más és más formátumban küldik el a beépített szerkesztőprogrammal készített szöveges üzeneteket, így a programunkat fel kell készítenünk ezen üzenettípusok lehető legszélesebb palettájának támogatására. d. Felhasználói csoportok kezelése

A felhasználók a könnyebb kezelhetőség érdekében csoportokba kell, hogy rendezhetőek legyenek, így pl. a céges kollégák könnyen elérhetőek lesznek egy csoportnak címzett üzenettel, nem kell mindenkinek külön megadni a nevét a címzettek listájába. Szükséges egyfajta nyilvántartás, amely az adott üzenetről eltárolja, hogy az mely felhasználóknak lett már kézbesítve és melyeknek kell még ezt megtenni. e. Grafikus felület

A szoftver több rétegű kell, hogy legyen, az üzenetek tárolásáért, kézbesítéséért és fogadásáért felelős modulok függetlenek kell, hogy legyenek az üzenetek létrehozásáért és megjelenítéséért felelős részektől. Ilyen módon a megjelenítés egyik felülete a terminál kijelzője lehet, amelyen a felhasználók könnyedén elvégezhetnek egyszerűbb feladatokat, mint az üzeneteik elolvasása, új üzenet írása, régi üzenetek törlése, beállításaik módosítása.

3 Object Exchange

12


f. Web-es felület

Rendkívül hasznosnak bizonyulhat, ha az iroda dolgozói akkor is képesek üzenetet hagyni, ha éppen nem tartózkodnak a terminál közelében. Például elakadtak egy dugóban munkába menet vagy akár az irodában ülve nem akarnak kimenni az ajtó elé az üzeneteik lekérdezéséhez. A legszéleskörűbb megoldás – szintén a platformfüggetlenséget és a saját alkalmazás telepítésének szükségtelenségét szem előtt tartva -, hogy egy Web-es felületről elérhetővé tesszük a terminálon lévő adatokat. A szerver program futtatására lehetőség van egy külső szerver gépen, vagy akár magán a terminálon is. A Web-es felületről könnyedén elérhetőnek kell lennie az üzenethagyó rendszer grafikus felületről is elérhető legtöbb funkciójának. g. Multimédiás üzenetek

A hagyományos módszerektől (papír) való legnagyobb elrugaszkodást talán a videó-, hang- és képüzenetek hagyása jelentheti, amit egy digitális rendszerrel könnyedén megvalósíthatunk. Ha a terminál rendelkezik beépített kamerával, akár videó üzeneteket is vehetünk fel a segítségével, de lehetőséget kell teremtenünk a felhasználók saját média fájljainak kezelésére is, így pl. a felhasználó saját mobiltelefonjával vehet fel egy videó üzenetet, amit átküldve a rendszer azt a hagyományos, szöveg alapú üzenetekhez hasonlóan kell, hogy kezeljen. h. SMS értesítő

Hasznos lehet bizonyos esetekben, a terminálon hagyott üzenet címzettjének távolléte esetén az üzenet bizonyos kritériumok szerinti SMS-ben történő kézbesítése is. Ekkor a direkt értesítést követően a címzett a Web-es felület segítségével reagálhat az üzenetre. i. Központosítás

Legkevésbé sürgető feladataink egyikének a több eszköz hatékony együttműködését elősegítő központosítási kérdések kidolgozását éreztük. Ugyanakkor fontos volt már a fejlesztés megkezdése előtt szem előtt tartani, hogy a program részei fel legyenek készítve több, egymás közelében lévő terminál párhuzamos működését és az üzenetküldések által okozott interferenciát is lekezelni, valamint lehetőséget teremteni a több készüléket egy hálózatként használó fejlettebb algoritmusok beépíthetőségére (pl. közeledő ember érkezésére felkészülni, ha egy közelben lévő terminál már észleli, de az üzenetkézbesítésért felelős példány még nincs hatótávolságban). 1.6. A választott fejlesztési környezet paraméterei A tervezés során nagyon fontosnak tartottuk a program könnyű hordozhatóságát, hogy a programkódot ne egy konkrét cég konkrét termékére készítsük el, hanem lehetőség szerint minél többféle eszközön futtatható legyen. Ehhez ideális választásnak bizonyult egy Linux alapú operációs rendszer, hiszen ezen rendszerek majdnem minden napjainkban elérhető platformra ingyen letölthetőek, ugyanakkor minden szükséges képességgel fel vannak vértezve a nagy programellátottságuknak köszönhetően. 13


A fejlesztés minden fázisában megpróbáltunk felhasználni minden, már korábban megírt és széles körben használt szoftver-elemet, amire szükségünk volt. Igyekeztünk pszeudo-szabvány keretrendszerek, API-k és könyvtárak használatára építeni, amik az eszközök legtöbbjére elérhetőek. Ilyen okok miatt választottuk a Python programnyelvet, a BlueZ Bluetooth könyvtárakat és már meglévő OBEX implementációkat. A grafikus felület GTK4-ban íródott, ami manapság már a mobil eszközöktől az asztali számítógépeken keresztül a szerver rendszerekig minden típusú számítógépre elérhető. A Web-es felület tekintetében az elsimert W3C 5 szabványok betartásával próbáljuk a kompatibilitást maximalizálni. A piacon kapható eszközök áttekintését követően arra a megállípításra jutottunk, hogy két alternatívánk van: egy kis LCD monitorral ellátott Via PicoITX alaplap beszerzése vagy a Nokia N szériás Internet tábláinak egyikének használata. A tanszék a rendelkezésünkre bocsájtott egy Nokia 770-es Internet táblát, mely egy Debian Linux operációs rendszert futtató, 4.1 inch képátlójú kijelzővel rendelkező, ARM processzort tartalmazó mobil eszköz. Rendelkezik a követelményekben említett minden tulajdonsággal, mint WiFi és Bluetooth rádió, érintőkijelző, alacsony fogyasztás, stb. Sajnos egy évnyi fejlesztés után a Nokia 770 kiforratlannak bizonyult bizonyos feladatok kezelésére, így beszereztünk egy fejlettebb modellt ugyanabból a szériából, egy Nokia N810-es készüléket[3]. 1.7. A Nokia N810, mint terminál Mindamellett, hogy az alkalmazás Nokia N810-en készült és lett tesztelve, fontos megjegyezni, hogy az jelenleg nagyon kis munkával asztali PC-n, Linux operációs rendszer alatt is működőképessé tehető. Pár modult módosítva a kód akár egy Symbian operációs rendszerű okostelefonon is használható. A Nokia N810-es modellje a cég harmadik N szériás készüléke, mely alapvetően mobil internetezésre lett kitalálva. Nem rendelkezik GSM/UMTS modullal, az Internetet WiFi rádión keresztül, vagy egy mobiltelefon segítségével Bluetooth kapcsolaton át érhetjük el vele. Rendelkezik beépített, mai szabványokat kezelni képes Internet böngésző programmal, azonnali üzenetváltásra alkalmas IM6 klienssel, és multimédiás tartalmak lejátszására szolgáló lejátszóprogrammal. Ami a projekt szempontjából számunkra sokkal fontosabb volt, az az, hogy az eszköz Internet Tablet OS 4.1-es operációs rendszert futtat, ami a Debian Linux-on alapul, és elérhető rá a Debian-ra készült legtöbb program. Köszönhetően a Linux operációs rendszerek rendkívül intenzív hálózatra termettségének, könnyedén elérhető távolról is

4 GIMP Toolkit; egy platformfüggetlen grafikus felhasználói felület létrehozására alkalmas eszközkészlet 5 World Wide Web Consortium; A WWW fő fejlesztési irányelveivel és szabványainak kidolgozásával foglalkozó szervezet 6 Instant Messaging; azonnali üzenetküldő

14


egy Internet kapcsolaton át, azaz SSH7 és VNC 8 szerver programok segítségével távoli adminisztrátorok is tudják vezérelni. Az eszköz mindemellett fel van szerelve Bluetooth 2.0 rádióval is, ami elég gyors multimédiás üzenetek továbbításához is. Az N810 rendelkezik pár nagyon előnyös tulajdonsággal a 770-es modellhez képest: található benne egy beépített kamera, ami alkalmas lehet videó üzenetek rögzítésére, valamint elcsúsztatható kivitelének köszönhetően a képernyő alá beépítettek egy teljes QWERTY billentyűzetet is (1. ábra), ami nagyban segíti az üzenetek írását (az érintőképernyőn megjelenő billentyűzet pontatlansága miatt).

1. ábra: A Nokia N810 becsukott és kihúzott billentyűzettel

7 Secure Shell; távolról történő parancssori bejelentkezésre használatos hálózati protokoll 8 Virtual Network Computing; A grafikus felület távolról történő használatát lehetővé tévő hálózati protokoll

15


2. A virtuális üzenőfal használata 2.1. A szoftver környezet kialakítása és a program telepítése A következőkben bemutatjuk röviden a virtuális üzenőfal szoftver környezete kialakításának és a program telepítésének lépéseit: 1. A program állományait másoljuk a /virtualpostit/ könyvtárba! 2. Állítsuk be a Bluetooth konfigurációt a grafikus felület segítségével! A Menü→ Settings→Control panel→Bluetooth menüpontját kiválasztva jelöljük be a „Bluetooth on” és a „Visible” opciókat! Előbbi a Bluetooth modul aktiválására, utóbbi pedig az eszköz jelenlétének hirdetésére szolgál. 3. A Bluetooth kapcsolatokat az eszközön a BlueZ szoftvercsomag kezeli. Az üzenőfalhoz elvárt működés elérése érdekében néhány működési paramétert meg kell változtatnunk. Ezeket

a

/etc/bluetooth/hcid.conf

fájlon keresztül módosíthatjuk a

következőképpen: # Security Manager mode # none - Security manager disabled # auto - Use local PIN for incoming connections # user - Always ask user for a PIN # security none; # Pairing mode # none - Pairing disabled # multi - Allow pairing with already paired devices # once - Pair once and deny successive attempts pairing none;

Bluetooth eszközök közötti kommunikáció során a kéretlen hozzáférések elkerülése végett gyakran használunk egy közös PIN 9 kódot, amit mind a küldő, mind pedig a fogadó eszközön meg kell adni. Erre esetünkben nincs szükség, csak kényelmetlenebbé tenné az üzenethagyást, így a security opció none-ra állításával ezt ki kell kapcsolnunk. Lehetőség van előzetesen megmondani, mely eszközökről érkező forgalomban bízunk meg, vagyis mely eszközökről fogadjuk el PIN kód nélkül az adatforgalmat. Ezt a folyamatot „párosításnak” nevezzük. A második, pairing nevű beállítási lehetőség azt szabályozza, hogy a párosítási folyamat megismételhető-e. Mivel az alkalmazásunk maga gondoskodik a párosítás végrehajtásáról, a rendszer ezen szolgáltatását ki kell, hogy kapcsoljuk. 4. Adjunk írási jogot a fájlok fogadására szolgáló könyvtárra, hogy az OBEX szerver képes legyen a bejövő üzeneteket itt elhelyezni: 9 Personal Identification Number

16

Sik András, Gruber Kristóf: Intelligens környezet, intelligens iroda – virtuális üzenőfal megvalósítása > chmod 777 /virtualpostit/receive

5. Állítsuk be programunk

/virtualpostit/receive

könyvtárát alapértelmezett OBEX

fájl fogadási könyvtárnak a /etc/init.d/obexrv módosításával: dsmetool -n -1 $USER_FLAGS -t "$DAEMON -l $DAEMON_OPTS"

helyett írjuk a következőt: dsmetool -n -1 $USER_FLAGS -t "$DAEMON -l $DAEMON_OPTS -r /virtualpostit/receive"

6. A menüből indíthatóság érdekében hozzunk létre egy állományt a következő néven az

alábbi

elérési

útvonalon:

/usr/share/applicaions/hildon/virtualpostit.desktop,

melynek tartalma legyen a következő: [Desktop Entry] Version=1.0.0 Encoding=UTF-8 Name=Virtual Post-It Exec=/virtualpostit/start.sh Icon=virtpostitlogo

Helyezzünk el egy ikont a következő helyen és következő névvel: /usr/share/pixmaps/virtpostitlogo.png

7. Telepítsük fel az ussp-push[4] csomagot: > wget “http://packages.debian.org/lenny/armel/ussp-push/download” > dpgk -i ussp-push-####.deb

Az USSP Push egy Bluetooth OBEX Push szolgáltatást megvalósító fáljküldő alkalmazás. Segítségével kézbesíti az alkalmazásunk üzeneteit. 8. Telepítsük fel a bluez-utils-test csomagot: > wget “http://repository.maemo.org/pool/chinook/free/b/bluez-utils/bluez-utilstest_3.22-0osso2_armel.deb” > dpkg -i bluez-utils-test_3.22-0osso2_armel.deb

A csomag telepítése azért szükséges, mert tartalmazza az általunk használt parancsot, ami bizonyos Bluetooth diagnosztikai feladatokra használatos.

hcitool[5]

9. Indítsuk újra a Nokia N810-et! A későbbiekben lehetővé fogjuk tenni az automatizált telepítést is, mely a beépített csomagkezelő segítségével fog működni. 2.2. A program indítása A program indítása alapvetően kétféle módon történhet: a programot futtató eszköz grafikus felületéről, vagy parancssorból, főként hibakeresés és a program üzeneteinek figyelemmel kísérése céljából.

17


Amennyiben a programot grafikus felületről indítjuk (2. ábra), azt az eszköz menüjéből tehetjük meg a következő elérési úton: Menu→My Selection→Virtual Post-It.

2. ábra: Virtual Post-It indítása a menüből

Parancssorból a /virtualpostit/ könytárból a programot (3. ábra).

start.sh

3. ábra: Indítás parancssorból

18

futtatásával tudjuk indítani a


2.3. A program főablaka A felhasználók a program főablakában (4. ábra) jelentkezhetnek be az üzeneteik megtekintéséhez. Az ablakban jobb oldalt látható az elérhető (a Virtual Post-It programot futtató eszköz Bluetooth hatótávolságán belül tartózkodó) regisztrált felhasználók listája, bal oldalt pedig a vezérlőgombok, melyek lehetőséget adnak a Bluetooth képes eszköz nélküli azonosításra is.

4. ábra: A Virtual Post-it program főablaka

Status Bar A főablakban a status bar tájékoztatja a felhasználókat, hogy az eszköz éppen keresi-e a közelben levő aktív felhasználókat. Ez akkor történik, mikor a kijelzőn a „Scanning...” felirat olvasható. Az ellenőrzési folyamat alatt, mely 10 másodpercenként ismétlődik, az eszköz nem képes üzeneteket fogadni. Az ezközök keresése közben sajnos nincs lehetőség üzenetek fogadására (a Bluetooth technológia korlátai miatt), így szükség van 10 másodperc várakozásra, mely idő alatt a felhasználó átküldheti az üzenetét a terminálra. Nagyobb időintervallum beállítására is van lehetőség, azonban ilyenkor a program a közelben lévő felhasználók várakozásra kényszerülhetnek, amíg a nevük megjelenik a kijelzőn. Add User Új felhasználó hozzáadására szolgáló nyomógomb. Felhasználó csak adminisztrátori jogosultsággal adható hozzá a listához. Jelenleg ez a funkció nem elérhető. Login without Bluetooth Device Amennyiben a felhasználónál nincsen ott egyik beregisztrált Bluetooth eszköze sem, lehetősége van enélkül is belépni a rendszerbe, így hozzáférve a felhasználói fiókjához. A gomb megnyomásával a 2.4 fejezetben leírt ablakhoz juthatunk.

19


User Button A kijelző jobb oldalán látható nyomógombok csoportja, melyek neve egy-egy felhasználót jelöl (pl. Teszt Elek). Ennek a gombnak a használatával az adott felhasználó jelszóval történő hitelesítést követően beléphet saját fiókjába, megtekintheti üzeneteit, valamint új üzeneteket küldhet. 2.4. Bejelentkezés aktív Bluetooth eszköz jelenléte nélkül A regisztrált felhasználók detektálását a rendszer Bluetooth eszközeik egyedi azonosító száma alapján végzi el. Ezt az azonosítót minden bekapcsolt Bluetooth eszköz folyamatosan sugározza. Egy felhasználóhoz több eszköz (pl. telefon, PDA, számítógép) is rendelhető. Amennyiben a felhasználónál nincsen ott egyik beregisztrált Bluetooth eszköze sem, lehetősége van enélkül is belépni a rendszerbe, így hozzáférve a felhasználói fiókjához. Ilyen bejelentkezés esetén ugyanazon jogokkal rendelkezik a felhasználó, mintha egy aktív eszköz segítségével jelentkezett volna be. A főablak „Login without Bluetooth deivce” gombjának megnyomása után egy listából kell kiválasztani a használni kívánt felhasználónevet (5. ábra), ezt követően történik a jelszóval való hitelesítés.

5. ábra: Bejelentkezés aktív Bluetooth eszköz jelenlétének hiányában

Cancel A felhasználó ennek a gombnak a megnyomásával visszajuthat a program főablakához. Users A felhasználó ebből a listából választhatja ki a felhasználónevet, amellyel be kíván jelentkezni. Login A felhasználónév kiválasztását követően ezzel a gombbal kezdeményezheti a felhasználó a jelszóval történő hitelesítést. 20


2.5. Jelszóval történő hitelesítés A felhasználónak egy jelszóval kell hitelesítenie magát, amennyiben hozzá kíván férni felhasználói fiókjához (6. ábra). Hitelesítés történhet aktív Bluetooth eszköz jelenlétében és hiányában is, azonban csak regisztrált felhasználók léphetnek be a rendszerbe. Aktív eszköz jelenlétében a felhasználó a főablakban a megfelelő felhasználót jelképező gomb használatával, eszköz hiányában pedig a „Login without Bluetooth Device” gomb megnyomását követően, felhasználónevét egy listából kiválasztva jelentkezhet be a „Login” gomb segítségével.

6. ábra: Hitelesítés jelszó segítségével

Password A Password címkét követő szövegmezőt megérintve megjelenik az operációs rendszer virtuális billentyűzete, melynek felhasználásával pálca (ún. stylus) segítégével írhatjuk be a jelszót. A jelszavak md5 hash lenyomatai10 vannak tárolva; bejelentkezéskor a megadott jelszó md5 hash lenyomatát és a tárolt lenyomatot hasonlítja össze a program, így a jelszó gyakorlatilag visszafejthetetlen. OK A felhasználó az „OK” gomb megnyomásával jelentkezhet be a rendszerbe. Amennyiben a jelszó helyesen lett megadva, a felhasználó a saját fiókját jelképező ablakot fogja látni; amennyiben nem, egy hibaüzenet kíséretében visszakerül a főablakhoz (7. ábra). Cancel A „Cancel” gomb megnyomásával visszajuthatunk a program főablakához.

10 Az md5 egy olyan kriptográfiai algoritmus, mely bármely szöveghez egyértelműen hozzárendel egy meghatározott hosszúságú ún. „hash” lenyomatot. A lenyomat ismeretében az eredeti szöveg visszaállítása praktikusan lehetetlen feladat.

21


7. ábra: Hibás bejelentkezés

2.6. A felhasználókhoz rendelt ablak Minden felhasználónak rendelkezésére áll egy saját fiók, ahol megtekintheti üzeneteit, új üzeneteket írhat, törölheti üzeneteit, megtekintheti és módosíthatja beállításait, valamint kijelentkezhet (8. ábra). Ezen felhasználói fiókok megjelenítésére szolgálnak a felhasználókhoz rendelt ablakok.

8. ábra: Az üzenetek listája

Status Bar Itt látható az aktuális felhasználó neve. (Az ábrán „Teszt Elek”) New message Ennek a gombnak megnyomásával írhat a felhasználó új üzenetet.

22


My Settings A felhasználó itt tekintheti meg és módosíthatja beállításait. Ez a funkció jelenleg nem elérhető. Logout A felhasználó ennek a gombnak a megnyomásával jelentkezhet ki, és juthat vissza a főablakba. Messages A felhasználónak szóló szöveges üzenetek a képernyő közepén sárga háttérrel jelennek meg. Támogatottak az ékezetes karaktereket tartalmazó üzenetek is. A fehér hátterű üzenetek a multimédiás üzenetek, melyeket az üzenet megérintésével játszhatunk le. A lejátszás bármikor megszakítható az N810 „vissza” gombjának megnyomásával. Lejátszás után a program visszakerül a felhasználó ablakába. Delete Az üzenetek a „Delete” gomb megnyomásával törölhetőek, törlésük a következő frissítési periódus után (1-2 másodperc) fog bekövetkezni. 2.7. Új üzenet írása Új üzenetet a felhasználóhoz rendelt ablakban a „New message” gombot megnyomva a megjelenő új ablakban (9. ábra) írhatunk. Itt lehetőségünk van az operációs rendszer virtuális billentyűzetének használatára, vagy választhatjuk az üzenetmező minél „nagyobb” területen történő megnyomásával az ujjakkal is használható billentyűzetet. Ha ki van nyitva az N810, akkor használható annak QWERTY billentyűzete is. Szöveges üzenetet külső eszközről is küldhetünk, ekkor az adott készülék valamely beépített programjával el kell készítenünk egy feljegyzést a következő szintaktikával: [;[;…]]#üzenet (pl. Teszt Elek;Gruber Kristóf#Holnap délután nem leszek elérhető.).

Ezt követően a feljegyzést Bluetooth kapcsolaton keresztül el kell

küldenünk az N810-re. Hagyható az eszközön videó és hang üzenet is, azonban ez még az N810 beépített hardverével nem, csupán külső eszköz felhasználásával támogatott. Üzeneteinket 3GP11 és AMR12 formátumban rögzíthetjük, majd a megfelelő elnevezési konvenció betartásával ([;[;…]]) elküldhetjük az N810-re. Cancel A felhasználó a „Cancel” gombot megnyomva visszatérhet a saját felhasználói ablakához.

11 A modern mobiltelefonok által leggyakrabban használt videó konténer. 12 Adaptive Multirate audio; mobiltelefonok hangjegyzet alkalmazásainak elterjedt formátuma

23


9. ábra: Új üzenet írása

Message Field A képernyő közepén helyet foglaló mezőbe írhatja be a felhasználó a küldeni kívánt üzenetet. Amennyiben a felhasználó ezt a felületet megérinti és az N810 össze van csukva, megjelenik az operációs rendszer virtuális billentyűzete, a mező minél „nagyobb” területen történő érintésével pedig az ujjakkal is használható billentyűzet (10. ábra). Kinyitott terminál esetén használható annak QWERTY billentyűzete az üzenet megszerkesztéséhez. Üres üzenet nem küldhető. Delete after delivery Amennyiben a felhasználó ezt a jelölőnégyzet elemet bejelöli, az üzenet sikeres kézbesítést követően törlődik a rendszerből.

10. ábra: Üzenet írása ujjakkal is használható billentyűzet segítségével

24


Select Recipients A felhasználó a „Select Recipients” gomb megnyomását követően kiválaszthatja a címzetteket akiknek az üzenetet küldeni szeretné. A részleteket a 2.8 fejezet taglalja. 2.8. Címzettek kiválasztása az elküldendő üzenethez Miután a felhasználó elkészítette az elküldeni kívánt üzenetet, a „Select Recipients” gomb megnyomását követően kiválaszthatja a címzetteket melyeknek az üzeneteket küldeni szeretné (11. ábra). Egy üzenetnek legalább egy címzettje kell, hogy legyen. Lehet azonban több címzett is, és ezek tetszőlegesen lehetnek felhasználók vagy csoportok.

11. ábra: Címzettek kiválasztása az üzenethez

Cancel A felhasználó a „Cancel” gomb megnyomásával térhet vissza az üzenet írására szolgáló ablakhoz. Users A felhasználó a bal oldali listából választhatja ki a jelölőnégyzetek bejelölésével a megcímezni kívánt felhasználókat. Groups A felhasználó a jobb oldali listából választhatja ki a jelölőnégyzetek bejelölésével a megcímezni kívánt csoportokat. Send A felhasználó a „Send” gomb megnyomásával tárolhatja el az üzenetet a rendszerben, amennyiben az rendelkezik legalább egy címzettel.

25


3. A virtuális üzenőfalat megvalósító szoftver moduláris felépítése 3.1. A programról általánosságban A program Python nyelven íródott, ami a legtöbb ma használatos operációs rendszerre elérhető (GNU/Linux, Windows, Mac OS X, AIX, AROS, MorphOS, BeOS, Palm OS, Symbian, VMS, Windows Mobile, OS/2, stb.). A Virtual Post-It a következő Python könyvtárakat használja[6]: • md5 – kriptográfiai függvények md5 hash lenyomat készítéséhez – a Nokia N810 grafikus felülete adta speciális tulajdonságok kihasználásához os – rendszerközeli műveletekhez

• hildon •

– Quoted Printable kódoláshoz és dekódoláshoz sys – rendszerspecifikus paraméterek és funkciók használatához

• quopri •

• datetime

– idő és dátum adattípusok használatához

– szálkezeléshez gtk – grafikus felület készítéséhez

• threading •

– tömbök duplikálásához bluetooth – Bluetooth műveletek elvégzéséhez

• copy •

Ezek mindegyike elérhető Nokia N810-re, legtöbbjük a Python csomag alaptartozéka. Külön szeretnénk kihangsúlyozni a bluetooth könyvtár meglétének fontosságát, ugyanis a program a közelben lévő felhasználók felderítését ennek a könyvtárnak a segítségével végzi el. A bluetooth modul működéséhez szükség van egy működő BlueZ[7] telepítésre. Ezen dokumentációnak nem célja a BlueZ feltelepítésének bemutatása. Megjegyzendő azonban, hogy a BlueZ már működőképes állapotban érkezik a Nokia N810-zel. A grafikus felület a Nokia N810-en célszerűen a GTK widget-készletre[8] épül. Mivel a GTK főleg asztali gépekre lett tervezve, a Nokia N810 speciális adottságait egy Hildon nevű, GTK-ra épülő kiegészítés segítségével tudtuk kihasználni. (Ilyen plusz funkciók pl. a jelszó bekérő ablak, vagy a teljes képernyő kezelés.)[9] Más platformokon a GTK lecserélhető a platform saját natív grafikus felületére, amennyiben létezik Python osztály, amiből az használható. Természetesen ezesetben újra kell írni a grafikus felületet az adott osztályhoz. Az általunk fejlesztett felület pár apróbb módosítással (pl. ablaknyitások, teljes képernyő kezelés) „Hildon-mentesíthető”, vagyis akár asztali gépen, Linux környezetben, asztali GTK-val is futtatható. 3.2. A program fájljai A program a Python nyelven írt forrásfájlokból, egy indító szkriptből, két ikonból, egy, a menüelemet megjelenítő desktop fájlból és az adatfájlokból áll. A program osztályai 26


nagyrészt az azonos nevű fájlokban foglalnak helyet. A fájlok alapértelmezésben a /virtualpostit mappában foglalnak helyet. A következő fájlok képezik a Virtual Post-It program részét: • start.sh

– az indító bash shell script;

• virtualpostit.py

– a program kontrollerét tartalmazó osztály;

• incominghandler.py

– a bejövő üzenetekért felelős osztály;

• outgoinghangler.py

– az üzenetek kiküldéséért felelős osztály;

• fun_encode.py

– vNote kódolásért/dekódolásért felelős függvények;

• mainwindow.py

– a program főablaka. A felhasználók listáját jeleníti meg;

• userwindow.py

– a felhasználó üzeneteit megjelenítő ablak;

• newmessagewindow.py

– új üzenet írása ablak;

• nodevice.py

– eszköz nélküli belépést lehetővé tévő ablak;

• password.py

– jelszó bekérés ablak;

• recipientwindow.py • logo.png

– az üzenet címzettjeinek kiválasztására szolgáló ablak;

– a program grafikus felületén megjelenő logo;

– a Python futtatás előtt előfordítja a forrás fájlokat, majd ezeket elmenti gyorsítási (cache) céllal. A pyo fájlok tartalmazzák ezeket az előfordított információkat. • *.pyo

Ezek a fájlok letörölhetőek, a program nélkülük is működőképes. A Virtual Post-It program által használt könyvtárak: • groups

– a felhasználók csoportjait tartalmazza;

• messages • outbox

– a már értelmezett, kézbesítendő üzenetek;

– azok az üzenetek kerülnek ide, melyeket elkezdett kézbesíteni a rendszer;

• parsefolder • users

– az IncomingHandler által használt átmeneti tárolásra szolgáló könyvtár;

– a felhasználókat tartalmazó könyvtár;

• passwords

– a felhasználói jelszavak lenyomatait tartalmazó könyvtár

3.3. A konfigurációs fájlok formátuma A program által használt, felhasználó által szabadon átírható konfigurációs- és üzenetfájlok formátumát és fájlrendszerbeli megkötéseit az 1. táblázat tartalmazza:

27

Sik András, Gruber Kristóf: Intelligens környezet, intelligens iroda – virtuális üzenőfal megvalósítása Típus

Könyvtár

Fájlnév

Tartalom formátuma

Üzenet

messages

Tetszőleges lehet, a program a dátumból generálja, és .mes kiterjesztést ad nekik

1. sor: címzettek neve „;” karakterrel elválasztva 2. sor: kézbesítés után törlendő-e (0 vagy 1) 3. sor: kézbesítve van-e (0 vagy 1) 4. sortól a fájl végéig: az üzenet szövege UTF-8 kódolásban

Felhasználó

users

A felhasználó neve

Minden sorban a felhasználó egy-egy eszközének Bluetooth címe

Csoport

groups

A csoport neve

Minden sorban egy-egy felhasználó neve

Jelszó

passwords

A hozzátartozó felhasználó neve A felhasználó jelszavának MD5 hash-e

1. táblázat: A felhasznált fájlformátumok összehasonlítása

3.4. A program osztályai A Virtual Post-It programozása a Modell-View-Controller architektúrát követi, amelynek lényege, hogy a program magja teljesen elkülönül a megjelenítésért felelős részektől. Esetünkben ez azt jelenti, hogy a program Bluetooth üzenetkezelésért felelős részei és a grafikus felület egymástól a lehető legkevésbé függenek, így könnyedén lecserélhető bármelyik (értelemszerűen ennek a grafikus felület cseréjénél van a legnagyobb jelentősége). A következő osztályokat alakítottuk ki: 3.4.1. VirtualPostIt

A kontrollert megvalósító osztály. Feladata a program osztályainak létrehozása, a

GTK

rendszer inicializálása, valamint a szálkezelés elindítása. A program indításakor, valamint új üzenet érkezésekor a kijelző háttérvilágítását bekapcsolja a program. A megoldást alkalmazza a VirtualPostit osztály screen_turn_on() metódusa is. 3.4.2. OutgoingHandler

A modellhez tartozó osztály, amely a rendszerben lévő üzenetek kézbesítéséért felelős. A kontroller példányosítja. A program indítása után elinduló négy fő szál (VirtualPostit, MainWindow, IncomingHandler

és OutgoingHandler) egyike.

Példányosítása után első dolga betölteni az előre definiált nevű könyvtárakban levő adatokat (felhasználók, csoportok, üzenetek, ld. később). Ezeket feldolgozza, és a program működéséhez elengedhetetlenül szükséges asszociatív tömböket építi fel belőlük. A fő ciklusa a felhasználók periodikus felderítését végzi, azonosítja az ismert felhasználókat regisztrált eszközeik alapján, és kézbesíti nekik Bluetooth-on a rendszerben lévő, nekik szóló üzeneteket. A kiküldéshez a program a fun_encode.py fájlban lévő

28


segédfüggvények segítségével vNote formátumú üzenetet állít elő a nyers szöveg formátumú tárolt üzenetekből, majd ki is kézbesíti a kreált fájlt a megfelelő paranccsal. 3.4.3. IncomingHandler

A modellhez tartozó osztály, amely a bejövő üzenetek feldolgozásáért felelős. A bejövő üzeneteket nem a programunk, hanem a megfelelően feltelepített és beállított sobexsrv[10] OBEX szerver program fogadja, és menti el egy megadott könyvtárba (/home/user/receive). Az IncomingHandler feladata periodikusan figyelni a könyvtár tartalmát; ha ott megjelenik egy fájl, akkor azt feldolgozza, vagyis amennyiben az vNote formátumú üzenet, akkor a tartalmazott szöveget kinyeri belőle, ha pedig ASCII szöveg, akkor üzenetként értelmezi, különben pedig eldobja. Az IncomingHandler dolgozza fel a beérkezett videó illetve hang üzeneteket is (ez utóbbi esetben a feldolgozás csupán egy átnevezés megfelelő konvenció betartásával). Az értelmezett üzenetek a messages mappába képződnek le. 3.4.4. MainWindow

A program fő ablakát megjelenítő osztály. (Ablakok alatt itt a Hildon interfész esetén teljes képernyőt betöltő, inkább logikai egységeket kell érteni.) Az ablakok felépítése következetesen minden képernyőn hasonló, a navigációt megkönnyítendő. Az ablak bal felében a program logója, alatta pedig a főbb funkciók elérésére szolgáló gombok találhatóak (a főablakban például „Add User” és „Login without Bluetooth Device”), jobb oldalon pedig az aktuális ablak érdemi tartalma (a főablakban például a Bluetooth-on észlelhető, tehát a közelben tartózkodó, azonosított felhasználók neve, és zárójelben az, hogy hány olvasatlan üzenetük van). Az osztály példányosítása után elkészíti a grafikus felületet, valamint a modelltől lekérdezi annak állapotát (pl. a modell épp szkennelést végez, üzenetet kézbesít), valamint a modell által látott felhasználók listáját. Ezeket az információkat periodikusan frissíti. A modell állapotát a logó alatti szövegmezőben jeleníti meg („Scanning…”, „Delivering…”, „Scanning & Delivering…”). A jobb oldalon a modelltől kapott információk alapján a MainWindow megjeleníti a látható felhasználók listáját. A gombokra kattintva A UserWindow osztályból készül egy új példány. Külön figyelmet fordítottunk a GUI13 frissítésének villogásmentes megvalósítására. (Vagyis egy-egy frissítési ciklus között csak akkor változtasson a rendszer a GUI-n, ha tényleg történt változás.) 3.4.5. UserWindow

A felhasználók a

MainWindow

ablakában a nevüket a kijelzőn megérintve, majd a

jelszavukat megadva „beléphetnek” üzeneteik közé. Az üzenetlistájukat megvalósító

13 Graphical User Interface; grafikus felhasználói felület

29


osztály a UserWindow. A jelszavas azonosítás lehetővé teszi, hogy ne nézhessék meg egymás üzeneteit a közelben lévő felhasználók. Az ablak felépítése hasonló a főablakéhoz: a bal oldalon az új üzenet létrehozására szolgáló gombot és a kilépés gombját találjuk. Előbbi a NewMessageWindow-hoz visz, utóbbi pedig vissza a

MainWindow-ba.

Jobb oldalon az üzenetek listája található, melynek kezelése

hasonló a MainWindow-ban lévő felhasználói lista frissítéséhez (csak változás esetén frissül). Az üzenetek két GUI objektumból állnak: egy szövegmező tartalmazza magát az üzenetet, mellette pedig egy, az üzenet törlésére szolgáló gomb foglal helyet[11]. A

UserWindow

szintén a modellel kommunikál a

MainWindow-tól

kapott felhasználó

üzeneteinek lekérése érdekében. 3.4.6. NewMessageWindow

A program új üzenetek írására szolgáló ablaka. A bal odalon a UserWindow-hoz visszavezető „Cancel” gomb található, jobb oldalt pedig egy szövegmező, amelybe az üzenetet írhatjuk. A „Delete after delivery” jelölőnégyzetet bejelölve az üzenet Bluetooth kézbesítést követően automatikusan törlődik a rendszerből14 , ellenkező esetben viszont a program minden adandó alkalommal próbálja kézbesíteni azt. Az „Select Recipients” gomb megnyomása után az osztály kinyitja a RecipientsWindow-t, amiben a felhasználók és csoportok listájából választhatunk címzettet, majd az üzenet „elküldésre kerül”, vagyis bekerül a megfelelő formátumban a kimenő üzenetek közé, amit a modell a következő könyvtár-olvasás alkalmával észlelni fog, és beolvas. Érdemes megemlíteni, a Nokia N810 három féle lehetőséget nyújt a szövegbevitelre: a beépített QWERTY billentyűzeten kívül kétféle, az érintőképernyőn megjelenő virtuális billentyűzet is előcsalogatható: egyiket ujjal való gépelésre találták ki, a másikat pedig a pálcával való használatra. 3.4.7. RecipientWindow

Az üzenetküldéskor megjelenített címzettválasztót reprezentáló osztály. A bal oldalon található „Cancel” gombbal visszaléphetünk az előző képernyőre. Az ablak nagy részét a címzettek listája foglalja el, minden név előtt egy jelölődobozzal, jelezve, hogy az üzenetet több címzettnek is elküldhetjük. A felhasználók mellett jobb oldalt a csoportok is fel vannak sorolva hasonló módon, a címzettek közé ugyanis csoportokat is választhatunk. A megfelelő beállítások elvégzése után a „Send” gomb megnyomására az osztály elkészíti a megfelelő „mes” kiterjesztésű, fentebb említett formátumú üzenetfájlt a messages könyvtárba, majd bezáródik.

Pontosabban a felhasználók elől elrejtjük, de maga az üzenet tárolódik, jelezve a fájlban, hogy már kézbesítve lett. 30 14


3.4.8. NoDeviceWindow

A MainWindow „Login without Bluetooth Device” gombjának megnyomására előugró ablakot megvalósító osztály. Egy rádiógombokból álló listát jelenít meg a jelenleg éppen nem látott felhasználókból. A felhasználó ezek közül választva léphet be, és jelenítheti meg üzeneteit. Működése a MainWindow-éhoz hasonlít, azonban ennek tartalma csak újranyitáskor frissül (mivel nem tartottuk fontosnak ezt a funkciót és jelen formájában is több, mint használható). A belépés folyamata során a kiválaszott felhasználóval meghívódik a password.py fájl CheckPassword() függvénye, majd egy példány készül a UserWindow-ból.

3.5.A program működése A programot a

start.sh

shell script indítja, ami egyelőre a tesztelési szempontokat

figyelembe véve készült. Így ez először leállítja a Virtual Post-It esetlegesen már futó példányait, majd belép a program könyvtárába (ez a grafikus felületről történő indítás miatt szükséges többek között), és törli a cache fájlokat, majd a python értelmezővel elindítja a program főosztályát. 3.5.1. A kontroller működése

A

VirtualPostit

osztály indulásakor elvégzi a Bluetooth .és a GTK inicializálását,

bekapcsolja a képernyő háttérvilágítását, majd példányosítja az

OutgoingHandler-t

és az

IncomingHandler-t.

Ezek után a program grafikus felületének elkészítése következik, melynek során a VirtualPostit először létrehozza a MainWindow-t; ekkor még csak a memóriafoglalás történik meg. A

VirtualPostit

indítjuk el. A

run()

konstruktorának (__init__) lefutása után annak

run()

függvényét

felelős a létrejött osztályok – melyek mind implementálják a

Thread

osztályt – szálként való elindításáért: ezt a három említett osztálypéldány start() függvényének meghívásával éri el. Megjegyzendő, hogy a három szál egymásra majd olyan módon tud hivatkozni, hogy mindegyik példányosításakor megkapta a VirtualPostit-re mutató referenciát, azon keresztül pedig elérik az osztály publikus tagváltozójaként a másik szálat. (pl. IncomingHandler-ből,

feltételezve, hogy osztályra vonatkozó referenciát.)

cont.outgoing.delivery_message()

hívható az

nevű változóként vette át a

VirtualPostit

cont

A szálak leválasztása után a VirtualPostit osztály feladata még a MainWindow ablakának megjelenítése (self.mainwindow.window.show_all()), majd a GTK fő ciklusának futtatása. (Erre minden GTK alkalmazás esetén szükség van.) A programból való kilépés úgy történik, hogy a VirtualPostit osztálynak létezik egy stop nevű publikus változója, aminek értékét minden szál fő ciklusa folyamatosan vizsgálja. Amennyiben ennek értékét

False-ra

31

állítjuk, a ciklusok véget érnek, így a szálak


megszűnnek. A gkt.main() függvényt körbefogó történő kilépés kezelésére szolgál.

KeyboardInterrupt

kivétel a

Ctrl-C-vel

3.5.2. A modell működése

A modell az OutgoingHandler-ből és az IncomingHandler-ből áll. Előbbi a rendszerben lévő üzenetek kézbesítésével, utóbbi pedig az OBEX szerver által fogadott fájlok feldolgozásával foglalkozik. A modell működését a 12. ábra szemlélteti, a 13. ábrán pedig az OutgoingHandler életciklusát részletezzük. OutgoingHandler start

Adatok beolvasása

Bluetooth szkennelés

Várakozás

Üzenetek kiküldése

OBEX szerver könyvtárának beolvasása

Új üzenetek átmásolása Új üzenetek értelmezése

Várakozás Üzenetek mentése a kimen! könyvtárba IncomingHandler

12. ábra: A modell működése

Az OutgoingHandler konstruktora az osztály változóit inicializálja: • cont

– a VirtualPostit osztályra való hivatkozás

• counter

– ennyi várakozó ciklus után indítja be a scan-elést

• sleeptimer • scanning

– ennyi másodpercet várakozik két ciklus közt

– szemafor, mely megmondja, hogy épp szkennelés stádiumban van-e a

program • deliveringmessage

– szemafór, mely megmondja, hogy épp üzenetkézbesítés

stádiumban van-e a program • foundusers

– a közelben lévő felhasználók neveit tartalmazó tömb 32


Start

Adatok beolvasása

Bluetooth szkennelés

Ismert a talált MAC?

N

I A talált felhasználó bejegyzése

Következ! talált MAC

I

Van még talált MAC?

Látható csoportok számítása

Az üzenet címzettei között szerepel a talált felhasználó?

N

Van még üzenet?

I I

N

Van még felhasználó?

N

I Üzenet kézbesítése

Következ! üzenet

Az üzenet címzettei között szerepel a talált csoport?

N

Következ! talált felhasználó

Van még üzenet?

I I

Van még csoport?

I Üzenet kézbesítése

Következ! üzenet

Következ! talált csoport

Várakozás

13. ábra: Az OutgoingHandler működése

33

N


A szál leválasztásakor a run() függvény indul el, mely a már említett változó (VirtualPostit.stop) értékének igazban maradásáig fut. Minden ciklus elején beolvassuk a függvény segítségével a fájlrendszerből a felhasználókat, csoportokat, üzeneteket és jelszavakat (ld. 14. ábra), így érjük el az akár teljesen független felületekkel való adatcserét (pl. egy jövőbeni PHP alapú Web-es felületnek nem szükséges a memóriában adatot cserélnie a Python programmal, könnyedén bevihet a rendszerbe új felhasználókat vagy üzeneteket a megfelelő fájlok megfelelő helyre történő elhelyezésével, ami sokkal könnyebben megvalósítható). Minden ciklus vége egy sleeptimer másodpercig tartó várakozás, a processzor túlterhelését megelőzendő. load_data()

Start

messages

Üzenetek beolvasása

users

Felhasználók beolvasása

groups

Csoportok beolvasása

passwords

Jelszavak beolvasása

Stop

14. ábra: A load_data() függvény működése

A ciklus minden counter-edik alkalommal a Python bluetooth könyvtára segítségével beolvassa a közelben lévő Bluetooth eszközök Bluetooth címét, majd végignézve a felhasználók eszközeinek listáját megállapítja, hogy mely felhasználók elérhetőek (15. ábra), ezeket pedig egy foundusers nevű tömbbe teszi. Fontos megjegyezni, hogy a felhasználók nevének semmi köze sincs az eszközök Bluetooth nevéhez. A program nem használja ez utóbbi adatot.) 34


Start

Tagja a csoportnak a felhasználó?

N

I

N

I

A csoport online

Van még csoport?

Van még online felhasználó?

Következ! online felhasználó

N

I Következ! csoport

Stop

15. ábra: A látható csoportok számítása

Hasonlóan történik az elérhető csoportok megállapítása is. Egy csoport elérhetőnek számít, ha annak bármely felhasználója elérhető. Ezután az üzenetek kiküldése következik. Végigmegyünk az üzeneteken, és amennyiben az üzenet bármely címzettje elérhető (legyen az csoport, vagy felhasználó) a deliver_message() függvénnyel kézbesítjük az üzenetet. A 16. ábra a deliver_message() függvény működését szemlélteti. Az IncomingHandler hasonló alapötletre épül. A fő szál ciklikusan beolvassa annak a könyvtárnak (/home/user/received) a tartalmát, melybe a feltelepített OBEX szerver (sobexsrv) elmenti a bejövő fájlokat. Hogy többször ne olvassuk be ugyanazokat a bejövő fájlokat, innen egyből egy mv (move) paranccsal átmozgatjuk őket egy ideiglenes könyvtárba (parsefolder), ahol a programunk fel fogja dolgozni őket.

35


Start

kézbesítve = hamis

N

Ha a címzett online

I I

Kézbesítve van már?

N Üzenet legenerálása outgoing

Generált üzenet elmentése

Küldés: obex push

N

Van még eszköze a felhasználónak?

Sikeres?

I

Következ! eszköz

I N

kézbesítve = igaz

Stop

16. ábra: A deliver_message() függvény működése

Az osztály további kódja három részre oszlik: az első rész megállapítja, hogy van-e

vnt

kiterjesztésű vNote formátumú fájl az ideiglenes könyvtárban. Amennyiben igen, feldolgozza azt, vagyis megállípítja a karakterkódolását (ha nincs megjelölve, akkor alapértelmezésként ISO-8859-2-t használ). Ezután eldobja a számunkra érdektelen fejléceket, és a megmaradt tartalmi részt dekódolja a Quoted-Printable kódolást (ami a quopri Python könyvtárban található) használva. Hibás üzenetformátum esetén leáll a feldolgozással. A második rész a fogadott egyszerű szövegfájlok feldolgozásáért felel. fájlokat keres, majd azokat ISO-8859-2 kódolást feltételezve értelmezi. 36

txt

kiterjesztésű


A harmadik rész felel a videó és hang üznetek áthelyezéséért és megfelelő névvel történő ellátásáért. Szöveges üzenet esetén az értelmezett üzenetet tovább feldolgozzuk, vagyis a várt fogadott üzenetformátumnak megfelelően (ami [;[;…]] #üzenet)

szétbontjuk, és a

messages

könyvtárba új fájlként üzenetet készítünk belőle. Ezt a

következő ciklus alkalmával az OutgoingHandler megtalálja, és nyilvántartásba veszi. A videó és hang üzenetekkel további műveleteket nem kell végeznünk. 3.5.3. A grafikus felület működése

A grafikus felület GTK widget-készletet használ a Python PyGTK könyvtárán keresztül. A grafikus környezet inicializálását a kontrollerként funkcionáló VirtualGraffiti osztály már elvégzi, így a grafikus felület osztályainak csak az ablakok összeállításával, a widgetek megfelelő módon történő elhelyezésével és a felhasználói interakciók lekezelésével kell törődnie. A konstruktorok végzik el a felület objektumainak elkészítését (vízszintes panelek (HPaned), függőleges dobozok (VBox), kép objektumok (Image), címkék (Label) és gombok (Button)). Ezekből összeállítják a kívánt felületet, majd az ablakot teljes képernyőre kényszerítik (hogy a Hildon felület felesleges ablaknevet, gombokat, státusz widget-eket és menüket tartalmazó kerete ne foglalja a számunkra értékes helyet). A MainWindow osztály működése a legösszetettebb. Összesen négy tömb segítségével folyamatosan nyilvántartja, hogy milyen gombok vannak (actfoundusers), illetve voltak (lastfoundusers) a felületen, valamint hogy a következő ütemben ezekből melyik gombokat kell levenni (removeusers) és mely új gombokat kell feltenni (addusers). A ciklikus működés itt is megfigyelhető. Minden ciklusban a modell állapotának (pontosabban szemaforjainak) megfelelően beállítjuk a státusz címke értékét („Scanning”, „Delivering”, egyik sem, ill. mindkettő). Lekérdezzük az adott időpillanatban a látható felhasználókat a modelltől (a már említett, kontrolleren keresztüli módon), majd kiszámítjuk az előbb említett tömbök értékét. Egy

külön,

userbuttons

nevű,

asszociatív

tömböt

tartunk

fenn

a

gombok

nyilvántartására. Új gomb létrehozásakor ennek adunk egy új tömbelemet, gomb eltávolításakor pedig a megfelelő felhasználóhoz tartozó elemet töröljük. (A tömbelemek a felhasználók neveivel vannak indexelve.) Természetesen a felületen „élesben” kint lévő listán is elvégezzük a megfelelő módosításokat (gomb be- és kiregisztrálása). A rendszer a megtalált felhasználók számának nyilvántartásával képes arra is, hogy egy Label-ben kiírja a gombok listájának helyére azt, ha nem található egy felhasználó sem. A ciklus végén a gombok szövegére a felhasználónév után kiírjuk a felhasználó számára érkezett üzenetek számát is zárójelben, majd sleeptimer-nyi időt várakozunk.

37


A gombok a login_with_device() függvényt hívják meg megnyomásukkor. Azok a megnyomáskor a saját (mármint a gombok) nevével együtt a gombhoz tartozó felhasználó nevét is megadják a függvénynek paraméterül. A függvény a password.py fájlban található CheckPassword() meghívásával bekéri a felhasználó jelszavát, majd ha az eredményes volt, akkor példányosít egy

UserWindow

objektumot, megjeleníti azt, ezt követően pedig saját

magát elrejti, majd új szálként elindítja az ablakot. A „Login without Bluetooth device” gomb megnyomásával a hasonló nevű függvény hívódik meg, ami a NoDeviceWindow osztályt példányosítja és jeleníti meg. Az osztály egyéb függvényei a teljes képernyő és ablakban futás közti váltás kezeléséért, valamint a programból való kilépésért felelősek. A UserWindow osztály működése nagyban hasonlít a MainWindow-éhoz; annyi az eltérés, hogy itt a modelltől az üzenetek listáját kérjük el, melyet aztán a filter_user() függvénnyel szűrünk meg a kívánt felhasználónak szóló üzenetekre. Egyszerű gombok helyett itt összetettebb, HPaned, Label és Button objektumokból álló konstrukciók kerülnek hozzáadásra és eltávolításra, hasonló módon. A törlés gomb kezelése az üzenet referenciájának átadásával megoldott, így maga a grafikus felület törli le az üzenet fájlját, amit a következő ciklusban észlel a modell. Fontos még, a logout() függvény, mely először a kontrolleren keresztül elért MainWindow ablakát jeleníti meg újra, majd saját magát elrejti, és a főciklus leállításával az egész szálat törli. A NewMessageWindow send() függvénye ellenőrzi, hogy nem üres üzenetet próbálunk-e elküldeni, majd az üzenetet paraméterként átadva megnyitja a RecipientWindow-t. A függvénye létrehoz egy üzenetfájlt a messages könyvtárban, amit a modell a következő ciklus során beolvas és nyilvántartásba vesz. RecipientWindow send()

A

PasswordCheck()

függvény a paraméterül kapott felhasználó jelszavát olvassa be a

könyvtárból, majd megjelenít egy Hildon jelszóbekérő ablakot, és az abból kapott jelszó hash-ét veszi a Python md5 könyvtárának[12] segítségével. Ezt a hash-t összehasonlítja az eltárolt jelszó hash-sel, majd ha a kettő egyezik, akkor OK-val tér vissza, ellenkező esetben NOK-val. passwords

A

NoDeviceWindow

nem tartalmaz újdonságot az eddigiekhez képest, feladata a

kiválasztott felhasználó beléptetése. 3.6. Fejlesztési lehetőségek A program a választott Python nyelvnek és a MVC architektúrának köszönhetően viszonylag kis befektetéssel bővíthető az igényeknek megfelelően. Elsődleges célunk a bevezetésben tárgyalt célok elérése volt, azok fontosságának sorrendjében, de nyitottak vagyunk új ötletek beépítésére is. 38


A következőkben pár példát említünk a bővíthetőségre, de ennél sokkal több lehetőség áll rendelkezésre. 3.6.1. Grafikus felület lecserélése

Már korábban is említettük, hogy a grafikus felület a futtató platform adottságainak megfelelően lecserélhető a modell módosítása nélkül. Először természetesen meg kell írni a grafikus felületet a kívánt widget-készletre, majd pedig a felület eseményeit hozzá kell rendelni a modell eseményeihez. Ez konkrétan abban nyilvánul meg, hogy a kontroller osztálypéldányosításait le kell cserélni az új GUI osztályaira, valamint az új felületnek ugyanúgy a kontrolleren keresztül kell lekérdeznie a modelltől annak paramétereit (pl. látható felhasználók). Minden további nélkül lehetőség van a lecserélés mellett akár párhuzamosan több grafikus felület futtatására is; értelemszerűen ilyen esetben a meglévő felület hívásai mellé kell elhelyezni az új kódot. 3.6.2. Új formátumok támogatása

Az IncomingHandler-t vNote és ASCII text formátumú szövegek fogadására készítettük fel, azonban szükség lehet rá, hogy kevésbé népszerű formátumokat is támogassunk (pl. a PocketPC-k PocketOffice-ának formátumát). Ez az IncomingHandler bővítésével megoldható. A kódot pl. a txt-t értelmező rész után szúrhatjuk be, tetszőleges elven válogathatunk a parsefolder-ben lévő fájlokból, majd egy értelmező kód megírásával kinyerhetjük az üzenet tartalmát, amire csak két megkötés van: UTF-8 kódolásban tároljuk el, mégpedig a messages könyvtárba (tetszőleges fájlnéven), és a fentebb részletezett üzenetformátumban. 3.6.3. A mobilról küldött üzenetek információtartalmának bővítése

Lehetőség van arra is, hogy a címzett mellett a „Delete after delivery” jellemzőt is megadjuk a mobilról érkező üzenetek esetében. Ehhez az IncomingHandler azon részeit kell módosítani, ahol a # karakter alapján vágja szét a kód a már dekódolt üzenetet. 3.7. Jövőbeli terveink Az alkalmazás jelenlegi formájában még közel sincs készen, bár már működőképes, bizonyos célokra pedig már most remekül használható. Elsősorban a következő célokat tűztük ki magunk elé: 3.7.1. Web-es felület elkészítése

A tervek szerint egy lighttpd[13], vagy thttpd[14] alapú webszervert állítunk üzembe az eszközön, amin egy PHP program fog hasonló (néhol bővebb) funkcionalitást elvégezni, mint a jelenlegi GTK alapú grafikus felület. Ez a web-es interfész távolról is elérhető lesz, akár mobiltelefonról, út közben, vagy otthonról számítógépen böngészhetjük az

39


üzeneteinket, hagyhatunk üzenetet másoknak, illetve a felhasználók és csoportok adminisztrálását végezhetjük el a rendszergazdai jogok birtokában. 3.7.2. Áttérés adatbázis alapú tárolásra

A jelenlegi, fájl alapú adattárolás nem túl jól skálázható, ezért feltett szándékunk az adattárolás migrálása valamely SQL alapú adatbázisba, amely vagy a programot futtató eszközön, vagy akár egy távoli gépen fut majd. A távoli gép előnye, hogy több példány is futhat különböző helyeken a programunkból, így akár az is megoldható, hogy az egyik helyen hagyott üzenetet egy távoli helyen lévő másik programpéldány kézbesítse a címzettnek, amennyiben az ott elérhető. 3.7.3. Bluetooth jelerő információk felhasználása

Bizonyos korlátozott lehetőségünk van a Bluetooth kapcsolatok jelerejének lekérdezésére is. Ezekből az adatokból hasznos információkat vonhatunk le a programunk segítségével: kideríthető például, hogy valaki épp közeledik-e az eszközhöz, távolodik-e tőle, vagy mondjuk huzamosabb ideig a közelben dolgozik. Más-más viselkedés társítható a különböző viselkedési formákhoz (pl. ha huzamosabb ideig az eszköz környékén van a felhasználó, akkor nem akar Bluetooth kézbesítést, hanem a kijelzőn történő olvasást preferálja). 3.7.4. SMS értesítő kiküldése

Egy SMS gateway-en keresztül szeretnénk lehetőséget biztosítani arra, hogy a program bizonyos üzeneteket SMS-ben kiküldjön a címzettnek. 3.7.5. További multimédiás szolgáltatások

A videó üzenetek Bluetooth-on keresztüli fogadásán túl terveink közt szerepel az N810 beépített kamerájának, ill. mikrofonjának használata videó, ill. hang felvételre.

40


4. Összefoglalás Tudományos diákköri dolgozatunkban egy „Virtual Post-It” névre hallgató virtuális üzenőfal tervezését és megvalósítását mutattuk be. Kitűztük, specifikáltuk az üzenethagyó rendszer által megvalósítandó feladatokat, megvizsgáltuk a tudományos szakirodalom által ajánlott javaslatokat, lehetőségeket, és a támasztott követelményeket. Az általunk elkészített alkalmazást ezen alapelvek alapján igyekeztük megvalósítani. Az alkalmazás egy nagyobb rendszer része, szervesen kapcsolódik TMIT kutatóinak a Mobil Innovációs Központ (MIK) keretein belül végzett tudományos munkájához, ezen belül is az Intelligens Iroda projekthez. A dolgozatban bemutatott eszköz és program a napjainkban sokat emlegetett intelligens környezetek egy építőeleme, mely környezetek jelentősége napról-napra növekszik, új és új értéknövelt és az emberi munkát megkönnyítő szolgáltatások nyújtásával.

5. Köszönetnyilvánítás Ezúton is szeretnénk köszönetet mondani témavezetőnknek, Dr. Vida Rollandnak a tudományos diákköri dolgozat elkészítéséhez nyújtott segítségéért, ránk fordított idejéért, ötleteiéért és javaslataiéért!

41


6. Rövidítéslista Rövidítés 3G 3GP AMR API ARM ASCII FTP GSM GTK GUI IM IrDA MD5 MVC

Angol kifejtés Third Generation Third Generation Partnership Project Adaptive Multirate Application Programming Interface Advanced RISC Machine American Standard Code for Information Interchange File Transfer Protocol Global System for Mobile communications GIMP Toolkit Graphical User Interface Instant Messaging Infrared Data Association Message-Digest algorithm 5 Modell-View-Controller

Magyar kifejtés Harmadik generációs Harmadik generációs partner projekt Adaptív többfokú Alkalmazás program-felülete Fejlett RISC gép Egységes amerikai kód az információcseréhez Fájlátviteli protokoll Globáli mobilkommunikációs rendszer GIMP eszközkészlet Grafikus felhasználói felület Azonnali üzenetküldés Infravörös Adat Egyesület 5-ös üzenet-kivonatoló algoritmus Modell-Nézet-Vezérlő

OBEX PC PDA PHP

Object Exchange Personal Computer Personal Digital Assistant PHP: Hypertext Preprocessor

Objektum-csere Személyi számítógép Személyi digitális asszisztens PHP: hiperszöveg előfeldolgozó

PIN RFID SMS SoC SQL

Personal Identification Number Radio-Frequency Identification Short Message Service System-on-a-Chip Structured Query Language

Személyes azonosító szám Rádiófrekvenciás azonosítás Rövid üzenet szolgáltatás Rendszer-egy-chipben Struktúrált lekérdező nyelv

SSH UMTS

Secure Shell Universal Mobile Telecommunications System

UTF-8

8-bit UCS/Unicode Transformation Format

VNC vNote W3C

Virtual Network Computing Virtual Note World Wide Web Consortium

Titkosított shell Univerzális mobil telekommunikációs rendszer 8 bites UCS/Unicode transzformációs formátum Virtuális hálózati számítástechnika Virtuális jegyzet Világ méretű háló konzorcium

WiFi

Wireless Fidelity

Drót nélküli hűség

WLAN

Wireless Local Area Network

Drót nélküli helyi hálózat

42


7. Irodalomjegyzék [1] Sneiderman, Ben: Leonardo's Laptop, Human Needs and the New Computing Technoloiges, MIT Press, 2003, ISBN: 0-262-19476-7. 104-106.o. [2] Béni, Tibor: Munkaidő-nyilvántartó rendszer impro beléptető rendszerhez, Diplomamunka, Pannon Egyetem, Műszaki Infomratikai Kar, 2007 [3] Nokia N Series – Nokia N810 http://www.nseries.com/index.html#l=products,n810

[4] USSP Push man page http://www.digipedia.pl/man/ussp-push.1.html

[5] hcitool man page http://linuxcommand.org/man_pages/hcitool1.html

[6] Python programming language official website http://www.python.org/

[7] PyBlueZ API documentation http://pybluez.googlecode.com/svn/www/docs-0.7/index.html

[8] PyGTK: GTK+ for Python http://www.pygtk.org/

[9] Maemo.org: Python-maemo-3.x: Hildon Widgets API for Python http://maemo.org/development/documentation/apis/3-x/python-maemo-3.x/↩ pyhildon_widgets_all.html

[10] Collin R. Mulliner: Scripting/Secure OBEX Server http://www.mulliner.org/bluetooth/sobexsrv.php

[11] Learning Python: Writing a Custom Widget Using PyGTK http://www.learningpython.com/2006/07/25/writing-a-custom-widget-using-pygtk/

[12] Python library reference: md5 http://docs.python.org/lib/module-md5.html

[13] Lighttpd – fly light: http://www.lighttpd.net/

[14] tiny/turbo/throttling HTTP server http://acme.com/software/thttpd/

43

Tudományos Diákköri Dolgozat 2008

Recommend Documents