Artykuł

xamarin.com xamarin.com
cze 26 2016
0

Xamarin - nie myśl że zrobisz z nim projekt 3 razy szybciej

Rynek aplikacji mobilnych wciąż ma się świetnie, mimo że na horyzoncie pojawia się silna konkurencja, która byłaby w stanie rozwiązać część problemów związanych z developmentem aplikacji mobilnych. Chodzi mi oczywiście o responsywne strony WWW, które w dzisiejszych czasach są już standardem. Z każdym tygodniem wzrasta wsparcie dla standardów webowych w mobilnych przeglądarkach, dlatego też możliwości programistów są w tym obszarze coraz większe.

Rozwój mobilnych stron nie jest jednak jeszcze w tej chwili problemem dla deweloperów aplikacji. Ci póki co wciąż mogą spać spokojnie. Strony WWW nie mają dostępu do wielu istotnych API po stronie urządzenia. Poza tym dedykowane aplikacje wciąż są lepiej dopasowane do realiów poszczególnych systemów.

Oczywiście aplikacje mobilne mają swoją problemy. Przede wszystkim trzeba ich napisać tyle, ile systemów mobilnych chcemy obsługiwać. Ma to oczywiście wpływ na czas oraz koszta. Musimy posiadać programistów specjalizujących się w technologi dedykowanej platformy mobilnej. Ale czy na pewno?

Można się skusić na tzw. rozwiązania cross-platformowe, czyli np. na tytułowego Xamarina. Ale czy wybór takiej technologii na pewno pozwoli na skrócenie czasu projektu x razy?

Realia rynkowe

Realia rynkowe są takie, że dziś głównie liczą się dwa systemy:

    Android - ponad 80% udział w sprzedaży nowych urządzeń
  • iOS - kilkunastoprocentowy udział w sprzedaży nowych urządzeń

Pozostałe systemy (w tym przede wszystkim Windows Phone/Mobile) mają przy tych dwóch kolosach marginalny udział.

W praktyce większość startupów celuje we wspomnianą wyżej dwójkę. Poważniejsze firmy czasem powalczą jeszcze o platformę Microsoftu - choć w tej chwili dzieje się to w moim odczuciu głównie przez istniejące już od jakiegoś czasu urządzenia na rynku.

Oczywiście są pewne obszary, w których naprawdę warto wydać aplikację gdzie się da. Są to np. aplikacje bankowe, serwisy społecznościowe, czy też programy do oglądania video.

Wybraliśmy systemy docelowe - co dalej?

Załóżmy, że wybraliśmy platformy docelowe. Postanowiliśmy wydać nasza aplikację na Androida, iOS oraz Windows 10 (UWP). Tym samym potrzebujmy przynajmniej po jednym programiście piszącym w:

  • Javie
  • Objective C/Swift
  • C#

Ponieważ jesteśmy poważnym biznesem, znamy ryzyko i tym samym uwzględniamy popularny najnowszych przejęć Microsoftu. Założenie tego produktu jest bardzo proste. Ustawia on język C# (oraz ogólnie technologie giganta z Redmond) w centrum mobilnego developmentu. Przy pomocy jednego języka jesteśmy w stanie napisać aplikację na kilka platform naraz. Ponadto, wiele elementów kodu możemy współdzielić pomiędzy wszystkimi wspieranymi systemami. W praktyce w ten sposób możemy np. oprogramować całą komunikację sieciową, czy też warstwę MVVM.

Wykorzystując podejście Xamarin.Forms, możemy również napisać wspólny kod layoutu, który wygeneruje się odpowiednio w zależności od platformy docelowej. Czy jest to zatem rozwiązanie wszystkich problemów? Czy korzystając z tej jednej technologi możemy skrócić development trzykrotnie oraz pozbyć się 2/3 programistów? Nie do końca, ale po kolei.

Jak jest naprawdę?

Tak naprawdę wiele zależy od wybranego podejścia oraz liczby docelowych platform. Zakładając trzy wspomniane wcześniej systemy, wydaje mi się że z wyjściowych 300 story pointów (po 100 na każdą platformę), możemy zejść do 150-200 SP w zależności od stopnia skomplikowania aplikacji, używanych API oraz wybranego podejścia - Forms/Native.

Xamarin na pewno pomoże nam przy pisaniu backendowej części aplikacji. Tu możemy napisać dużą część wspólną. Pewne specyficzne API muszą być obsługiwane przez implementacje dla konkretnych systemów. Do takich rzeczy można zaliczyć np. wszelkie API odpowiedzialne za pobieranie rozszerzonych informacji o urządzeniu.

Wizualna część również nie napisze się sama. Problemów będzie tym więcej im więcej rozwiązań specyficznych dla wybranych platform będziemy wykorzystywać, a także w sytuacji gdy będziemy próbowali nadpisywać domyślne zachowania określonych kontrolek. Jak zwykle istnieje ścieżka szczęścia oraz kilka wersji alternatywnych.

Pisanie w Xamarinie nie zwalnia nas również z konieczności znajomości takich tematów jak plik manifestu dla Androida, czy pliki plist dla iOS.

W obu podejściach - Forms/Native, Xamarin wrappuje oryginalne API (w Forms dodatkowo najpierw trzeba przetłumaczyć warstwę abstrakcji). Stąd istnieje zawsze dodatkowa szansa, że programiści tej technologii popełnili jakiś błąd pisząc swoje interfejsy.

Podsumowując - zachowujcie dystans w wycenach Waszych projektów, bo potencjalnych problemów wciąż jest całkiem sporo;-)

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus