Post on 20-Aug-2020
Wydział Informatyki i Zarządzania
kierunek studiów: Informatyka
Praca dyplomowa - inżynierska
Aplikacja zarządzająca listą zadań za pomocą głosu
Mateusz Tomasz Wielgosz
słowa kluczowe:
Android
zarządzanie wydarzeniami
asystent głosowy
krótkie streszczenie:
Celem pracy jest zaprojektowanie i zaimplementowanie aplikacji mobilnej na
platformę Android, która będzie w sposób interaktywny zarządzała listą zadań /
wydarzeń zdefiniowanych przez użytkownika, w szczególności: rozpoznawała
komendy wypowiedziane przez użytkownika, umożliwiała dodawanie
wydarzeń do kalendarza, modyfikowanie prywatnych wpisów/ notatek
użytkownika i powiadamiała o konfliktach terminów dodawanych do
kalendarza z wpisami już istniejącymi.
opiekun pracy
dyplomowej
dr inż. Marek Kopel ....................... ....................... Tytuł/stopień naukowy/imię i nazwisko ocena podpis
Do celów archiwalnych pracę dyplomową zakwalifikowano do:*
a) kategorii A (akta wieczyste)
b) kategorii BE 50 (po 50 latach podlegające ekspertyzie) * niepotrzebne skreślić
pieczątka Instytutu, w którym
student wykonywał pracę
Wrocław 2016/2017
Streszczenie
Celem pracy jest zaprojektowanie i zaimplementowanie aplikacji mobilnej na platformę
Android, która będzie w sposób interaktywny zarządzała listą zadań / wydarzeń
zdefiniowanych przez użytkownika, w szczególności: rozpoznawała komendy wypowiedziane
przez użytkownika, umożliwiała dodawanie wydarzeń do kalendarza, modyfikowanie
prywatnych wpisów/ notatek użytkownika i powiadamiała o konfliktach terminów dodawanych
do kalendarza z wpisami już istniejącymi. Dzięki możliwością, jakie daje Google, powstałe
rozwiązanie łączy wiele usług i możliwości znanych z najpopularniejszych pozycji w Sklepie
Play zachowując przy tym wysoką wygodę użytkowania oraz spójny interfejs graficzny zgodny
z wytycznymi Material Design. Implementacja została zrealizowana. Efektem jest działająca
aplikacja skupiająca notatki, zadania i wydarzenia z planu dnia w jednym miejscu.
Abstract
The purpose of this thesis is to create a project and implement a mobile application on
Android platform, which takes care of ToDo list, events and private notes. User can interact
with voice commands and phrases. The application has a possibility to delete or add calendar
events, modify private notes and tasks and inform the user whenever new event will be in a
conflict with already existing ones. All of this is implemented with friendly user interface,
compatible with Material Design concept. The implementation is completed. As the result of
this project there is a working application with private notes, events and tasks management
support.
Spis treści 1. Wprowadzenie ................................................................................................................................ 4
1.1. Geneza pracy ........................................................................................................................... 4
1.2. Cel pracy .................................................................................................................................. 4
1.3. Użytkownik docelowy .............................................................................................................. 5
2. Porównanie technologii i istniejących rozwiązań .......................................................................... 5
2.1. Istniejące rozwiązania ............................................................................................................. 5
a) SplenDo ................................................................................................................................... 5
b) Any.do...................................................................................................................................... 8
c) Voice Search .......................................................................................................................... 10
2.2. Porównanie istniejących rozwiązań z projektem aplikacji .................................................... 12
2.3. Przegląd środowisk i technologii ........................................................................................... 12
3. Założenia projektowe ................................................................................................................... 15
3.1. Wymagania funkcjonalne ...................................................................................................... 15
3.2. Wymagania niefunkcjonalne ................................................................................................. 16
3.3. Architektura systemu ............................................................................................................ 17
3.4. Sposób realizacji .................................................................................................................... 17
4. Projekt aplikacji ............................................................................................................................ 17
4.1. Diagram przypadków użycia .................................................................................................. 18
4.2. Opis przypadków użycia ........................................................................................................ 19
a) Moduł zarządzania wydarzeniami ......................................................................................... 19
b) Moduł zarządzania zadaniami ............................................................................................... 22
c) Moduł zarządzania prywatnymi notatkami ........................................................................... 24
4.3. Projekt interfejsu użytkownika .............................................................................................. 26
4.4. Wzorce projektowe i architektoniczne.................................................................................. 31
5. Implementacja .............................................................................................................................. 31
5.1. Wykorzystane środowiska i narzędzia programistyczne ....................................................... 32
5.2. Elementy składowe projektu ................................................................................................. 32
5.3. Interfejs użytkownika ............................................................................................................ 32
5.4. Problemy implementacyjne i ich rozwiązania ....................................................................... 40
5.5. Możliwości rozwoju projektu ................................................................................................ 43
6. Podsumowanie ............................................................................................................................. 43
Bibliografia ............................................................................................................................................ 45
Spis ilustracji ......................................................................................................................................... 47
Spis tabel ............................................................................................................................................... 49
1. Wprowadzenie
1.1. Geneza pracy
Znajdujemy się w takim momencie rozwoju technologii, że powoli coraz mniej rzeczy
potrafi nas zaskoczyć. Jeszcze kilkanaście lat temu posiadanie urządzenia tak wielofunkcyjnego
i użytecznego jak smartfon było dla nas niewyobrażalne. Wydajne komputery, na których
pracowaliśmy nie miały nawet zbliżonej funkcjonalności do tego, co teraz prawie każdy z nas
nosi przez cały dzień w kieszeni swoich spodni. Już coraz śmielej na rynku pojawiają się
inteligentne zegarki, opaski, okulary a nawet pralki czy lodówki.
Autor zauważył potrzebę rozwijania nowych sposobów wprowadzania i zarządzania
informacjami, zadaniami lub po prostu tekstem. Pisanie na klawiaturze jest coraz mniej
praktyczne. O wiele wygodniej jest komunikować się z otaczającymi nas inteligentnymi
urządzeniami (smart devices) poprzez gesty lub mowę. Trend wydawania komend do aplikacji
w sposób bardziej interaktywny niż wprowadzanie tekstu staje się coraz bardziej popularny, a
najwięksi gracze na rynku nowych technologii prześcigają się w coraz to lepszych i nowszych
wynalazkach w tej dziedzinie.
Dzisiaj możemy już dość wygodnie korzystać z takich propozycji jak apple’owe Siri,
Cortana z Microsoftu lub Voice Search od Google. Każdy z wymienionych asystentów
głosowych korzysta z zaplecza funkcji i aplikacji swojej firmy. Wyłonienie jednoznacznie
najlepszego systemu głosowego nie jest możliwe. Myśląc jednak o tej pracy skupiłem się na
potężnej sile możliwości Google i to z rozwiązań tej firmy będę korzystał.
Z drugiej strony życie każdego z nas dzisiaj składa się z ogromnej liczby często szybko
zmieniających się wydarzeń, zadań i obowiązków. Potrzebujemy mieć wszystkie ważne dla nas
informacje pod ręką oraz na bieżąco planować swoje kolejne dni. Stąd pojawił się u autora
pomysł zaprojektowania i zaimplementowania aplikacji dzięki której każdy w wygodny sposób
będzie mógł zarządzać swoimi wydarzeniami w kalendarzu, zadaniami jak i notatkami z
poziomu jednej prostej i wygodnej aplikacji. Program będzie mocno zintegrowany z
rozwiązaniami Google, w tym z asystentem głosowym.
1.2. Cel pracy
Celem pracy jest zaprojektowanie i zaimplementowanie aplikacji służącej do
zarządzania wydarzeniami w kalendarzu, wygodnej obsługi list zadań (ToDo lists) oraz
usuwania i dodawania osobistych notatek. Praca będzie realizowana w środowisku Android
Studio, w oparciu o język programowania Java. Dużo uwagi zostanie poświęcone na
zrealizowanie intuicyjnego i wygodnego interfejsu użytkownika oraz zintegrowanie aplikacji z
asystentem głosowym Google.
1.3. Użytkownik docelowy
Aplikacja jest przeznaczona dla każdego, kto poszukuje szybkiego i wygodnego
sposobu zarządzania swoimi zadaniami, najbliższymi wydarzeniami w kalendarzu oraz
prywatnymi notatkami. Przy tym użytkownik docelowy nie musi martwić się o monotonne
pisanie na klawiaturze, a większość czynności przeprowadzi poprzez komendy głosowe.
Jako grupę docelową autor obrał sobie osoby posiadające bardzo napięty grafik np.
celebryci, prawnicy, lekarze, agenci. Dzięki szybkiemu i wygodnemu dostępowi do
wszystkiego co najważniejsze w organizacji swojego planu dnia, aplikacja będzie bardzo
przydatna i może cieszyć się dużym zainteresowaniem. Dodatkowo banalny interfejs zgodny z
zasadami Material Design sprawi, że nikt nie będzie miał najmniejszych problemów przy
korzystaniu z tej nowej pozycji w Sklepie Play. Użytkownik nie musi posiadać praktycznie
żadnej wiedzy technicznej czy informatycznej aby w stu procentach wykorzystywać
możliwości proponowanej aplikacji.
Jedynym wymaganiem, jakie musi spełniać zainteresowany jest posiadanie telefonu lub
tabletu z Androidem 4.4 lub wyżej. Aplikacja w początkowej fazie będzie dostępna tylko w
języku angielskim (ze względu na asystenta głosowego, który nie jest jeszcze całkowicie
kompatybilny z językiem polskim).
2. Porównanie technologii i istniejących rozwiązań
Aplikacji służących do zarządzania listą zadań na rynku jest bardzo dużo. Podobnie ma
się sytuacja z kalendarzami i aplikacjami, w których możemy używać komend głosowych. W
tłumie propozycji nie udało mi się jednak znaleźć prostej aplikacji łączącej wszystkie trzy
funkcje w sposób zaspokajający moje oczekiwania względem tego typu programów.
2.1. Istniejące rozwiązania
W tym podrozdziale zostaną przedstawione najciekawsze przykłady z oficjalnego
Sklepu Play (Play Store) [1] czyli aplikacje, które w przyszłości mogą być realną konkurencją
dla tego projektu. Skupiłem się na kluczowych funkcjach tych rozwiązań oraz porównaniu ich
z cechami powstającej aplikacji.
a) SplenDo
Aplikacją, o której nie można nie wspomnieć przy przedstawianiu typowych propozycji
dla listy zadań jest właśnie aplikacja SplenDo. Banalnie prosty interfejs użytkownika
praktycznie wyklucza możliwość niepoprawnego korzystania z tego rozwiązania. Mamy tutaj
również możliwość wprowadzenia tytułu zadania w sposób głosowy. Niestety aplikacja nie
posiada automatycznej synchronizacji zadań z kalendarzem ani dodawania notatek, a użycie
określenia „zintegrowanie funkcji komand głosowych” w kontekście SplenDo byłoby nad
wyraz przesadzone.
Rys.2.1. Lista zadań aplikacji SplenDo Rys.2.2. Dodawanie nowego zadania w SplenDo
Rys.2.3. Menu aplikacji SplenDo Rys.2.4. Szybkie dodanie nowego zadania za
pomogą głosu w SplenDo
b) Any.do
Jedną z najbardziej popularnych a jednocześnie (subiektywnie) najładniejszych
aplikacji (jeżeli chodzi o interfejs użytkownika) służącą do zarządzaniem listą zadań jest
Any.do. W tym przypadku synchronizacja z kalendarzem jest dobrze przemyślana, ale dalej
komendy głosowe ograniczają się tylko do ustawienia tytułu nowego zadania. Autorzy tego
rozwiązania bardziej skupili się na przyjemnych animacjach i dźwiękach. Niestety ta
funkcjonalność bardzo szybko się nudzi i okazuje się, że poza wręcz dziecinną łatwością
obsługi aplikacja nie ma nic więcej do zaoferowania.
Rys.2.5. Lista zadań aplikacji Any.do
Rys.2.6 Szybkie dodanie nowego zadania za
pomogą głosu w Any.do
Rys.2.6. Szybkie dodanie nowego zadania za
pomocą głosu w Any.do
Rys.2.7. Menu aplikacji Any.do Rys.2.8. Planowanie dnia z aplikacj Any.do
c) Voice Search
Głównym konkurentem tej pracy jest aplikacja samego Google. Gigant technologiczny
może pochwalić się całym ekosystemem możliwości. Możemy za pomogą głosu dodać nowe
wydarzenie do kalendarza, zapisać notatkę, wysłać wiadomość, zadzwonić a nawet sprawdzić
trasę do wyznaczonego miejsca. Sam Voice Search nie ma możliwości pokazania nam
konfliktów wydarzeń czy całego kalendarza, ani nie wyrecytuje nam naszej listy zadań.
Ogromne możliwości jakie daje nam Google potrafią też nas przytłoczyć, a obsługiwane
komendy musimy przed użytkowaniem dokładnie poznać.
Rys.2.9. Ustawianie nowego wydarzenia w
kalendarzu za pomogą Voice Search
Rys.2.10. Potwierdzanie dodania nowego
wydarzenia za pomogą Voice Search
Rys.2.11. Dodanie notatki za pomogą Voice
Search
Rys.2.12. Potwierdzenie dodanie notatki za
pomogą Voice Search
2.2. Porównanie istniejących rozwiązań z projektem aplikacji
Po przeanalizowaniu podobnych pozycji na rynku autor zdecydował się na
zaproponowanie swojego własnego rozwiązania t.j. zaprojektowanie i zaimplementowanie
aplikacji umożliwiającej:
dodanie w sposób interaktywny (za pomocą głosu) nowego wydarzenia do
kalendarza,
usunięcie tego wydarzenia,
wyświetlenie ewentualnych konfliktów pozycji w kalendarzu,
tworzenie listy zadań,
głosowe odczytywanie i zatwierdzanie utworzonych zadań,
tworzenie, odczytywanie i usuwanie prywatnych notatek,
przy czym duży nacisk zostanie postawiony na wygodny i intuicyjny interfejs użytkownika oraz
user flow. Zauważa się brak aplikacji, która realizowałaby wszystkie wyżej wymienione
zadania przy zachowaniu wysokiego komfortu użytkowania i wykorzystując komendy
głosowe.
2.3. Przegląd środowisk i technologii
Rozmawiając na temat rynku mobilnego musimy mieć na uwadze tak naprawdę dwa
systemy operacyjne: Android i iOS. Dominującą przewagę tych dwóch pozycji szczególnie
dostrzegamy w ostatnim czasie. Według najnowszych statystyk możemy wyraźnie zauważyć
wzrost udziału i tak bezdyskusyjnego lidera w branży systemów mobilnych. Android działa na
ponad 85% telefonach i tabletach. Windows Mobile możemy już traktować jako ciekawostkę i
nic nie zapowiada żeby w najbliższym czasie coś się w tej sprawie zmieniło. Analizując wykres
w dłuższej perspektywie możemy zauważyć niesamowicie dynamiczny wzrost popularności
Androida. W 3 lata (2009 – 2012) ten system z niszowego wynalazku stał się
niekwestionowanym liderem mobilnego rynku. Teraz ciężko jest wyobrazić sobie jakąkolwiek
sytuację, w której potęga Google mogłaby zostać ograniczona.
Zaprojektowanie aplikacji na platformę Android jest więc bardzo świadomym
wyborem. Autor kierował się w tym przypadku popularnością systemu, co umożliwi mu
znalezienie największego grona odbiorców. Każdy użytkownik platformy od Google ma
ogromny wybór pozycji w Sklepie Play dlatego nowa aplikacja będzie musiała wyróżniać się
prostotą i wygodą użytkowania.
Rys. 2.13. Udziały danych systemów operacyjnych na rynku urządzeń mobilnych [2]
Rys.2.14. Porównanie liczby aplikacji w Google Play i Apple App Store (2016) [3]
Ważną kwestią dla programisty zainteresowanego publikowaniem nowych aplikacji na
Androida jest możliwość wyboru samego języka jak i środowiska programistycznego. Jeżeli
ktoś nie jest przekonany do Javy może znaleźć dla siebie alternatywę.
Jako pierwszy przykład przedstawię Corona SDK [4]. Te darmowe rozwiązanie oparte
o swój własny język LUA obiecuje dziesięciokrotnie szybszą implementację aplikacji przy
zachowaniu możliwości korzystania z natywnych bibliotek. Do przedstawienia obiecanej
prostoty rozwiązania posłużę się przykładem:
local background = display.newImage( "myimage.jpg", display.contentCenterX,
display.contentCenterY )
local myText = display.newText( "Hello, World!", display.contentCenterX, d
isplay.contentWidth / 4, native.systemFont, 40 )
myText:setFillColor( 1, 110/255, 110/255 )
Powyższy kod wykonuje trzy akcje, które w Javie kosztowałyby nas kilkukrotnie dłuższą
implementacje. Pierwsza linia ustawia obraz w tle, druga wyświetla tekst na ekranie a trzecia
ustawia kolor tekstu.
Pomimo niewątpliwych zalet, obiecanej prostocie i wydajności autor nie posłuży się
tym rozwiązaniem w powstającym projekcie. Corona Labs skupiło się głównie na
implementacji gier oraz aplikacji wymagających aktywnego przetwarzania multimediów.
Istnieje obawa o stosunkowo mało rozwinięte community i brak pełnej kompatybilności z
rozwiązaniami Google.
Konkurencja giganta mobilnych technologii chce odkroić sobie jak największy
kawałek z tortu z wielkim napisem „Android” na środku. Microsoft postanowił wypuścić swoje
własne środowisko programistyczne. Używając Xamarin [6] (Visual Studio) oraz języka C#
(który jest reklamowany jako „najlepszy język do programowania aplikacji mobilnych”) firma
Bill’ego Gates’a obiecuje nam wygodne i szybkie realizowanie projektów natywnych aplikacji
na aż trzy systemy operacyjne równolegle. Pomysł jest świeży i dopiero pojawia się na rynku,
ale wygląda obiecująco. Propozycja Microsoftu jest darmowa dla małych projektów.
Żeby zacząć swoją przygodę z Xamarin należy zainstalować Visual Studio (albo kupić
MacBook’a). Środowisko Microsoftu jest bardzo ciężkim programem obciążającym komputer
na którym się znajduje oraz nie zapewnia (zdaniem autora) wystarczającej wygody
Rys.2.15. Logo Corona Labs [4]
Rys.2.16. Logo Xamarin [6]
użytkowania dlatego projekt pracy inżynierskiej nie zostanie zrealizowany za pomocą tego
narzędzia.
Ostatnim przykładem jest Android Studio [7]. Jest to niekwestionowany leader
popularności, jeżeli chodzi o programowanie aplikacji na system Android. Z wydania na
wydanie staje się coraz wygodniejszym środowiskiem oferującym najwięcej możliwości
spośród wszystkich aplikacji. Ta propozycja jest autorstwa samego Google, co zapewnia nam
najlepsze wsparcie oraz najmniejszą awaryjność. Oczywiście językiem programowania w tym
przypadku jest Java.
Przy realizacji tej pracy inżynierskiej postawiono na sprawdzone rozwiązanie. Dzięki
ogromnemu community samej Javy jak i Android Studio praktycznie zawsze w określonym
czasie można znaleźć rozwiązanie swojego problemu podczas implementacji.
3. Założenia projektowe
Aplikacja będzie w sposób interaktywny zarządzała listą zadań / wydarzeń
zdefiniowanych przez użytkownika, w szczególności: rozpoznawała komendy wypowiedziane
przez użytkownika, umożliwiała dodawanie wydarzeń do kalendarza, modyfikowanie
prywatnych wpisów/ notatek użytkownika i powiadamiała o konfliktach terminów dodawanych
do kalendarza z wpisami już istniejącymi.
3.1. Wymagania funkcjonalne
Do opisu wymagań autor zdecydował się definiować funkcjonalność za pomocą wzoru:
„Jako [rola] chciałbym [funkcjonalność].”
a) Jako użytkownik chciałbym mieć możliwość dodania nowego wydarzenia do
kalendarza mojego urządzenia za pomocą głosu.
b) Jako użytkownik chciałbym mieć podgląd najbliższych wydarzeń z mojego
kalendarza.
c) Jako użytkownik chciałbym w wybranej przez siebie chwili usłyszeć informację o
zbliżającym się wydarzeniu.
d) Jako użytkownik chciałbym mieć możliwość usunięcia najbliższych wydarzeń z
mojego kalendarza.
e) Jako użytkownik chciałbym mieć podgląd konfliktów wydarzeń z mojego
kalendarza.
f) Jako użytkownik chciałbym mieć możliwość dodania nowych zadań do listy za
pomocą głosu.
g) Jako użytkownik chciałbym mieć możliwość wyświetlenia listy zadań.
h) Jako użytkownik chciałbym mieć możliwość wysłuchania listy zadań do
zrobienia.
Rys.2.17. Logo Android Studio [7]
i) Jako użytkownik chciałbym zatwierdzać zrealizowane zadania.
j) Jako użytkownik chciałbym za pomocą głosu zatwierdzać zrealizowane zadania.
k) Jako użytkownik chciałbym mieć możliwość dodania prywatnej notatki.
l) Jako użytkownik chciałbym mieć możliwość wyświetlenia listy prywatnych
notatek.
m) Jako użytkownik chciałbym mieć możliwość wyświetlenia wybranej prywatnej
notatki.
n) Jako użytkownik chciałbym mieć możliwość wysłuchania wybranej prywatnej
notatki.
o) Jako użytkownik chciałbym mieć możliwość usunięcia prywatnej notatki.
3.2. Wymagania niefunkcjonalne
a) Aplikacja jest przeznaczona dla pojedynczego użytkownika lub pojedynczej grupy
użytkowników (np. zespół muzyczny ze wspólnymi wydarzeniami i zadaniami).
b) Program nie będzie zsynchronizowany z bazą danych.
c) Do synchronizacji danych między różnymi urządzeniami będzie wykorzystywane
konto Google danego użytkownika.
d) Aplikacja będzie kompatybilna z każdym urządzeniem działającym pod kontrolą
Androida w wersji 4.4 (KitKat) czyli z API 19 lub wyższym.
Wyjaśnienie do wymagania d): Zapewni to kompatybilność nowej pozycji w
Sklepie Play z ponad 80% działających urządzeń [8]. Dyskryminacja starszych
telefonów i tabletów ma na celu uniknięcie braku wsparcia asystenta głosowego
Google jak i problemów z wydajnością. Dzięki temu użytkownicy będą świadomie
korzystać z aplikacji i oceniać ją na podstawie jej funkcjonalności, a nie traktować
problemy z jej użytkowaniem na swoim pięcioletnim urządzeniu jako winę
programisty.
Tabela 3.1. Udział wersji Androida na urządzeniach z systemem Google (2016) [8]
3.3. Architektura systemu
Każda wygodna aplikacja zarządzająca listą zadań, prywatnymi notatkami czy
wydarzeniami z kalendarza musi realizować tak podstawową funkcjonalność jak
synchronizacja danych pomiędzy różnymi urządzeniami. Autor zdecydował się w tym
przypadku na skorzystanie z Drive API [9] od Google i umieszczenie danych z aplikacji w
chmurze połączonej z kontem osoby korzystającej z programu. Sam użytkownik systemu
operacyjnego od Google będzie musiał świadomie przyzwolić na synchronizację informacji
pomiędzy telefonami i tabletami, na których jest zalogowany na to samo konto.
Tworzenie bazy danych w tym przypadku byłoby bardzo wymuszone ponieważ nie są
tutaj zbierane żadne dane o samym użytkowniku ani jego zadaniach w kontekście globalnym.
Sam tworzący swoje wydarzenia i korzystający z projektowanej aplikacji decyduje kto i kiedy
będzie miał dostęp do jego notatek i planów.
3.4. Sposób realizacji
Środowisko programistyczne: Android Studio 2.2
Język programowania: Java
Język znaczników: XML
Testowanie aplikacji:
o emulator systemu Android 6.0 na urządzeniu LG Nexus 5X,
o właśnie urządzenie działające pod kontrolą Androida 5.0 z nakładką MIUI 8
(LeTV X600)
Wykorzystywane biblioteki i dodatki:
o Google Drive API [9]
o Speech API [10]
o Google Calendar API [11]
o RecyclerView [12]
System kontroli wersji: GIT
Program do projektowania aplikacji: Visual Paradigm 13.2
4. Projekt aplikacji
Etap projektowania aplikacji jest tak naprawdę najważniejszym elementem cyklu
wytwarzania oprogramowania. Wykrycie i poprawienie błędów przed implementacją
zaoszczędza dużo czasu w późniejszych etapach. W tym rozdziale zostanie przedstawiony
projekt aplikacji uwzględniający przypadki użycia, interfejs i wzorce projektowe, które zostaną
wykorzystane przy realizacji.
4.1. Diagram przypadków użycia
Diagram przypadków użycia został zaprojektowany przy użyciu narzędzia Visual
Paradigm 13.2 na podstawie tutorialu [13]. Dla wygody przedstawienia diagram został
podzielony na trzy moduły: zarządzanie wydarzeniami, zarządzanie zadaniami i zarządzanie
prywatnymi notatkami. Każdy moduł został przedstawiony na osobnej ilustracji.
Rys.4.1. Diagram przypadków użycia dla modułu zarządzania wydarzeniami
Rys.4.2. Diagram przypadków użycia dla modułu zarządzania zadaniami
4.2. Opis przypadków użycia
W tym rozdziale zostaną opisane dokładnie przypadki użycia, uwzględniając
warunki początkowe, opis, ścieżkę główną, ścieżkę alternatywną i warunki końcowe. Dla
czytelności każdy przypadek został umieszczony w tabeli i – jak w przypadku poprzedniego
podrozdziału – przydzielony do konkretnego modułu.
a) Moduł zarządzania wydarzeniami
Nazwa dodawanie nowego wydarzenia do kalendarza za pomocą
głosu
ID UC01
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do nagrywania
dźwięku oraz czytania wydarzeń z kalendarza
Aktor Użytkownik
Opis Użytkownik chce dodać nowe wydarzenie do swojego
kalendarza za pomocą głosu.
User flow Ścieżka główna 1. System pyta użytkownika o tytuł wydarzenia.
2. Użytkownik podaje tytuł wydarzenia.
3. System pyta użytkownika o miejsce wydarzenia.
4. Użytkownik podaje miejsce wydarzenia.
5. System pyta użytkownika o czas rozpoczęcia się
wydarzenia.
Tabela 4.1. UC01 - dodawanie nowego wydarzenia do kalendarza za pomocą głosu
Rys.4.3. Diagram przypadków użycia dla modułu zarządzania prywatnymi notatkami
6. Użytkownik podaje dzień i godzinę rozpoczęcia się
wydarzenia.
7. System pyta użytkownika o czas zakończenia się
wydarzenia.
8. Użytkownik podaje dzień i godzinę zakończenia
wydarzenia.
9. System wyświetla podsumowanie wydarzenia.
10. Użytkownik potwierdza dodanie nowego
wydarzenia (przycisk „Add”)
11. System dodaje nowe wydarzenie do kalendarza
użytkownika.
Ścieżka
alternatywna
System nie zrozumiał tego, co mówił użytkownik w
punkcie 1, 3.
Jeżeli użytkownik w punkcie 10 nie potwierdzi dodania
nowego zadania to wydarzenie nie zostanie dodane.
Aplikacja pozostanie na widoku podsumowania
wydarzenia, użytkownik będzie mógł sam zmienić
konkretne parametry wydarzenia i przycisnąć przycisk
„Add”.
Warunki końcowe Nowa wydarzenie zostało dodane do kalendarza
użytkownika.
Nazwa wysłuchanie informacji o najbliższym wydarzeniu
ID UC02
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do czytania
wydarzeń z kalendarza
Aktor Użytkownik
Opis Użytkownik chce wysłuchać informacji związanych z
najbliższym wydarzeniem.
User flow Ścieżka główna 1. System uruchamia activity z listą wydarzeń i
recytuje informacje związane z najbliższym
wydarzeniem.
Ścieżka
alternatywna
-
Warunki końcowe Użytkownik widzi listę wydarzeń oraz został głosowo
poinformowany o zbliżającym się wydarzeniu.
Nazwa podgląd najbliższych wydarzeń z kalendarza
ID UC03
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do czytania
wydarzeń z kalendarza
Aktor Użytkownik
Tabela 4.2. UC02 - wysłuchanie informacji o najbliższym wydarzeniu
Tabela 4.3. UC03 - podgląd najbliższych wydarzeń z kalendarza
Opis Użytkownik chce zobaczyć listę najbliższych wydarzeń z
kalendarza.
User flow Ścieżka główna 1. System wyświetla listę najbliższych wydarzeń z
kalendarza użytkownika.
Ścieżka
alternatywna
Użytkownik może też skorzystać z przypadku użycia
UC02 w celu zobaczenia tej listy.
Warunki końcowe Użytkownik widzi listę wydarzeń najbliższych wydarzeń.
Nazwa podgląd konfliktów w kalendarzu
ID UC04
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do czytania
wydarzeń z kalendarza
Aktor Użytkownik
Opis Użytkownik chce zobaczyć listę najbliższych konfliktów
wydarzeń w kalendarzu.
User flow Ścieżka główna 1. System wyświetla listę najbliższych konfliktów
wydarzeń w kalendarzu użytkownika.
Ścieżka
alternatywna
-
Warunki końcowe Użytkownik widzi listę najbliższych konfliktów wydarzeń
w kalendarzu.
Nazwa usunięcie istniejącego wydarzenia z kalendarza
ID UC05
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do czytania
wydarzeń z kalendarza
Aktor Użytkownik
Opis Użytkownik chce usunąć wybrane wydarzenie ze swojego
kalendarza.
User flow Ścieżka główna 1. Użytkownik wybiera ikonkę kosza przy wybranym
wydarzeniu na liście wydarzeń.
2. System pyta, czy na pewno użytkownik chce usunąć
wydarzenie z kalendarza.
3. Użytkownik potwierdza („Yes”).
4. System usuwa wybrane urządzenie z kalendarza.
Ścieżka
alternatywna
W punkcie 3 użytkownik wybiera „No”. Wydarzenie nie
zostaje usunięte z kalendarza.
Warunki końcowe Wybrane wydarzenie zostało usunięte z kalendarza
użytkownika.
Tabela 4.4. UC04 - podgląd konfliktów w kalendarzu
Tabela 4.5. UC05 - usunięcie istniejącego wydarzenia z kalendarza
b) Moduł zarządzania zadaniami
Nazwa dodawanie nowych zadań za pomocą głosu
ID UC06
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do nagrywania
dźwięku
Aktor Użytkownik
Opis Użytkownik chce dodać nowe zadania.
User flow Ścieżka główna 1. Użytkownik wybiera przycisk dodania nowych
zadań.
2. System pyta o nowe zadania.
3. Użytkownik podaje nowe zadania.
4. System po każdej zrozumiałej wypowiedzi dodaje
nowe zadanie do listy i pyta o kolejne.
5. Użytkownik podaje „That’s all.” lub „I’m done”
6. System przestaje nasłuchiwać nowych zadań.
Ścieżka
alternatywna
W punkcie 3 lub 5 jeżeli system nie zrozumie co
powiedział użytkownik. Nasłuchiwanie nowych zadań
zostanie przerwane.
Warunki końcowe Nowe zadania zostały dodane do listy zadań użytkownika.
Nazwa wyświetlenie listy zadań
ID UC07
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce wyświetlić listę zadań.
User flow Ścieżka główna 1. System uruchamia activity z listą zadań.
Ścieżka
alternatywna
Użytkownik może też skorzystać z przypadku użycia
UC02 w celu zobaczenia tej listy.
Warunki końcowe Użytkownik widzi listę zadań.
Nazwa wysłuchanie listy zadań do zrobienia
ID UC08
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce wysłuchać listę zadań, które ma do
zrobienia
User flow Ścieżka główna 1. System uruchamia activity z listą zadań i recytuje je.
Tabela 4.6. UC06 - dodawanie nowych zadań za pomocą głosu
Tabela 4.7. UC07 - wyświetlenie listy zadań
Tabela 4.8. UC08 - wysłuchanie listy zadań do zrobienia
Ścieżka
alternatywna
-
Warunki końcowe Użytkownik widzi listę zadań oraz został głosowo
poinformowany o tych, które musi jeszcze zrobić.
Nazwa głosowe zatwierdzanie wykonania zadania z listy zadań
ID UC09
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do nagrywania
dźwięku
Aktor Użytkownik
Opis Użytkownik chce za pomocą głosu zatwierdzić zadania z
listy zadań.
User flow Ścieżka główna 1. System uruchamia activity z listą zadań i recytuje je.
Po każdym zadaniu czeka na reakcję użytkownika.
2. Użytkownik odpowiada „checked”.
3. System zatwierdza wykonanie aktualnego zadania i
przechodzi do recytowania kolejnego. Wracamy do
punku 2. do momentu wyrecytowania wszystkich
niezrealizowanych zadań.
Ścieżka
alternatywna
Przy punkcie 2 użytkownik może odpowiedzieć
cokolwiek innego niż „checked”. Wtedy zadanie nie
zostanie zatwierdzone przez system. Lista zadań jest dalej
recytowana przez system z takim samym warunkiem
zakończenia jak w normalnym user flow.
Warunki końcowe Odpowiednie zadania zostały oznaczone jako zrobione.
Nazwa zatwierdzanie wykonania zadania z listy zadań
ID UC10
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce zatwierdzić zadania z listy zadań.
User flow Ścieżka główna 1. System uruchamia activity z listą.
2. Użytkownik zaznacza wykonane przez siebie
zadania (check box obok pozycji z zadaniem).
3. System usuwa zadanie z listy zadań.
Ścieżka
alternatywna
-
Warunki końcowe Odpowiednie zadania zostały oznaczone jako zrobione i
zniknęły z listy zadań.
Tabela 4.9. UC09 - głosowe zatwierdzanie wykonania zadania z listy zadań
Tabela 4.10. UC10 - zatwierdzanie wykonania zadania z listy zadań
c) Moduł zarządzania prywatnymi notatkami
Nazwa dodawanie nowych prywatnych notatek za pomocą głosu
ID UC11
Warunki początkowe aplikacja musi mieć nadanie uprawnienia do nagrywania
dźwięku
Aktor Użytkownik
Opis Użytkownik chce dodać nową prywatną notatkę.
User flow Ścieżka główna 1. Użytkownik wybiera przycisk dodania nowej
prywatnej notatki.
2. System pyta o tytuł.
3. Użytkownik podaje tytuł.
4. System pyta o treść.
5. Użytkownik podaje treść notatki.
6. System wyświetla tytuł i treść notatki oraz pyta
użytkownika, czy na pewno dodać nową notatkę.
7. Użytkownik potwierdza dodanie nowej notatki
(przycisk „Add”).
8. System dodaje nową notatkę do listy notatek.
Ścieżka
alternatywna
W punkcie 3 lub 5 jeżeli system nie zrozumie co
powiedział użytkownik.
Jeżeli użytkownik w punkcie 7 nie potwierdzi dodania
nowego zadania to notatka nie zostanie dodana. Aplikacja
pozostanie na widoku podsumowania notatki, użytkownik
będzie mógł sam zmienić konkretne parametry notatki i
przycisnąć przycisk „Add”.
Warunki końcowe Nowa prywatna notatka została dodana do listy prywatnych
notatek użytkownika.
Nazwa wyświetlenie listy prywatnych notatek
ID UC12
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce zobaczyć listę prywatnych notatek.
User flow Ścieżka główna 1. System wyświetla listę prywatnych notatek (ich
tytułów).
Ścieżka
alternatywna
-
Warunki końcowe Lista prywatnych notatek została wyświetlona.
Tabela 4.11. UC11 - dodawanie nowych prywatnych notatek za pomocą głosu
Tabela 4.12. UC12 - wyświetlenie listy prywatnych notatek
Nazwa wyświetlenie wybranej prywatnej notatki
ID UC13
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce zobaczyć treść wybranej prywatnej
notatki.
User flow Ścieżka główna 1. System wyświetla treść wybranej prywatnej notatki.
Ścieżka
alternatywna
-
Warunki końcowe Treść wybranej prywatnej notatki została wyświetlona.
Nazwa wysłuchanie wybranej prywatnej notatki
ID UC14
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce wysłuchać treść wybranej prywatnej
notatki.
User flow Ścieżka główna 1. System recytuje treść wybranej prywatnej notatki.
Ścieżka
alternatywna
-
Warunki końcowe Treść wybranej prywatnej notatki została wyrecytowana.
Nazwa usunięcie wybranej prywatnej notatki
ID UC15
Warunki początkowe -
Aktor Użytkownik
Opis Użytkownik chce usunąć wybraną prywatną notatkę.
User flow Ścieżka główna 1. Użytkownik wybiera ikonkę kosza przy wybranej
notatce na liście z tytułami prywatnych notatek lub
w activity wybranej prywatnej notatki.
2. System pyta, czy na pewno użytkownik chce usunąć
tą prywatną notatkę.
3. Użytkownik potwierdza („Yes”).
4. System usuwa wybraną prywatną notatkę.
Ścieżka
alternatywna
W punkcie 3 użytkownik odpowiada „No”. Notatka nie
zostaje usunięta.
Warunki końcowe Wybrana prywatna notatka została usunięta.
Tabela 4.13. UC13 - wyświetlenie wybranej prywatnej notatki
Tabela 4.14. UC14 - wysłuchanie wybranej prywatnej notatki
Tabela 4.15. UC15 - usunięcie wybranej prywatnej notatki
4.3. Projekt interfejsu użytkownika
Sklep Play jest zapełniony milionami pozycji. Wiele z nich oferuje praktycznie takie
same funkcjonalności a różnią się jedynie interfejsem graficznym. To właśnie ta część aplikacji
w dzisiejszych czasach jest najczęściej decydującym elementem dla potencjalnego
użytkownika. Projektowany program musi więc wyróżniać się wygodą użytkowania i
sprawnym user flow.
Przy projektowaniu interfejsu graficznego aplikacji autor zastosował wytyczne Google
dotyczące Material Design. Szczególną uwagę przywiązał do wskazówek znajdujących się w
źródle [14]. Dla wygody użytkowania zostaną zastosowane karty umożliwiające przełączanie
się pomiędzy różnymi Fragmentami oraz boczne menu z opcjami przełączania się pomiędzy
zarządzaniem wydarzeniami, zadaniami a prywatnymi notatkami.
Bardzo ważne jest też rozmieszczenie przycisków oraz przełączników w odpowiednich
miejscach. Często wykorzystywany będzie guzik z dolnego prawego rogu (Floating Button) –
bezpośrednio kojarzony element z najnowszymi wytycznymi Google.
Poniżej został przedstawiony prototyp interfejsu zrealizowany za pomocą Fluid UI [15].
Rys.4.3.1. Widok opcji w menu bocznym
Rys.4.3.2. Widok listy wydarzeń z kalendarza
Rys.4.3.3. Widok konfliktów wydarzeń z kalendarza
Rys.4.3.4. Widok dodawania nowego wydarzenia
Rys.4.3.5. Widok dodawania nowych zadań
Rys.4.3.6. Widok listy zadań
Rys.4.3.7. Widok dodawania nowej prywatnej notatki
Rys.4.3.8. Widok listy prywatnych notatek
Rys.4.3.9. Widok pojedynczej prywatnej notatki.
4.4. Wzorce projektowe i architektoniczne
Wykorzystywanie wzorców projektowych i architektonicznych w swoich rozwiązaniach jest
dobrą praktyką programistyczną. Stawiając na sprawdzone rozwiązania ułatwiamy sobie
implementację. Wiemy, jaki efekt przyniesie użycie konkretnego rozwiązania i jak najlepiej możemy
wykorzystać zaistniałą sytuację.
a) MVC
Wzorzec Model-View-Controller [16] jest sposobem kontroli i synchronizacji
logiki aplikacji z widokiem i interfejsem graficznym. W praktyce opisuje on współprace
klas opisanych w Javie ze schematami i layout’ami XML. Oczywiście to rozwiązanie
w projekcie będzie wykorzystywane na każdym kroku. Jest to niezbędny element
praktycznie każdej nowocześniej aplikacji z interfejsem graficznym.
b) Fasada
Wzorzec strukturalny, jakim jest Fasada [17], ma na celu ułatwienie
rozmieszczenia logiki aplikacji oraz synchronizację zadań wykonywanych w obrębie
modułów z klasami odpowiadającymi za obsługę konkretnych activity. Autor
przewiduje wielokrotne użycie wymienionego wzorca w swoim rozwiązaniu. Ułatwi to
zarządzanie większą ilością kodu oraz bardziej skomplikowanymi elementami
oprogramowania.
c) Singleton
Wzorzec kreacyjny, zwany Singletonem [18], jest to wzorzec w którym
określanym pewną klasę, tworzymy dokładnie jedną instancję tej klasy i zapewniamy
do niej publiczny, globalny dostęp. Singleton zostanie wykorzystany w celu
przekazywania informacji pomiędzy różnymi activity w aplikacji.
5. Implementacja
W tym rozdziale zostanie opisany proces implementacji z naciskiem na konkretne
elementy. Duża część wykorzystanych praktyk jest opisana w źródle [19]. Autor opisze również
interfejs użytkownika oraz przesłanki, jakimi kierował się podczas realizacji zaproponowanego
rozwiązania. W kolejnym kroku zostaną przedstawione problemy implementacyjne oraz
sposoby, jakie zostały użyte przy ich rozwiązywaniu.
5.1. Wykorzystane środowiska i narzędzia programistyczne
Projekt został zrealizowany w środowisku Android Studio [7] w wersji 2.2. Względem
poprzedniego wydania nowa odsłona użytego oprogramowania oferuje wprowadzanie zmian w
aplikacji podczas testowania w sposób bardziej dynamiczny oraz bogatsze możliwości
projektowania interfejsu użytkownika. Implementacja została wykonana za pomocą języka
Java, a szablony i layout’y zostały zapisane w plikach XML przy wsparciu dynamicznego
kreatora widoków, zintegrowanym z Android Studio.
W porównaniu z projektem aplikacji zostały wykorzystane dodatkowe następujące
rozszerzenia:
CardView [12],
CircleImageView [20].
5.2. Elementy składowe projektu
W kodzie aplikacji zostały wyróżnione wyraźnie kategorie dla klas realizujących różne
zadania. Te elementy zostały umieszczone w następujących pakietach:
activities – Klasy reprezentujące konkretne activity działające w aplikacji.
adapters – Adaptery obsługujące zmiany wyświetlanych fragmentów na ekranie
w zależności od wybranej karty jak i adaptery definiujące zachowanie oraz
sposób wyświetlania treści na RecyclerView.
features – Zaimplementowane usługi przetwarzania danych np. pobierania
informacji o pogodzie z wybranego API, pobranie wydarzeń z kalendarza,
ustalenie lokalizacji urządzenia lub zdefiniowany wzorzec singleton.
fragments – Klasy reprezentujące konkretne fragmenty oraz ich role w aplikacji.
objects – Obiekty zdefiniowane na potrzeby aplikacji: Conflict, Event, Note,
Task.
5.3. Interfejs użytkownika
Zaproponowany przez autora interfejs użytkownika oferuje wygodne poruszanie się po
aplikacji. Dzięki zastosowaniu konwencji wymaganych w Material Design użytkownik
końcowy nie będzie potrzebował żadnej instrukcji ani wyjaśnienia jak korzystać z programu.
Na poniższych rysunkach przedstawiono gotowy i działający graficzny interfejs użytkownika.
Rys.5.3.1. Widok pakietów istniejących w obrębie aplikacji
Rys.5.4.1. Boczne menu aplikacji Rys.5.4.2. Lista wydarzeń z kalendarza
Rys.5.4.3. Potwierdzenie usunięcia wydarzeń z
kalendarza
Rys.5.4.4. Lista konfliktów wydarzeń z
kalendarza
Rys.5.4.5. Dodawanie nowego wydarzenia do
kalendarza Rys.5.4.6. Dodawanie tytułu wydarzenia za
pomocą głosu
Rys.5.4.7. Ustawianie daty rozpoczęcia
wydarzenia
Rys.5.4.8. Ustawianie godziny rozpoczęcia
wydarzenia
Rys.5.4.9. Lista zadań do zrobienia
Rys.5.4.10. Lista prywatnych notatek
Rys.5.4.11. Szczegóły prywatnej notatki Rys.5.4.12. Potwierdzenie usunięcia prywatnej
notatki
Rys.5.4.13. Dodawanie nowej prywatnej notatki
Rys.5.4.14. Ustawianie tytułu prywatnej notatki
za pomocą glosu
5.4. Problemy implementacyjne i ich rozwiązania
Główną cechą, wyróżniającą powstałą aplikację od istniejących rozwiązań jest
obsługa podstawowych funkcji za pomocą głosu. W związku z tym wyzwania
implementacyjne, jakie pojawiły się, dotyczyły najczęściej współpracy programu z
asystentem głosowym.
Nazwa Nasłuchiwanie głosu użytkownika
ID P1
Opis Podstawowym założeniem pracy było zintegrowanie funkcjonalności z
asystentem głosowym Google. Z tego powodu bardzo ważną kwestią
już na samym początku implementacji było umożliwienie
użytkownikowi na głosową komunikację z aplikacją.
Rozwiązanie Najprostszą metodą nasłuchiwania poleceń przez aplikacje jest
wystartowanie asystenta głosowego i przetworzenie wyniku, jaki
otrzymamy. Została zaimplementowana metoda:
private void promptSpeechInput(int req) {
Intent intent = new
Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH);
intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL,
RecognizerIntent.LANGUAGE_MODEL_FREE_FORM);
intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE, "en-
US");
try {
startActivityForResult(intent, req);
} catch (ActivityNotFoundException a) {
a.printStackTrace();
}
}
Po wywołaniu tego skrawka kodu otrzymujemy w efekcie słowa, które
użytkownik wypowiedział podczas nasłuchiwania. Możemy je
przetworzyć nadpisując metodę:
@Override
protected void onActivityResult(int requestCode, int
resultCode, Intent data) {
if (requestCode == TITLE_REQ && resultCode ==
RESULT_OK) {
// do soemthing with data
}
if (requestCode == PLACE_REQ && resultCode ==
RESULT_OK) {
// do something else
}
}
Tabela 5.5.1. P1 - nasłuchiwanie głosu użytkownika
Nazwa Wypowiadanie zdań przez aplikacje
ID P2
Opis Kolejnym wyzwaniem stojącym przed autorem było
zaimplementowanie wypowiadania zdań przez samą aplikację. Razem z
problemem P1 są to kluczowe elementy aplikacji.
Rozwiązanie W pierwszej kolejności klasa, która będzie odpowiedzialna za
wypowiadanie tekstu musi implementować interface
TextToSpeech.OnInitListener, oraz nadpisywać metodę:
@Override
public void onInit(int status) {
if (status == TextToSpeech.SUCCESS) {
} else {
Log.e("TTS", "Initialization failed");
}
}
Następnie musimy zdefiniować zmienną:
TextToSpeech tts = new TextToSpeech(this, this);
i użyć ją do wypowiedzenia konkretnych słów:
tts.speak("Test 1", TextToSpeech.QUEUE_FLUSH, null);
Bardzo ważne jest, żeby metoda, odpowiedzialna za wypowiadanie
zdań była metodą Asynchroniczną. Używanie mowy w głównym
wątku aplikacji blokuje jej zawartość i jest złą praktyką.
Należy też kontrolować, kiedy syntezator mowy skończy wypowiadać
jedną frazę przed rozpoczęciem kolejnej:
while(tts.isSpeaking()) {}
Nazwa Dodanie wydarzenia do kalendarza
ID P3
Opis Umożliwiając użytkownikowi dodawanie nowych wydarzeń do
swojego kalendarza trzeba było znaleźć sposób, w jaki można to
zrealizować.
Rozwiązanie Na początku trzeba zdefiniować nowe wydarzenie zgodnie z
przykładem poniżej:
ContentValues l_event = new ContentValues();
l_event.put("calendar_id", 3);
l_event.put("title", title.getText().toString());
l_event.put("eventLocation", place.getText().toString());
l_event.put("dtstart",
getAccDate(startTime.getText().toString()));
l_event.put("dtend",
getAccDate(endTime.getText().toString()));
Tabela 5.5.2. P2 – wypowiadanie zdań przez aplikacje
Tabela 5.5.3. P3 – dodanie wydarzenia do kalendarza
l_event.put("allDay", 0);
l_event.put("eventTimezone", "Poland");
Po określeniu konkretnych wartości wystarczy dodać wydarzenie do
kalendarza użytkownika poleceniem:
addEventActivity.this.getContentResolver()
.insert(l_eventUri, l_event);
, gdzie addEventActivity to nazwa klasy, w której jest wywoływana
metoda dodania nowego wydarzenia, a l_eventUri jest zależne od
wersji androida użytkownika i dla nowszych urządzeń (obsługiwanych
przez zaimplementowaną aplikację) to:
l_eventUri =
Uri.parse("content://com.android.calendar/events");
Nazwa Potwierdzenie wykonania czynności
ID P4
Opis Podczas implementacji niejednokrotnie była potrzeba potwierdzenia
pewnej czynności (np. przy usuwaniu wydarzenia z kalendarza lepiej
zapytać użytkownika czy na pewno chce to zrobić). Warto więc było
znaleźć jakiś natywny sposób zatwierdzania operacji.
Rozwiązanie W pierwszej kolejności należy zdefiniować konkretny Listener dla
interesującej nas akcji:
DialogInterface.OnClickListener dialogClickListener = new
DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int
which) {
switch (which){
case DialogInterface.BUTTON_POSITIVE:
// do action
break;
case DialogInterface.BUTTON_NEGATIVE:
// don’t do anything
break;
}
}
};
Następnie należy zdefiniować AlertDialog.Builder dla naszego
activity:
AlertDialog.Builder builder = new
AlertDialog.Builder(MainActivity.this);
Na koniec wystarczy tylko określić, co będzie się wyświetlać na
powiadomieniu oraz jakie opcje wyboru będzie miał użytkownik, oraz
wyświetlić dialog:
Tabela 5.5.4. P4 – potwierdzenie wykonania czynności
builder.setMessage("Do you want to delete this
note?").setPositiveButton("Yes",
dialogClickListener).setNegativeButton("No",
dialogClickListener).show();
5.5. Możliwości rozwoju projektu
Główną cechą, wyróżniającą tą aplikację od istniejących rozwiązań jest obsługa
głosowa podstawowych funkcji. W związku z tym jako ewentualne możliwości rozwoju
przewiduję daleko idącą integrację nowych usług z rozpoznawaniem komend głosowych.
Przedstawiłem konkretne pomysły na nową funkcjonalność za pomocą listy:
ciągłe nasłuchiwanie podczas użytkowania aplikacji,
obsługa nawigacji po aplikacji za pomocą komend głosowych,
integracja aplikacji z innymi urządzeniami smart (wearables, lodówki, pralki),
skorzystanie z produktów Google Home – Smart Speakers, Home Assistante,
ulepszenie integracji z aplikacjami Google (np. możliwość odczytu i zapisu notatek
z Google Keep),
powiązanie rozwiązań z Android Auto,
przechowywanie danych użytkownika w chmurze,
prognozowanie pogody do każdego wydarzenia uwzględniając czas i miejsce
wydarzenia,
proponowanie rozwiązań konfliktów w czasie rzeczywistym,
łączenie wydarzeń z konkretnymi zadaniami i notatkami,
możliwość udostępniania swoich zadań, wydarzeń, notatek wybranym osobom za
pomocą aplikacji trzecich (Facebook, Messenger, What’s up).
6. Podsumowanie
Cel pracy inżynierskiej został osiągnięty. Autorowi udało się zaprojektować oraz
zaimplementować aplikację zarządzającą zadaniami, wydarzeniami i prywatnymi notatkami za
pomocą głosu. Dodawanie danych, usuwanie ich oraz informowanie głosowe jest głęboko
zintegrowane z asystentem głosowym Google. Dzięki temu aplikacja może okazać się
szczególnie przydatna osobom, które nie chcą (lub nie mogą) korzystać z klawiatury
systemowej. Nasze społeczeństwo staje się coraz bardziej społeczeństwem starzejącym się.
Ludzie starsi stanowią coraz większy odsetek. Są to często osoby z problemami zdrowotnymi
(słaby wzrok, trzęsące się ręce). Aplikacje, które możemy obsługiwać za pomocą głosu są na
pewno dużą szansą dla tych ludzi.
Interfejs użytkownika został zrealizowany zgodnie z wytycznymi Material Design.
Celem autora było zastosowanie takich rozwiązań, żeby nowy użytkownik „czuł się” znajomo
w nowym środowisku. Zastosowanie bocznego menu, wysuwanego z prawej strony,
przesuwalnych fragmentów jako kart oraz floating action button to często stosowane techniki
w systemowych aplikacjach Google jak i w profesjonalnych propozycjach innych gigantów
technologicznych. Autor dążył do tego, żeby wygląd aplikacji oraz rozmieszczenie elementów
było optymalne i zapewniało wystarczającą wygodę dla użytkownika końcowego.
Główne wyzwania jakie się pojawiły przy implementacji zostały opisane w
podrozdziale 5.5. Dzięki łatwemu dostępowi do asystenta głosowego Google przez aplikacje
pisane na platformę Android, realizacja projektu nie przysporzyła większych problemów.
Gigant technologiczny udostępnia nam też pełną gammę swoich rozwiązań, które pomagają
programistom w łatwy sposób zintegrować wiele usług w jednej aplikacji.
Geneza projektu jest głęboko powiązana z potrzebą wykorzystywania innych sposobów
przetwarzania danych i tekstów niż pisanie na klawiaturze. Komendy głosowe są coraz bardziej
popularne i coraz śmielej wykorzystywane w najnowszych rozwiązaniach i „inteligentnych”
produktach. Aplikacja końcowa jest tylko przedsmakiem możliwości w jaki sposób możemy
używać naszego głosu jako narzędzia do zarządzania i organizowania naszego życia. Pomysły
na rozwój projektu znajdują się w podrozdziale 5.5. Możliwości dalszego rozwoju są tak na
prawdę ograniczone jedynie przez wyobraźnie autora, a przedstawione przykłady są tylko
propozycjami, które w przyszłości mogą okazać się świetnie prosperującymi projektami.
Bibliografia
[1] Google Inc, Google Play,
https://play.google.com/store,
dostęp w dniu 03.11.2016
[2] Felix Richter, The Smartphone Platform War Is Over,
https://www.statista.com/chart/4112/smartphone-platform-market-share/,
data publikacji 22.08.2016, dostęp w dniu 03.11.2016
[3] Number of apps available in leading app stores as of June 2016,
https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-
stores/,
miesiąc publikacji czerwiec 2016, dostęp w dniu 03.11.2016
[4] Corona Labs,
https://coronalabs.com/,
dostęp w dniu 03.11.2016
[5] Gary Sims, I want to develop Android Apps – What languages should I learn?,
http://www.androidauthority.com/want-develop-android-apps-languages-learn-391008/,
data publikacji: 29.07.2016, dostęp w dniu 01.11.2016
[6] Microsoft, Xamarin
https://www.xamarin.com/,
dostęp w dniu 03.11.2016
[7] Google, Android Studio
https://developer.android.com/studio/index.html,
dostęp w dniu 03.11.2016
[8] Google, Dashboards,
https://developer.android.com/about/dashboards/index.html,
dostęp w dniu 03.11.2016
[9] Introduction to the Google Drive Android AP,
https://developers.google.com/drive/android/intro,
dostęp w dniu 03.11.2016
[10] Google, Opis pakietu android.speech,
https://developer.android.com/reference/android/speech/package-summary.html,
dostęp w dniu 03.11.2016
[11] Google Calendar API,
https://developers.google.com/google-apps/calendar/,
dostęp w dniu 03.11.2016
[12] Creating Lists and Cards,
https://developer.android.com/training/material/lists-cards.html,
dostęp w dniu 03.11.2016
[13] Tutorialspoint: UML – Use Case Diagram,
https://www.tutorialspoint.com/uml/uml_use_case_diagram.htm,
dostęp w dniu 08.10.2016
[14] Ian G. Clifton, Android User Interface Design: Implementing Material Design for Developers,
Addison-Wesley Professional,
– rozdział 1. „Android UI and Material Design”
data publikacji 21.11.2015, dostępne na https://books.google.pl/ dnia 18.10.2016
[15] Fluid,
https://www.fluidui.com/
dostęp w dniu 03.11.2016
[16] Łukasz Socha, MVC w praktyce – tworzymy system artykułów. cz. 1
http://lukasz-socha.pl/php/mvc-w-praktyce-%E2%80%93-tworzymy-system-artykulow-cz-1/
data publikacji 20.10.2011, dostęp w dniu 03.11.2016
[17] Łukasz Socha, Wzorce projektowe, cz. 10 Facade
http://lukasz-socha.pl/php/wzorce-projektowe-cz-10-facade/
data publikacji 22.08. 2012, dostęp w dniu 03.11.2016
[18] Kamil Dworak, Wzorce projektowe: Singleton,
http://www.algorytm.org/wzorce-projektowe/singleton-singleton.html,
data publikacji 01.09.2010 dostęp w dniu 03.11.2016
[19] Robert C. Martin, Czysty kod: Podręcznik dobrego programisty,
tłumaczenie: Paweł Gonera,
Helion, 2014
[20] Henning Dodenhof, CircleImageView,
https://github.com/hdodenhof/CircleImageView/tree/master/circleimageview,
dostęp w dniu 04.10.2016
Spis ilustracji
Rys.2.1. Lista zadań aplikacji SplenDo 6
Rys.2.2. Dodawanie nowego zadania w SplenDo 6
Rys.2.3. Menu aplikacji SplenDo 7
Rys.2.4. Szybkie dodanie nowego zadania za pomogą głosu w SplenDo 7
Rys.2.5. Lista zadań aplikacji Any.do 8
Rys.2.6. Szybkie dodanie nowego zadania za pomocą głosu w Any.do 8
Rys.2.7. Menu aplikacji Any.do 9
Rys.2.8. Planowanie dnia z aplikacj Any.do 9
Rys.2.9. Ustawianie nowego wydarzenia w kalendarzu za pomogą Voice Search 10
Rys.2.10. Potwierdzanie dodania nowego wydarzenia za pomogą Voice Search 10
Rys.2.11. Dodanie notatki za pomogą Voice Search 11
Rys.2.12. Potwierdzenie dodanie notatki za pomogą Voice Search 12
Rys. 2.13. Udziały danych systemów operacyjnych na rynku urządzeń mobilnych [2] 13
Rys.2.14. Porównanie liczby aplikacji w Google Play i Apple App Store (2016) [3] 13
Rys.2.15. Logo Corona Labs [4] 14
Rys.2.16. Logo Xamarin [6] 14
Rys.2.17. Logo Android Studio [7] 15
Rys.4.1. Diagram przypadków użycia dla modułu zarządzania wydarzeniami 18
Rys.4.2. Diagram przypadków użycia dla modułu zarządzania zadaniami 18
Rys.4.3. Diagram przypadków użycia dla modułu zarządzania prywatnymi notatkami 19
Rys.4.3.1. Widok opcji w menu bocznym 26
Rys.4.3.2. Widok listy wydarzeń z kalendarza 27
Rys.4.3.3. Widok konfliktów wydarzeń z kalendarza 27
Rys.4.3.4. Widok dodawania nowego wydarzenia 28
Rys.4.3.5. Widok dodawania nowych zadań 28
Rys.4.3.6. Widok listy zadań 29
Rys.4.3.7. Widok dodawania nowej prywatnej notatki 29
Rys.4.3.8. Widok listy prywatnych notatek 30
Rys.4.3.9. Widok pojedynczej prywatnej notatki. 30
Rys.5.3.1. Widok pakietów istniejących w obrębie aplikacji 32
Rys.5.4.1. Boczne menu aplikacji 33
Rys.5.4.2. Lista wydarzeń z kalendarza 33
Rys.5.4.3. Potwierdzenie usunięcia wydarzeń z kalendarza 34
Rys.5.4.4. Lista konfliktów wydarzeń z kalendarza 34
Rys.5.4.5. Dodawanie nowego wydarzenia do kalendarza 35
Rys.5.4.6. Dodawanie tytułu wydarzenia za pomocą głosu 35
Rys.5.4.7. Ustawianie daty rozpoczęcia wydarzenia 36
Rys.5.4.8. Ustawianie godziny rozpoczęcia wydarzenia 36
Rys.5.4.9. Lista zadań do zrobienia 37
Rys.5.4.10. Lista prywatnych notatek 37
Rys.5.4.11. Szczegóły prywatnej notatki 38
Rys.5.4.12. Potwierdzenie usunięcia prywatnej notatki 38
Rys.5.4.13. Dodawanie nowej prywatnej notatki 39
Rys.5.4.14. Ustawianie tytułu prywatnej notatki za pomocą glosu 39
Spis tabel
Tabela 3.1. Udział wersji Androida na urządzeniach z systemem Google (2016) [8] 16
Tabela 4.1. UC01 - dodawanie nowego wydarzenia do kalendarza za pomocą głosu 19
Tabela 4.2. UC02 - wysłuchanie informacji o najbliższym wydarzeniu 20
Tabela 4.3. UC03 - podgląd najbliższych wydarzeń z kalendarza 20
Tabela 4.4. UC04 - podgląd konfliktów w kalendarzu 21
Tabela 4.5. UC05 - usunięcie istniejącego wydarzenia z kalendarza 21
Tabela 4.6. UC06 - dodawanie nowych zadań za pomocą głosu 22
Tabela 4.7. UC07 - wyświetlenie listy zadań 22
Tabela 4.8. UC08 - wysłuchanie listy zadań do zrobienia 22
Tabela 4.9. UC09 - głosowe zatwierdzanie wykonania zadania z listy zadań 23
Tabela 4.10. UC10 - zatwierdzanie wykonania zadania z listy zadań 23
Tabela 4.11. UC11 - dodawanie nowych prywatnych notatek za pomocą głosu 24
Tabela 4.12. UC12 - wyświetlenie listy prywatnych notatek 24
Tabela 4.13. UC13 - wyświetlenie wybranej prywatnej notatki 25
Tabela 4.14. UC14 - wysłuchanie wybranej prywatnej notatki 25
Tabela 4.15. UC15 - usunięcie wybranej prywatnej notatki 25
Tabela 5.5.1. P1 - nasłuchiwanie głosu użytkownika 40
Tabela 5.5.2. P2 – wypowiadanie zdań przez aplikacje 41
Tabela 5.5.3. P3 – dodanie wydarzenia do kalendarza 41
Tabela 5.5.4. P4 – potwierdzenie wykonania czynności 42