Czy XAMARIN jest wart uwagi i czy jest już wystarczająco dojrzały?

Odpowiedz Nowy wątek
2017-01-14 15:33
Krzywy Krawiec
1

Przyglądam się XAMARIN-owi od dłuższego czasu. W teorii to ciekawe rozwiązanie, pozwalające pisać w jednym języku na dwie njaważniejsze platformy (Windows Phone pomijam bo to już historia). Wszystko fajnie, ale dotychczas XAMARIN był trochę kłopotliwy, czytałem opinie użytkowników i generalnie był "problemowy". Nie wszystko działało tak jak należy i trzeba było często używać jakichś obejść, tricków, itp. Czy po przejęciu XAMARINA-a przez MS coś się poprawiło? I czy do XAMARINA - włączą Universal Apps 10 (WUP), tak żeby można było pisać jeden kod na trzy platformy? Jak sądzicie? Jak oceniacie XAMARIN?

Pytam się o Wasze opinie na temat XAMARIN, ponieważ w ostatnim czasie powstało wiele alternatyw crossplatformowych. I w zasadzie to samo można osiągnąc w PhoneGAP, IONIC, Cordova, oraz już natywnie w: RubyMotion, KIVY, React Native, itd. itd.

Krzywy Krawiec

edytowany 1x, ostatnio: Ktos, 2017-01-14 20:06

Pozostało 580 znaków

2017-01-14 20:25
0

Xamarin dalej jest czasami problemowy, ale się poprawiło. Nie piszę osobiście, to wiem tylko z drugiej ręki, z opinii znajomych.
Xamarin dla UWP jest już teraz (Forms), możesz w nim pisać: https://developer.xamarin.com[...]ndows/installation/universal/

Pozostało 580 znaków

2017-01-15 20:14
Krzywy Krawiec
0

Dzięki za info. Jeszcze raz przyjrzę się XAMARINowi. Ciekawe czy UWP w ogóle się przyjmie, bo coś mi się obiło o uszy, że sprzedaż telefonów z Windowsem leży... A UWP miało być uniwersalnym rozwiązaniem na desktopy, tablety i komórki.

Krzywy Krawiec

Pozostało 580 znaków

2017-01-15 20:22
0

Sprzedaż tabletów nie leży, desktopów stoi, Xboxa pewnie rośnie, AR (HoloLens) pewnie urośnie więc może UWP ma rację bytu w tych dziedzinach. Ale faktycznie, Windows na telefonach obecnie jest na dnie i nie widzę szans na wzrost ponad pewną niszę.

Aczkolwiek gdyby UWP skleić z Xamarinem w taki sposób, że jednym kodem faktycznie da się napisać na Windows desktop, tablet, mobile, Xbox, HoloLens, IoT, Androida i iOS to by było idealnie - obecnie Xamarin.Forms jest powiedzmy dość blisko, ale nie jest identyczny z UWP.

Pozostało 580 znaków

2017-01-16 09:28
0

A czy ktoś z obecnych na forum programuje komercyjnie w Xamarinie?
Chce zacząć klepać coś na Androida i właśnie zastanawiam się nad językiem.
Na co dzień piszę coś w C# więc zainteresował mnie Xamarin, ale znalazłem w sieci trochę nie przychylnych informacji i stwierdzeń że jak Android to tylko Android Studio + Java/Kotlin.

Jak to w końcu jest ;)?

Pozostało 580 znaków

2017-01-16 09:42
1

Ja. Powiem Ci tyle, że ostatni projekt z Xamarinem u nas zabito, z czego jestem niezmiernie szczęśliwy. Większość czasu poświęciliśmy na szukanie różnych sposobów obejścia rozwiązań proponowanych przez MvvmCross, zwłaszcza w dziedzinie nawigacji. Sam C# działał akurat całkiem nieźle, ale brak możliwości np. prostego utworzenia "TabBarControllera" dla mnie dyskwalifikuje ten projekt. Performance powstałego tworu był tragiczny (pracowałem nad iOS, w Androidzie nie wiem).

Nie wiem dlaczego nikomu nie daje do myślenia, że Xamarina rozwija teraz Microsoft, który jak wiadomo od lat tworzy wiodące platformy mobilne ;)

Jak dla mnie liczenie na taki walkaround (znam już C# i coś z tego będzie) nie zadziała - lepiej nauczyć się czegoś natywnego, czy to Androida czy iOSa. Znajomość samych języków to w tym przypadku najmniejszy problem, ważniejsze jest API konkretnej platformy i możliwość osiągnięcia dobrych efektów w rozsądnym czasie.


Life is like jazz - It's best when you improvise

Pozostało 580 znaków

2017-01-16 10:01
Antek
0

"lepiej nauczyć się czegoś natywnego, czy to Androida czy iOSa"
Otóż w C# piszemy natywnie, gdyż korzystamy z tego samego Androidowego SDK co Java (w przypadku pisania w Android Studio). Używałeś frameworka MvvmCross dlatego byłeś od niego uzależniony i dlatego musiałeś stosować workaround.
Jeżeli piszemy czysto na Androida w Xamarin, bez multiplatformowości to napiszemy dokładnie to samo co w Javie z dokładnie tą samą wydajnością.

Pozostało 580 znaków

2017-01-16 10:03
Antek
1

Dodam tylko że to samo jest z iOS. Używając Xamarin (bez dodatkowych frameworków) po prostu zastępujemy język czy to Objective-C/Swift czy to Jave, językiem C#. Podkreślam piszemy jak najbardziej natywnie. Problemem w pisaniu na te wszystkie platformy jest niewątpliwie znajomość SDK i cyklu życia aplikacji a nie samego języka.

Pozostało 580 znaków

2017-01-16 10:33
1

No i pewnie skończy się na tym, że będziesz pisał Javę w C#. Każdy tutorial czy post na SO będzie w Javie, a ty będziesz zastanawiał się jak Javizmy przetłumaczyć na idiomatyczny C#.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-01-16 10:47
0
Antek napisał(a):

Otóż w C# piszemy natywnie

Skrót myślowy, chodziło mi o macierzystą platformę.

Z tym idiomatycznym C# to jak najbardziej prawda, nie sztuka jest sklecić cokolwiek.
Ok jeśli framework ogranicza i lepiej z niego zrezygnować, to czemu nie pisać części wspólnej w C/C++? Xamarin to też framework, którego głównym założeniem jest przyspieszenie pisania apek. Dlatego należy operować na wyższym poziomie abstrakcji. Byłem w projektach iOS + C++ i działało to bardzo dobrze, jednak na pewno nie zostało zrobione przez 2 tygodnie.

Jeśli chodzi o MvvmCross to rezygnacja z niego byłaby jednak cofaniem się. Same założenia są fajne, coś jak RxSwift w stylu "reactive programming". Wybierając MVVM mamy możliwość współdzielenia ViewModeli między platformami, co w założeniach jest bardzo efektywne. Bez jakiegoś frameworka skończysz z dużą ilością boilerplatu, bo jakoś musisz powiązać V z VM. MVC nie ma sensu, bo byłoby to napisanie 2 oddzielnych aplikacji.

"Jedyny" problem jest taki, że współdzielenie ViewModeli nie do końca działa, bo coś co np. w Androidzie jest 1 kontrolerem, w iOS jest 4 i vice versa. Wtedy paradygmaty narzucane przez framework zawodzą, zwłaszcza że większość rzeczy dokonuje się magicznie przez DI i/lub refleksje.

Ja na miejscu autora wolałbym spróbować np. React Native, podszkolić się trochę z JavaScriptu, podpatrzeć fajne patenty we współczesnym froncie.


Life is like jazz - It's best when you improvise
edytowany 3x, ostatnio: lubububu, 2017-01-16 10:59

Pozostało 580 znaków

2017-01-16 13:44
3

Xamarin.Forms ma skracać czas który jest potrzebny na wykonanie kilku aplikacji które mają robić dokładnie to samo. W trakcie pisania jednak często występuje tyle błędów i problemów związanych z tym że na którejś z platform aplikacja działa inaczej lub wcale nie chce działać, że czas zwiększa się myślę dwukrotnie w porównaniu z tym co zakładamy. Dodatkowo często trzeba siedzieć i myśleć nad pewnymi obejściami bo jeżeli wykonamy coś to potem okazuje się że albo wydajność tego jest na słabym poziomie albo czegoś się "nie da" zrobić. Nie rozumiem również tego podejścia często pokazywanego w oficjalnej dokumentacji Xamarina i akceptowanego przez wielu na np stackoverflow żeby zamiast tworzyć viewsy w xamlu pisać je w c#, tworzy się wtedy takie spaghetti że współczuję rozwijania takiego kodu.

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