Apki – dlaczego tak, a nie inaczej

Opublikowano przez

Najfajniejsze są takie posty, które sam nie wiem jak się skończą 🙂 Zacząłem pisać z jednym wyborem, a skończyłem z innym. To tylko dowodzi, że warto sobie wypisać za i przeciw, i na spokojnie rozważać takie decyzje.

Wiadomo, że głównie chciałbym robić gry. Jednak sporo różnych programów w życiu napisałem i czasem coś się przyklei do głowy i nie chce odkleić. Czasem wkurza mnie to co jest, czasem inni marudzą – np. o apkę do VINów Land Roverów, czy apkę do liczenia kół zębatych i ustawiania obwiedniówki.

Wypada więc podciągnąć się trochę z robienia apek i cośtam opublikować.

Opcje

W tym momencie liczą się tylko dwie platformy: iOS i Android.

Za Androidem stoi popularność i masa sprzętu za każde pieniądze.

Za iOS kasa (userzy bardziej przyzwyczajeni do płacenia) i to że sam używam 😀

No dobra, ale jak i w czym te apki można pisać?

Mamy dwie główne drogi:

1. Aplikacje natywne

Czyli apki napisane w tym, w czym sobie życzy właściciel platformy. Dla iOS to będzie pisanie w Swifcie pod XCode. Dla Androida to będzie Kotlin albo Java i pod Android Studio. Upraszczając oczywiście, bo są różne opcje – nie zamierzam jednak jakoś mocno kombinować – ma być prosto i w miarę standardowo.

Zalety

  • wydajność – nie ma żadnej warstwy pośredniej więc taka apka jest szybka
  • pełna obsługa funkcji wbudowanych – wszystkie sensory, pushe, widgety, today extensiony, ju-nejm-yty
  • UI i UX dostosowane do systemu operacyjnego – korzystam z tych samych kontrolek co twórcy systemu
  • łatwiejsze debugowanie – w 99.99% przypadków błąd będzie po mojej stronie i łatwy do wyłapania – a nie ukryty gdzieś w warstwach pośrednich
  • języki – Swift i Kotlin są seksi – nowoczesne, dynamicznie rozwijające się, z mocnym wsparciem sporych graczy
  • massa tutoriali, książek i kursów, stackoverflow pełen pomocnej wiedzy
  • można za darmo – jeżeli mam kupione konta developerskie to żadnych opłat i abonamentów – odpalam, piszę program i publikuję

Wady

Trzeba robić dwa projekty. Swift i Kotlin są do siebie dosyć podobne, ale to tyle. Budowanie GUI, obsługa sensorów i samo IDE jest inne. Nie ma się co czarować – to jest praktycznie drugie tyle roboty. Za tym idzie większa ilość czasu potrzebnego na napisanie i potem utrzymanie obu wersji. A czas to cenny zasób.

2. Aplikacje hybrydowe

Tu mamy różne wynalazki, począwszy od zwykłych kontrolek wyświetlających HTML obudowanych w apkę, a kończąc na React Native i Xamarin gdzie kod napisany w JavaScripcie lub C# jest konwertowany na natywny kod dla danej platformy.

Zalety

  • mniejszy nakład czasowy – bo z jednego źródła eksportuję na obie platformy (i często mogę jeszcze wyrzucić na WWW)
  • w miarę proste narzędzia – najczęściej hybrydy pisze się w JavaScripcie. Do tego CSS i jakieś HTML albo HTMLopodobne szablony. Mógłbym sobie cisnąć w Emacsie.

Wady

  • generalnie są wolniejsze – czarują, poprawiają, ale raczej będzie wolniej
  • JavaScript się mocno zmienia – to niby dobrze, ale trzeba strasznie gonić za peletonem. A to czas.
  • nierówna obsługa funkcji wbudowanych – często jakaś funkcja systemu docelowego nie jest obsługiwana w jednym frameworku, a druga w innym. To może ciągnąć za sobą konieczność opanowania kilku. A to czas.
  • UI i UX mniej lub bardziej różniące się od systemu
  • zależność od 'firmy’ trzeciej – zawsze lekki poślizg z nowościami, jeżeli czegoś nie ma to trzeba se dopisać natywny kawałek, albo poczekać.
  • dodatkowa warstwa – błędy mogą się chować albo w programie, albo w warstwie pośredniej. I koniec, końców okazuje się, że dobrze jednak znać jedną i drugą platformę docelową i jej IDE, bo trzeba za błędem pogonić, albo zmodyfikować jakąś bibliotekę, albo poprawić opcje kompilacji.
  • często początek jest za darmo, ale potem „to tylko z abonamentem, tamto tylko z abonamentem, tu się zarejestruj, tam wyślij kod”

Kontekst

Czas – najgorszy zasób – zawsze go mało.

„Programistość” – trudno to ująć w słowa. Trochę to zahacza o „prawdziwi programiści to…” ale nie czuję się komfortowo lepiąc takie patchworki/potworki z Javascriptu, HTMLa, CSSów, śliny i gliny.

Mocny kandydat

Ionic – w sumie to nadal nie jestem w 100% przekonany, czy nie robić tego w Ionicu. Mam spore doświadczenie w dłubaniu aplikacji webowych – HTML, CSS, JavaScript – przerabiam to od 20 lat i nie boję się żadnych wynalazków na nich opartych. W Ionicu cośtam nawet poskładałem kiedyś i działało. Generalnie to byłby dla mnie rozsądny wybór TM.

Ale to jest straszna nuda 😀

No i Ionic mocno się wyłożył tym, że nie da się łatwo zrobić widgeta pod Androida i today extension pod iOS – a połowa z apek które mi chodzą po głowie wymaga akurat tych funkcjonalności.

Wybór i powody

Na dzień dzisiejszy (znaczy na ten rok) wybieram apki natywne.

Daję ciała z czasem i Emacsem (bo raczej trzeba się trzymać właściwych IDE (ale jeszcze zobaczymy :D)).

Na swoją obronę mam to, że zaplanowane apki są proste – na tyle proste, że napisanie ich 'dwa razy’ to nie jest większy problem. A większe otrzaskanie z XCode i Android Studio i ich profilerami/debuggerami powinno procentować przy budowaniu Unitowych gierek. Znowu dobra znajomość Kotlina i Swifta pozwoli dłubać w Unitowych pluginach i ew. pisać własne. Zostają natywne.

Zabawki wybrane. Mam nadzieję, że w przyszłym tygodniu już wysmaruję coś konkretnego, coś z czego da się „kopypastnąć” jakiś kod, bo za dużo juz tych dywagacji – apki i gry się same nie napiszą 🙂