Pokaż kod I – Speechlist

Pierwszy post z serii o moich aplikacjach od zaplecza.

Zapraszam!


tl;dr
Stworzyłem aplikację na telefon do ćwiczenia języka angielskiego, polegającą na uzupełnianiu luk w tekście, z możliwością pobierania kolejnych, nowych testów z serwera.
https://play.google.com/store/apps/details?id=com.dbeef.speechlist.android


Przez kilka tygodni wakacji rozwijałem aplikację; cały pomysł zawiera się w rozwiązywaniu testów przez uzupełnianie luk gotowymi wyrazami.
O ile idea jest prosta (mnóstwo tego typu zadań w podręcznikach, na każdym etapie edukacji), rozwinąłem ją – w przeciwieństwie do ćwiczeń w podręcznikach, zeszytach, gdziekolwiek indziej – testy w telefonie mają 3 podstawowe plusy:

  • są w telefonie, zawsze pod ręką
  • wykonasz je wielokrotnie
  • co jakiś czas pula twoich testów się powiększa – możesz je pobrać z serwera, prosto w aplikacji, na który będę wrzucał co jakiś czas kolejne

Postawiłem też od razu na samo ćwiczenie i obycie z językiem;
Nie jest to zdecydowanie samouczek, który od podstaw nauczy języka.
Na pewno można jednak powiedzieć, że jest to coś pomiędzy czytaniem tekstu po angielsku, a uczeniem się na pamięć słówek, coś czego mi osobiście brakowało.

Czuję się zobowiązany wstawić link do materiału osoby która często pojawiała się w znaleziskach na wykopie, a wrzuca mnóstwo materiałów do nauki Javy pod względem pracy.
tl;dr wnioski bez oglądania tego filmu – pomysł na aplikację językową dokładnie pasuje w model aplikacji na staż, co napędzało pracę, bo przynajmniej z mojej perspektywy, często nad pracą nad tym projektem wpadała do głowy myśl z rodzaju “jak to bardzo bez sensu, co mi to niby da”.

Same testy staram się robić sam, w większości w oparciu o artykuły z Wikipedii, co zdaje się być wystarczające, ale:
testy podzielone są na 4 kategorie – vocabulary, idioms, tenses i various.
Jak można zauważyć – testy oparte o uzupełnianie ciągu tekstu, gdzie stawia się na naukę nowych słówek pasują do tej pierwszej – resztę uzupełniłem na podstawie materiałów z innych stron uzyskanych za mailową zgodą autorów.

Co do materiałów graficznych – skorzystałem z ikon dostępnych na prawach licencyjnych jasno pozwalających na takie użycie, każda jest z jednej konkretnej strony, toteż nie było zbyt dużo problemów z wstawianiem do aplikacji… hm. Uznania autorstwa? Tj. po prostu informacji o źródłach z których skorzystałem.

Koszty stworzenia takiej aplikacji i publikacji:

Publikacja na Google Play – 25 USD, płatne kartą, miałem już wcześniej bo robiłem proste gierki.
Wynajęcie serwera – za 1 miesiąc – 18 zł
Reszta – własna praca.

Tutaj kończą się ogólniki, a zaczynają szczegóły techniczne.


Szczegóły techniczne – co i jak działa (albo jak co czasem nie działa).

Szybko skacząc w głęboką wodę, technologie z których korzystałem:

  • Java SE
  • Hibernate
  • PostgreSQL
  • LibGDX
  • Tomcat8 (o ile to dodać jako technologię)
  • Jersey framework

Szybko tłumacząc;
Java SE, język w którym pisałem zarówno backend jak i frontend
Hibernate, framework z którego korzystałem aby połączyć web service z bazą danych, jaśniej;
aplikacja zajmująca się przesyłaniem odpowiednich testów w odpowiedzi na zapytania z jakiegoś telefonu, aby odpowiedzieć na zapytanie – jak wygląda test o id = 15 – łączy się z bazą danych na tym samym serwerze, pobiera z niego listę testów, sprawdza który ma identyfikator równy 15 i odsyła.
PostgreSQL – wspomniana baza danych
LibGDX – framework z którego korzystałem do napisania frontendu, zajmuje się wyświetleniem wszystkiego na właściwym miejscu na ekranie telefonu, teoretycznie do pisania gier – natomiast ja skorzystałem z niego ponieważ wcześniej miałem pewne doświadczenie w nim (dwie małe gierki i kilka takich których nie publikowałem, skazanych na wieczne niedokończenie), nie chciałem więc uczyć się od podstaw innego bo zbyt długo by to zajęło (zależało mi na czasie, nie chciałem żeby skończyło się jak z programami które zaczyna się i w którymś momencie odechciewa nad nimi pracować)
Tomcat8 – serwer aplikacji javowych, na nim uruchomiłem web service (jeśli już się poplątałeś, przypominam -> na komputerze (nazywanym też w innych miejscach tekstu serwerem) uruchomiłem tomcat, który jest z kolei serwerem aplikacji javowych, na którym uruchomiłem web service, który komunikuje się z bazą danych na tym właśnie komputerze, baza danych to po prostu inny program którego zadanie to dysponowanie danymi)
Jersey – po raz kolejny – framework, który odpowiada za konkretnie sieciowy aspekt backendu, czyli odbieranie/wysyłanie danych do klienta

Przechodząc do sedna , oto co dzieje się po uruchomieniu aplikacji:

  • Telefon wysyła zapytanie do serwera;
    podaj mi identyfikatory wszystkich testów jakie masz
  • Serwer odsyła odpowiednie dane
  • Telefon wczytuje testy które posiada na miejscu, w pamięci i porównuje ich identyfikatory z tymi z serwera – tworzy wtedy listę testów które są na serwerze, a których sam nie ma – wtedy wysyła kolejne zapytanie do serwera
    wyślij mi nazwy testów, o identyfikatorach o numerach { id testów których nie ma w telefonie }
  • Serwer odsyła odpowiednie nazwy
  • Telefon tworzy na ich podstawie przyciski z odpowiednimi podpisami, wkleja je do ekranu “downloads” i gdy użytkownik je klika, telefon zna ich identyfikator, więc wyśle po prostu kolejne zapytanie do serwera, o test o zadanym id.

Jak wygląda sam test?

Najłatwiej chyba będzie wkleić jeden z nich dla przykładu, potem omówić strukturę:

Jest to json, parsowany w kliencie by uzyskać konkretne dane, z odpowiednimi znacznikami (<<||>>) dla aplikacji aby wiedziała gdzie wstawić przycisk do wstawienia luki.
Słówka są podane w kolejności odpowiadającej lukom, w aplikacji natomiast ich wyświetlanie jest losowane, tak aby po prostu nie wstawiać słówek z listy jedno za drugim.
Różnica między id a uniqueID – id jest przypisywane przez bazę danych, odpowiada kolejności w liście z testami, natomiast uniqueID to id które samemu przypisuję, każdemu testowi z osobna, aby uniknąć konfliktu między klientem a serwerem, gdzie jeden nazywa swój test tak, a drugi inaczej. Z zasady przydzielam w jsonie wartość id taką samą jaką ma uniqueID, to bez znaczenia bo i tak ulegnie zmianie.

Perspektywy rozwoju (co działa lub nie i czy można to jeszcze bardziej… ulepszyć)

  • Zmieściłem aplikację w 3.7 mb, ale na pewno da się upakować ją w mniejszych rozmiarach (są odpowiednie narzędzia do odchudzania takich plików)
  • Graficzne zmiany, takie jak renderowanie tekstu w większej rozdzielczości i skalowanie go do mniejszej, tak aby uzyskać na klarowności, pasek przewijania pokazany podczas poruszania się po liście, płynniejsza praca kamery, wsparcie dla starszych Androidów
  • Wydanie aplikacji na iOS, co akurat jest trochę trikowe (na razie korzystając z maca kolegi dotarłem do momentu, gdzie za pomocą odpowiedniej wtyczki, kod z Javy konwertowany jest na odpowiednik w C#, potem należy do otworzyć w xcode i mając licencję dewelopera testować na urządzeniach Apple)

Co się tyczy materiałów do nauki:

Jeśli chodzi o Javę, ja zacząłem od Head First Java i z ręką na sercu mogę powiedzieć –na pewno nie od deski do deski.
Skończyłem gdzieś w rozdziale pisania aplikacji sieciowych, natomiast wydaje mi się że trochę wyćwiczyłem w praktyce, pisząc od tamtego czasu (jakieś 2-3 lata temu).

Jersey i Hibernate – proste do bólu tutoriale z sieci, prowadzące praktycznie za rękę do napisania własnego rest service
LibGDX – to samo co poprzednie, z tym że najważniejsze to ćwiczyć i ćwiczyć.

Inne

Przez jakiś czas miałem pomysł, aby Speechlist był sterowany… Głosem. Skorzystałem z Javowego API do Sphinxa i rezultaty możecie zobaczyć tutaj:

Pomimo niemal 100% rozpoznawalności słów (ograniczyłem Sphinxowy słownik tylko do słów z testu, dawału mu to bardzo małą bazę danych do porównania co przekładało się na szybkość i trafność) miałem trudności z przeniesieniem działającej wersji na telefon. Co prawda istnieje CMUSphinx na Android, ale sprawiał mnóstwo kłopotów.

Pokaż kod!!!111jeden

Mam pomysł aby nagrać kilka filmów, gdzie piszę Speechlist od podstaw, natomiast na ten moment zostawiam tu moje repozytorium z gotową aplikacją:

Frontend:

Główny branch – “new libgdx version”

Branch z rozpoznawaniem mowy – “master”

Branch “no speech recognition” – śmieci

https://bitbucket.org/dbeef/speechlist

Backend:
https://bitbucket.org/dbeef/speechlist-rest-service


PS: Wiecie co mnie denerwuje w blogerach? Skoro mam okazję to o tym napiszę: memiczność na siłę. Wrzucanie hehe śmiesznych obrazków gdzie tylko się da w taki sposób, że ma się ochotę rzygnąć. Stop.


dsp2017-1.png

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s