Założenia techniczne aplikacji mobilnej

Forma, w jakiej to pisałeś, nie brzmi jak rzeczowa dyskusja, żywku.
A jeśli chodzi o odwołania do serwera, przypominam pierwszy wpis w tym wątku, Elten Mobile i generalnie wszystko prócz desktopowego klienta wykorzysta osobne API, pod adresem
api.elten-net.eu
komunikujące się przez JSON.

Dane można przekazywać zarówno przez post, get, jak i jsonem, kodując informację jako json, przekazując jako zawartość dokumentu i ustawiając nagłówek
Content-Type
na
application/json
czyli zgodnie z RFC.

Cierpliwość ludzka ma swoje granice, tak Ci powiem ze smutkiem.
Co nie zmienia faktu, że do rozpoczęcia jakiejkolwiek pracy i tak potrzebne mi jest coś więcej, niż tylko api.elten-net.eu
I tak samo jest z aplikacją stacjonarną

W wypadku aplikacji stacjonarnej jest to znajomość Rubiego.
W wypadku mobilnej... Nie mam, szczerze, pojęcia, co mógłbyś zrobić nawet, gdybym miał czas wykonać dokumentację całego kodu.
To i tak jest wstępny zalążek.
Jeśli chcesz coś zrobić, możesz zaimplementować wątkowanie w wiadomościach na stronie

Daj mi chociaż listę tych zapytań i zwrotów któe CI do iOS zwraca

Ja akurat Pajper wiem, co żywek chciał powiedzieć.
Ja na przykład mółbym zacząć pisać chociażby nieoficjalny klient na Androida, mając listę zapytań i zwrotów. Nie chozi tutaj o to, żebyś klepał poradnik dla świerzakó, tylko żebyś dał nam rzeczową, surową dokumentację programistyczną.

Eapi też miało mieć kurs etc.

niestety, panowie, trzeba wybierać między rozwijaniem się programu, a jego dokumentacji :)

Tylko, że to się łączy.

słuchajcie, studjuje więc zdaje sobie sprawę, że robienie dokumentacji to conajmniej tyle samo roboty, co pisanie kodu, a nie ma żadnej gwarancji, że jak taka dokumentacja by powstała, to nagle chmara programistów eltenowych zasiądzie do kodu. Ilu mamy tu zdeklarowanych programistów? Poza tym, dobry programista poradzi sobie z kodem eltena tak czy tak, a w razie co zapytania można kierować do autora, którego macie na wyciągnięcie ręki.

Jestem bardzo ciekaw jednej rzeczy - mianowicie: co wam da dokumentacja?
Bo wiecie... Dokumentacja biblioteki ma sens, bo nie musimy rozumieć, jak działa każda funkcja, ważne, że działa, nie musimy rozumieć kodu biblioteki.
Skoro jednak jesteście chętni pomocy przy Eltenie, to i tak musielibyście ten kod zrozumieć, modyfikując wiedzieć, co modyfikujecie.
Więc i tak musicie przeczytać ten kod, nim coś ruszycie, nie piszecie od zera.

Jkie nie piszecie od zera?
Niomu tu się ni chce bawić, poza Tobą, w kompatybilność z rubym bla bla bla.
A zapytania i to, co zwracają to jest kilka godzin roboty.
Amen ija już się nie udzielam, bo i tak tu się nigdy nic nie zmieni.

Czy możecie zrozumieć, że API dla wersji mobilnej, po prostu...
nie, jest, skończone?
Nie będę dokumentował czegoś, co w każdej chwili się może zmienić, co się rozwija...
Nawet ostatnie wsparcie forów i wiadomości głosowych wymagało zmian w API, bo poprzednia wersja potrafiła obsługiwać tylko treści binarne w formacie base64, co niepotrzebnie wydłużało czas przesyłania, a więc API od ledwo końcówki grudnia obsługuje przesyłanie danych binarnych, co się ustawia odpowiednimi nagłówkami i parametrami, pojawiła się więc potrzeba wprowadzenia informacji o źródle treści.
I jak mam oddać w ręce programistów coś, co zaraz może okazać się nieaktualne?

A co do Rubiego.
Czy ktoś narzekał, że NVDA jest w Pythonie? Nie słyszałem.
Czy ktoś narzekał, że kernel Linuxa jest w C? Także nie słyszałem.
Albo czy ktoś narzekał, że Githubowe narzędzia są w Ruby? Nie spotkałem się.

Sory, ale naturalne zasady mówią, że decyzję o języku podejmuje po prostu pierwszy programista. No więc ja podjąłem następującą: Elten będzie w Rubym, bo ten język lubię, dobrze znam.
Kto inny napisałby w Go, C czy Pythonie? Ok, każdy ma inny język, inną technikę, jakie lubi.
Ale Eltena napisałem ja, nie kto inny, a ja wybrałem Rubiego.

I jeszcze jedna sprawa. Załóżmy, że teraz dokumentuję to API, ktoś zabiera się do roboty i pisze nieoficjalny port Eltena na Androida w, powiedzmy, Javie.
Ten port działa, ale autorowi się znudził, nie miał on czasu, cokolwiek. Co wtedy? Nawet jeśli port będzie otwartoźródłowy, widzicie tu kogoś, kto by go pociągnął?
Bo ja na pewno nie: klient desktopowy, iOS, Android, za dużo.
Właśnie dlatego pracuję nad wspólnym API pod komputery i wspólnym na telefony, by miast pięciu projektów: Windows, Linux, Mac, Android, iOS, były tylko dwa.
Właśnie dlatego też piszę obydwa w Rubym, by jak najwięcej kodu współdzielić, minimalizując ilość pracy.

Właśnie. Piszesz.
A tylko potem nie narzekaj, że jak to się ten wątek nazywał?
Że coś tam, przydałoby się wywołać kilka osób, które zadeklarowały... bla, bla, bla.
Chcesz, rób sam.
Dobranoc.

Przynajmniej bylaby mozliwosc napisania takiego portu...
--Cytat (pajper):
I jeszcze jedna sprawa. Załóżmy, że teraz dokumentuję to API, ktoś zabiera się do roboty i pisze nieoficjalny port Eltena na Androida w, powiedzmy, Javie.
Ten port działa, ale autorowi się znudził, nie miał on czasu, cokolwiek. Co wtedy? Nawet jeśli port będzie otwartoźródłowy, widzicie tu kogoś, kto by go pociągnął?
Bo ja na pewno nie: klient desktopowy, iOS, Android, za dużo.
Właśnie dlatego pracuję nad wspólnym API pod komputery i wspólnym na telefony, by miast pięciu projektów: Windows, Linux, Mac, Android, iOS, były tylko dwa.
Właśnie dlatego też piszę obydwa w Rubym, by jak najwięcej kodu współdzielić, minimalizując ilość pracy.

--Koniec cytatu

@żywek nie wiem, o co ci chodzi.
@nuno69 licencja Eltena, Open Public License, zabrania tworzenia niezależnych dystrybucji i kopii Eltena, jak długo program jest wspierany przez autora, bez jego zgody. A ja nie wyraziłbym zgody na coś takiego.
I nie jest to moja złośliwość, a sprawa bezpieczeństwa.
Skoro mamy tu tylu palących się do pracy programistów, bardzo się cieszę, ale naprawdę są rzeczy, w których możecie pomóc teraz.

A na pompkę że tak powiem konwertować nieszczęsne AAC'e do Opusa, nawet server side, skoro: 1. Apple ma dobrą implementację referencyjną mpeg-4 AAC, która działa.
2. Wewnętrznie do wszystkiego, nawet opusa w Eltenie (przynajmniej PC) działa FFMpeg, który natywnie z AAC jak i AACplus sobie radzi.
Jedyne, choć mgliste wytłumaczenie to fakt, że Internet Exploder nie obsługuje AAC w kontrolce HTML 5 na stronie.
Analogicznie, Windows XP ma podobny problem pod dowolną przeglądarką.

Przyczyna jest dość prosta: chcę, by na serwerze wszystko miało ten sam format. Obecnie nie jest to problem, ale nie wiem, co może się pojawić. A: jedne wpisy w opusie, inne w aac... To brzmi jak przepis na katastrofę.

Tak, możemy cos robić, ale nie ma co robić, więc nie możemy robić nic.
I co o co mi chodzi? Przecież jasno napisałem. CHcesz, rób sam. Tylko potem nienarzekaj, że Ci ciężko. BO każdemu w życiu, czy Arkowi, czy Patrykowi w ten, czy inny sposób jest ciężko. Życie nie jest usłane chipsami i trzeba to zrozumieć.
Trzeba zrozumieć również, że nie jesteś jedynym człowiekiem na tym globie i czasem dopuścić do siebie racjonalne tłumaczenia innych ludzi.
Tak samo, jak do tej pory nie jest rozwiązana kwestia, o której CI pisałem kilka lat temu. metodą GET i post nie robi się dużych serwisów. Poczytaj sobie różne poradniki programistyczne, gdzie jest wszystko wyjaśnione, że
"Przy większym obciążeniu infrastruktury prosciej jest napisać serwer pośredniczący, do któego sobie te zapytania getem możesz wysyłać..."
Ale cóż, ja może się nie znam i ludzie, którzy pomagali mi w pewnych projektach też się nie znają...
Tylko, ze ciekawe, że pracują w dużych korpo programistycznych...
NO to ciekawe, czemu nie wiedzą, co mówią.

Ciekawe jest to, co piszesz, bo metodą POST i GET wysyłamy nawet takie rzeczy, jak powiadomienia na serwerze Applea, łączymy się z API Googlea do Youtube czy Gmaila, z API Twittera, Facebooka (gdy jeszcze było publicznie dostępne).
Przez POST i GET działa apt i pacman, działa homebrew, diagnostyka w Windowsie...
W tej sytuacji chyba jednak jest to dobre rozwiązanie. I, za przeproszeniem, nigdy nie widziałem żadnych problemów z tą metodą, najmniejszych.
Elten działa, nie sypie się co 5 minut, serwer się nie zwiesza chyba, że ktoś go DDOSuje, nie. To śmiga możliwie lekko i żadne pisanie innych protokołów nic tu nie zmieni, tyle tylko, że znowu będziemy mieli problemy wieku dziecięcego.

A co robić jest zawsze. Aplikacja mobilna na Androida nie jest jedyną możliwością prac nad Eltenem.