Programowanie mobilne dla nie-programistów mobilnych

Pytanie do programistów mobilnych i nie: czy bierze was czasem chęć zrobienia apki mobilnej? Jeśli tak, to z czego korzystacie: PhoneGap, Xamarin, czy może narzędzia per platforma?

Pytam bardzo interesownie, bo pracuję dla Kinetise.com, gdzie robię webowy edytor natywnych apek mobilnych na 5 platform:

Chętnie bym się dowiedziała, czy to jest coś, czego byście używali gdybyście mieli jakieś zlecenie na cross-platformową apkę, i dlaczego tak/nie. Będę super wdzięczna jeśli odpiszecie mi parę słów tu albo na [email protected], a w podzięce mam dla was promo-code "starter" na darmowe konto na 30 dni na dobry początek.

Cześć. Wygląda to jak reklama, ale odpiszę. Zasadniczo, uważam, że poszczególne platformy mobilne na tyle mocno się od siebie różnią, że pisanie jednej cross-platformowej aplikacji na wszystkie platformy nie ma sensu. Ponadto, wydajność, szybkość działania, jakość i wygląd cross-platformowych aplikacji pozostawia wiele do życzenia. Narzędzia developerskie również są niezbyt dobre. Idea zacna, ale w praktyce się to nie sprawdza. Wyjątkiem są gry mobilne, które można pisać m.in. w Unity i uruchamiać na różnych platformach, ale "klasyczne" aplikacje powinno się, moim zdaniem, pisać per platforma.

Dzięki za odpowiedź. :) Swoich powiązań i interesów absolutnie nie ukrywam. :)

Ponadto, wydajność, szybkość działania, jakość i wygląd cross-platformowych aplikacji pozostawia wiele do życzenia.

Tak się dzieje w przypadku HTMLowych apek. Jeśli się robi apki natywne, to te problemy znikają. Tylko wyzwaniem jest zrobić natywne i wszędzie takie same, ale właśnie w tym tkwi siła Kinetise. :)

Ale one z samej definicji nie mogą być takie same - "user expierience" dla Androida i iOS czy Windows Phone się kompletnie różni, są inne kontrolki, inne schematy interakcji... Bo potem wychodzą takie koszmary, że aż żal patrzeć.

Miałem m.in. na myśli to samo, co Krzywy Młot, dlatego uważam, że ideologicznie cross-platformowy development brzmi fajnie, ale w praktyce się nie sprawdza, a projekty tworzone w ten sposób są po prostu słabe. Najlepsze aplikacje na Androida i iOS-a są napisanie w natywnych technologiach, gdyż tylko wtedy można osiągnąć odpowiednio wysoką jakość tworzonego projektu.

Krzywy Młot napisał(a):

Ale one z samej definicji nie mogą być takie same - "user expierience" dla Androida i iOS czy Windows Phone się kompletnie różni, są inne kontrolki, inne schematy interakcji... Bo potem wychodzą takie koszmary, że aż żal patrzeć.

Nie muszą wychodzić koszmarki jeśli robić to dobrze, a i platformy mobilne jednak aż tak się nie różną - np. nie w połowie tak jak desktop od mobile. Co by Cię przekonało, że da się to zrobić dobrze? :)

Lilavati napisał(a):

Co by Cię przekonało, że da się to zrobić dobrze? :)

Musiałbym zobaczyć w miarę złożony projekt (coś trudniejszego, niż np. czytnik RSS-ów) napisany w taki sposób. Zarówno działającą aplikację jak i kod, a następnie ocenić, czy rzeczywiście jest to zrobione dobrze.

Właściwie, to dobry podział aplikacji z wymiennymi widokami zdałby test - aplikacja byłaby natywna i mogłaby wyglądać w sposób odpowiedni dla danej platformy.

wiciu napisał(a):

Lilavati napisał(a):

Co by Cię przekonało, że da się to zrobić dobrze? :)

Musiałbym zobaczyć w miarę złożony projekt (coś trudniejszego, niż np. czytnik RSS-ów) napisany w taki sposób. Zarówno działającą aplikację jak i kod, a następnie ocenić, czy rzeczywiście jest to zrobione dobrze.

Apek z ficzerami (logowanie, geolokalizacja, wysyłanie zdjęć...) do poklikania do wyboru do koloru :) :

• wersje iOS: Kinetise w iTunes
• wersje Android: Kinetise w Play

Kodu pokazać nie mogę, ale tajemnicą nie jest, że kodu dzielonego między apkami na różne platformy zwyczajnie nie ma. Apki zapisujemy we własnym formacie, z którego kompilujemy na konkretne platformy - i w tych kompilatorach tkwi moc robienia apek natywnych, wyglądających i działających w ściśle określony sposób.

Może masz jakiś pomysł na apkę który chciałbyś zobaczyć w akcji? :)

Żadnych aplikacji w Sklepie dla Windows nie ma?

Ale wszystkie te aplikacje umieszczone w Google Play są bardzo do siebie podobne. Graficznie ok, inne. Ale funkcje prawie identyczne - przeglądanie listy tekstów, dostęp do pojedynczego tekstu, jakaś mapa, wysłanie maila.

Ja doskonale wiem, że takie narzędzia do tworzenia aplikacji dla nie-programistów (z mojego/Microsoftowego podwórka: np. Project Siena, Windows Phone App Studio) nie służą do tworzenia wymyślnych produktów, tylko właśnie niezbyt wielkich prezentacji, szybkich informacji z konferencji/wydarzeń, czytników RSS ze stron i tak dalej. I fajnie, dla wielu osób może wystarczy.

Tylko, że na przykład na Windows Phone kładziony był (początkowo, bo biedny nie wybrzydza) bardzo wysoki nacisk na zgodność z zasadami interakcji i wyglądu systemu. Aplikacje niezgodne ze stylem "Metro" były traktowane z pogardą. Żadna aplikacja wieloplatformowa nie ma szans tego osiągnąć - będzie absolutnie wymagana przynajmniej zmiana widoku. W obecnej chwili oczywiście zarówno Windows ewoluuje w stronę Androida/iOS (niesławny "hamburger menu", naciągane zmiany w nawigacji - ogólnie Microsoft Design Language 2.0), jak i dzieje się to w drugą stronę (Material Design) i pewne różnice się będą zacierać, co będzie z korzyścią dla twórców aplikacji dla wielu platform (i być może dla mojej - niszowej - platformy).

A jak z możliwością wykorzystania np. sensorów urządzenia (GPS, akcelerometr)? A jak z możliwością wykorzystanie unikatowych elementów platformy (np. kafelki, widżety)? Możliwe są zmiany widoku przygotowawcze dla konkretnej platformy (na Androidzie wygląda tak, na iOS siak?). Wielojęzyczność aplikacji? Są dziesiątki aspektów, które trzeba rozwiązać w aplikacjach dla wielu urządzeń i choć przy takich nie pracowałem to niestety mam wrażenie, że poszedłbym jednak drogą "starego" Xamarina (bez Xamarin.Forms) - wspólny back-end, klasy współdzielone, jednakowe modele - i z ręcznym stworzeniem warstwy widoku dla każdej z platform oddzielnie.

Nie spotkałam się z sytuacją, że ktoś chciał kafelki dla kafelków - aplikacje muszą raczej wyświetlić to, zapisać owo, umożliwić tamto. Funkcjonalności w sensie biznesowym, zapewniamy. (GPS jest, akceleratorów nie ma, ale nie ma też przeszkód, by w przyszłości się pojawiły).

Dodatkowo nawet robiąc na jedną platformę, należy obsłużyć wiele urządzeń, a różnice nie kończą się bynajmniej na rozdzielczości ekranu czy wersji systemu.

Jednemu użytkownikowi będzie wygodniej zaprojektować aplikację raz i mieć gwarancję spójnego wyglądu między platformami i urządzeniami, inny będzie chciał korzystać z funkcjonalności poszczególnych platform - tu nie ma dobrej czy złej opcji, tylko do różnych celów są różne narzędzia. Kinetise jest w duchu "design once, deploy everywhere", czyli przypadnie do gustu tym pierwszym.

Nie mamy apek w sklepie Windowsowym, nasz kompilator jeszcze nie jest w stadium produkcyjnym, ale niebawem będzie. A że niektórzy traktują z pogardą niektóre apki, cóż, Gumpy Cat gardzi wszystkimi równo: :)

Powiem jak to wyglada u nas. Piszemy aplikcje mobilne (miedzy innymi) dla BMW, Audi, Renault, Deimler itp. i sa one wysoce specjalistyczne (np. na komputerki pokladowe itp.). Nie ma bata zebysmy uzywali do tego jakies Xamariny czy Phone Gapy, musimy niemal zawsze robic rzeczy, do ktorych trzeba zejsc i tak do kodu natywnego na dana platforme. Robilismy rozne testy, studenciaki mialy rozne zadania pod naszym nadzorem, zeby costam popisac w takich cross-platform, ocenic, itp. i lipa jest jednym slowem. Czyli: my piszemy uzywajac jedynie natywnych narzedzi.
Co do wspoldzielenia kodu - mamy projekty ktore mialy wspolny kod pisany w c i kompilowany do liba, i nastepnie lib opdlaczany do appki androidowej z NDK, i na iOS podobnie (nie piszemy nic na WP poniewaz nikt tego nie zamawia, chociaz powoli cos pomrukuja na ten temat). Dziala Ok, ale ostatnio (1.5 roku, powoli sie konczy) pracuje w projekcie w ktorym wspolny kod biblioteczny napisany jest w Javie i nastepnie konwertowany do Obj-C za pomoca j2objc (https://github.com/google/j2objc). Wygenerowany kod piekny nie jest i nie odpowiada temu, do czego przywzyczajeni sa programisci iOS, dlatego napisalismy cienka warstwe tzw. 'wrapperow' ktore adaptuja konwertowany kod do 'ladniejszego' API na iOS. Da sie tez to zrobic tak, ze wystawia sie interfejsy w kodzie wspoldzielonym ktore musza byc implementowane na kazdej platformie osobno bo wymagaja np. Androidowych albo iOS-owych API, czasami jest do dosc trudne ale bardzo rzadko. W ten sposob wspoldzielimy ok 2/3 kodu calych aplikacji. Ogolnie jestesmy z wynikow bardzo zadowoleni i nastepne projekty na pewno beda braly j2objc pod uwage.

Lilavati napisał(a):

Jednemu użytkownikowi będzie wygodniej zaprojektować aplikację raz i mieć gwarancję spójnego wyglądu między platformami i urządzeniami, inny będzie chciał korzystać z funkcjonalności poszczególnych platform - tu nie ma dobrej czy złej opcji, tylko do różnych celów są różne narzędzia. Kinetise jest w duchu "design once, deploy everywhere", czyli przypadnie do gustu tym pierwszym.

Z mojego doswiadczenia wynika, ze uzytkownicy jednej platformy chca zeby aplikacja zachowywala sie zgodnie z tym co oni znaja. Bardzo rzadko jedna osoba uzywa i iOS i Androida, a jesli sie zdarza, to np. telefon na jednej platformie, tablet na drugiej, gdzie UI i tak sie znaczaco rozni. Guzik ich obchodzi czy appka wyglada na iOS i Android tak samo; oni chca, zeby wygladala tak jak inne appki na ich platforme.

Apropos, nie wiem czy juz napisalas, ale jak wyglada sprawa z UI na telefon vs tablet? Tam bardzo czesto roznice sa wielkie, wieksze niez miedzy aplikacjami na rozne platformy ale obie na telefony lub tablety (znowu, moje doswiadczenia).

Spójność między platformami to przede wszystkim ogromna oszczędność czasu i kosztów dla twórcy czy zamawiającego. Racja, że użytkownika końcowego nie interesuje, czy kto inny ma tak samo, tylko ważne, żeby było dobrze. Ale dobrze jest. :) Wszelkie pobieranie czy wysyłanie danych, dodawanie do kalendarza, dzwonienie a nawet płatności można u nas ogarnąć - ogólnie 90% rzeczy o które ludzie nas konkretnie pytają można zrobić u nas z marszu. A realizowanie tych funkcjonalności jest czasem poprzez otwarcie innej apki, np. aby zrobić otwiera się apkę telefonu (albo Skype) na właściwym urządzeniu, a w Kinetise się daje akcję CALL:

Podobnie logowanie przez Facebook czy LinkedIn też będzie koniec końców wyglądać inaczej, swojsko. Natomiast to co zostaje wewnątrz apki, jej layout, jej menu, jej dane - to będzie identyczne, a menu będzie menu, przycisk będzie przyciskiem i użytkownik będzie zadowolony.

A z tabletami to wygląda tak: u nas apka się przeskaluje na dowolny ekran. I apki na tablety w portfolio mamy: była historia gdy Muzeum Narodowe zamówiło multimedialne przewodniki na tablety, dostawca się nie wyrobił na czas, a my im zrobiliśmy 10 apek w 2 dni. :)
Natomiast że to skalowanie jest w miarę proporcjonalne, to apka zaprojektowana na telefon będzie dziwnie wyglądać na tablecie i wice-wersa - w takiej sytuacji radziłabym chyba zrobić dwie osobne apki.

Spójność między platformami to przede wszystkim ogromna oszczędność czasu i kosztów dla twórcy czy zamawiającego.

Natomiast że to skalowanie jest w miarę proporcjonalne, to apka zaprojektowana na telefon będzie dziwnie wyglądać na tablecie i wice-wersa - w takiej sytuacji radziłabym chyba zrobić dwie osobne apki.

Khem :D

A tak serio, to nawet nie chce mi się tego testować - co mi po możliwości wyklikania appki, jak klient i tak prędzej czy później wpada na jakieś szalone pomysły i chciałby dorobić "jeszcze tylko taką jedną drobną opcję". I co ja zrobię, jak jej nie będzie w waszym katalogu? Nie widzę tu żadnych możliwości własnych modyfikacji, nie można podejrzeć kodu... E tam.

Jakbyście udostępnili ten swój kompilator pseudokodu wraz z dokumentacją, to co innego... Wtedy mogłabym się nawet zainteresować.

Lilavati napisał(a):

A z tabletami to wygląda tak: u nas apka się przeskaluje na dowolny ekran. I apki na tablety w portfolio mamy: była historia gdy Muzeum Narodowe zamówiło multimedialne przewodniki na tablety, dostawca się nie wyrobił na czas, a my im zrobiliśmy 10 apek w 2 dni. :)
Natomiast że to skalowanie jest w miarę proporcjonalne, to apka zaprojektowana na telefon będzie dziwnie wyglądać na tablecie i wice-wersa - w takiej sytuacji radziłabym chyba zrobić dwie osobne apki.

No i wlasnie takie podejscie jest bardzo czesto zle. Tablet to nie tylko wiekszy ekran; bardzo czesto uzywane sa inne layouty. Np. pod iOS, master-detail. Na telefonie jeden ekran to lista, i gdy sie kliknie w jakis wiersz to nowy ekran sie pokazuje z detalami. Wstecz -> idziesz do listy. Tablet - lista jest z lewej strony, a detale reszta ekranu. Klikasz na ikonke, nie znienia sie ekran tylko content aktualnego.
Tablet to nie po prostu wiekszy ekran, to calkiem inny tzw. ui idiom. Co mi z tego ze lista z telefonu zostanie przeskalowana na tablet i wszystko bedzie wieksze, i lista zajmie cala szerokosc ekranu? wiekszosc z tego bedzie puste, bo test jest krotki. dlatego Apple (nestowanie UIViewController, rozne udogodnienia w iOS 7 i 8) i Google (Fragment) daza wlasnie do tego, aby na tablety byly inne interfejsy, czasem znacznie inne. Robienie 2 aplikacji tez jest slabe, bo one maja wtedy: osobne id, osobna baze uzytkownikow, osobne recenzje, itp. itd. Do tego znowu trzeba wspolny kod wyodrebniac. Tak sie raczej nie robi.

W przypadku programowania na desktopy nie udało się stworzyć narzędzia z prawdziwego zdarzenia, które umożliwiłoby pisanie cross-platformowych apek. W tym celu stworzoną platformę Java, a później .NET, ale i tak każdy wie, że mają one głównie zastosowanie w pisaniu aplikacji dla firm. Gry czy aplikacje użytkowe przez lata powstawały jako natywne i nie udało się znaleźć konsensusu.

Podobnie będzie w przypadku aplikacji mobilnych szczególnie, że właścicielom platform nie zależy na tym, żeby twórcy mieli prościej.

Krzywy Kot napisał(a):

Podobnie będzie w przypadku aplikacji mobilnych szczególnie, że właścicielom platform nie zależy na tym, żeby twórcy mieli prościej.

Z tym sie nie zgodze - Apple i Google zarabiaja pieniadze glownie na tzw. content (appki ktore sa w sklepach), np. 30% od ceny sprzedazy, reklamy itp. a nie na tym ile osob jak dlugo pracuje nad aplikacja. Im szybciej tym lepiej, wiecej w app/play store.

ccboy napisał(a):

Z tym sie nie zgodze - Apple i Google zarabiaja pieniadze glownie na tzw. content (appki ktore sa w sklepach), np. 30% od ceny sprzedazy, reklamy itp. a nie na tym ile osob jak dlugo pracuje nad aplikacja. Im szybciej tym lepiej, wiecej w app/play store.

To nie jest takie proste, jak próbujesz to przedstawić. Apple Store to nie wszystko. Apple poza systemem dostarcza również obrzydliwie drogi sprzęt. Ich filozofia jest taka sama od lat. Narzucają ogromną marżę na swoje produkty, uzasadniając to tym, że dostarczają kompletny produkt: urządzenie + zamknięty system dostosowany do tego konkretnego urządzenia.

Google ma inną filozofię. Android na tle iOS jest otwartym oprogramowaniem. Po zakupie Motoroli niektórym wydawało się, że Google może pójść śladami Apple i dostarczać system razem ze sprzętem jednak tak się ostatecznie nie stało, a Google sprzedało Motorolę firmie Lenovo. Androida cały czas używają inne firmy np. Samsung czy LG, które go dostosowują i rozwijają swoje nakładki na ten system.

A co to ma do tego co ja napisalem? Jeszcze raz, moze jasniej: jesli chodzi o zarabianie pieniedzy na aplikacjach mobilnych, to obie firmy zarabiaja na tzw. contencie, czyli raczej zalezy im na tym, zeby sie content szybko pojawial, czyli zeby szybko sie programowalo nowe appki, czyli zeby bylo prosciej. To wszystko co mam do powiedzenia w odpowiedzi na to zdanie:

Podobnie będzie w przypadku aplikacji mobilnych szczególnie, że właścicielom platform nie zależy na tym, żeby twórcy mieli prościej.

LOL nie można przecież tego rozpatrywać oddzielnie. Apple nie zarabia tylko na Apple Store, więc im nigdy nie będzie zależało żeby raz napisana apka pod iOS działa tak samo na innych urządzeniach. Z tego powodu ich system jest zamknięty, wymuszają w ten sposób, że apka napisana pod iOS będzie działała tylko na ich urządzeniach i że będzie kupowana w ich sklepie.

Jest cała masa aplikacji, które zostały napisane tylko w wersji na iOS. Widać to szczególnie w przypadku amerykańskich startupów, które mając ograniczone środki piszą zazwyczaj swoją pierwszą apkę mobilną na iOS, a na Androida i WP dopiero w drugiej kolejności.

Google też ma swoje sposoby na zamykanie systemu, np. wydzielając część API do Google services.

Po pierwsze co to ma do tematu. Po drugie wyraźnie napisałem, że "Android jest otwarty na tle iOS", a nie że w ogóle jest otwarty.

aurel napisał(a):

A tak serio, to nawet nie chce mi się tego testować - co mi po możliwości wyklikania appki, jak klient i tak prędzej czy później wpada na jakieś szalone pomysły i chciałby dorobić "jeszcze tylko taką jedną drobną opcję". I co ja zrobię, jak jej nie będzie w waszym katalogu? Nie widzę tu żadnych możliwości własnych modyfikacji, nie można podejrzeć kodu... E tam.

Jakbyście udostępnili ten swój kompilator pseudokodu wraz z dokumentacją, to co innego... Wtedy mogłabym się nawet zainteresować.

Jeśli klient ma dużo change requestów, to tylko się cieszyć z dobrego źródła zarobku. :)

A co robić? Proste: powiedzieć klientowi, że apka kosztuje X, ale jeśli jakiś zbiór ficzerów mu wystarczy, to może mieć apkę za 1/5 X - i niech wybiera co mu pasuje. :)

Ponadto, jeśli jakiegoś ficzera brakuje, albo fajnie by było go przerobić, to bardzo bardzo chętnie przyjmę taką informację. :) Dostosowywanie się do potrzeb klientów się firmom najzwyczajniej w świecie opłaca. :)

Lilavati napisał(a):

wiciu napisał(a):

Lilavati napisał(a):

Co by Cię przekonało, że da się to zrobić dobrze? :)

Musiałbym zobaczyć w miarę złożony projekt (coś trudniejszego, niż np. czytnik RSS-ów) napisany w taki sposób. Zarówno działającą aplikację jak i kod, a następnie ocenić, czy rzeczywiście jest to zrobione dobrze.

Apek z ficzerami (logowanie, geolokalizacja, wysyłanie zdjęć...) do poklikania do wyboru do koloru :) :

• wersje iOS: Kinetise w iTunes
• wersje Android: Kinetise w Play

Kodu pokazać nie mogę, ale tajemnicą nie jest, że kodu dzielonego między apkami na różne platformy zwyczajnie nie ma. Apki zapisujemy we własnym formacie, z którego kompilujemy na konkretne platformy - i w tych kompilatorach tkwi moc robienia apek natywnych, wyglądających i działających w ściśle określony sposób.

Może masz jakiś pomysł na apkę który chciałbyś zobaczyć w akcji? :)

Oba linki prowadzą do Google Play pomimo tego, że jest podana informacja o iTunes.

wiciu napisał(a):

Lilavati napisał(a):

• wersje iOS: Kinetise w iTunes
• wersje Android: Kinetise w Play

Oba linki prowadzą do Google Play pomimo tego, że jest podana informacja o iTunes.

Dzięki za wyłapanie! :) Poprawiłam tamtego posta, appki w iTunes można obejrzeć pod tym linkiem