Wątek przeniesiony 2019-04-28 14:54 z przez furious programming.

Aplikacja iOS/Android jako strona mobilna

Odpowiedz Nowy wątek
2019-04-27 21:40
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.


"Trolling is a art"

Pozostało 580 znaków

2019-04-28 19:47

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?

edytowany 5x, ostatnio: Michał Sikora, 2019-04-28 22:24

Pozostało 580 znaków

2019-04-28 22:28
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.


"Trolling is a art"

Pozostało 580 znaków

2019-04-28 22:35
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ł.


Jest to rozwiązanie nad którym właśnie myślimy dość mocno. Natomiast pozostaje ten problem ikonki na liście aplikacji. - Hispano-Suiza 2019-04-28 23:28
@Hispano-Suiza: ale w jakim sensie? ikonkę dodajesz w manifeście w różnych rozdziałkach i potem masz ją w telefonie po zgodzie na istalację - czysteskarpety 2019-04-29 10:31
Muszę się wczytać, bo jak już mówiłem wiedzy mam tyle co bootcampowicz :-) - Hispano-Suiza 2019-04-29 14:30

Pozostało 580 znaków

2019-04-28 22:38
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.

edytowany 2x, ostatnio: Michał Sikora, 2019-04-28 22:43
Żadnych desktopów. Tylko web + konieczność przeniesienia web do mobile. - Hispano-Suiza 2019-04-28 23:27
@Michał Sikora: możesz napisać co to za aplikacje? ściągnąłbym i zobaczył jak to działa. Jestem też ciekaw jak te apki zarabiają na siebie, reklamy czy może subskrypcje? - alMarko 2019-04-29 20:11
dzięki za linki - alMarko 2019-04-29 20:18

Pozostało 580 znaków

2019-04-30 09:36
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?

Poczytaj o Embarcadero Delphi i frameworku FireMonkey. Z pomocą jednego kodu zbudujesz aplikacje na Windows (32, 64 bit), macOS, iOS, Android. Ewentualne różnice w kodzie wynikające ze specyfiki danej platformy umieszczasz w dyrektywach. - XailonOZ 2019-04-30 11:39
Ciekawe, próbowałeś coś w tym pisać? - kkojot 2019-04-30 11:45

Pozostało 580 znaków

2019-05-05 14:59
V-2
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.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

2019-05-05 15:58
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.

Jak widzę kod z tymi podkreślnikami w prefiksach w "nowoczesnym" języku to mnie coś bierze (_Foo, _someMethod() itp.) - dbCooper 2019-05-06 08:00

Pozostało 580 znaków

2019-05-05 16:08
V-2
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).


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

2019-05-05 17:06
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.

edytowany 2x, ostatnio: Michał Sikora, 2019-05-05 17:34

Pozostało 580 znaków

2019-05-05 18:06
V-2
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.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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