Pozostałe platformy

Założenia techniczne aplikacji mobilnej

Started by pajper 143 posts last post 7 years ago Page 6 of 8

#101 1 like

Znam przewagę JSON nad czym innym, już strona Internetowa wykorzystuje JSONa w niektórych rzeczach. Ale boję się jednej pułapki.
Klient JSON o tyle jest problemem wydajnościowym, że mnożą się zapytania do serwera. Elten nie jest Googlem z ogromną serwerownią, a użytkowników mamy wielu.
Osiągamy po 80-90 osób zalogowanych jednocześnie.
Boję się sztucznie to podwajać.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#102 1 like

W ogóle, gdybym miał czas nieograniczony, bez studiów i niczego, mógł przekreślić, co mi się nie podoba i pewne rzeczy zrobić od nowa, zrobiłbym to tak:
1. Cały serwer w PHP'ie wyrzucił.
2. Przepisał stronę Internetową do Rubiego, obsłużył w Rubim także api JSONa.

Korzyści byłyby takie:
1. Dzięki JSON, każdy mógłby się łączyć, pisać klienty itp.
2. A dzięki Rubiemu, w komunikacji serwer-klient możliwe byłoby serializowanie zmiennych, dużo wydajniejsze od JSON.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#103 1 like

Czegoś nie rozumiem.
Brak API ze względu na ryzyko bezpieczeństwa.
Kilka postów dalej:
"Nie wiem czy strony nie rozwijać dalej, jak jest - skrypty php łączące się bezpośrednią z bazą sql. Oczywiście, ma to swoje wady, większe ryzyko bezpieczeństwa szczególnie..."
Sygnatura to może być w sądzie. Sygnatura sprawy np. :P

#104 1 like

Daszku, to akurat jest proste.
Każdy nieoficjalny, pierwszy klient będzie traktowany jako oficjalny nawet, gdy pojawi się w nazwie unofficial, w dodatku podwajając pisany kod i tworząc niepotrzebne podziały.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#105 1 like

A co do bezpieczeństwa, nie do końca się zgodzę.
Jeśli np. klient mobilny pisany będzie w JS, wystarczy jedno niedoparsowanie, by umożliwić bardzo poważne ataki poprzez XSS.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#106 1 like

A do tych, co uważają, że to moja złośliwość - już się deklarowałem.
Jeśliście tak gotowi do pracy, nic nie stoi na przeszkodzie by napisać silnik dla Eltena Mobile w Rubym pod Andka i to z wielkim mym błogosławieństwem i wszelką możliwą pomocą.
I mi zaoszczędzicie pracy, i sobie wszystko przyspieszycie.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#107 1 like

Dobra, by być słownym, mały opis, jak to działa...
Bazą do silnika jest taka biblioteczka do Rubiego o nazwie Flow.
Projekt jest porzucony i nieco funkcjonalności mu brakuje, ale jako podstawa jest całkiem fajny.
Tworzy on szereg klas o wspólnym kodzie dla Androida i iOS, w tym: obsługa JSON, requestów http, UI itp.
Kod:
https://github.com/HipByte/Flow.git

Przy czym, biblioteka jest porzucona i pewnych rzeczy jej brakuje.

Wprowadzone na potrzeby Eltena modyfikację:
Moduł UI::Text nie jest polem statycznym, jak tutaj, tylko polem edycyjnym, tekst statyczny to zaś jego submoduł StaticText.

Dopisane funkcje i atrybuty:
UI::Text oraz UI::TextInput posiadają zdarzenia :blur na wyjście kursora, :show na wejście w pole, :change na wpisanie, usunięcie and so on.
UI::TextInput posiada flagę UI::TextInput::Numeral służącą do wymuszenia wprowadzania liczb.
UI::View posiada funkcję scale skalującą okno, aby np. zmniejszyć go do połowy wysokości ekranu: view.scale(1,0.5)
Moduł UI::List posiada funkcję scroll(index), która przenosi kursor na wybraną pozycję listy.
Moduł UI::Label posiada flagę UI::Label::Header, zgadnijcie, poco.

Na pewno o czymś zapomniałem, bo kodu pod ręką nie mam, ale to tak mniej-więcej.
Plus przepisałem wszystkie moduły tak, by poprawić ich zgodność z Voice Overem.

Pierwszym celem dla Androida byłoby więc zaimplementowanie tych modyfikacji.

Następny krok to napisanie odtwarzacza, tutaj wzorem Elten Desktop, a więc wypełnić trzeba funkcjami i podobnymi rzeczami moduł:

module Sound
class Player
def initialize(filename)
# initializes player of a file or stream URL
end
def play
# plays a file
end
def stop
# stops a file
end
def pause
# pauses a file
end
def resume
# resumes file playing
end
def duration
# file duration in seconds, float
end
def position
# current position in seconds, foat
end
def position=(pos)
# slides to position pos in seconds, float
end
def format
# returns file format
end
def bitrate
# returns fil bitrate
end
def freq
# return file freq
end
def freq=(val)
# changes frequency to freq
end
def source
# returns stream source
end
def source=(src)
# changes file source and resets positon
end
def volume
# returns volume as float value from 0 to 1
end
def volume=(val)
# changes volume to val
end
def mode
# returns mode, 0 speaker, 1 phone speaker
end
def mode=(val)
# changes mode to val
end
def state
# returns 0 if not playing, 1 if playing, 2 if paused, 3 if error
end
def error
# returns 0 if no error occurred, error code otherwise
end
end
class Recorder
def self.permitted?
# returns true if so, false in other case
end
def self.request_permission
# requests recording permission, returns true if success
end
def initialize(filename)
# initializes recording
end
def error
# if any error occurred, returns its code, otherwise 0
end
def start
# starts recording
end
def stop
# stops recording and saves file
end
def pause
# pauses recording
end
def resume
# resumes recording
end
def duration
# recording duration in seconds, float value
end
def state
# returns 0 if ready, 1 if recording, 2 if paused, 3 if error
end
attr_accessor :format # file format, defaults to wav
attr_accessor :freq #recording frequency, defaults to 44100
attr_accessor :bitdepth # bit depth, defaults to 16
attr_accessor :bitrate # used if compression format selected, defaults to 96000
end
end
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#108

No i mamy to, tylko szkoda że ten Ruby, ale i tak dzięki.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb

#109 1 like

Jak coś, kompilujemy w NDK w wersji 23, Marshmallow.
Ta wersja natywnie obsługuje dekodowanie Opusa, więc odtwarzacz można napisać na native functions.
Recorder, zależy od poziomu skomplikowania. Jeśli trudny, ślemy w AAC jak na iOS, jeśli łatwo, implementujemy enkoder i lecim z tym po ludzku.

Ale, po kolei.
Priorytet to UI dla Androida.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#110

Nie jestem programistą więc nie wiem czy to się przyda ale uwaga na sposób otwierania mikrofonu w Andku. Nuno pewnie o tym wie ale nwszelki wypadek napiszę. Tam jest kilka scenariuszy użycia mikrofonu, które każdy producent interprietuje po swojemu tak więc jeden może sobie wymyślić, że tryb x będzie miał stereo, odszumarkę i coś jeszcze, inny stwierdzi, że najlepiej w tym trybie będzie mono ale bez żadnych dodatków. Najlepiej w opcjach dać mozliwość wyboru trybu, gdyż w przypadku różnych modeli telefonów te tryby óżnie działają.
jeszcze tak na koniec, OPUS zasadniczo funkcjonuje w 48000Hz więc na to też lepiej uważać. O ile wiem, Android odtwarza i nagrywa w OPUS bez problemów ale to nie jest informacja pewna.

#111 1 like

Tak, wiem @tomecki, mnie barziej przeraza mus nauczenia sie nowego frameworka w jezyku, ktorego wrecz nie znosze.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb

#112 1 like

Te tryby to: rear, back, Camcorder i Default.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb

#113 1 like

No, Nuno, to bierz się do pracy...
Albo się nie bierz.
Ja niestety tak jak zapowiadałem, do jednego programu nie będę się uczył nowego języka, bo i tak zawalam wszystko z góry na dół, jak tylko to możliwe.

#114

Chyba niekoniecznie, tj. to jest chyba starsze api. Teraz jest coś jak communication, raw, cam, default, call i chyba coś tam jeszce.

#115

Po drodze było jeszcze default, cam, mic, voice i call.

#116

Cyt DP:
Jeśli np. klient mobilny pisany będzie w JS, wystarczy jedno niedoparsowanie, by umożliwić bardzo poważne ataki poprzez XSS.
GZ: Mój ulubiony argument, chociaż trudno mi sobie wyobrazić, na czym te poważne ataki XSS w przypadku Eltena mogłyby polegać.
Idąc tym torem rozumowania: starczy jedna literówka w Linuxowym poleceniu DD, żeby sobie skasować zawartość dysku, więc lepiej nie używać Linuxa.
Starczy przypadkowy średnik przed słowem where w zapytaniu SQL, żeby cała baza poszła w kosmos, więc najlepiej nie używać SQL.
Wniosek: chłopaki, zamykamy internety.
Cyt DP: Klient JSON o tyle jest problemem wydajnościowym, że mnożą się zapytania do serwera. Elten nie jest Googlem ...
GZ: nie mitologizujmy tej wydajności, bo ani JSON nie wpłynie na wydajność w porównaniu do serializowania zmiennych w Rubym o czym pisałeś gdzie indziej, a nawet najlepiej napisaną stroną w starym stylu można zastrzelić serwer, jeśli się go będzie odpytywać odpowiednio często.
Zresztą tutaj przygotowanie odpowiedzi w JSON jest mniej zasobożerne niż przygotowanie jej w HTML z całą resztą bałaganu czyli kodu pełnej konkretnej podstrony.
Jak pokazuje przykład z niedawno rozwiązanymi problemami z "co nowego", to co ma wpływ na wydajność, to struktura bazy danych, konstrukcja zapytań SQL i ewentualnie konfiguracja buforów silnika bazodanowego.
Jeśli szybkim strzałem skróciliśmy zapytanie z dwóch minut do kilku dziesiątych sekundy, to szukanie optymalizacji wydajnościowych w formacie odpowiedzi jest przysłowiowym przecedzaniem komara, a przepuszczaniem wielbłąda.
Przy okazji, podtrzymuję wcześniejszą deklarację, że mógłbym pomóc w sprawie optymalizacji bazodanowych, a jak na razie nie dostałem schematu bazy którego na githubie też nie ma.
Ale nie frustruję się tym faktem, a idąc za radą, której parę wpisów wcześniej udzieliłem bardziej nerwowym kolegom, po prostu zająłem się innymi sprawami w wolnym czasie.

#117 1 like

Ojj co do XSS się nie zgodzę. Jedni używają Eltena jako ciekawostki, inni bardzo poważnie.
Luka XSS mogłaby pozwolić chociażby zabrać całą bazę wiadomości, pozwolić się pod kogoś potrzyć itp. Nie, nie bagatelizowałbym tego.
Oczywiście, w dobrze napisanym kliencie nie powinno być luk XSS. Ale nawet najmniejsza mogłaby być poważna, więc tym bardziej boję się, by takiego klienta pisał ktoś bez doświadczenia.
Co do serializacji w Rubym i JSONie, nie chodziło mi o czas serializacji/deserializacji tylko o wielkość danych.
Przy bardziej złożonych tablicach haszów i podobnych Marshal Rubiowski generuje dużo, dużo mniejsze dane od JSONa.
Co do bazy danych, dziękuję za przypomnienie się, umknęło mi to. Jeśli chwilkę znajdę, zajmę się tym w weekend.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#118

GZ: a czy przykłady z Linux i SQL które podałem, są bagatelne? Przecież wprost przeciwnie.
Cyt DP: więc tym bardziej boję się, by takiego klienta pisał ktoś bez doświadczenia.
GZ: no i to zmienia postać rzeczy, tylko jak się powiedziało A., to trzeba powiedzieć B.
Jeśli będzie otwarte API, to klienty w dowolnych językach o dowolnym stopniu zapluskwienia, będzie mógł tworzyć każdy niezależnie od doświadczenia, jakie posiada.
A zatem trzeba, żeby tego uniknąć:
1. Usunąć Elten z githuba.
2. Stworzyć własny sposób transmisji między serwerem i klientami, najlepiej bazujący na jakimś własnym zamkniętoźródłowym pomyśle, żeby ktoś nie rozpracował sposobu komunikacji z i do serwera.
3. Odetchnąć z ulgą, bo jeśli będą jakieś pluskwy w kodzie, to tylko autora.
I tą samą jedynie słuszną drogą powinni iść twórcy wszelkich serwisów, udostępniających cokolwiek na otwartych źródłach, a już tym bardziej otwarte API.
Jacyś wybitnie nieuświadomieni w tych serwisach siedzą, że sobie nie potrafili wyobrazić, że każdy może zrobić na ich API zapluskwionego klienta z podatnościami XSS lub innymi, co będzie miało opłakane skutki dla używających tego klienta milionów użytkowników.
Z tym rubiowskim marshalem to nie wiem co to znaczy dużo, czyli o jakich realnie wartościach i oszczędnościach mówimy, podejrzewam, że Google protobuf byłoby bardziej wydajniejsze może, ale nikt w zasadzie tego nawet nie zauważy.
A skoro światowym defacto standardem się stał JSON, to można robić jakieś swoje, ale prócz mniejszej kompatybilności niewiele zyskujemy: parsowanie JSON ma każdy język, a o Rubiowskim marshalowaniu nawet nie słyszałem do dzisiaj i pewnie już długo nie usłyszę.

#119 1 like

Nie do końca się rozumiemy. Ja nikomu nie zabronię stworzenia klienta Eltena niezależnego. Ja się sprzeciwiłem powstaniu klienta Eltena na Androida obecnie.
Dlaczego? Dlatego, że to nie będzie jakiś tam mniejszy projekt, tylko pierwszy projekt, który zainteresuje dziesiątki albo setki osób.
I błąd w takim projekcie oznaczałby prawdopodobnie ryzyko dla setek użytkowników, którzy nawet nie zrozumieliby, co oznacza pojęcie klienta nieoficjalnego.
W późniejszym czasie sprawa wygląda inaczej oczywiście.
Choć, szczerze, zablokowanie dostępu do serwera dla zewnętrznych klientów byłoby dużo, dużo prostsze, a wystarczy tu np. kryptografia asymetryczna.
Co do marshalingu Rubiowskiego, nigdy nie rozważałem go jako jedynej opcji komunikacji, to mija się z celem.
Ale, pisząc stronę w Rubym, można tak minimalnie zwiększyć przepustowość, ustawiając możliwość zwrócenia danych jako Marshal poprzez np. odpowiedni nagłówek. Feature, a nie must.
#StandWithUkraine

Shoot for the Moon. Even if you miss, you'll land among the stars.

#120

No dobra, bo zabrnęliśmy w dygresję. Nie wiem co ma klient Androidowy do podatności XSS, a z Marshallem rubiowskim to i tak hipoteza była w jednym z wcześniejszych wpisów, niemożliwa do zrealizowania, żeby wszystko robić w Rubym.