Architektura aplikacji a współdzielenie kodu między aplikacjami dla platformy desktopowej i mobilnej

0

Tworzenie aplikacji wymaga połączenia twardej wiedzy analitycznej, programistycznej z umiejętnością tworzenia zaawansowanych, lecz jednocześnie prostych w obsłudze rozwiązań, gdzie końcowy użytkownik powie: „wow – ten produkt rozwiązuje moje problemy”. Niezależnie od tego, czy jesteś programistą, analitykiem czy odpowiadasz za stronę biznesową projektu, musisz wiedzieć, że budowanie czegokolwiek ma sens tylko i wyłącznie
wtedy, gdy w centrum wykonywanych działań jest klient i jest to wspólna praca wszystkich zaangażowanych osób. Kończą – a może już skończyły – się czasy, gdy developerzy tworzyli rozwiązanie na podstawie specyfikacji, którą analityk przygotował bez porozumienia, zapisanej na setkach stron dokumentacji. Nic odkrywczego? Niby tak, tylko że to już nie jest agile, scrum, scrumban development… to połączenie świata biznesowego ze światem technologii. To łączenie metodyk zwinnego budowania biznesu w metodykami zwinnego wytwarzania oprogramowania. Nie ma agile bez lean, nie ma backlogu bez zweryfikowanych hipotez... Nawet najlepsze zwinne podejście nie doprowadzi do końcowego sukcesu, jeżeli budowana aplikacja będzie bazowała na wymaganiach, które pozostaną niezweryfikowanymi hipotezami.

W niniejszym artykule opowiem, jak przygotować architekturę wieloplatformowej aplikacji, która działa na urządzeniach mobilnych oraz desktopie. W obecnej wersji wpieramy platformy ios i android oraz Windows 7 (WPF). W przyszłości aplikacja będzie dostosowana także do wymagań Windows 10 (UWP), korzystając z .NET Core oraz prawdopodobnie postanie wersja na Mac Os z wykorzystaniem Xamarin.mac. Architektura ta nie powstałaby
prawidłowo, gdyby nie to, iż klient oraz zespół developerski cały czas skupiał się na tym, aby stworzyć rozwiązanie, które będzie zaspokajało potrzeby użytkowników – to w pierwszym punkcie. Następnie potrzeby klienta – właściciela produktu, a w ostatnim potrzeby zespołu
programistycznego – tak aby rozwój aplikacji mógł przebiegać długofalowo i płynnie. Aby to osiągnąć, już na samym początku trzeba zadać sobie pytanie o to, co chcemy osiągnąć i w jaki sposób. Głównym zadaniem aplikacji CharCRM jest obsługa procesu zamawiania towarów z branży
optycznej. Ze względu na specyficzne know how oraz wymagania biznesowe, których nie spełniało żadne z rozwiązań obecnych na rynku, klient zdecydował się na stworzenie dedykowanej aplikacji.

Zapraszamy do lektury artykułu Tomka Soroki, który ukazal się w sierpniowym Programiście
https://www.leaware.com/pl/blog/1118/architektura-aplikacji-a-wsp%C3%B3%C5%82dzielenie-kodu-mi%C4%99dzy-aplikacjami-dla-platformy-desktopowej-i-mobilnej

0

Jeśli to ma być o architekturze aplikacji to jak dla mnie artykuł jest dość płytko napisany, sprawia wrażenie suchego raportu, a nie porywającego case study. Trochę szkoda, bo tematyka jest ciekawa, i autor pisał to na podstawie realnych doświadczeń "z produkcji", jednak... ja w tym artykule widzę mało architektury (zaledwie jakieś ogólniki typu "wzorzec MVVM jest fajny" i oczywistości typu współdzielenie kodu albo używanie sprawdzonych bibliotek) a bardziej opis podjętych długofalowych decyzji biznesowych (co też jest ważne - po prostu treść nie zgadza mi się z tytułem - miało być o architekturze, a nie o growth hackingu czy innych koncepcjach bardziej biznesowych, w porywach biznesowo-technicznych, a nie związanych faktycznie z architekturą kodu).

Sama architektura też jakoś strasznie upraszczająco została potraktowana. Wklejony tam diagram architektury z lotu ptaka ( https://www.leaware.com/Content/Media/UploadedImage/rys3.jpg ) przypomina mi ten obrazek: https://imgur.com/KrZVDsP
Przypominają mi się projekty, w których brałem udział, gdzie też na wstępie pokazywano mi takie proste diagramy z lotu ptaka, ale po wejściu do projektu okazało się, że już tak wesoło i prosto to nie wygląda.

Tym niemniej ciekawy case, artykuł mnie zainteresował, ale jednak czuję, że w sumie nie wiadomo czy jest on:

  • o decyzjach stricte biznesowych, związanych bardziej z rozwojem produktu (growth hacking, minimum viable product, decyzja biznesowe, że zaczynamy od Windows 7 itp.)
  • o wyborach stricte technologicznych (MS SQL, Recurly itp.)
  • o właściwe architekturze (MVP, współdzielenie kodu czy inne rzeczy niezależne od konkretnej technologii, ale właśnie nadające strukturę całemu projektowi).

Na pewno te 3 rzeczy wpływają na siebie (np. i np. decyzje biznesowe wpływają na dobór technologii czy na tworzoną architekturę), ale jednak mam wrażenie, że w tym artykule jakoś mętnie zostało to napisane.

0

Z tego względu odrzuciliśmy technologie web czy hybrydowe do jego stworzenia.
Wiedzieliśmy, że proces analizy danych jest na tyle skomplikowany, że aplikacja hybrydowa,
a co gorsza webowa w przypadku urządzeń mobilnych nie pozwoli na tak zaawansowaną
interakcję i użyteczność, aby stworzyć rozwiązanie, które pokochają użytkownicy.

Co w konkluzji daje

Do stworzenia aplikacji na platformy mobilne skorzystaliśmy z technologii Xamarin, która jest
kompatybilna z wzorcem MVVM i bardzo dobrze wspiera MvvmCross, co udało nam się
sprawdzić w boju w wielu dużych projektach dotyczących aplikacji mobilnych.

???

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