Apki – dlaczego tak, a nie inaczej
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ą 🙂
Najnowsze komentarze