Image
30.6.2016 0 Comments

Programujeme pre Android /12. časť

V tejto časti seriálu opíšeme nové bloky programového kódu aplikácie db_sync, pomocou ktorých sme ukončili implementáciu všetkých častí CRUD (Create Read Update Delete), teda skupiny príkazov umožňujúcich manipuláciu s údajmi uloženými v tabuľkách databáz. Vytváranie a čítanie údajov z tabuliek umožňovala už prvá verzia aplikácie. Do druhej verzie sme doplnili časti súvisiace s aktualizáciou a mazaním údajov. V neposlednom rade sme aplikáciu rozšírili o BroadcastReceiver periodicky kontrolujúci výskyt zmien v databáze MySQL.

Aktualizácia a mazanie údajov

Na jedinečnú identifikáciu konkrétnych riadkov v rámci oboch databáz sme do tabuliek doplnili stĺpec typu DATETIME. Uvažujeme pritom v intenciách toho, že v jednom čase nevzniknú nové riadky súčasne v oboch databázach. Keby sa tak aj stalo, muselo by to nastať v tej istej sekunde, čo je málo pravdepodobné, najmä ak počítame s faktom, že aplikáciu db_sync a časť nachádzajúcu sa na serveri používa ten istý používateľ. Nami použitý spôsob identifikácie riadkov nie je jediný ani dokonalý, no postačuje na vysvetlenie princípu práce jednotlivých algoritmov.

Pri aktualizácii údajov sa najskôr vykoná kontrola existencie konkrétneho riadka v tabuľke SQLite. Kód tejto kontroly je doplnený do funkcie update_SQLitedB(). Pomocou dopytu (query) dochádza k výberu riadka tabuľky SQLite, ktorého údaj uložený v stĺpci DATETIME sa rovná údaju uloženému v stĺpci DATETIME tabuľky MySQL. V prípade, ak takýto riadok existuje, nedôjde k doplneniu nového riadka do databázy SQLite, ale k aktualizácii už existujúceho riadka. Úplne rovnaký princíp je aplikovaný aj v skripte PHPV okamihu, keď má dôjsť k doplneniu riadka do tabuľky MySQL, sa najskôr načíta riadok tabuľky MySQL, ktorý má rovnaký údaj DATETIME, a v prípade, ak sa takýto riadok v tabuľke nachádza, dôjde namiesto doplnenia nového riadka k aktualizácii už existujúceho riadka.

V prípade mazania údajov sme do oboch tabuliek doplnili stĺpec tobedeleted, ktorý identifikuje riadky určené na zmazanie. Pri požiadavke na zmazanie jedného, resp. všetkých riadkov nedôjde k ich okamžitému zmazaniu, ale iba k nastaveniu príkazu tobedeleted. Zmazanie údajov nastane až v okamihu synchronizácie databáz, a to vykonaním funkcií delete_from_SQLitedB() a Na strane servera túto úlohu plní nový skript PHP delete_tbd_rows.


Aplikácia db_sync_v2, vpravo – riadok označený na zmazanie, dole obsah tabuľky databázy MySQL po zmazaní riadka

AlarmManager, PendingIntent, BroadcastReceiver

Podrobné vysvetlenie všetkých detailov týkajúcich sa uvedených troch tried ďaleko presahuje rozsah tohto článku. Ich význam preto uvedieme iba stručne.

Trieda AlarmManager je určená na spúšťanie požadovaného programového kódu vo vopred stanovenom čase (časových intervaloch), a to aj v prípade, ak aplikácia, ktorá AlarmManager používa, nie je práve spustená. Inštanciu triedy AlarmManager vytvárame pomocou context.getSystemService(Context.ALARM_SERVICE).

Metódou setRepeating() nastavujeme periodicitu spúšťania alarmov. Jej parametrami sú:

  1. typ (variant) správania sa alarmu,
  2. čas, keď má byť alarm prvýkrát spustený,
  3. interval spúšťania (v milisekundách),
  4. operácia, ktorá sa má vykonať po spustení alarmu.

PendingIntent je druh zámeru (intent), ktorým poskytneme aplikácii, ktorá zámer, resp. požadovanú operáciu vykoná, rovnaké práva, ako má aplikácia, ktorá zámer odoslala. PendingIntent dôsledne dodržiava princíp odovzdávania tokenu (známky), ktorý je udržiavaný vo funkčnom stave aj v prípade ukončenia aplikácie, ktorá ho vytvorila.

Inštanciu triedy PendingIntent vytvárame rôznymi spôsobmi. Medzi ne patrí aj vytvorenie metódou getBroadcast(), ktorou získame PendingIntent vysielajúci systémový broadcast. V našom prípade ide o broadcast zámer, ktorý prijme práve nami zaregistrovaný receiver MyReceiver.

BroadcastReceiver je trieda prijímajúca zámery (intents) posielané systémovými broadcastmi. Tento systémový mechanizmus je odlišný od veľmi podobného mechanizmu štartu aktivít pomocou zámerov. BroadcastReceivery nereagujú na zámery určené na štart aktivít a rovnako broadcastové zámery nie sú určené na štart aktivít. Štart aktivity je operácia vykonávaná na popredí a naopak, broadcast zámeru je operácia vykonávaná na pozadí.

BroadcastReceiver implementuje metódu onReceive(), ktorá je spúšťaná po prijatí broadcastového zámeru. Objekt receivera existuje iba počas výkonu uvedenej metódy. Po jej ukončení možno objekt receivera systémovo zrušiť.


Notifikácia používateľa o zmene tabuľky databázy MySQL, vpravo oznam o počte zmenených riadkov

Service

Služba aplikácie (application service) beží v rovnakom procesnom vlákne ako sama aplikácia. Nejde teda o samostatný proces ani o samostatné vlákno. Je to súčasť - komponent - aplikácie, pomocou ktorej je aplikácia schopná odovzdať systému požadovanú informáciu. Naštartovaním služby pomocou metódy startService() dôjde k vykonaniu metódy onStartCommand(), do ktorej umiestňujeme náš programový kód. Našu službu MyService používame na notifikáciu používateľa, a to s využitím triedy NotificationCompat.Builder.

V rámci aplikácie db_sync_v2 nájdeme kód obsahujúci inštancie už spomínaných tried v rámci metódy onCreate() triedy Inštanciu triedy PendingIntent získavame pomocou getBroadcast() a odovzdávame AlarmManageru v rámci jeho metódy setRepeating().

Metóda onReceive() triedy MyReceiver rozširujúca triedu BroadcastReceiver je vykonávaná každých 5 minút zaslaním príslušného broadcastového zámeru. Úlohou receivera je získať počet nezosynchronizovaných riadkov tabuľky MySQL. Ak sa v tabuľke MySQL nachádzajú zmenené, teda nezosynchronizované riadky, je spustená služba Tá má jedinú úlohu - oznámiť (notifikovať) používateľovi, že došlo k zmene obsahu tabuľky databázy MySQL. Po kliknutí na ikonku notifikácie dôjde k spusteniu aktivity MainActivity, v rámci ktorej môže používateľ vykonať synchronizáciu (výberom v menu).

 

Zobrazit Galériu
Autor: Marek Sopko

Nechajte si posielať prehľad najdôležitejších správ emailom

Mohlo by Vás zaujímať

ITPro

Linux súkromne i pracovne v2.0 (14. časť): Small Business Server

09.11.2016 14:57

Pojem Small Business Server (malý firemný server) začala používať spoločnosť Microsoft ešte v roku 2000 na označenie servera, ktorý ­dokázal plniť úlohy niekoľkých samostatných serverov. Aplikačná vrs ...

ITPro

Industry 4.0: Fikcia alebo už realita?

09.11.2016 14:52

Štvrtá priemyselná revolúcia je pomenovanie rozsiahlych zmien prudko vstupujúcich do súčasného priemyslu. Nositeľom týchto zmien je digitalizácia výroby a optimalizácia všetkých podnikových procesov v ...

ITPro

Vývoj aplikácií UWP pre Xbox One II.

09.11.2016 14:47

V predošlej časti sme ukázali postup, ako si ­vytvoriť vývojársky účet a aktivovať vývojársky režim na hernej konzole Xbox One, aby ste mohli testovať svoje aplikácie. Výhodou hernej konzoly Xbox je v ...

Žiadne komentáre

Vyhľadávanie

Kyocera - prve-zariadenia-formatu-a4-s-vykonom-a3

Najnovšie videá