Jakie podejście zastosować przy tworzeniu aplikacji przeznaczonych na wiele platform?


9

W przypadku aplikacji kierowanych na wiele platform widzę głównie dwa podejścia do programowania -

  • Wybierz platformę programistyczną podobną do JAVA. Posiadaj jedno rozwiązanie kodu i pozwól, aby pośredni środowisko wykonawcze obsługiwał różne platformy. Jeśli coś pójdzie nie tak na dowolnej platformie, popraw trochę kod. Ale zachowaj to dla wszystkich.

  • Utwórz modułowy kod oddzielający logikę rdzenia i interfejs użytkownika. Opracuj osobne interfejsy dla odpowiednich platform, które będą wywoływać te same biblioteki podstawowe. Zbuduj aplikację osobno dla każdej platformy docelowej.

Który więc wybrać? Wiem, odpowiedź zacznie się od „ To zależy ”. Ale chcę usłyszeć wasze opinie na temat tych podejść i czynników, które należy wziąć pod uwagę przy wyborze jednego z nich.


2
Jeśli chodzi o to pytanie, nie ma sposobu, aby na nie odpowiedzieć bez użycia „to zależy”. Zależy to od wielu czynników, takich jak rzeczywiste platformy, które masz na myśli, czy planujesz samodzielną aplikację komputerową lub planujesz korzystać z niektórych usług internetowych, jakie masz plany dotyczące interfejsu użytkownika (taki sam dla każdej platformy czy różnych?) I wkrótce. Czy uważasz, że model rozwoju Qt lub Gtk pasuje do pierwszego modelu, czy nie? Co z .Net i Mono? Mam kontynuować ...?
Paweł Dyda

@Gulshan Przepraszamy, oczywiste pytanie - czy istnieje powód, dla którego nie może to być aplikacja internetowa i / lub zrobiona w / w coś takiego jak Adobe Air?
jellyfishtree,

Ta strona służy bardziej subiektywnym pytaniom i odpowiedziom, ale również powody do akceptacji. To sprawia, że ​​czujemy, że się bawisz. Zazwyczaj szukam ostatnio opublikowanych pytań, a nie odpowiedzi bez odpowiedzi.
JeffO

Odpowiedzi:


3

Odkładając na bok obecne Oracle / Apache / Google, nadal trudno jest pokonać JVM w tym celu. Jest naprawdę bardzo wysokiej jakości na większości platform, uniwersalny, i masz wiele języków do wyboru (Java, Clojure, Scala itp.). Pozwala kierować reklamy na architekturę pojedynczej maszyny (VM) i nie martwić się zbytnio o konkretny sprzęt użytkownika końcowego.

To powiedziawszy, istnieją pewne typy aplikacji, które mogą nie być tak odpowiednie: przychodzi na myśl sieć niskiego poziomu, podobnie jak ciężkie przetwarzanie grafiki / wideo.


2

Przejdź na HTML5. Każda platforma z przeglądarką HTML5 może uruchomić twoją aplikację. Chociaż HTML5 nie jest jeszcze gotowy na długi czas, podejście do aplikacji internetowych jest.


2
Brak pełnych funkcji przeglądarek HTML5.
Craig,

2

W edytorze dźwięku Audacity używamy wxWidgets jako naszej biblioteki wieloplatformowej. Ponieważ musimy połączyć się z bibliotekami C i potrzebujemy szybkości i dostępu na niskim poziomie, podejście JVM nie zadziałałoby dla nas. Kod GUI jest 95% taki sam na wszystkich platformach. Używamy #ifdefs dla małych odmian. Uważamy jednak, że niezbędne jest, aby programista pracował na każdej z trzech platform (Mac, Windows Linux), ponieważ nawet przy użyciu biblioteki między platformami zmiana na jednym komputerze jest zbyt łatwa, aby coś zepsuć na innym.

Jeśli możesz uzyskać wymaganą wydajność, wybierz JVM. Jeśli nie możesz, użyj QT lub wxWidgets, a ja sugerowałbym QT w porównaniu z wxWidgets, ponieważ jest mniej pracy, aby ładnie wyglądać.


1
+1 za „niezbędne, aby programista pracował na każdej platformie”. Projekty wieloplatformowe szybko stają się pojedynczą platformą, jeśli programujesz tylko dla jednej platformy naraz.
AShelly,

2

Jako programista w czasie rzeczywistym z powodzeniem zastosowałem opcję podobną do 2 - oddzielne moduły specyficzne dla platformy ze wspólnym interfejsem API używanym przez podstawową logikę. Jednak nic, co zrobiłem, nie ma interfejsu użytkownika - sieci, audio, przesyłania danych - w tym przypadku jest to interfejs sprzętowy niskiego poziomu, który jest specyficzny dla platformy.

Zrobiłem to w ten sposób z kilku powodów:

1) Aby uzyskać optymalną wydajność na każdej platformie

2) Aby skorzystać z funkcji oferowanych tylko na 1 platformie

3) (J) Maszyny wirtualne nie istniały na niektórych platformach (systemy wbudowane, konsole do gier ...)


2

To zależy od tego, co jest dla Ciebie ważne :)

Kiedy 10 lat temu stanęliśmy przed wyborem dotyczącym wieloplatformowej aplikacji na Maca / Windowsa, dobrze rozejrzeliśmy się po różnych opcjach międzyplatformowych - Java, Qt, wxWidgets itp. Problem polegał na tym, że wygląd interfejs użytkownika był dla nas bardzo ważny, a wszystkie aplikacje „wieloplatformowe” wyglądały na dobrze skompromitowane. W końcu gryzliśmy kulę i budowaliśmy własny rdzeń wieloplatformowy z niestandardowym interfejsem użytkownika dla każdej platformy na górze (napisanym w PowerPlant dla komputerów Mac i MFC w systemie Windows). Z biegiem czasu osiągnęliśmy całkiem niezły wynik, a część „wieloplatformowa” zrobiła się grubsza bez narażania interfejsu użytkownika.

Teraz znów patrzymy na tę decyzję dotyczącą nowego projektu. Patrząc teraz na opcje, prawdopodobnie wybrałbym Qt - jest darmowy i naprawdę wydaje się ładnie dojrzał. Java mogła być opcją, ale tak naprawdę nie możemy znieść wydajności (przetwarzamy obrazy 3D).

Jeśli interfejs użytkownika jest dla Ciebie naprawdę ważny, podejrzewam, że będziesz musiał zainwestować sporo czasu, aby wszystko wyglądało dobrze na każdej platformie, niezależnie od tego, czy używasz Qt, czy rzucasz własną. W przypadku aplikacji wewnętrznych lub specjalistycznych, w których użytkownicy mogą bardziej akceptować mniej dopracowany interfejs użytkownika, może być w porządku!


1

Wszyscy robią duże zamieszanie z powodu języków, takich jak Java, które są „wieloplatformowe”, ale tak naprawdę chodzi o to, że można raz skompilować i uruchomić wszędzie. Nawet w języku takim jak Java (lub C # / mono) nadal będziesz potrzebować warstw abstrakcji, aby poradzić sobie ze szczegółowymi szczegółami systemu operacyjnego w niektórych obszarach.

C ++, a właściwie większość języków, jest wieloplatformowa, wystarczy skompilować, aby dotrzeć do każdej platformy.

Kluczem jest raczej proces niż narzędzia / języki:

  1. Upewnij się, że masz zintegrowany proces kompilacji, który buduje i uruchamia testy jednostkowe dla wszystkich platform docelowych .
  2. Upewnij się, że każdy programista testuje na wszystkich platformach docelowych przed wpisaniem kodu - to oczywiście oznacza upewnienie się, że zawsze programista ma dostęp do odpowiedniej liczby maszyn / vms.
  3. Streszczenie dobrze. Streszczenie wszystkiego, co wywołuje rodzime api. Napisz biblioteki, które zamykają te wywołania.
  4. Jeśli robisz coś poza dość prostym interfejsem użytkownika, który tylko spełnia najniższy wspólny mianownik, po prostu zaakceptuj, że kod GUI nie jest wieloplatformowy. Wyodrębnij warstwę GUI / prezentacji i zakoduj ją osobno dla każdej platformy. Tak, istnieją międzyplatformowe zestawy narzędzi GUI, które są odpowiednie dla prostych aplikacji, ale jeśli robisz coś bardziej zaawansowanego, będziesz chciał kodować do możliwości natywnej platformy.

Kroki te są takie same bez względu na używany język / zestaw narzędzi / strukturę.


1

Wykorzystaj sieć!

Poważnie, jeśli chcesz NAJBARDZIEJ uderzyć za złotówkę, napisz aplikację internetową.

Dlaczego?

  • Klienci WWW zazwyczaj nie wymagają dużej mocy komputera.
  • Klienci WWW są WSZĘDZIE. Nie tylko PC / MAC / Linux, ale także telefony, urządzenia mobilne i wiele innych.
  • Nic dodatkowego do pobrania dla użytkowników! (Zwykle, chyba że chcesz czegoś wymyślnego i użyć Flasha lub Silverlight)
  • Wszystkie typowe komponenty są po stronie serwera i mogą to być Java, .NET, PHP lub połączenie wielu istniejących komponentów. Klient nie powinien się tym przejmować!

Nawet dwa wymienione przez ciebie podejścia są bardzo podobne. Przeglądarka internetowa renderuje HTML dla wielu bazowych architektur. Podobnie JVM interpretuje kod Java w sposób, który ma sens dla podstawowego sprzętu. Internet ma jednak po prostu szerszą bazę klientów!


0

Miałem dość szczęścia z Mono. Mogę napisać ten sam kod dla komputerów z systemem Windows, jak dla komputerów z systemem Linux, i w większości przypadków działa na obu. I mogę korzystać z umiejętności, które już znam w C # i Winforms.


Jakiego interfejsu używasz, czy masz na myśli aplikacje oparte na serwerze? Jestem ciekawy, ponieważ mam działającą aplikację korzystającą z Winforms, i przeniosłem się do Mono i jest to miłe, ale zajmie OGROMNĄ pracę, aby być jak „prawdziwe” winformy. Być może GTK # jest lepszy? MonoDevelop jest fajny, ale może nieco niezręczny.
Dan Rosenstark,

W przypadku Mono można zastosować oba podejścia. Jak Yar, którego obserwujesz i dlaczego? Oto jest pytanie.
Gulshan,

Tak, nie zdawałem sobie sprawy, że szukasz idealnej wierności formy między platformami. Możesz to zrobić za pomocą GTK #, ale dostaniesz to kosztem „ładnego”, ponieważ taki zwykły zestaw narzędzi musi mieć „najniższy wspólny mianownik”. Jestem skłonny zgodzić się z StartClass0830: HTML5 to dużo pracy, ale możesz zrobić z nim naprawdę fajne rzeczy na wiele platform.
Robert Harvey

0

Najpierw zrób dowód koncepcji.

Jeśli jest to dość złożona aplikacja, ustalenie dowodu koncepcji pozwoli ci zorientować się, jakich funkcji językowych potrzebujesz i jakich obszarów będziesz potrzebować do wykorzystania frameworku lub bibliotek stron trzecich.

Potrzebne funkcje językowe i biblioteki określą, który język wybierzesz (a tym samym, w jaki sposób poradzisz sobie z obsługą wielu platform)


0

Zbudowałem system, zaczynając od aplikacji komputerowej, 15 lat temu, gdy Java była jeszcze w powijakach i nie była gotowa do użycia przy tworzeniu tego rodzaju aplikacji. Wiedziałem, że muszę mieć rdzeń w C ++ i od samego początku zaprojektowałem go tak, aby był wieloplatformowy, w tym używać typów o różnych rozmiarach (np. Int32 zamiast int lub long), aby mógł działać na komputerach Mac, Windows i UNIX (wcześniejszych niż Linux) dni).

W tym czasie starałem się znaleźć dobre środowisko interfejsu dla wielu platform, było ich wtedy kilka, w tym XVT. Przeszedłem szkolenie XVT i kiedy zacząłem tworzyć prawdziwą aplikację, zdałem sobie sprawę, że nie będę w stanie stworzyć czystego, natywnego wyglądu na platformie (zaczynając od Maca). Zrezygnowałem z tego pomysłu i zbudowałem natywny interfejs Maca (PowerPlant) na przenośnym rdzeniu.

Kilka lat później przeszliśmy na system Windows (interfejs użytkownika w MFC). Za drugim razem szybsze było budowanie interfejsu użytkownika, przez krótki czas utrzymywaliśmy równolegle interfejs Mac i Windows, a następnie przeszliśmy na system Windows. Rdzeń później przeszedł na różne wersje systemów UNIX i Linux, aby umożliwić nam wykonywanie obliczeń serwerowych. Rdzeń działał dobrze, z pewnymi poprawkami, kiedy przygotowaliśmy go do pracy w wersji 64-bitowej.

Teraz wracam do korzystania z komputera Mac i chciałbym wrócić na komputer Mac, ale rozmiar i złożoność aplikacji sprawia, że ​​jest to trudny wybór. Nadal ma sens, aby większość tej aplikacji była aplikacją komputerową - to jest jak środowisko CAD. Ale zamiast budować interfejs ponownie w języku C / C ++ specyficznym dla platformy (i nadal utrzymywać interfejs oparty na MFC), jestem bardziej skłonny do przepisania całego stosu w Javie, aby mógł on działać na wielu platformach.

Nadal mogą istnieć powody, by uruchamiać rdzeń inny niż Java, powiedzmy C ++ tak jak my. Chciałbym jednak przeprowadzić wczesne testy wydajności, aby sprawdzić, czy jest to naprawdę wymagane. I uważnie przyjrzałbym się mojemu interfejsowi użytkownika, aby sprawdzić, czy mógłbym budować go jako aplikację internetową, połączoną z rdzeniem za pośrednictwem usług internetowych, dzięki czemu mógłbym mieć wielu klientów - aplikacje komputerowe, aplikacje mobilne, aplikacje internetowe itp. Gdybym potrzebował utworu w C lub C ++, czy mógłby zostać napisany pod warstwą Java? Lub jako usługa internetowa?

Kolejna uwaga - jak długo będzie działać Twoja aplikacja? Jak skomplikowany będzie? Jeśli masz jakieś pomysły na ten temat, zastanów się nad możliwą długowiecznością dowolnych bibliotek interfejsu użytkownika, których używasz, oraz swoją zdolnością do utrzymywania z czasem pomocy ludzi w ich utrzymaniu. To może być trudne do rozważenia teraz, ale warte przemyślenia.

- Alex


JVM okazał się bardzo stabilny pod względem kompatybilności wstecznej biblioteki wykonawczej. W tym scenariuszu byłoby bardzo dobrze dopasowane ...

0

Jeśli możesz uczynić to aplikacją internetową, uczyń ją aplikacją internetową. Korzystając z zestawów narzędzi takich jak ExtJS , tworzenie interfejsów użytkownika zgodnych z różnymi przeglądarkami jest stosunkowo łatwe.

W przeciwnym razie Java lub QT + C ++ lub C + Wx są możliwymi opcjami posiadania jednego źródła dla wszystkich.

Drugie podejście jest odpowiednie, jeśli chcesz, aby aplikacja wyglądała i działała natywnie na każdej platformie docelowej. Natywne aplikacje Mac wyglądają inaczej niż natywne aplikacje Windows, wystarczy użyć innej skórki, a skróty klawiszowe nie wystarczą, aby to pokryć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.