Lazarus/Pascal i tworzenie oprogramowania dla systemu Android

Myślałem, że ten cały LAMW to tylko sztuka dla sztuki, ale okazuje się że jednak da się zrobić całkiem fajną aplikacje dla systemu Android, napisaną w Object Pascalu przy użyciu Lazarus Android Module Wizard:)

https://play.google.com/store/apps/details?id=swbcdx.cap.shortwavelist
Aplikacja całkiem nieźle działa i się prezentuje, nie tylko pokazuje częstotliwości radiostacji z całego świata ale je też odtwarza:)
Info, że to jest w Pascalu znalazłem na forum freepascal.org.
Ciekawe czy ktoś z Was próbował tworzyć w ten sposób aplikacje na androida? Mnie jak na razie nie chciało się bawić :(

Przymierzam się żeby ugryźć temat ale widziałem, że trzeba robić cuda ze środowiskiem więc póki co zrezygnowałem ;)

Dla mnie wszelkie problemy związane z budowaniem aplikacja na inne platformy (na inne niż ta, na której uruchomione jest IDE) nie powinny w ogóle istnieć. Nie powinno być tak, że muszę cuda na kiju uprawiać, żeby zbudować aplikację np. na Androida z poziomu Win32. Jeśli – ogólnie pisząc – środowisko pozwala tworzyć programy na wiele platform, ale nie mogę tej platformy wybrać i projektu skompilować bo dostaję błędy, to takie narzędzie jest wybrakowane. No i jest wybrakowane – niby mogę zbudować apkę na inną platformę, ale nie mogę.

Lazarus powinien być dostarczany z kompletem kompilatorów i konfiguracji dla wszystkich wspieranych jako target platform. Wszystkie od razu gotowe do użycia, a wybór docelowej platformy powinien być równoważny z wybraniem odpowiedniej pozycji np. w combobox w oknie ustawień projektu. Wszelkie prace związane z dociąganiem kompilatorów, ich budowaniem, konfiguracją ścieżek i ogólnie ręcznym edytowaniem konfigów itd. to marnotrastwo czasu programisty.

Lazarus powinien być dostarczany z kompletem kompilatorów[...] wybór docelowej platformy powinien równoważny z wybraniem odpowiedniej pozycji np. w combobox w oknie ustawień projektu

Trochę cierpliwości, jeszcze z 12-15 lat i do tego pewnie dojdzie ;)

@cerrato: na szczęście póki co nie mam parcia na tworzenie oprogramowania na inne platformy niż desktopowy Windows, więc mogę poczekać. Swoją drogą, skoro już tyle platform ma wsparcie, to przydałoby się dodać do zestawu takie perełki jak NES i SNES – tym bradziej że GameBoy Advance jest już obsługiwany. :]

A co znaczy, że gameboy jest obsługiwany? Czy polega to na tym, że FPC jest w stanie stworzyć na niego binarki, czy może jakaś część LCL została na niego portowana?

cerrato napisał(a):

A co znaczy, że gameboy jest obsługiwany?

FPC potrafi kompilować binarki dedykowane tej platformie (czyli gry), dodatkowe narzędzia też są. Ale póki co wsparcie nie jest imponujące, artykułów jak na lekarstwo (w dodatku wiele niedokończonych), no i najpierw trzeba się babrać w budowanie kompilatora, więc może nie być łatwo… :/

W razie czego poczytaj krótki artykuł GameBoy Advance we wiki – nakreśli Ci to sprawę.

Od dawna rozmyślam na temat stworzenia dużego i funkcjonalnego IDE do robienia gier na platformę NES, z własnym, prostym językiem programowania (ze składnią wzorowanym na Lua). Środowiska wyposażonego we wszystko co jest potrzebne do budowy kompletnej gry, czyli w edytor kodu, edytor palet kolorów, sprajtów i map, a także edytor dźwięku i całych utworów (pokroju FamiTracker).

Mam już jakieś doświadczenie jeśli chodzi o pisanie komponentów, w tym komponentów będących edytorami, więc nie byłoby żadnego problemu ze stworzeniem wygodnego i funkcjonalnego interfejsu. Przy czym żadnych konsolowych i konfiguracyjnych pierdół – wszystkie opcje do szybkiego wyklikania, tak aby maksymalnie ułatwić i przyspieszyć pracę.

Jednak aby zabrać się za taki projekt, potrzebowałbym masy czasu na naukę, projektowanie i pisanie (dwa, może trzy lata), a także dofinansowania (np. solidnej zbiórki w którymś z serwisów crowdfundingowych), więc póki co ten projekt pozostanie w swerze marzeń. Może kiedyś…

http://itaprogaming.free.fr/index.php?x=p&pag=50

Tylko w sumie to jakoś przeskoczylismy z lazarusa na "gołego" FPC. Po przejrzeniu linku od ciebie (oraz tego wklejonego powyżej) mam mocne wrażenie, że pisanie kodu dla gameboya przypomina obsługę trybu graficznego w Turbo Pascalu :D

cerrato napisał(a):

Po przejrzeniu linku od ciebie (oraz tego wklejonego powyżej) mam mocne wrażenie, że pisanie kodu dla gameboya przypomina obsługę trybu graficznego w Turbo Pascalu :D

A to źle? Obsługa trybu graficznego w TP była tak prosta jak malowanie po PaintBox z LCL. Zawsze lepiej jest skorzystać z czytelnych, wysokopoziomowych instrukcji, niż rzeźbić w assembly. ;)

Nie napisałem, że to źle tylko zwyczajnie się zdziwiłem. Po prostu - ten wątek zaczął się i dotyczy Lazarusa, więc w zakresie gameboya liczyłem na coś innego ;)

furious programming napisał(a):

A to źle? Obsługa trybu graficznego w TP była tak prosta jak malowanie po PaintBox z LCL. Zawsze lepiej jest skorzystać z czytelnych, wysokopoziomowych instrukcji, niż rzeźbić w assembly. ;)

Jednak z tego co pamiętam wbudowanu unit graph był dość powolny, zwłaszcza w „wyższych” rozdzielczościach (czyli np. 640x480).
Dostępne były różne alternatywne rozwiązania, szybsze.

Aplikacja randkowa(!) w Delphi ;-)

Apka ładna i schludna, a że w Delphi? TO nie ma żadnego znaczenia. Można ją zrobić w czymś darmowym i uzyskać ten sam efekt. Dodatkowo taki rodzaj aplikacji musi mieć solidny backend serwerowy, a my tutaj widzimy tak naprawdę możliwości GUI. Podsumowując cieszę się, że ktoś się bawi tym, ja bym sam w to nie szedł.

Jakie przykładowe problemy napotkaliście podczas developmentu w Firemonkey ? Jak je obeszliście ? Czy w kontekście zdobytych doświadczeń rozważylibyście Firemonkey do kolejnej aplikacji pisanej od 0 ? Pytam, bo jestem zainteresowany tą technologią.

Ja po zrobieniu swojej pierwszej apki na Androida, zauważyłem, że podczas przewijania palcem scrollboxa uruchamiam akcje spod przycisków znajdujących się na tym scrollboxie. Okazało się, że jak dam zdarzenie OnClick, tak właśnie się dzieje. Trzeba używać OnTap :) Szkoda, że OnClick nie jest uniwersalne dla różnych platform i działa prawidłowo tylko w zakresie klikania/przyciskania, ale już źle dla przewijania itp.
Drugi problem napotkałem z TEdit, gdy dałem w nim element TClearEditButton (czyli znak X po prawej stronie pola, służący do wyczyszczenia pola), to po jego naciśnięciu apka się wykrzaczała z jakimś błędem. Było to wersji 10.3.0 lub 10.3.1 (już nie pamiętam). Nie sprawdzałem czy tak samo jest w najnowszej 10.3.2.

Ale co to ma wspólnego z tematem tego wątku, czyli z tworzeniem aplikacji dla Androida w Lazarusie…? :/

Jeśli chcecie podyskutować o tworzeniu programów w Delphi to załóżcie osobny wątek.

XailonOZ napisał(a):

Jakie przykładowe problemy napotkaliście podczas developmentu w Firemonkey ? Jak je obeszliście ? Czy w kontekście zdobytych doświadczeń rozważylibyście Firemonkey do kolejnej aplikacji pisanej od 0 ? Pytam, bo jestem zainteresowany tą technologią.

1. Start aplikacji przy dużej ilość widoków - trzeba pamiętać aby ze startu usunąć wszystko zostawiając jeden ekran robiący za splash screen z ładną animacją (nie, nie używamy statycznego obrazka, który standardowo jest dla iOS i Android), reszta widoków to już lazy creation. Apka startuje błyskawicznie (iOS + Android), a poszczególne widoki na zawołanie zwykle poniżej 0,6 s. (oczywiście zależy też od tego jak ciężki widok zbudowaliśmy i czy w OnCreate nie ma jakiegoś potworka).

2. Brak płynnych animacji, zacinanie się widoków np. jeśli scroll-box ma po 10 i więcej elementów, nie będzie się płynnie przesuwał, dlatego że każdy element jest rysowany ponownie podczas przesuwania, czyli jedna klatka i repaint wszystkich elementów, płynna animacja nie jest możliwa w FMX by design (brzmi kozacko!). Należy własnoręcznie zaimplementować cache dla widoków, żeby podczas przesuwania nie przerysowywać milion razy wszystkich elementów.

3. TAniIndicator - zło straszne, potrafi wywalać apkę. Zamiast tego używamy TBitmapListAnimation dla naszych własnych wskaźników zajętości. Działa pięknie.

skrzat napisał(a):

Drugi problem napotkałem z TEdit, gdy dałem w nim element TClearEditButton (czyli znak X po prawej stronie pola, służący do wyczyszczenia pola), to po jego naciśnięciu apka się wykrzaczała z jakimś błędem. Było to wersji 10.3.0 lub 10.3.1 (już nie pamiętam). Nie sprawdzałem czy tak samo jest w najnowszej 10.3.2.

Ja do TEdit po prostu dostawiam własnego "X-a" i rzucam akcję typu Edit.Text:=''; działa zawsze :) Generalnie, w FMX sprawdza się zasada, im prościej tym lepiej, jak się da, nie używać komponentów, tylko ręcznie wyklepać itp. itd. No i używać asynchronów, a nie wszystko pakować do głównego wątku :)

Jak znajdę czas to wrzucę jakiś artykuł o FMX i doświadczeniach z tym tworem. Flutter nieststy lepszy, ale dla fanów Delphi zostaje jeszcze FGX, którego będę także testował, może być ciekawie :)