Założenia techniczne aplikacji mobilnej

Niniejszy dokument kieruję jako ciekawostkę lub też dla ludzi zainteresowanych ewentualną pomocą w tworzeniu aplikacji mobilnej Eltena.
W przyszłości trafi do repozytorium tego wydania, ale że na razie żadnego repozytorium nie ma, prezentuję go tutaj.
Zawiera on założenia programistyczne aplikacji mobilnej Eltena, konwencję, podstawę API, zalecenia, koncept i tak dalej.

Spis treści:
1. Specyfikacja
2. Założenia kompilacji
3. Elten API
4. API serwera i zasady połączeń
5. Wątki
6. Interfejs
7. Organizacja kodu

1. SPecyfikacja
Elten Mobile napisany jest w języku Ruby.
Jeśli tylko to możliwe, wykorzystywane są biblioteki wieloplatformowe.
Kompilatorem jest Ruby-Motion, w momencie pisania niniejszego tekstu w wersji 5.1.2.
Jako, że wsparcie dla Rubiego w wersji 2.5.1 przyniesie dopiero MacOS 10.14 Mojave i xCode 10.0, obecnie stosowana wersja to Ruby 2.3.7 z planowanym przejściem na najnowszą edycję wraz z premierą nowych narzędzi od Apple.
Jako, że rozwój platformy wciąż trwa, lista komponentów nie jest zamknięta.
W chwili pisania tego dokumentu stosowane są następujące elementy biblioteki standardowej: base64, cgi, date, digest, json, net, openssl, socket, uri; oraz następujące biblioteki zewnętrzne (gems): ruby-motion, motion-flow, motion-gradle (tylko Android), motion-provisioning, (tylko iOS), Store, Task, REPL (tylko w wersji debug).
Natywne API iOS nie obsługuje kodowania ani dekodowania formatu OPUS, co wymaga użycia dodatkowej biblioteki audio. Na razie jeszcze nie dokonałem wyboru. Problem nie dotyczy Androida.
Uwaga! Część powyższych bibliotek jest lokalnie modyfikowana poprzez subclassing i/lub aliasing.

2. Założenia kompilacji
Elten Mobile będzie kompilowany jedynie w wersji 64-bitowej i też jego kod pisany jest z myślą o takiej wersji.
Używana wersja API iOS to obecnie 11.4, ale w przyszłości będzie to 12.0, co pozwala uzyskać zgodność od iPhone 5S w zwyż.
Decyzja o przejściu na API iOS 13.0 będzie zależna od wspieranych urządzeń.
Używane API Androida to rewizja 23, R13B, co oznacza wsparcie dla Androida 6.0 Marshmallow i nowszych.

3. Elten API
Elten API znane z wersji desktopowej zostało w wersji mobilnej uszczuplone.
Wciąż jednak zostały przeniesione funkcje do lokalnego parsowania danych, jak również zgodne jest nazewnictwo niektórych funkcji elementu interfejsu użytkownika.
Wszystkie przeportowane funkcje znajdują się w folderze app/eltenapi i należą do modułu Elten::EltenAPI.
Ze względu na politykę Apple, nie będzie jednak możliwe pisanie zewnętrznych programów na tą wersję Eltena, nie wykluczam jednak dostępu do konsoli, muszę się bliżej przyjrzeć polityce Apple w tym zakresie.

4. API serwera i zasady połączeń
W przeciwieństwie do klienta używającego dedykowanego mu systemu kodowania danych, wersja mobilna używa standardowej komunikacji JSON - ze względu na jej większą elastyczność i popularność.
API pisane jest równolegle do aplikacji mobilnej na adresie
api.elten-net.eu
Dane do API mogą być wysyłane dowolnie jako POST lub GET, serwer sprawdza obydwie możliwości.
Dodatkowo, możliwe jest wysyłanie danych jako czysty JSON przy spełnieniu standardowych wymagań nagłówkowych.
W odpowiedzi przesyłane są informacje zakodowane jako JSON, kody odpowiedzi (code) są zgodne z kodami HTTP.
Odpowiednie sekcje API posiadają własne adresy URL, na przykład: api.elten-net.eu/handshake, api.elten-net.eu/login.
Obsługiwana jest wyłącznie transmisja zaszyfrowana https.
Zalecany protokół to HTTP 2.0, obsługiwany jest jednak stary HTTP 1.1.
Kod źródłowy API serwera zostanie udostępniony.
Wszystkie zapytania do serwera wykonywane są asynchronicznie, a działania podejmowane dopiero po otrzymaniu poprawnie zakodowanej odpowiedzi.
Ta technika nie została wprowadzona w kliencie desktopowym z powodu takiego, że w gimnazjum nawet o niej nie słyszałem, na aplikacji mobilnej jednak można już ją wdrożyć od podstaw, a więc warto.
Uchroni to przed nagłymi błędami powodującymi utratę treści.

5. Wątki
Na systemie iOS jest w pełni obsługiwane wielowątkowanie procesu. Wszystkie funkcje napisane są tak, by korzystać z tego, o ile możliwe.
Interfejs użytkownika znajduje się w osobnym wątku w stosunku do wszystkich działań serwerowych.
Na systemie Android struktura wielowątkowa jest emulowana (Android Marshmallow) lub wdrożona (Android Nougat, Android Oreo).
Synchronizacją wątków zarządza Mutex Apple (iOS) lub wbudowany w system Ruby (Android).

6. Interfejs
Używane jest natywne API obydwu systemów.
Obecnie wszystko pisane jest w ramach jednej instancji nawigacji, z przewidywanym późniejszym podzieleniem interfejsu na karty.
Funkcje charakterystyczne dla danych systemów znajdują się w folderach app/android oraz app/ios, a wykorzystywane są wspólnie.
Używane są jedynie elementy interfejsu wspólne dla obydwu platform, a więc przyciski, listy, etykiety itp.

7. Organizacja kodu
Kod jest budowany poprzez rake (plik rakefile).
Poszczególne konfiguracje znajdują się w plikach config/android.rb oraz config/ios.rb.
Zasoby aplikacji - w tym dźwięki - znajdują się w folderze resources.
Kod źródłowy programu znajduje się w folderze app i zorganizowany jest zgodnie z jego przeznaczeniem: natywne wsparcie platform (android, ios), eltenapi, controllers, views, server, extras.


Ostatnia aktualizacja: 04.09.2018 15:43.

Pewnie apka mobilna to kwestja długich miesięcy, i pewnie do tamtej pory zmienię telefon, ale pókico mam Iphonea 5, i to znaczy, że mogę się pożegnać z Eltenem mobilnym? Dawidzie- proszę cię, nie idź tą drogą.

Ja nawet nie mam w tym zakresie innych możliwości technicznie obawiam się.
Nie mogę wydać nowej aplikacji na starszą platformę, Apple nie daje mi takiej możliwości.
Opłaciłem abonament programisty w Apple kilka dni temu. I dostęp mam tylko do narzędzi najnowszych na ten moment.
To znaczy, jak już Elten teraz powstał, mogę pisać go w tej wersji API dalej.
Ale nie mogę w dawniejszej, niż najnowsza na chwilę zapoczątkowania projektu.

No nic- wielka szkoda, ale na pewno się odezwę, jak nabędę coś nowszego.

Elten od następnej kompilacji będzie w API iOS 12, a ja donoszę, że do audio użyję biblioteki bass, tej samej co w kliencie desktopowym, bo ktoś był tak miły, że ją przeportował na Jabłuszka.

Ooo. Fajnie. Dobrze wiedzieć, że ktoś ułatwił robote. :)

Na Andka Bass ponoć też jest. To tak na w razie czego.

Dobrze słyszeć, to ułatwi sprawę znacznie. :)

A jest, na pewno jest

Ktokolwiek zainteresowany kodem aplikacji mobilnej?
Na razie, z braku sprzętu, niebardzo jest jak to rozwijać - bez testowania mija się to z celem - ale za to postanowiłem nieco uporządkować kod.
I zasadniczo możnaby go wyrzucić na Githuba, jeśli ktoś ma ochotę zerknąć na niego oczkiem.

Ludzie, nie róbcie tego. Zawał murowany. :)

A tak poważnie, to...

Hmmmm... Czy to jest oficjalna publikacja kodu na licencji Open Source? Bo wiem, że się jeszcze wstrzymywałeś chyba. W sensie, chciałeś zaczekać.

Taki miałem zamiar. Ale gdyby znalazł się ktoś chętny do współpracy, wyfrunęłoby to już teraz.

Może też pozapytuj w necie albo pozwól zapytywać, bo tę apkę już widać, to widzący mogliby wspomóc

Bitrate dla aplikacji mobilnej, wg AAC, bo jak się nie bawić, i tak iOS do AAC nagrywa i ewentualnie potem koduje do Opusa, więc tu mamy i tak podwójną stratę: kompresja do AAC, a z niego do Opusa, ale, dobra, i tak jest nieźle:
Dla forów jest to 96kbps, dla wiadomości 64kbps.
Decyzja o niższej jakości tu wynika nie ze względów serwerowo-dyskowych, a z tak prozaicznych, jak szybkość wysyłania: 64kbps audio będzie wysyłać się prawie dwa razy krócej, niż 96kbps, a jednak przy wiadomościach prywatnych, nagrywanych na szybko na mieście czy gdzieś, może to być znacząca różnica. Tym czasem niby LTE, niby 5G, a z doświadczenia wiem, że te komórkowe szybkości Internetu rzadko kiedy są porównywalne z Wi-Fi.
W przyszłości pewnie dodam szersze ustawienia w tej kwestii, ale na razie będzie, jak jest.
Audio na serwer ślemy jako AAC, serwer już to konwertuje do Opusa lokalnie, szybciej to zrobi od telefonu dużo.
Można wysyłać audio JSONem lub w ciele zapytania, binarnie, przy czym tu niezbędne będzie ustawienie nagłówka Content-Length oraz parametru 'src' na "-".
Ale to wszystko będzie wyjaśnione w dokumentacji API, gdy ta się ukaże.

Moim zdaniem to bitrate w zupełności wystarczy. W końcu to tylko głos.

Dobrze powiedziane, ze "Jeśli" czy tam "kiedy" się ukaże. W końcu oficjalnej dokumentacji klienta desktopowego nie ma do tej pory, i ludzie nie wiedzą co mają robić nawet, jakby chciel pomóc

A znajdź, żywku, mniejszy projekt open-source, który ma szczegółową dokumentację.
Nie mówię o bibliotece, mówię o programie.
Duże projekty, jak NVDA, Linux, Orca to co innego, tam jest sztab ludzi.
Gdybym ja, prócz programowania, miał wszystko wyjaśniać, ilustrować, co chwila zmieniać, to bym drugie tyle, co piszę Eltena, pisał wykazy dla programistów.
A wychodzę z założenia, że programista nie potrzebuje dokumentacji, by zrozumieć widziany kod.
Są do tego narzędzia, jak doxygen, w kodzie Eltena w ważniejszych miejscach są komentarze...

Taa... Ciekawe. No jaik widzisz najwyraźniej programista... Ja tam się za niego nie uważam, więc o sobie nie mówię... Zresztą nie bądź hipokrytą, bo sam mówiłeś, że masz problem ze zrozumieniem kodu, któego sam nie pisałeś, he, he... No, ale programiści najwidoczniej kodu nie rozumieją

Ciekawe to podejście - obrażanie drugiego człowieka w ramach tzw. próby współpracy.
Jasne, że zrozumienie czyjegoś kodu jest trudniejsze. Ale nie niemożliwe.
Z resztą, co chciałem napisać, napisałem w poście 17 w tym wątku.

Nadinterpretowanie też jest ciekawe, a ja sobie nie przypominam, żebym CIę obrażał.
Sam mi pisałeś jakiś rok temu, więc teraz to tylko prawie zacytowałem.
A nie chodziło mi o dokumentowanie kodu, tylko odwołań, których używasz do otrzymania konkretnej rzeczy od serwera. I nie ma co strzelać, że tak to ujmę, fochów. BO przepraszam bardzo, ale przez ostatnie 2 lata w tej kwestii nie zrobiono nic.