Wątek: Elten dla Androida - decyzja

Strona: 3 z 6

41 z 107: pajper

Nikt chętny się nie zgłosił. Jak pisałem, ja slużę wszelką pomocą, ale chętnych brak.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
18.03.2020 15:56

42 z 107: zywek

Ja też powiedziałem. Kupisz mi maca?

18.03.2020 20:42

43 z 107: pajper

I jaki sens powtarzanie się ma? Bo ja go nie widzę.
Albo przyznaj, że z takich czy innych przyczyn nie chcesz się zaangażować, do czego oczywiście każdy ma prawo, albo nie zarzucaj mi czegoś, bo robi sie to nudne.
Frameworków jest pełno i można użyć innego. Jest API JSON, chcesz pisać własną, niezależną appkę w innym języku? Także proszę bardzo.
--Cytat (pajper):
Zrobiłem research.
Ja zdecydowałem się na framework Rubymotion, bo działa i na Androidzie, i iOS. Oczywiście składnia dla tych platform jest różna.
Ale wystarczy wrzucić w Google ruby android, a już na pierwszej stronie wyników wyszukiwani mamy prócz Rubymotion projekty Ruboto oraz jRuby - obydwa pozwalają kompilować Rubiego dla Androida.
Zważywszy na przenośność kodu, nie stoi nic na przeszkodzie, by wykorzystać jedną z nich. Oczywiście pracy będzie więcej, ale wciąż prawie cały kod można między platformami przenieść.
Przypominam tu także, że Elten Mobilny pisny jest w paradygmacie MVC.

--Koniec cytatu
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
18.03.2020 21:24

44 z 107: longshoot

a była by możliwość, żeby ktoś nie z polski się tym zajął, z niewidomej społeczności?

18.03.2020 21:31

45 z 107: pajper

Oczywiście, że tak. Projekt jest open-source.
Zaletą rozwijania go w Rubym na dowolnym Frameworku jest współdzielenie kodu, tj. znacznie mniej pracy. Jeśli ktoś napisze tylko oskryptowanie EltenAPI dla Androida, automatycznie wszystkie nowości z iOS będą na niego trafiały.
Jeśli nie Ruby, to trzeba pisać wszystko i nadążać za każdą nową funkcją na bieżąco, a więc sporo więcej roboty. Ale można.
Jak ktoś chce pisać w Pascalu, droga wolna, o ile oczywiście istnieje jakikolwiek kompilator Pascala na Androida. :D
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
18.03.2020 21:35

46 z 107: longshoot

jest jakieś info na zagranicznych forach o wersji na androida, bo nie sprawdzałem.

18.03.2020 21:36

47 z 107: pajper

Jest, na angielskich i rosyjskich. Na razie brak chętnych.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
18.03.2020 21:36

48 z 107: daszekmdn

Ja tak tylko nieśmiało przypomnę: HM, Nuno kiedyś chciał, to mu się API zamknęło.

18.03.2020 23:14

49 z 107: pajper

Plotki i niedomówienia. Owszem, trwała tu kiedyś dyskusja na temat API i nieoficjalnych klientów. Zapomina się jednak, że ostatecznie na nie pozwoliłem. Ale potem już zainteresowania nie było...
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
19.03.2020 08:05

50 z 107: zywek

Jaasne, a ja też powtarzać się nie lubię, że nadal, pomimo pseudootwarcia, współpraca jest utrudniona.
I jakim niby prawem wszystkie nowości będą wyglądały tak samo, będą wprowadzane od razu do dwóch wersji, skoro sporo kodu z racji frameworku będzie zupełnie inne? Albo to są brednie, albo ja jestem debil.

19.03.2020 21:00

51 z 107: pajper

Istnieje spore prawdopodobieństwo, że odpowiedzi na te pytania znajdziesz w repozytorium Eltena Mobile. I generalnie dyskusję jakąkolwiek należałoby zacząć od zrozumienia, czym jest model MVC, Framework Flow oraz zapoznania się z kodem Eltena Mobile oraz Eltena 2.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
19.03.2020 21:29

52 z 107: zywek

Baardzo zabawny jesteś.
Porównaj proszę bardzo, sobie te dwa frameworki. Twoje ukochane rubymotion i ruboto. Ciekawe gdzie Ty widzisz dla obu tych frameworków miejsce w jednym kodzie, niezależnie, czy używasz jakiegoś mvc, jakiegoś innego mvp czy czegoś innego, co tam było w tym ruboto wspomniane.

20.03.2020 10:00

53 z 107: pajper

Sory, ale ta dyskusja nie ma sensu. I tyle.
Nie chcesz, nie pomagaj. Nie mam żadnego prawa Ciebie zmuszać. Ale nie udawaj i nie mów czegoś, co nie jest prawdą.
Jak to się dzieje, że takie GTK czy inne QT potrafi być cross-platformowe, skoro Cocoa, X i WinAPI są tak różne? Bo tworzymy pewną warstwę abstrakcji.
W ten sam sposób można dowolne frameworki spiąć, także Ruboto i RubyMotion. W kodzie Eltena Mobile żadne funkcje prócz translatora abstrakcyjnego nie korzystają z funkcji RubyMotion. W ani jednym miejscu.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
20.03.2020 10:26

54 z 107: zywek

Żeby nie było, rozejrzałem się trochę. Życzę powodzenia w przepisywaniu całego interfejsu od zera. Co z tego, że jakieś tam rzeczy są wspólne, że korzystają z jakiegoś tam API, skoro to wszystko i tak trzeba będzie ręcznie poumieszczać w odpowiednich widokach, albo jak kto woli aktywnościach?
To to samo, co napisać wszystko od zera, czego robić nie zamierzam.
Co do struktury.
Jeśli już mamy katalog views, to chyba powinien wylądować w katalogu ios, bo androidowy i tak od zera trzeba napisać.

20.03.2020 15:05

55 z 107: pajper

Widzę, że albo nie zapoznałeś się, albo nie zrozumiałeś kodu. Postaram się więc wyjaśnić, czemu nie masz racji.
1. RubyMotion nie jest frameworkiem. Jest tylko nakładką pozwalającą kompilować kod w Rubym na iOS, używającą parsera do linkowania i odwołań do Cocoa Touch API.
Innymi słowy, jest, w uproszczeniu, portem czy bindingiem iOS API na Rubiego.
2. Nie dostarcza on żadnych frameworków czy własnych funkcji, wyłącznie bibliotekę natywną Rubiego, czyli RI i odpowiednie funkcje iOS.
3. Podobnie sprawa ma się przy Androidzie. Gdy RubyMotion kompiluje się do APK, używane są odwołania do Androidowego API.
4. Oznacza to, że tak naprawdę niewiele ma to wspólnego z (SIC) crossplatformowością, a raczej jest kompilatorem platform dependend.
5. Kod w RubyMotion napisany dla iOS nie będzie wcale zgodny z RubyMotion dla Androida, bo to zupełnie inne frameworki.
6. Bo jeśli o frameworkach mówimy, to jedyne, jakie można wskazać, to Cocoa Touch i Android JDK.
7. models, views, controllers nie są w żaden sposób zależny od platformy. Więc słusznie znajdują się, gdzie są.
Nie znajdziesz w nich, o ile czegoś nie przeoczyłem, ani jednego odwołania do API iOS.
8. Całe API iOS jest zmapowane do abstrakcyjnych klas interfejsu w folderze iOS. Tam się znajdują odpowiednie definicje kontrolek, obsługi sieci, dźwięku. Cała reszta kodu korzysta z funkcji zdefiniowanych w folderze iOS.
9. Przepisanie tych funkcji na Androida z zachowaniem tej samej konwencji namespace, niezależnie od frameworka czy platformy, umożliwi wieloplatformowe działanie wszystkiego innego, ponieważ nie polega ono na natywnym API, a abstrakcyjnej warstwie właśnie w tej części kodu zdefiniowanej.

Zasadniczo więc nie ma większej różnicy, czy używamy RubyMotion, czy innego kompilatora lub nawet innego języka, choć tu jest zabawa z linkerem.
Jedyny problem to fakt, że próbowałem importować do projektu biblioteki, które miały swoje porty na Androida i iOS i są zgodne z RM. Użycie innego kompilatora wymusi więc prawdopodobnie przeportowanie ich na Androida.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
20.03.2020 15:33

56 z 107: pajper

A tu przykładowy plik sound.rb . Jak widać, mapuje on obsługę dźwięku na iOS: odtwarzanie i nagrywanie. Tworzy interfejsy Player i Recorder, korzystając z natywnego AVFoundation i biblioteki OrigamiEngine.
Stworzenie identycznego pliku, w którym zamieni się odwołania do API iOS na Androidowe, przy zachowaniu tych samych nazw klas i funkcji, da nam wieloplatformowość i przeniesie całą obsługę dźwięku niezależnie od tego, czy jest ona w kodzie używana pięć, czy dwieście razy.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
20.03.2020 15:44

57 z 107: zywek

A ja się nadal będę kłócił. Konwencja nazewnicza funkcji, czy czegokolwiek innego, czym tworzysz ekrany różni się między Androidem i iOSem i nie mów mi, że tego nie zauwżyłeś, więc wcale nie wystarczy przepisać jedynie obsługi dźwięku i czegoś tam jeszcze, co wymieniłeś.

20.03.2020 16:01

58 z 107: pajper

Widzę, że nie próbujesz zrozumieć, więc ta dyskusja nie ma sensu.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
20.03.2020 16:07

59 z 107: zywek

Faktycznie, z takim podejściem to nie ma sensu. Po co mam się męczyć z przestarzałymi technologiami, które nie są rozwijane...
Życzę powodzenia w dalszym szukaniu kogoś, kto Cię zrozumie lepiej.

20.03.2020 16:15

60 z 107: longshoot

będzie trzeba będzie trzeba można to można ja umiesz to napisz, nawet jeśli technlologia przestarzała.

20.03.2020 16:17