Wątek: Kod aplikacji mobilnej

Strona: 3 z 4

41 z 62: zywek

Hehehe...
Nie jest tak duża wada...
Kto kupi maca tylko po to, by programować eltena?
A czytałem sobie wczoraj te rubymotion i nawet nie jest durne... No ale i tak nic nie zrobię, bo nie mam jak testować, a od SkyDarka Maca brać nie zamierzam, bo programowanie wymaga czasu, a dźwiękowa realizacja dźwięku też wymaga czasu i maca, więc... NO cóż.


09.02.2019 12:09

42 z 62: pajper

Nie jest to duża wada nie ze względu na to, że Mac nie jest problemem, a ze względu raczej takiego, że i tak iOS go wymaga. I to nie tylko w Rubymotion, a w każdej technologii. Nawet Xamarina nie da się dla iOS bez Maca zrobić.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
09.02.2019 12:25

43 z 62: zywek

Ja nie chcę dla iOS! Przypominam, że nie mam iPhona, bo się go pozbyłem. CO więc w takiej sytuacji, potencjalny programista, półprogramista czy coś tam ma zrobić?


09.02.2019 12:35

44 z 62: pajper

Wiem, że nie chcesz na iOS, tłumaczę tylko szlak podejmowania decyzji o tej technologii. Obecnie? Niewiele, niestety.
Można programować na ślepo, ale sam wiem, jak bardzo to niewygodne. To znaczy możesz napisać kod i go PR'nąć, a ja poprawię błędy, ale... No wiem.
Możesz też zainstalować wirtualną maszynę z Macem. Wiele więcej nie wymyślimy.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
09.02.2019 12:37

45 z 62: zywek

Hm, troche trudno będzie tak pisać bez możliwości sprawdzenia...
I coś mi się wydaje, tak jeśli chodzi o to rubymotion, że wystarczy większość kodu z iOSa przewalić do androida i tylko te rzeczy, które bezpośrednio siedzą w systemie, jak dostęp do dźwięku itd przepisać, przynajmniej z tego co widziałem gdzieś tam w tym wstępie. No chyba, że się myle.


09.02.2019 12:49

46 z 62: pajper

Tak, dokładnie. Dlatego jakieś 95 procent kodu będzie wspólne.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
09.02.2019 13:01

47 z 62: zywek

Ehh, ale to i tak nie jest to, co chcieliśmy uzyskać. BO i tak za każdą nową zmianą będziesz musiał je osobno wprowadzać do klientów, zamiast rozwiązać to w podobny sposób, co próbujemy w Eltenie na desktopy.


09.02.2019 13:21

48 z 62: pajper

Wcale nie. Zobacz sobie, jak ten kod jest napisany. On się odnosi do wspólnych funkcji, wystarczy te funkcje napisać.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
09.02.2019 13:42

49 z 62: zywek

ALe masz osobne katalogi do osobnych systemów i nieprawda, bo jak coś gdzieś zmienisz w funkcjach systemowych, to będziesz musiał zmieniać osobno dla każdego systemu. A chcieliśmy uzyskać wspólny rdzeń dla funkcji systemowych. A przynajmniej ja myślałem, że tak chciałeś. Więc... Nie wiem sam.


09.02.2019 16:13

50 z 62: mikolajholysz

A mnie zastanawia jedna rzecz. Widzę tam straszne połączenie kodu odpowiedzialnego za view z kodem odpowiedzialnym za komunikację z serwerem. Moja sugestia to rozdzielenie tego na 2, co by kod odpowiedzialny za komunikację mógł, prędzej czy później, trafić do desktopa.


w związku z przesiadką na Maca, prawie mnie tutaj nie ma. Inne sposoby kontaktu w wizytówce.
09.02.2019 17:14

51 z 62: pajper

@żywek
Wcale nie. Prócz odwołań do API popakowanych w klasy typu Player, Recorder, UI, wszystko będzie wspólne.

@mikolajholysz
Co masz na myśli?
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
09.02.2019 23:22

52 z 62: mikolajholysz

@pajper to mam na myśli, że ja dobry kod widzę tak.

Jest sobie, dla przykładu, klasa Message zawierająca sendera, recipienta, content_text, względnie jakieś audio attachments. Może mieć jakieś podstawowe metody zajmujące się np. dodawaniem nowego odbiorcy, treści audio, walidacją, czy jest poprawną wiadomością, względnie serializacją siebie do jakiegoś akceptowalnego przez API formatu, choć nad ostatnim to bym się akurat zastanawiał. Generalnie powinna być prościutką klasą, bardziej strukturą niż klasą, nie mającą zależności prawie. Do tego jakaś klasa typu MessagingService zawierająca metodę send przyjmująca wiadomość i wysyłająca ją do API. Można zrobić to po hamsku, ale w rubym by to przeszło, i połączyć te dwie, dając wiadomości metodę send. Jak tam kto woli, ja bym akurat rozdzielił.

Najważniejsze jednak, że kod odpowiedzialny za wyświetlanie listy wiadomości na ekranie nie powinien nic wiedzieć o tym, jak wiadomości są wysyłane. On powinien wywoływać send, koniec, kropka.

Taka architektura pozwoli przyszłościowo na przeniesienie kodu odpowiedzialnego sensus stricte za komunikację z API na Desktopa, albo po prostu spakowanie jako pakiet, w przypadku Ruby chyba Gem i użycie gdzie tylko chcesz. Fakt, view trzeba będzie przepisać, ale to i tak mniej kodu do utrzymania. Efekt będzie tego taki, że będzie można docelowo sprawić, że desktop i mobile będą z jednym api komunikować się jednym kodem, a różnić się będą tylko kodem od interfejsu. Obecny kod mieszający wszystko na raz jest absolutnie nie do przeniesienia na cokolwiek co nie jest twoją biblioteką do appek mobilnych.
Właśnie sobie uświadomiłem, że to, co mamy obecnie to tak na prawdę metoda na php, mieszanie html, sql i Bóg wie czego jeszcze zaś to, co ja proponuję, to prawie architektura model, view, controller, gdzie model określa, jak reprezentowany jest dany typ objektu, jakie ma reguły itp, controller zajmuje się wykonywaniem akcji typu dodaj, usuń, pobierz itp, zaś view wyświetla to, co dostał z controllera w sposób zależny od tego, na czym akurat działa. W ten sposób można, prawie nie tykając modelu i controllera przepisać view i łatwo przenieść kod na co tylko chcesz.

w związku z przesiadką na Maca, prawie mnie tutaj nie ma. Inne sposoby kontaktu w wizytówce.
10.02.2019 21:39

53 z 62: pajper

Jestem za. To wcale nie jest dużo roboty, prawdę mówiąc.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
10.02.2019 21:45

54 z 62: mikolajholysz

Ta robota zrobiona teraz będzie popłacać później
w związku z przesiadką na Maca, prawie mnie tutaj nie ma. Inne sposoby kontaktu w wizytówce.
10.02.2019 22:31

55 z 62: pajper

Wiem, dlatego też jestem za, po prostu nie myślałem o napisania mobilki w ten sposób. Ale można, czemu nie?
Kod będzie na pewno przejrzystszy.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
10.02.2019 22:33

56 z 62: mikolajholysz

Powinieneś sobie przeczytać kiedyś, w wolnej chwili, "Clean Code" Roberta Martina. Jeżeli jest jedna książka, którą każdy deweloper przeczytać powinien, to jest właśnie ta książka. Gość pisze w Javie, ale znając w minimalnym chociaż stopniu ten język przykłady zrozumiesz, a to, o czym pisze, nie tyczy się Javy bezpośrednio a programowania w języku jakimkolwiek, objektowym zwłaszcza. Na "clean architecture" tego samego autora też możesz zerknąć, znacznie mniej dostępna, bo dużo diagramów itp, ale i tak warta uwagi.

w związku z przesiadką na Maca, prawie mnie tutaj nie ma. Inne sposoby kontaktu w wizytówce.
11.02.2019 18:23

57 z 62: pajper

Znam założenia MVC, nie rozważałem ich w kontekście mobilki, jakoś do głowy mi to nie przyszło o tyle, że duża część mobilki to copy-paste desktopu, gdzie o MVC pisząc pierwsze wersje nie słyszałem. Ale, ma taka polityka i swoje wady, choć akurat w wypadku takiej wieloplatformowości więcej zalet.
Szczególnie, że Ruby kompiluje się do Web Assembly, co oznacza, że w wypadku nowej strony Internetowej można to skompilować i wywołać prosto z JavaScriptu.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
11.02.2019 18:27

58 z 62: mikolajholysz

Na to bym nie wpadł. Swoją drogą ciekawe, jak w wasm wygląda sprawa z requestami http, czy ich moduł jest kompatybilny) ale w sumie... czemu nie?


w związku z przesiadką na Maca, prawie mnie tutaj nie ma. Inne sposoby kontaktu w wizytówce.
11.02.2019 21:07

59 z 62: pajper

Uwaga!
Kilka uwag odnośnie nowej wersji systemu MacOS - Cataline.

Przede wszystkim z systemu, niestety, usuwane są środowiska uruchomieniowe. Przyznam, że nie rozumiem do końca decyzji Apple, bo tym samym sztucznie powiększane są rozmiary nawet natywnych programów, ale... Ich decyzja.
W efekcie Mac nie będzie posiadał od przyszłych wersji ani Rubiego, ani Pythona, ani Perla - będą one dołączone jednak do xCode oraz dostępne do instalacji z Appstore.

Na chwilę obecną mamy wersję Ruby 2.6.1. Nie nadążyłem jeszcze z aktualizacją kodu Eltena, tak więc trzeba wykorzystać rbenv do przełączenia Rubiego na poprzednią wersję, używam 2.3.7, ale z powodzeniem kompilowałem także pod 2.5.1.

W nowej wersji xCode narzędzia terminalowe nie są domyślnie instalowane, trzeba to zrobić ręcznie z menu narzędzi. Bez nich makefile kodu nie zadziała, a więc trzeba pamiętać, by o to zadbać.

I najważniejsze. Kompilator Objective C ma problem z wielowątkowaniem i jednoczesną budową plików wykorzystujących te same funkcje. Nie, nie wiem, o co chodzi, już problem jest na Apple Developer omawiany.
Na razie jedyną solucją jest wyłączenie ochrony wątków w OBJC. W efekcie mogą udawać się błędne kompilacje, ale... inaczej się po prostu nie da.
W terminalu:
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

Z pozdrowieniami,
DP

#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
11.07.2019 14:39

60 z 62: nuno69

Gratulacje dla waszego kochanego Apple.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb
11.07.2019 16:48