Amuse for Android platforma do tworzenia i wymiany interaktywnych zabawek

Transkrypt

1 Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki Piotr Lewandowski Łukasz Marecik Robert Rosołek Grzegorz Swatowski Nr albumu: , , , Amuse for Android platforma do tworzenia i wymiany interaktywnych zabawek Praca licencjacka na kierunku INFORMATYKA Praca wykonana pod kierunkiem dra Jacka Sroki Instytut Informatyki Lipiec 2012

2 Oświadczenie kierującego pracą Potwierdzam, że niniejsza praca została przygotowana pod moim kierunkiem i kwalifikuje się do przedstawienia jej w postępowaniu o nadanie tytułu zawodowego. Data Podpis kierującego pracą Oświadczenie autora (autorów) pracy Świadom odpowiedzialności prawnej oświadczam, że niniejsza praca dyplomowa została napisana przeze mnie samodzielnie i nie zawiera treści uzyskanych w sposób niezgodny z obowiązującymi przepisami. Oświadczam również, że przedstawiona praca nie była wcześniej przedmiotem procedur związanych z uzyskaniem tytułu zawodowego w wyższej uczelni. Oświadczam ponadto, że niniejsza wersja pracy jest identyczna z załączoną wersją elektroniczną. Data Podpis autora (autorów) pracy

3 Streszczenie Przedmiotem naszego projektu jest zaprojektowanie i realizacja platformy do tworzenia i przeglądania interaktywnych zabawek (ang. amusements ). Zabawka może składać się ze zdjęć, dźwięków, animacji oraz udostępniać prostą interakcję z użytkownikiem. Amusementy są tworzone za pomocą intuicyjnego w obsłudze graficznego edytora. Gotowe zabawki można przechowywać na serwerze. To umożliwia przesłanie odnośnika do zabawki znajomym lub umieszczenie jej na jednym z serwisów społecznościowych a tym samym spowoduje wirusowe rozprzestrzenianie się naszego projektu. Słowa kluczowe Android, amusement, zabawka, zabawa, zdrapka, scratchcard, soundpad, meme 11.3 Informatyka Dziedzina pracy (kody wg programu Socrates-Erasmus) D. Software D.0 General Klasyfikacja tematyczna Tytuł pracy w języku angielskim Amuse for Android platform for creating and sharing interactive amusements

4

5 Spis treści Wprowadzenie Wstęp Definicje Wizja systemu Wizja ogólna Zabawki Grupa docelowa Promocja produktu Analiza ryzyka Konkurencja Wymagania Funkcjonalności Opis implementacji Architektura Użyte technologie Serwer Klient Generator zabawek do HTML Problemy technologiczne Dźwięk Nagrywanie Odtwarzanie Android Popularne przeglądarki Dokumentacja użytkowa Menu Zdrapka Sound Pad Meme Menedżer zabawek Przykładowe użycie Wdrożenie Perspektywy rozwoju

6 7. Podsumowanie A. Zawartość dysku CD B. Opis instalacji C. Podział pracy Bibliografia

7 Wprowadzenie 0.1. Wstęp Żyjemy w dobie Internetu i sieci społecznościowych. Przez serwisy takie jak Facebook dzielimy się ze znajomymi muzyką, zdjęciami, filmami czy ulubionymi przepisami. Ponadto w polskim Internecie triumfy świętują serwisy typu Kwejk oraz Demotywatory, udostępniające zabawne obrazki. Celem niniejszego projektu jest pójście o krok dalej w tym kierunku i stworzenie platformy do tworzenia zabawek amusementów, które składałyby się ze zdjęć, muzyki i prostych animacji. Tym, co będzie wyróżniać ten projekt, to wyposażenie amusementów w szeroko rozumianą interakcję z użytkownikiem. Zabawki mają być projektowane za pomocą aplikacji klienckiej przeznaczonej na telefony z systemem Android. Możliwe będzie dzielenie się stworzonymi amusementami ze znajomymi poprzez dowolne portale społecznościowe. Kluczowym problemem jest to, że wykonanie zabawek powinno być proste do wyklikania w wypadku zdjęć wystarczy nacisnąć dwa, trzy przyciski w telefonie, żeby zrobić zdjęcie i wysłać je znajomym a jednocześnie oczekuje się osiągnięcia jak najciekawszego efektu. Poniższy tekst jest dokumentacją pracy włożonej w zrealizowanie tej idei, wykonanej w ramach Zespołowego Projektu Programistycznego w roku 2011/2012. Pomysłodawcą projektu jest mgr Bolesław Szewczyk, inżynier z firmy Google, któremu na samym wstępie należą się wyrazy największego uznania. W tym miejscu chcielibyśmy mu również podziękować za współpracę i opiekę nad projektem. Podczas zajęć Pan Bolesław pełnił rolę naszego klienta, za co my Amoose Team serdecznie dziękujemy. Jest on również twórcą pierwszego prototypu zabawki Definicje Podstawowe definicje używane w tej pracy: serwis społecznościowy - serwis internetowy istniejący w oparciu o zgromadzonych wokół niego użytkowników amusement, zabawka - prosta aplikacja w HTML, składająca się z obrazków, tekstu i prostych animacji oraz udostępniająca interakcję z użytkownikiem, najczęściej z jakimś zabawnym motywem np. zdrapka. Innym przykładem może być zdjęcie ze znajomymi. Po najechaniu na sylwetkę każdego ze znajomych usłyszymy jego ulubioną piosenkę lub znany wszystkim cytat danej osoby. W niniejszym dokumencie będziemy używali zamiennie zarówno polskiego słowa zabawka jak i angielskiego amusement. W dalszej przyszłości, po sukcesie naszego projektu w Stanach Zjednoczonych, zamierzamy zastrzec termin amusement jako nasz znak firmowy. 5

8 edytor amusementów - aplikacja na Androida umożliwiająca szybkie tworzenie amusementów (w czasie co najwyżej około trzech minut). szablon do tworzenia amusementów - predefiniowany szablon do tworzenia amusementów. Przy jego pomocy użytkownik powinien stworzyć zabawkę, dodając jedynie zdjęcia, dźwięki i wpisujący tekst (nie trzeba ustawiać elementów, definiować nowych akcji). klient, aplikacja kliencka - aplikacja przeznaczona na telefony z systemem Android zawierająca edytor amusementów oraz umożliwiająca podzielenie się zabawkami ze znajomymi. serwer - serwer WWW przechowujący stworzone przez użytkowników zabawki. Dzięki niemu użytkownicy mogą się dzielić efektami swojej pracy poprzez udostępnienie odpowiedniego odnośnika. Zdrapka (ang. Scratchcard) - zabawka składająca się z folii, którą można zdrapać i zdjęcia znajdującego się pod nią. SoundPad (ang. SoundPad) - zabawka składa się z przycisków w formie zdjęć, które po naciśnięciu wydają dźwięki Meme (ang. Meme) - zabawka składa się z tła, zdjęcia i zabawnego podpisu 6

9 Rozdział 1 Wizja systemu 1.1. Wizja ogólna Projekt obejmuje stworzenie platformy do projektowania i przeglądania interaktywnych zabawek (amusementów). Zabawka może składać się ze zdjęć, dźwięków, prostych animacji, krótkich materiałów filmowych oraz udostępniać interakcję z użytkownikiem. Amusementy będą tworzone za pomocą intuicyjnego w obsłudze edytora na telefon z systemem Android. Gotowe zabawki będą przechowane na serwerze. Dzięki temu użytkownik będzie mógł dzielić się nimi ze swoimi znajomymi za pomocą serwisów społecznościowych lub wysyłając odnośnik em Zabawki Do tej pory zaprojektowano i zrealizowano trzy zabawki: Sound Pad - panel z przyciskami, które są wybranymi przez użytkownika zdjęciami. Po naciśnięciu każdego zdjęcia odtwarzany jest dźwięk zdefiniowany dla danego przycisku. Z przycisku wylatują nutki. Zabawka składa się najczęściej z kilku do kilkunastu takich przycisków. Meme - obrazek z opisem. Najczęściej na jakiś żartobliwy/ironiczny/złośliwy temat. Można także zmienić tło na jakim znajduje się obrazek. Opis jest dodawany nad obrazkiem lub/i pod nim. Meme jako forma przekazywania myśli jest czymś stosunkowo nowym, aczkolwiek jego popularność zdołała już opanować światowy Internet. W Sieci można znaleźć mnogość predefiniowanych szablonów. Zdrapka (Scratchcard) - wirtualna wersja zdrapki. Opis działania: na początku widoczna jest folia. Po zdrapaniu ukazuje nam się stopniowo zdjęcie, które jest wybierane losowo z grupy obrazków dodanej przez użytkownika. Folia jest zdrapywana za pomocą myszki. Bardziej spektakularny efekt jest osiągany na telefonach z dotykowym ekranem, gdzie folię można zdrapać palcem tak, jak prawdziwą zdrapkę. Folię można wybrać spośród kilku predefiniowanych w edytorze. 7

10 1.3. Grupa docelowa Aplikacja jest skierowana przede wszystkim do osób w wieku lat, aktywnie korzystających z serwisów społecznościowych i telefonów z system Android. Jest to bardzo duża i zróżnicowania grupa odbiorców, jednak większość z nich cechuje chęć do współdzielenia treści ze znajomymi i przekazywania sobie zabawnych wiadomości. Większość potencjalnych odbiorców nie widzi dużego problemu w wydaniu niewielkiej kwoty na aplikacje z Google Play (dawniej Android Market), jeżeli tylko coś ich do tego zachęci. Jednocześnie jest to wymagający użytkownik, jeżeli chodzi o interfejs. Aplikacja zbyt skomplikowana w obsłudze szybko go znudzi. Typowy odbiorca liczy na to, że będzie mógł w krótkim czasie stworzyć coś bajecznego i bez większych trudności móc się podzielić owocem swojej kilkuminutowej pracy ze znajomymi Promocja produktu Edytor zostanie umieszczony w Google Play i w ten sposób, w miarę wzrostu popularności, jego promowanie powinno być dosyć łatwe. Integracja platformy z serwisami społecznościowymi zapewni szybkie wirusowe rozprzestrzenianie się amusementów wśród nowych użytkowników. Sprzyja temu również sama idea platformy: udostępnianie zabawek znajomym automatycznie przyciąga nowych użytkowników. Istnieje możliwość promocji produktu poprzez serwisy typu Demotywatory, na których internauci zamieszczają śmieszne wiadomości i obrazki. Jest to potencjalnie duża i aktywna grupa odbiorców dla naszego projektu Analiza ryzyka Istnieje szereg potencjalnych zagrożeń związanych z rozwojem serwisu oraz dotyczących prezentowanych tam treści: udostępnianie śmieciowych plików baza danych może zostać zalana przez treści nie mające nic wspólnego z udostępnianiem amusementów. Użytkownicy będą wrzucali zdjęcia jedynie w celu przechowywania ich na serwerze. przewaga wulgarnych treści w pierwszej wersji platformy oraz początkowej fazie rozwoju nie będzie żadnych ograniczeń odnośnie materiałów wykorzystywanych przez użytkowników do tworzenia zabawek, jednakże w przyszłych wersjach należy się liczyć z potrzebą eliminowania treści wulgarnych/pornograficznych/rasistowskich. powstanie konkurencji wraz z rozwojem serwisu oraz wzrostem popularności istnieje potencjalne zagrożenie powstania aplikacji kopiujących nasze rozwiązania. lenistwo użytkowników standardowy użytkownik może preferować proste przesyłanie zdjęć niż układanie amusementów, dlatego edytor na telefon z systemem Android powinien być prosty i przejrzysty, by każdy w krótkim czasie mógł wygenerować swoją zabawkę. Skomplikowany oraz toporny interfejs skutecznie odstrasza potencjalnych odbiorców. niski zysk z reklam na stronie WWW (profil serwisu nie jest w żaden sposób powiązany z konkretną grupą konsumencką typu: turyści, mechanicy itp.). Rozwiązanie: profilowanie reklamy na podstawie grupy wiekowej, statusu społecznego, wykształcenia (to już prędzej da się określić dla tego typu platformy). 8

11 duże koszty składowania i przesyłu mediów takich jak dźwięki, zdjęcia czy filmy Konkurencja W sklepie z aplikacjami mobilnymi Google Play nie istnieje program, który oferowałby taką funkcjonalność. Jednak istnieją aplikacje, które są instancjami konkretnych zabawek. Natomiast naszym celem jest stworzenie platformy, która będzie ich uogólnieniem. Poniżej chcielibyśmy je przedstawić i krótko przeanalizować i wierzymy, że wiedza o tych aplikacjach pomoże nam ulepszyć nasz produkt. Aplikacje [Animation Maker] oraz [Drawing cartoons] to bardzo dobre kreatory animacji. Stworzona animacja nie zawiera jednak żadnych elementów interaktywnych, a interfejs jest o wiele bardziej skomplikowany od tego opracowanego przez nas. Edytor Meme [Meme Maker] jest jedną z oferowanych przez nas zabawek. Istnieje jeszcze kilka aplikacji tego typu np. aplikacja do tworzenia Meme ze zwierzętami; aplikacja do tworzenia i publikowania Meme na stronie. Dla nas jest to jedna z zabawek, a więc oferujemy o wiele więcej niż wspomniane aplikacje. W Google Play, a także App Store (sklep internetowy z aplikacjami na urządzenia mobilne filmy Apple) okazjonalnie pojawiają się programy będące z naszego punktu widzenia konkretnymi instancjami naszej zabawki SoundPad, np. [Justin Bieber Soundpad] z Justinem Bieber em. Często zyskują one okresowo bardzo wysoką popularność (liczoną według statystyk pobrania). Jest to bardzo dobry znak, ponieważ za pomocą naszej platformy będzie można stworzyć takie Sound Pad y. [Steamy Window] i [scratch (ads)] to przykłady aplikacji, które umożliwiają tworzenie zdrapek. Szczególnie druga aplikacja zdrapkowa jest interesująca i na niej można się wzorować. Nasza aplikacja potrafi generować zdrapki nieco uboższe pod względem efektów ścierania, ale w zamian oferuje możliwość współdzielenia zdrapek między użytkownikami. [Photo Warp] to kolejna aplikacja, która pozwala w prosty sposób tworzyć zmodyfikowane zabawne zdjęcia. Z kolei [Instagram] umożliwia modyfikację i współdzielenie zdjęć fotografomamatorom. Nasza aplikacja jest o tyle inna, że nie chcemy tworzyć narzędzia do edytowania zdjęć. Fotografie są dla nas raczej elementami zabawek, które mają powstać. Wiedza o powyższych aplikacjach zdecydowanie wpłynęła na ulepszenie naszej aplikacji. Pomogła nam stworzyć przejrzysty i łatwy w obsłudze interfejs dzięki temu, że uniknęliśmy popełniania kilku podstawowych błędów, np. zbyt duża liczba przycisków, oraz wzorowaliśmy się na dobrych rozwiązaniach, np. miniaturki w Meme, tekst zastąpiony intuicyjnymi obrazkami Wymagania Oczekiwania wobec poszczególnych elementów systemu: edytor na platformę Android prosty, szybki w obsłudze, intuicyjny, przejrzysty stworzenie prostego amusementa musi zajmować mniej niż trzy minuty gotowe szablony z amusementami zawierającymi: zdjęcia, filmiki, animacje, dźwięki, zdrapki oraz wszystko co zespół uzna za zabawne wysyłanie na serwer oraz udostępnianie na serwisach społecznościowych Facebook, Buzz, Twitter za pomocą jednego przycisku 9

12 zapisywanie pracy bez konieczności połączenia z Internetem interfejs WWW serwer jednym z kluczowych założeń projektowych jest ukierunkowanie na technologię HTML 5. Użytkownik nie powinien potrzebować żadnych dodatkowych wtyczek do otworzenia naszych zabawek. Wraz z projektantami nowego standardu HTML jesteśmy przekonani, że przeglądarka powinna być w pełni samo wystarczalna i wstępnie odrzucamy technologię flash na korzyść nowych tagów audio-video zgodny z najnowszymi wersjami najpopularniejszych przeglądarek na PC. Na chwilę obecną, zgodnie ze statystykami ruchu sieciowego, są to: Chrome 20 Firefox 14 Internet Explorer 9 Safari zgodny z przeglądarkami na urządzenia mobilne, zwłaszcza na telefony z systemem Android minimalistyczny zachęcający nowych użytkowników do pozostania na dłużej i skorzystania z platformy skalowalny powinien być tak zaprojektowany, żeby nagły wzrost ilości użytkowników / przesłanych amusementów nie skończył się katastrofą niezawodny powinien działać 24/7. Każda chwila przestoju to irytacja oraz spadek zainteresowania użytkowników 1.8. Funkcjonalności Pierwsza udostępniona wersja ma zawierać: edytor na Androida, w którym można tworzyć amusementy z pewnej liczby gotowych szablonów przechowywanie stworzonych amusementów na serwerze przeglądanie umieszczonych na serwerze amusementów bezpośrednio w przeglądarce WWW bez konieczności instalowania dodatkowych narzędzi szybki interfejs do dzielenia się stworzonymi amusementami ze znajomymi dostęp do zabawek na serwerze przez zwykły odnośnik, integracja z serwisami społecznościowymi zapisywanie zabawek na aplikacji klienckiej 10

13 Rozdział 2 Opis implementacji 2.1. Architektura Obrazek nr 2.1 prezentuje poglądowy schemat architektury systemu. Rysunek 2.1: Schemat architektury systemu Użyte technologie Kod serwera, klienta i generatora zabawek jest napisany w języku Java. Zabawki są generowane do JavaScript i HTML 5. Oto przegląd technologii użytych w projekcie: Android aplikacja kliencka jest przeznaczona na urządzenia z systemem Android w wersji 2.1 lub wyższej. Z naszej strony wiązało się to z użyciem Android SDK w 11

14 wersji 7. Firma Google udostępnia wygodne i proste API to obsługi wielu funkcji nowoczesnych smarftonów. Do pracy nad projektem używaliśmy środowiska Eclipse i wtyczki do Androida dostarczanej przez producenta Androida. Google App Engine [GAE] Jest to platforma programistyczna dla serwisów internetowych działająca na zasadzie chmury obliczeniowej. Jest darmowa przed przekroczeniem limitów związanych z obciążeniem serwera. Za dodatkowy transfer lub obciążenie serwerów pobierane są opłaty. Nasza część serwerowa znajduje się na tej platformie. GAE wspiera kilka języków programowania. My użyliśmy języka Java. Objectify [OBJ] biblioteka udostępniająca interfejs do bazy danych dla GAE. Jest wiele możliwości używania bazy danych dostępnej na Google App Engine. My wybraliśmy framework Objectify. Wybraliśmy go głównie ze względu na bardzo prosty interfejs, którego można się bardzo szybko nauczyć. Nasza baza danych służy głównie do serializacji zabawek, dlatego prostota użycia tej biblioteki była dla nas ważniejsza niż rozbudowane opcje. Jednocześnie jest używany przez spore grono klientów GAE i zgromadził wokół siebie aktywną społeczność. Restlet [RES] WebService typu REST. Wybraliśmy ten typ WebService u ze względu na to, że wywodzi się z filozofii protokołu HTTP. Ta konkretna biblioteka miała przygotowane specjalne wydania dla GAE oraz Androida, dlatego była bardzo wygodna w użyciu. Mimo to w wydaniu na Androida znalazł się błąd, który poprawiliśmy w naszej aplikacji klienckiej. HTML 5 Jest to nowy standard HTML, który cały czas jest jeszcze opracowywany i wdrażany. Jest odpowiedzią na FLASH i aplety Javy. Przy użyciu HTML 5 będzie można tworzyć aplikacje bardzo zbliżone do aplikacji okienkowych. Na uwagę zasługuje fakt, że w pracę nad nowym standardem włączyli się producenci znanych i popularnych przeglądarek. jplayer [JPL] biblioteka JavaScript do odtwarzania dźwięku i filmów. Domyślnie stara się uruchomić plik przy pomocy technologi HTML 5. Jeżeli przeglądarka tej technologii jeszcze nie wspiera, to odtwarza plik przy pomocy technologii Flash. FOggPlayer [FOPL] biblioteka do Flash odtwarzająca pliki w formacie.ogg. Została użyta ze względu na to, że Flash nie wspiera domyślnie formatu dźwiękowego.ogg. Dopiero w początkowej fazie rozwoju. LAME [LAM] biblioteka służąca do konwersji dźwięku na format mp3. Jest napisana w C. Używaliśmy jej w aplikacji klienckiej, dlatego musieliśmy ją skompilować przy użyciu Android NDK, co umożliwiło użycie tej biblioteki w naszym programie Serwer Serwer ma za zadanie przechowywać zabawki i za pomocą WebService u umożliwiać przechowywanie i serwowanie ich użytkownikowi. Został napisany przy pomocy technologii dostarczonych do obsługi Google App Engine. Użyliśmy bazy danych typu NoSQL App Engine Datastore. Komunikowaliśmy się z nią za pomocą biblioteki Objectify. W bazie przechowywane są zabawki. Pliki związane z zabawkami (zdjęcia, dźwięki) przechowywane są w BlobStore. 12

15 Serwer komunikuje się z klientem za pomocą WebService u typu REST. Służy do tego biblioteka Restlet. Zabawki są pobierane z bazy danych, przekazywane generatorowi zabawek i serwowane użytkownikowi za pomocą strony WWW. Użycie Google App Engine spowodowało przeniesienie ciężaru odpowiedzialności za skalowalność oraz niezawodność główne postulatu dotyczące funkcjonalności serwera na programistów rozwijających GAE. Kluczową decyzją był wybór pomiędzy jednym z trzech wspieranych języków (Java, Python, Go). Nasz wybór padł na Javę: dzięki temu pojawiła się możliwość współdzielenia kodu generatora zabawek zarówno przez serwer jak i przez klienta Klient Klient składa się z następujących części: Menu Umożliwia przejście do innych części systemu stworzenia zabawki określonego typu lub wczytania już istniejącej. Edytor Daje możliwość tworzenia i edytowania trzech rodzajów zabawek: Scratchcard, Meme, SoundPad. To tutaj możemy zapisać zabawkę, zobaczyć jej podgląd lub podzielić się nią ze znajomymi. Zatem jest to moduł, który porozumiewa się z większością pozostałych modułów na kliencie. Podgląd Udostępnia podgląd zabawek w HTML 5. Rejestrator dźwięku ze względu na formaty dźwięku, które wspieramy, konieczne było napisanie własnego rejestratora dźwięku. Po nagraniu i zakodowaniu utworu do surowego, nieskompresowanego formatu korzysta on z biblioteki LAME do przekodowania i zapisania dźwięku w formacie mp3. Menedżer zabawek udostępnia listę zabawek zapisanych na kliencie. Pozwala na ich edycję, podgląd i usuwanie. Komunikator z serwerem Wysyła otrzymaną zabawkę na serwer przy użyciu biblioteki Restlet Generator zabawek do HTML 5 Generator zabawek jest wykorzystywany zarówno przez serwer, który z założenia ma udostępniać amusementy, jaki i przez klienta, na którym możemy obejrzeć podgląd swojego dzieła. Generator przetwarza otrzymaną zabawkę na odpowiedni kod w HTML 5 i JavaScript. Technologia HTML 5 jest stosunkowo nowa, a właściwie to jeszcze nieukończona, dlatego musieliśmy w pewnych miejscach ograniczyć jej użycie. Tak jest z odtwarzaniem dźwięku w gadżecie SoundPad. Jeżeli przeglądarka wspiera odtwarzanie dźwięku przy pomocy HTML 5, to używamy tej funkcji. W przeciwnym przypadku staramy się odtworzyć dźwięk za pomocą technologii Flash. Do rozpoznawania wsparcia po stronie przeglądarki i użycia odpowiedniego narzędzia użyliśmy jplayer i FOggPlayer. 13

16

17 Rozdział 3 Problemy technologiczne Niniejszy rozdział zawiera opis problemów technologicznych, z jakimi borykaliśmy się w trakcie pisania aplikacji, oraz sposób w jaki one zostały rozwiązane. Problemy technologiczne pochłaniały bardzo dużą część włożonej pracy oraz skutecznie opóźniały rozwój projektu i tworzenie nowych zabawek Dźwięk Jedną z podstawowych trudności była kwestia multimediów, przede wszystkim dźwięku. Dotyczy to zarówno nagrywania (na systemie Android), jak i odtwarzania (w przeglądarce). Zgodnie z założeniami projektowymi dźwięk powinien być odtwarzany za pomocą tagu <audio> w HTML 5, dlatego zdecydowaliśmy się wspierać tylko i aż formaty mp3 oraz ogg. Format mp3 jest obecnie najpopularniejszym formatem dźwiękowym, gwarantującym wysoki stopień kompresji, natomiast ogg jest jego rozwijającym się poważnym konkurentem, mniej popularnym, ale za to będącym w pełni wolnym nie obłożonym żadnymi patentami, jak to jest w przypadku mp3. Duże znaczenie miał też fakt, że oba formaty dają pokrycie na wszystkie najpopularniejsze przeglądarki, zdefiniowane w pierwszych rozdziałach, oraz że żaden sam nie pokrywa wszystkiego Nagrywanie Jeden z przykładowych przypadków użycia zabawki zwanej Sound Pad, polega na nagraniu dźwięku (np. życzeń) i podpięciu go pod jeden z przycisków. Android udostępnia wbudowany dyktafon, który można łatwo wywołać, jednakże zakres jego możliwości jest niewystarczający dla naszego projektu potrafi on tylko nagrywać do formatu 3gp/amr (zoptymalizowanym pod kątem mowy). Nasz projekt nie wspiera podanych formatów, poza tym przekodowanie otrzymanych sampli jest mocno problematyczne brakuje wbudowanych narzędzi. Dlatego zdecydowaliśmy się napisać własny dyktafon, będący częścią naszej aplikacji. Schodząc poziom niżej, przechwytywaliśmy czysty, nieskompresowany dźwięk. Ponieważ system Android nie posiada kodera mp3, zdecydowaliśmy się użyć jednej z gotowych, dobrze znanych i przetestowanych bibliotek LAME MP3. Lame jest w całości napisany w języku C, dlatego trzeba było znaleźć jakiś sposób by połączyć Jave na której jest oparty Android z dodatkową biblioteką w C. Z pomocą przyszedł Android NDK zestaw narzędzi pozwalających implementować składniki aplikacji używając natywnego języka jak C albo C++. Przed właściwą kompilacją projektu, programista powinien uruchomić ndk, tworzące prekompilowaną bibliotekę, którą następnie można automatycznie wkompilować w projekt. Możliwość embed owania 15

18 C w Androidzie jest stosunkowo nowa i nie wszystkie telefony/tablety ją obsługują. Główne znaczenie ma architektura CPU ze zbiorem dostępnych instrukcji. Na całe szczęście Google Play automatycznie filtruje urządzenia, nie spełniające wymagań, nie pozwalając im na instalację aplikacji. W trakcie prac powstały też inne pomysły na rozwiązanie przedstawionego problemu. Zakładały one przesyłanie dźwięku (3gp bądź też nieskompresowanego) na serwer i kodowanie/dekowanie do mp3/ogg na serwerze. Pomysł został odrzucony ze względu na wydajność nieskompresowany dźwięk zajmuje kilka razy więcej niż gotowe mp3, poza tym nie możemy sobie pozwolić na tak kosztowną operację, jak przekodowanie, na serwerze: maksymalny czas odpowiedzi na żądanie to 5 s. Istnieją techniki na ominięcie podanego limitu, jednakże mimo to zlecanie serwerowi takiej pracy wygląda bardzo źle, zwłaszcza gdy nasza aplikacja zdobędzie popularność i serwer będzie zalewany amusementami z dźwiękiem Odtwarzanie Kolejną kwestią związaną z dźwiękiem jest jego odtwarzanie. Jak już wyżej było wspomniane, projekt zakładał, że HTML 5 jest samowystarczalny i przyszłościowy dlatego absolutnie nie powinien korzystać z zewnętrznych wtyczek. Pomysł bardzo szczytny ideologicznie i wspaniały marketingowo, jednakże zderzenie z rzeczywistością było bardzo brutalne: nie istnieje jeden format dźwiękowy, który byłby odtwarzany przez wszystkie popularne przeglądarki. Przykładowo mp3 nie jest wspierane przez Firefox a i nie będzie przynajmniej do 2017, gdyż wtedy wygasają ostatnie patenty na ten format. Natomiast Internet Explorer nie wspiera wolnego formatu ogg, najprawdopodobniej ze względu na politykę firmy. Nasz zespół zdecydował się jednak reanimować podany pomysł, zmuszając przeglądarkę to odtwarzania dźwięku tagiem <audio> wszędzie gdzie się da a w razie niepowodzenia, próbować otwierać w technologii Flash. Z pomocą przyszła biblioteka jplayer. Korzystając z javascriptu sprawdza ona możliwości użytej przeglądarki pod kątem podanego pliku. Jeżeli przeglądarka sama potrafi otworzyć dany format, jplayer otwiera go za pomocą <audio>. Jeżeli nie, próbuje wywołać Flash a, przekazując mu dany plik. Stosując powyższe rozwiązanie, udało nam się uzyskać pokrycie na dwóch formatach dźwiękowych na większości przeglądarek. Problem nadal stanowił o zgrozo Internet Explorer. Kompatybilność naszego projektu z tą przeglądarką jest kluczowa trzeba pamiętać o tym, że IE jest cały czas w posiadaniu sporej części rynku. Wchodząc bardziej w detale, IE, jako jedyna z popularnych przeglądarek, nie wspiera natywnie ogg. Co więcej, domyślna instalacja Flash a też nie zawiera żadnego dekodera ogg. W celu pokrycia tego ostatniego przypadku, zdecydowaliśmy się na użycie jeszcze jednej biblioteki, FOggPlayer, będącą rozwojowym dekoderem ogg a we Flash u. Jest ona wywoływana tylko i wyłącznie w tym ostatnim, najmniej przyjemnym przypadku. Z niezrealizowanych alternatywnych pomysłów warto wspomnieć ideę kodowania i wysyłania identycznych dźwięków w dwóch formatach jednocześnie na serwer oraz ideę konwersji pomiędzy różnymi formatami na serwerze. Obie odrzucono: drugą ze względu na wydajność; dla pierwszej nakład pracy zdawał się przewyższać zyski. W ten sposób udało się uzyskać wsparcie dla dwóch formatów mp3 i ogg na wszystkich popularnych przeglądarkach. W szczególności nie oznacza to wsparcia wszędzie cały czas istnieją przeglądarki zarówno na PC, jak i na telefony z systemem Android, które ani nie implementują nowego standardu HTML 5, ani nie potrafią korzystać z Flash a. Na szczęście obejmują one niszowy fragment rynku. 16

19 3.2. Android Nasza aplikacja jest przeznaczona nie na konkretny model telefonu/tabletu, ale na wszystkie urządzenie korzystające z systemu Android w wersji co najmniej 2.1 (oraz posiadające pewne funkcjonalności, np. obsługę kart SD). Urządzenia różnią się od siebie parametrami, szerokością ekranu, zainstalowanymi standardowymi aplikacjami itp. Kompatybilność z wszystkimi urządzeniami nieraz było źródłem frustracji: to, co wyglądało bardzo ładnie na jednym ustalonym modelu telefonu, na tablecie było źle przeskalone albo niewidoczne ; przy zapisywaniu plików trzeba było uważać, bo struktura katalogów może być nieznacznie zmodyfikowana ; w zależności od modelu wywoływanie androidowego intentu do wbudowanej galerii z plikami wygląda inaczej, co więcej różne implementacje galerii filtrują różne typy plików. Nasz zespół starał się minimalizować te różnice, testując aplikację na różnorodnym sprzęcie Popularne przeglądarki Jak wcześniej zostało wspomniane, borykaliśmy się z problemem odtwarzania dźwięków w przeglądarkach. Drugim wyzwaniem związanym z przeglądarkami było doprowadzenie do stanu, w którym wszystkie elementy HTML 5 wyświetlały się z zamierzonym efektem. Otrzymaliśmy od klienta listę przeglądarek, na których zabawki muszą wyświetlać się poprawnie. Na Windowsie 7 były to Chrome, Firefox, Microsoft Explorer, Opera oraz Safari, natomiast na Linuxie: Chrome, Firefox oraz Opera. Kompatybilność musi być również zapewniona na przeglądarkach mobilnych takich jak domyślna przeglądarka Android, Mobile Firefox oraz Mobile Opera. Wiązało się to z większym nakładem pracy w porównaniu z przeglądarkami stacjonarnymi ze względu na odpowiednie dostosowanie rozmiarów zabawki do ekranu oraz skalowanie w przypadku zmiany orientacji. Wszystkie wymienione nazwy dotyczą najnowszych wersji przeglądarek. Z sukcesem udało się rozwiązać krytyczne problemy z kompatybilnością na prawie wszystkich przeglądarkach. Ostatnie testy zostały przeprowadzone w czerwcu 2012 roku na najnowszych przeglądarkach. Dwa problemy zostały zauważone i nierozwiązane. Pierwszy polega na tym, że na Microsoft Explorer 9 i na Safari na Windowsie 7 niektóre dźwięki są odtwarzane dwa razy szybciej. Komentarz od twórców biblioteki FOggPlater: The library at the moment lacks a resampler, and since Flash s audio is fixed at 44.1 khz any files with a different sample rate won t play at correct speed.. Wygląda na to, że z tym nie możemy sobie już poradzić w tej chwili. Drugi problem polega na tym, że na Mobile Firefox nie wyświetla się przycisk +1. Nie udało się znaleźć żadnych odnośników do tego problemu i niestety problem został nierozwiązany. 17

20

21 Rozdział 4 Dokumentacja użytkowa W tej części jest opisane działanie aplikacji klienckiej przeznaczonej na urządzenia z systemem Android służącej do projektowanie zabawek i dzielenia się nimi z innymi. Wymagania Edytora: Urządzenie z systemem Android w wersji 2.1 lub wyższej. Wymagania do obejrzenia zabawki na stronie WWW: przeglądarka internetowa. Może być wymagane zainstalowanie najnowszych aktualizacji do przeglądarki Menu Aplikacja wita nas przyjaznym menu z czterema opcjami. Trzy z nich służą do tworzenia nowych zabawek: Zdrapki, Sound Pad a lub Meme. Czwarta służy do odczytywania wcześniej stworzonych i zapisanych. Obrazek 4.1 przedstawia menu główne aplikacji. Rysunek 4.1: Menu główne aplikacji. 19

22 4.2. Zdrapka Po naciśnięciu przycisku zdrapka w Menu przechodzimy do edycji zdrapki (obrazek 4.2a). U góry ekranu możemy zmienić nazwę zabawki. Od razu możemy bawić się naszą zabawką w trakcie jej tworzenia. Możemy zdrapać kawałek folii (obrazek 4.2b). Naciskamy przycisk z zielonym plusem, aby dodać nowe zdjęcie z galerii lub zrobić je aparatem. Zdjęć można dodać kilka - w gotowej zabawce zdjęcia będą się pokazywały losowo. Za każdym razem inne. Jeżeli chcemy usunąć jeden z obrazków, to naciskamy na niego na liście i wybieramy Usuń. Naciskamy menu aplikacji w prawym dolnym rogu. Zazwyczaj są to trzy kropki, ale jest to zależne od urządzenia, którego używamy. Widzimy kilka opcji. Możemy uruchomić podgląd wygenerowanej zabawki (pobawić się efektem naszej pracy). Obejrzyj na stronie spowoduje przejście na stronę WWW z opublikowanym gadżetem. Zapisz pozwala na zapisanie amusementu, co umożliwi powrót do naszej pracy przy pomocy Menedżera zabawek. Udostępnij wyśle zabawkę na serwer i pozwoli nam podzielić się nią ze znajomymi przy pomocy serwisów społecznościowych zainstalowanych w telefonie. (a) przed zdrapaniem. (b) po częściowym zdrapaniu. Rysunek 4.2: Zabawka Zdrapka 4.3. Sound Pad Naciskając w Menu SoundPad przeniesiemy się do ekranu projektowania kolejnej zabawki (obrazek 4.3a). Jak poprzednio możemy naszemu gadżetowi nadać nazwę, a w menu znajdziemy opcje do zarządzania zabawką (obrazek 4.3b). Odmienny jest jednak sposób projektowania amusementu. Zabawka - Sound Pad składa się z kilku obrazków - przycisków, po których naciśnięciu słyszymy różne dźwięki. Na początku widzimy cztery plusy. Możemy dodać ich więcej ( Dodaj nowy element ) lub usunąć. Po kliknięciu na dany element widzimy trzy opcje Dodaj dźwięk, Zmień zdjęcie oraz Usuń element. Jeżeli chcemy mieć działający SoundPad, to do wszystkich elementów musimy przypisać dźwięki i obrazki. Dźwięki możemy nagrać za pomocą mikrofonu lub wybrać jeden z utworów zapisanych w telefonie. Tak samo ze zdjęciami, które w razie potrzeby możemy wykonać aparatem. 20

23 (a) Przykżadowa zabawka. (b) Menu. Rysunek 4.3: Zabawka Sound Pad 21

24 4.4. Meme Meme to bardzo prosta zabawka: składa się z dwóch zdjęć i komentarza - najczęściej na jakiś zabawny temat (obrazek 4.4a). Naciskając na górny lub dolny tekst możemy go zmienić (obrazek 4.4b). Tak samo będzie jak naciśniemy na tło albo obrazek z przodu. Tło i obrazek możemy zmienić wybierając jeden z elementów, który sugeruje nam aplikacja lub robiąc własne zdjęcie. (a) Przykżadowa zabawka. (b) Edycja górnego tekstu. Rysunek 4.4: Zabawka Meme 4.5. Menedżer zabawek Menedżer zabawek pozwala na zarządzanie zapisanymi zabawkami (obrazek 4.5). Możemy po naciśnięciu jednego z gadżetów z listy przejść do edycji i poprawić amusement, zobaczyć go na podglądzie lub skasować. 22

25 Rysunek 4.5: Lista zapisanych zabawek. 23

26 4.6. Przykładowe użycie Pokażemy jak szybko można stworzyć zabawkę od początku do końca. Po włączeniu aplikacji widzimy menu. Naciskamy Zdrapka. Nadajemy nazwę moje zdjęcie. Naciskamy przycisk z plusem i robimy swoją fotografię. Wchodzimy w opcje znajdujące się w prawym dolnym rogu i wybieramy Udostępnij. Dalej pozostaje już tylko użyć swojego ulubionego serwisu społecznościowego i poinformować znajomych o naszym dziele. I już. Zabawka jest w sieci, a inni mogą podziwiać efekt naszej ciężkiej pracy. 24

27 Rozdział 5 Wdrożenie W ciągu roku akademickiego udało nam się stworzyć stabilną wersję aplikacji. Część kliencka pozwala na stworzenie jednego z trzech rodzajów amusementów: Zdrapki, SoundPada lub Meme. Gotową zabawkę można umieścić na serwerze i podzielić się nią ze znajomymi za pomocą serwisów społecznościowych. Dużo pracy poświęciliśmy na przetestowanie i poprawienie aplikacji pod kątem działania na różnych wersjach systemu Android i modelach telefonu. Sprawdzaliśmy także jak wyświetlają się amusementy na popularnych przeglądarkach. Biorąc pod uwagę wszystkie wspomniane aspekty, zdecydowaliśmy, że nasz projekt dojrzał na tyle, aby opublikować pierwszą stabilną wersję aplikacji na Google Play. Pierwszego czerwca 2012 roku program o nazwie Amoose pojawił się w Google Play. Uważamy, że jest to jeden z największych naszych sukcesów przy tworzeniu tego projektu wydanie pierwszej wersji systemu. Dla nas jest to wyrazem tego, że jakość wytworzonego przez nas projektu wyszła daleko poza typowy akademicki zaliczeniowy projekt, a owoc naszej pracy spełnia wszelkie standardy rynkowe. Publikacja umożliwiła nam także zbieranie opinii o produkcie od szerszej grupy użytkowników. W momencie pisania tego dokumentu zbieramy wypowiedzi osób używających Amoose i zastanawiamy się, jak je wykorzystać do poprawienia naszego produktu. 25

28

29 Rozdział 6 Perspektywy rozwoju Pomysły na zabawki, które nie zostały zrealizowane: wirtualny pokój Poruszamy się po wirtualnym pokoju. Jesteśmy w stanie powiększyć te elementy, do których dołączono dodatkowe zdjęcie, np. podejrzeć, co jest w szafie albo pod łóżkiem. Możemy przejść do innego. W ogólności pokój zawiera elementy, które same są amusementami, np. w naszym pokoju umieszczamy ramkę ze zdjęciem, która po naciśnięciu okazuje się być zdrapką. kartka z życzeniami kilka zdjęć skomponowanych w kartkę pocztową. Dodatkowo pozdrowienia dla znajomych. zimowy pejzaż Obrazek z zimowym kurortem. Animacja z padającym śniegiem. Grupa postaci, do których wklejamy zdjęcia twarzy swoich znajomych. szron na szybie na początku mamy obrazek za oszronioną szybą. Przejeżdżając palcem zdrapujemy lód, efekt zależy od szybkości zdrapywania. Z czasem szyba znowu staje się oszroniona. Z naszego doświadczenia wynika, że pomysły na nowe amusementy przychodzą bardzo łatwo. Prototyp danej zabawki tworzy się bardzo szybko. Najtrudniejszą część stanowi zapewnienie wsparcia dla wielu wersji systemu Android oraz kompatybilność z różnymi przeglądarkami. Dla dalszego rozwoju projektu kluczowe jest wybranie kilku najtrafniejszych pomysłów. Docelowo nie chcemy umieszczać więcej niż siedmiu amusementów. Osłabiłoby to siłę odbioru aplikacji. Tryb from scratch pozwalałby na stworzenie zabawki w sposób bardziej niskopoziomowy. Udostępniałby możliwość rozmieszczenia wielu elementów w dowolnym położeniu na stronie i używaniu jako części gotowych amusementów (np. Sound Pad). Przy pomocy tego narzędzia można by stworzyć także szablon zabawki (tak jak teraz szablonem jest zdrapka). Sporym wyzwaniem jest stworzenie wygodnego edytora na urządzenia mobilne, który nie wymuszałby skomplikowanego interfejsu. Strona z najpopularniejszymi zabawkami Istnieje wiele serwisów WWW, które pozwalają na udostępnianie śmiesznych zdjęć, czy filmików. W tym kontekście zabawki sprawdzają się bardzo dobrze. Można by stworzyć stronę zawierającą listę najczęściej oglądanych amusementów. Konkursy tematyczne Projektując platformę do wymiany zabawek, zastanawialiśmy się nad naszą grupą docelową. Aplikacje przeznaczone dla ściśle określonej grupy społecznej czasami mają sporą siłę przebicia. Są dostosowane dla konkretnego użytkownika i łatwiej 27

30 je rozreklamować. Zdecydowaliśmy jednak, że nasze projekty są na tyle ogólne, że nie warto narzucać na nie dodatkowych ograniczeń. Jednak pewnym sposobem na wykorzystanie tej idei mogłyby być konkursy tematyczne. Użytkownicy mieliby za zadanie stworzyć najciekawszą zabawkę związaną z danym tematem. Przykładem może być najciekawszy motyw z bajki dla dzieci. Amusementy byłyby umieszczane na osobnej stronie konkursowej. Integracja z innymi serwisami Zastanawialiśmy się nad udostępnieniem dodawania amusementów na różne serwisy WWW, np. zabawki o temacie żartobliwym byłyby umieszczane na stronach typu demotywatory.pl, czy kwejk.pl, gdzie gromadzi się śmieszne zdjęcia. Jak to zwykle bywa, pomysłów jest wiele, ale najważniejsze jest skupienie się na tym, co może przynieść największe korzyści. W tym momencie z naszej perspektywy najważniejsze są wszelkie działania związane z wypromowaniem aplikacji i dotarciem do szerokiej grupy użytkowników. Pod tym względem najistotniejszymi dalszymi kierunkami rozwoju są wykonanie strony z najpopularniejszymi zabawkami i integracja z rozmaitymi serwisami. Spośród innych możliwych działań marketingowych rozważamy także stworzenie tzw. Fan Page na portalu Facebook. 28

31 Rozdział 7 Podsumowanie Pomysł na współdzielenie amusementów jest bardzo ciekawy i wierzymy, że ma duży potencjał. Praca nad platformą bardzo wiele nas nauczyła. Sporo czasu pochłonęło opanowanie nowych technologii. Część z nas nigdy nie miała do czynienia z technologią Android. Żaden z nas nie pracował z Google App Engine. HTML 5 jest projektem, który nie został nawet jeszcze ukończony. Uznaliśmy jednak, że praca nad Zespołowym Projektem Programistycznym, to doskonała okazja do tego, żeby poznać nowe technologie. Informatyka, to dziedzina, w której nowe idee i technologie powstają i rozprzestrzeniają się bardzo szybko. Nasza aplikacja ze względu na prostotę obsługi i wykorzystanie serwisów społecznościowych powinna też rozprzestrzeniać się bardzo szybko. Jak pokazaliśmy mamy też wiele pomysłów na jej rozbudowę, ulepszenie i wypromowanie. Na samo zakończenie chcieliśmy gorącą podziękować dwóm naszym mentorom, bez których projekt Amuse by nie powstał: pomysłodawcy projektu i klientowi panu mgr Bolesławowi Szewczykowi oraz naszemu promotorowi i opiekunowi dr Jackowi Sroka. Pan Bolesław wykazał się wielką wyrozumiałością oraz nieprzerwanie wspierał nasz projekt i nakierowywał na nowe pomysły. Pan Jacek nieustannie nas dopingował, mobilizował i pomagał wydajniej zarządzać pracą, która cały czas się opóźniała przez napotykane problemy technologiczno - kompatybilnościowe ; tylko dzięki niemu udało nam się zdążyć z wydaniem aplikacji na czas. Panowie, Amoose Team dziękuje Wam za waszą pracę oraz poświęcenie włożone w nasz projekt. 29

32

33 Dodatek A Zawartość dysku CD dokumenty praca licencjacka (ten dokument) architektura przypadki użycia źródła aplikacji Aplikacja znajduje się w folderze src. Struktura katalogów jest następująca: Android katalog zawierający źródła projektu aplikacji klienckiej, do otworzenia w Eclipse. CodeConverter katalog ze skryptem, który czyta zawartość katalogu HTML5 i na jego podstawie generuje definicje klas javy, które są szablonami zabawek GAE katalog zawierający źródła serwera HTML5 katalog zawierający szablony zabawek w HTML5, wraz z przykładowymi, zakomentowanymi danymi jars katalog zawierający wykorzystywane biblioteki: Objectify framework do obsługi bazy danych dla Google App Engine oraz fileupload i commons-io od Apache do obsługi przesyłania plików na serwer lib katalog zawierający kod współdzielony zarówno przez serwer jak i przez aplikację kliencką restlet katalog zawierający bibliotekę do obsługi WebService u Restlet z dwoma wydaniami dla Androida i dla Google App Engine 31

34

35 Dodatek B Opis instalacji Najprostszym sposobem uruchomienia naszej aplikacji na telefonie jest po prostu ściągnięcie jej z Google Play Ponadto Amuse jest aplikacją open source, kod źródłowy jest dostępny na Instalacja z kodu źródłowego: Niech <AMOOSE HOME> będzie ścieżką do folderu ze źródłami projektu. Instalujemy: Eclipse Android SDK Eclipse Android ADT Google App Engine Eclipse plugin: Help Install New Software Add.. podajemy Wgrywamy następujące projekty do Eclipse: Android : File Import... General / Existing Projects into Workspace Select root directory : <AMOOSE HOME>/Android Amoose-Lib : File Import... General / Existing Projects into Workspace Select root directory: <AMOOSE HOME>/lib GAE : File Import... General / Existing Projects into Workspace Select root directory: <AMOOSE HOME>/GAE Tworzymy classpath variable: Windows Preferences Java Build Path Classpath Variables New Name: AMOOSE HOME Path: <AMOOSE HOME> Zmieniamy ścieżkę w projekcie GAE: Klikamy prawym przyciskiem na projekt amoose-gae Properties Java Build Path Source. Tutaj edytujemy ścieżkę amoose-gae/lib-src na <AMOOSE HOME>/lib/src (folder name ma być ustawiony na lib-src) 33

36 Kompilujemy bibliotekę C do Lame a Ściągamy Android NDK Niech <NDK> oznacza ścieżkę do folderu do którego rozpakowano archiwum. Przechodzimy w konsoli do ścieżki ze źródłami <AMOOSE HOME>/Android/jni Uruchamiamy <NDK>/ndk-build W Eclipse budujemy wszystkie projekty (Project Build All) i uruchamiamy aplikację na emulatorze lub telefonie (klikamy prawym przyciskiem na projekt Amuse Run As Android Application) 34

37 Dodatek C Podział pracy Nasza praca przebiegała w kilku iteracjach. Wartymi wyróżnienia są następujące etapy: Tworzenie dokumentacji: wizji i nieformalnej wersji architektury. Projekty pierwszych zabawek: Zdrapka, Sound Pad, Meme, płatki śniegu. Pierwsza wersja prototypu: klient na Androidzie, serwer GAE, zdrapka. Dodanie Sound Pada, prace nad udoskonaleniem interfejsu dla zabawek. Prace nad Meme, usuwanie błędów. Zapewnianie zgodności ze wszystkimi przeglądarkami, testowanie i udoskonalanie klienta mające na celu wspieranie jak najszerszej gamy telefonów z Androidem, praca licencjacka (ten dokument). Uznaliśmy, że przy takim systemie pracy najlepszy będzie przydział zadań zależny od tego, co w danej chwili jest najpilniejsze do wykonania, a nie np. przypisywanie osób do poszczególnych modułów. W szczególności ciężko określić dokładny wkład w rozwój klienta na Androidzie, przy którym każdy z członków zespołu wniósł bardzo wiele, zarówno w kwestii projektu jak i implementacji poszczególnych części. Poniżej znajduje się orientacyjne podsumowanie wkładu poszczególnych członków zespołu w tworzenie artefaktów związanych z projektem: Piotr Lewandowski serwer, praca licencjacka (ten dokument), wstępna wersja wizji, architektura, klient Łukasz Marecik klient - m. in. interfejs zdrapki, kwestie związane z nagrywaniem i odtwarzaniem dźwięku, elementy serwera, poprawki do wizji i pracy licencjackiej Robert Rosołek lider zespołu, klient - m. in. Sound Pad, kwestie związane z opracowaniem elementów graficznych interfejsu, generowanie zabawek do formatu HTML 5, poprawki do wizji i pracy licencjackiej, przygotowanie plakatu promocyjnego Grzegorz Swatowski klient - m. in. Meme, kwestie związane z opracowaniem elementów graficznych interfejsu, generowanie zabawek do formatu HTML 5, poprawki do wizji i pracy licencjackiej. 35

38

39 Bibliografia [Animation Maker] [Drawing cartoons] [Instagram] [Justin Bieber Soundpad] [Meme Maker] [Photo Warp] [scratch (ads)] [Steamy Window] [GAE] Google App Engine [FOPL] FOggPlayer [JPL] jplayer [LAM] Lame [OBJ] Objectify [RES] Restlet 2.0/13-restlet/275-restlet/266-restlet.html 37