Aplikacja iOS/Android jako strona mobilna

0

Pytanie kieruję do programistów aplikacji mobilnych.

Gdzieś obiło mi się o oczy (chyba nawet na forum), że często jakieś w miarę proste aplikacje w sklepach są w zasadzie stronami - po otworzeniu otwiera się widok mobilny w kontrolce(?). Chciałem dopytać o jakieś większe szczegóły takich rozwiązań. Aplikacja pisana byłaby prawdopodobnie w React Native. A to co chciałbym wiedzieć na temat takiego wytwarzania:

  • Plusy
  • Minusy
  • Wszelkie ograniczenia, które można napotkać
  • Jak ugryźć ten temat

Jeżeli coś pokręciłem to proszę o naprostowanie mojej pokrętnej logiki. Potrzebujemy po prostu w miarę szybko dostarczyć aplikację jak najmniejszym nakładem pracy.
Dzięki.

3

Trochę jest tutaj namieszanych pojęć. Chodzi Ci o aplikacje ściągane bezpośrednio ze sklepu Googla albo Appla? Jeśli tak, to jedyna powszechna technologia, której tutaj się używa to Cordova. Ze wszystkich wieloplatformowych technologii jakie znam, to z tą jest najwięcej problemów.

  • Cordova (dawniej PhoneGap) - Platforma do pisania aplikacji, które są odpalane w natywnym komponencie (WebView) do wyświetlania zawartości HTML. Popularny framework zbudowany na bazie Cordovy to Ionic. Początkowo Ionic był mocno związany z Angularem. Teraz, z tego co wiem, jest możliwość budowania UI korzystając już z większej ilość frameworków (Angular, React, Vue).

  • PWA - Są to aplikacje stricte webowe, które zachowują się jak natywne, ale są odpalane w przeglądarce. Do niedawna były dostępne tylko w ten sposób, że wchodziłeś na jakąś stronę przez przeglądarkę, dodawałeś skrót do strony na ekranie startowym i zachowywało się to jak aplikacja natywna. W tym roku Google pozwolił na dodawanie aplikacji PWA do sklepu. Apple jeszcze na to nie pozwala (o ile w ogóle pozwoli). Taką aplikację piszesz w jakiejkolwiek technologi webowej.

  • React Native - Framework, które ma wyglądać, zachowywać się i działać jak React, ale być pod spodem zbudowanym z natywnych komponentów danej platformy. Działa to w ten sposób, że React Native odpala się na silniku JavaScriptCore i rozmawia z platformą, dba o główny wątek itp. Zaletą jest to, że faktycznie można dzielić kod Reacta z React Nativem i mieć jednocześnie natywną aplikację. Nie powiem dokładnie ile procent kodu można współdzielić. Znajomi i artykuły, które czytałem, podawali liczby w zakresie od 70 do 100 procent zależnie od aplikacji. Z tym że RN nie jest stroną mobilną, jeśli tego koniecznie potrzebujecie.

Wady, zalety, itp.? Ciężko mi konkretnie poradzić bez wiedzy, co aplikacja ma robić, kto miałby ją pisać i dla kogo miałaby być pisana. Na pewno unikałbym Cordovy jak ognia, bo widziałem za dużo z nią związanych problemów. Pytanie czy koniecznie potrzebujecie aplikacji jako strony mobilnej czy hybrydowego rozwiązania? Czy chodzi tylko o dzielnie kodu między mobilkami czy też między mobilkami i webem?

0

Dzięki za wyjaśnienie do tej pory ;-)

Pytanie czy koniecznie potrzebujecie aplikacji jako strony mobilnej czy hybrydowego rozwiązania? Czy chodzi tylko o dzielnie kodu między mobilkami czy też między mobilkami i webem?

Budujemy projekt, który w większości będzie obsługiwany przez smartfony. Będzie do tej oczywiście wersja desktop natomiast trzeba skupić się od strony urządzeń przenośnych. Szkoda nam tracić czas, i energię na pisanie jakiegoś natywnego rozwiązania zwłaszcza, że potrzeba obsłużyć obie platformy.
Zastanawiam się więc czy można jakoś dać użytkownikowi wersję mobilną strony spakowaną w postaci aplikacji na jego urządzeniu. Odpada wtedy konieczność wchodzenia na stronę przez przeglądarkę, i gdy aplikacja jest w systemie pod ręką to szanse na to, że ktoś z niej skorzysta znacznie wzrastają niż w momencie kiedy musi pamiętać, że na stronie X może dostać coś czego szuka. Wiem, że piszę jak typowy noob ale z aplikacjami mobilnymi mam tyle wspólnego co z PHP :-)
Odwzorowanie wersji mobilnej vs aplikacja może być nawet 1 - 1. Chodzi o nie zmuszanie użytkownika do ciągłego wchodzenia na stronę żeby mieć dostęp do przygotowanych dla niego informacji.

Możliwe, że aplikacja hybrydowa jest tutaj jakimś rozwiązaniem. Projekt nie żre zasobów. Tak na dobrą sprawę jedyne jego zadanie to pobieranie informacji, push do usera jeżeli zostanie spełniony jakiś warunek (zewnętrzna usługa) oraz możliwość zakupienia wybranego/wyszukanego przez siebie produktu.

1

Zwykłą stronę możesz zrobić PWA+powiadomienia push+dostęp do strony offline, jeśli to nie wystarczy to wyżej jak pisze Michał.

0

Jeżeli macie już (będziecie mieli) wersję apki na desktopa to bardzo rozważyłbym przerobienie jej na PWA. Prawdopodobnie byłoby to najszybsze i najłatwiejsze rozwiązanie w utrzymaniu. Będzie lekka upierdliwość, że użytkownicy iPhonów musieliby ręcznie dodać skrót z przeglądarki, ale po tym aplikacja zachowywałaby się jak natywna. Jeśli to jest zbyt kluczowe, to pewnie zrobiłbym RN albo (choć otwiera mi się nóż w kieszeni) Flutter. Mimo że za Flutterem nie przepadam, to wiem, że szybko można uzyskać zadowalające wyniki, jeśli aplikacja jest prosta. Znam przypadki ludzi, którzy nie programując wcześniej w ogóle albo mało wypuścili zarabiające na siebie aplikacje po kilku miesiącach.

0

Też jestem kompletnie zielony w tym temacie, ale chciałbym zadać pytanie od drugiej strony. Czy napisanie aplikacji mobilnej w Android Studio i nie wiem w czym dla iOS się pisze :D (xcode, swift?) jest bardzo upierdliwe?

Zakładając, że mamy webówkę gotową, opartą na RESTach i chcemy aplikację mobilną. Zwykłe CRUDy.

  • Czy napisanie GUI z obsługą RESTów w Android Studio, znając podstawy Javy, jest trudne?
  • jw. ogarnięcie tego dla iOS, dużo nauki?
  • i czy to wszystko to jest kolejny wielki strup na głowie z punktu widzenia utrzymania projektu. Czyli jedna zmiana w trzech miejscach, testy, deployment itp..

A co jeśli wiem, że w przyszłości w aplikacji mobilnej będę chciał wyświetlić mapę, mieć dostęp do GPS, aparatu, galerii zdjęć, powiadomień itp? Czy lepiej już na starcie odpuścić Ionic i React Native?

1
Michał Sikora napisał(a):

Jeśli to jest zbyt kluczowe, to pewnie zrobiłbym RN albo (choć otwiera mi się nóż w kieszeni) Flutter. Mimo że za Flutterem nie przepadam, to wiem, że szybko można uzyskać zadowalające wyniki, jeśli aplikacja jest prosta.

Co takiego złego jest we Flutterze? Na mnie zrobił wyraźnie lepsze wrażenie, niż React Native. Dużo w nich nie grzebałem - po kilka tygodni w każdym.

0

Odnośnie samego Fluttera, to uważam za błędne pisanie aplikacji natywnej, która pomija zestaw narzędzi platformy, na której ma działać. Natomiast Dart to kaleka, który udaje, że nim nie jest. Trochę o tym tutaj pisałem.

1
Michał Sikora napisał(a):

Odnośnie samego Fluttera, to uważam za błędne pisanie aplikacji natywnej, która pomija zestaw narzędzi platformy, na której ma działać.

Jeśli chodzi o UI, to jest potencjalnie minus, ale dobrze zrekompensowany. W SDK dają bogaty zestaw widgetów, które wiernie emulują te natywne. Nie mają zresztą wyboru - w przeciwnym wypadku Apple mogłoby nie wpuścić aplikacji do sklepu. A po stronie Androida, to akurat sprawy zostają "w rodzinie", więc też nie spodziewałbym się wielkich problemów.

Czy chodzi o jakieś inne API?

Natomiast Dart to kaleka, który udaje, że nim nie jest. Trochę o tym tutaj pisałem.

W porządku, ale według mnie to i tak postęp względem JavaScriptu (skoro porównujemy z RN).

1
V-2 napisał(a):

Jeśli chodzi o UI, to jest potencjalnie minus, ale dobrze zrekompensowany. W SDK dają bogaty zestaw widgetów, które wiernie emulują te natywne. Nie mają zresztą wyboru - w przeciwnym wypadku Apple mogłoby nie wpuścić aplikacji do sklepu. A po stronie Androida, to akurat sprawy zostają "w rodzinie", więc też nie spodziewałbym się wielkich problemów.

No UI we Flutterze jest ładne. Nie czepiam się tego jak wygląda. UI to akurat najmocniejsza strona Fluttera. Moim zdaniem kiepskim pomysłem jest dostarczanie silnika renderującego z każdą aplikacją.

Jak Apple mógłby zablokować korzystanie z natywnych komponentów? W sensie Apple ma jakieś reguły, które nie pozwalają na korzystanie z natywnych komponentów przez kod nie Appla?

Czy chodzi o jakieś inne API?

Nie chodzi mi o API tylko o całą platformę. Jak już ją porzucamy, to lepszym rozwiązaniem jest web, który nie zamyka się na jeden konkretny silnik do renderowania i język programowania i dostarcza przy tym pełen wachlarz nowych możliwości.

W porządku, ale według mnie to i tak postęp względem JavaScriptu (skoro porównujemy z RN).

Nigdzie nie porównywałem Fluttera do RN (którego też nie darzę jakąś specjalną sympatią). Za mało pisałem w JavaScripcie, żeby wiedzieć, który język jest lepszy, ale wierzę na słowo. Zwłaszcza biorąc pod uwagę horrory jakie się słyszy i widzi związane z tym językiem. Ale RN nie zmusza do pisania w JavaScripcie. Jest TypeScript, Kotlin i w przyszłości WebAssembly otwiera drzwi na ciekawe rozwiązania.

1
Michał Sikora napisał(a):

Jak Apple mógłby zablokować korzystanie z natywnych komponentów? W sensie Apple ma jakieś reguły, które nie pozwalają na korzystanie z natywnych komponentów przez kod nie Appla?

Nie rozumiemy się... Pisałem w kontekście UI... Apple jest dość restrykcyjne, jeśli chodzi o aplikacje, które nie odpowiadają iOS-owym standardom "look & feel". Co wymusza - w tym wypadku na autorach Fluttera - żeby dali nam narzędzia pozwalające wiernie podrobić ten "look & feel".

Czy chodzi o jakieś inne API?

Nie chodzi mi o API tylko o całą platformę. Jak już ją porzucamy, to lepszym rozwiązaniem jest web, który nie zamyka się na jeden konkretny silnik do renderowania i język programowania i dostarcza przy tym pełen wachlarz nowych możliwości.

Gdyby rozwiązania oparte o webówkę się sprawdzały, nie byłoby tej rozmowy, bo ani React Native, ani Flutter nie miałyby powodu powstawać ;)

Nigdzie nie porównywałem Fluttera do RN (którego też nie darzę jakąś specjalną sympatią).

Napisałeś:

Jeśli to jest zbyt kluczowe, to pewnie zrobiłbym RN albo (choć otwiera mi się nóż w kieszeni) Flutter.

Przy RN nie było nic o nożu, więc zrozumiałem to jako porównanie, w którym niekorzystnie wypadał Flutter ;) Silly me

Ale RN nie zmusza do pisania w JavaScripcie. Jest TypeScript

Zgadza się, ale ma to swój koszt. Dodajemy w ten sposób kolejny ruchomy element do i tak skomplikowanej układanki. I jak zawsze, kiedy stajemy na piramidzie kilku krzeseł, coś się przez to spierdzieli :) Ryzyko rośnie. Nie teoretyzuję, bo sam się na to naciąłem. Transpilacja z TypeScriptu do JavaScriptu (jest za to odpowiedzialny Babel, jeśli pamiętam) wywoływała pewne problemy, np. z breakpointami.

0
V-2 napisał(a):

Nie rozumiemy się... Pisałem w kontekście UI... Apple jest dość restrykcyjne, jeśli chodzi o aplikacje, które nie odpowiadają iOS-owym standardom "look & feel". Co wymusza - w tym wypadku na autorach Fluttera - żeby dali nam narzędzia pozwalające wiernie podrobić ten "look & feel".

Dlatego o to zapytałem, bo nie wiedziałem do końca o co Ci chodzi. Wiem, że Apple jest restrykcyjne jeśli chodzi o takie rzeczy, ale szczerze to każda Flutterowa apka, którą znam nie jest typowo iOS-owa. Ma albo Material Design albo coś swojego. Aczkolwiek fakt, dobrze że we Flutterze jest chociaż możliwość naśladowania Cupertino. Z tym, że zrobienie aplikacji, która jest na Androidzie Material na iOS-ie Cupetrino jest mało praktyczne, bo trzeba pisać dodatkowe abstrakcje i zdać się np. na https://pub.dartlang.org/packages/flutter_platform_widgets.

Gdyby rozwiązania oparte o webówkę się sprawdzały, nie byłoby tej rozmowy, bo ani React Native, ani Flutter nie miałyby powodu powstawać ;)

Web dzisiaj jest dużo dalej niż w czasie, kiedy powstawał RN czy Flutter. Jasne, nie można jeszcze zrobić tyle, co w aplikacji instalowanej na telefonie, ale ta linia z dnia na dzień się coraz bardziej zaciera (https://whatwebcando.today) i wolałbym, żeby wysiłki szły w stronę rozwoju weba niż takiego rozwiązania jak Flutter.

Zgadza się, ale ma to swój koszt. Dodajemy w ten sposób kolejny ruchomy element do i tak skomplikowanej układanki. I jak zawsze, kiedy stajemy na piramidzie kilku krzeseł, coś się przez to spierdzieli :) Ryzyko rośnie. Nie teoretyzuję, bo sam się na to naciąłem. Transpilacja z TypeScriptu do JavaScriptu (jest za to odpowiedzialny Babel, jeśli pamiętam) wywoływała pewne problemy, np. z breakpointami.

Różnica tutaj jest taka, że jest to bug w narzędziach, które da się naprawić w przeciwieństwie do rzeczy, które uważam za błędne we Flutterze i wynikają na etapie jego koncepcji. Jeśli ktoś nie uważa tego za wady albo mu nie przeszkadzają, to też ok. W końcu Flutter ma dużo pozytywnych opinii i jeśli komuś zwiększa efektywność pracy, to niech go używa. Dla mnie takie rzeczy jak natywny kod omijający natywną platformę, niewspółczesny i kiepski język programowania, brak wsparcia dla śmierci procesu, dostarczanie całej swojej wewnętrznej platformy razem z każdą aplikacją czy ciągłe nadganianie natywnego UI są ciężkostrawne. Uważam, że są lepsze wieloplatformowe rozwiązania. Ale i tak pewnie przez najbliższy rok będę pracował we Flutterze. ¯\_(ツ)_/¯

2
Michał Sikora napisał(a):

Zgadza się, ale ma to swój koszt. Dodajemy w ten sposób kolejny ruchomy element do i tak skomplikowanej układanki. I jak zawsze, kiedy stajemy na piramidzie kilku krzeseł, coś się przez to spierdzieli :) Ryzyko rośnie. Nie teoretyzuję, bo sam się na to naciąłem. Transpilacja z TypeScriptu do JavaScriptu (jest za to odpowiedzialny Babel, jeśli pamiętam) wywoływała pewne problemy, np. z breakpointami.

Różnica tutaj jest taka, że jest to bug w narzędziach, które da się naprawić w przeciwieństwie do rzeczy, które uważam za błędne we Flutterze i wynikają na etapie jego koncepcji.

Bardziej naprawiać, niż naprawić ;) Z im większej liczby warstw składa się dany system, tym częściej coś się posypie przy updejcie któregoś elementu. Jak byś nie naprawiał - Syzyfowa praca. I to jest taki grzech pierworodny JavaScriptu ogólnie. Jego niedociągnięcia są od lat łatane za pomocą kolejnych bibliotek, abstrakcji, nakładek itd. Inaczej mówiąc, ta kategoria problemów też sięga korzeniami do poziomu koncepcji.

Zaznaczam, że nie bronię Fluttera, bo mam o wiele za mało doświadczenia, żeby udawać jakiś autorytet. Bardziej zniechęcił mnie RN, który jest ewidentnie skrojony pod frontendowców. A za tym ekosystemem zwyczajnie nie przepadam. I języka nie lubię, i sam React uważam za przeinżynierowany (rozumiem zamysł, nie jestem fanem wykonania - podobnie jak miałem kiedyś z WPF, niech spoczywa w spokoju).

0

Pozwolę się Panowie dołączyć do dyskusji zadając pytanie :D
Programuje od jakiegoś czasu w Kotlinie + Android Studio, mam już swoje apki, lecz ostatnio stwierdziłem, że muszę wypuszczać zarówno na Androida jak i iOS.

Zainteresowałem się właśnie Flutterem i podczas przeglądania opinii o tym frameworku naszło mnie pytanie, która Wam tu zadaję, czy programowanie czysto w kotlinie na androida jest perspektywiczne mając na uwagę popularność webowych rozwiązań oraz właśnie rozwój wieloplatformowości ?
Można uznać, że jestem freelancerem. Programuje po godzinach pracy w innym zawodzie, więc moje projekty nie są bardzo skomplikowane więc teoretycznie taki Flutter powinien dać radę, a ja korzystając z niego bym zyskał zasięg dla systemu iOS.

Jakie jest Wasze zdanie ?

2

Moim zdaniem programowanie na Androida w Kotlinie jest bardzo perspektywiczne zwłaszcza biorąc pod uwagę rozwój wieloplatformowości. Takie podejście, jakie oferuje Kotlin, jest moim zdaniem najlepsze, bo daje współdzielony kod, nie wymusza języka przy końcówkach, gdzie integrujemy się z platformą i pozwala na w pełni natywne doświadczenie. Nie jest to rozwiązanie, które oferuje wszystko już dzisiaj, bo Kotlin Native wymaga jeszcze pracy, więc jeśli interesuje Cię pisanie aplikacji już teraz, to Flutter może być rozwiązaniem dla Ciebie. Zwłaszcza, że dużo pozytywnych opinii słyszałem od ludzi, którzy nie są programistami i zaczęli z tym zabawę.

2
Radek Dobrzyński napisał(a):

czy programowanie czysto w kotlinie na androida jest perspektywiczne mając na uwagę popularność webowych rozwiązań oraz właśnie rozwój wieloplatformowości ?

To pytanie typu "czy jest sens robić prawo jazdy na samochód, biorąc pod uwagę popularność motocykli?". Crossplatformówki mają swój segment rynku. Przy natywnych są mikrusami. Jeśli ktoś oczekuje, że je zmarginalizują czy zastąpią, to moim zdaniem wpadł w jakieś reality distortion field.

Na Androidzie nie da się natomiast (niestety) ominąć Javy. Pisać można sobie w Kotlinie, jeśli mamy luksus wyboru. Ale znać Javę tak czy owak trzeba.

Można uznać, że jestem freelancerem. Programuje po godzinach pracy w innym zawodzie, więc moje projekty nie są bardzo skomplikowane więc teoretycznie taki Flutter powinien dać radę, a ja korzystając z niego bym zyskał zasięg dla systemu iOS.

Flutter jest obiecujący, ale jeszcze bardzo młody. Moim zdaniem warto się z nim zapoznać, ale za wcześnie, żeby wkładać sobie oba jaja do tego koszyka, jak mawiają zagramanicą ;)

Zleceń na Fluttera jest jeszcze niezbyt wiele... Pracuję dla dużego software house'u: krąży legenda, że w którymś z oddziałów mamy jeden komercyjny projekt Flutterowy. Chodzą tam wycieczki z przewodnikiem dziwować się tej egzotyce. Tak że własne apki można sobie pisać, ale ja bym nie inwestował we Fluttera 100% czasu i wysiłku, i nie zakładał dalekosiężnego powiązania z nim swej kariery. Szczególnie, że Google ma przykrą skłonność do agresywnego ubijania własnych projektów, jeżeli nie chwycą.

2

Google ma przykrą skłonność do agresywnego ubijania własnych projektów, jeżeli nie chwycą

Nie znam się, więc się wypowiem ;)

IMHO Fluttera nikt nie ubije, a wręcz przeciwnie. Google powoli będzie za pewien czas wycofywał Androida, tworzą nowy system, który nie będzie (jak Android) oparty o jądro Linuksa, ale o własne, autorskie. To cudo nazywa się Fuchsia i właśnie we Flutterze ma się pisać na to apki. Oczywiście - do czasu wejścia tego na rynek jeszcze trochę czasu minie, więc mają chwilę, żeby Fluttera rozkręcić, wypromować i dopieścić. Zauważ, że jakby teraz weszli z czymś nowym, co zrywa kompatybilność z Androidem, to by była lekka masakra. Dlatego zrobili rozwiązanie 3w1 - Flutterem można pisać na Androida, Apple oraz Fuchsie. Programiści się przyzwyczają, nauczą, a wtedy CIACH - Android znika, ale apki zostają.

Moim zdaniem wprowadzenie następcy Androida oraz nowego, wieloplatformowego środowiska prawie w tym samym czasie to nie przypadek, Google się szykuje do rewolucji, która nastąpi za kilka lat. Teraz Flutter jest w powijakach, dopiero niedawno wyszła pierwsza wersja nie będąca betą, ale za 2-3 lata będzie dojrzałym środowiskiem, które będzie dawało radę/będzie jakimś standardem. A dla tych, którzy będą je ogarniać, zrobi się eldorado :)

1

Tak, tak - jeśli wszystko pójdzie idealnie ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1