luka telefoniczna vs monotouch dla aplikacji intensywnie wykorzystującej dane

Question

Szukamy opracowania aplikacji intensywnie wykorzystującej dane na urządzenia mobilne. Naszym głównym problemem jest

1. Będziemy musieli przechowywać sporo danych na kliencie
2. Klient chce aplikacja do pracy w trybie offline
3. Nasz zestaw umiejętności jest bardzo Web Development C# ASP.Net. Zdecydowanie nie Objective C

Myśleliśmy z trzech możliwości dev

1. aplikacji internetowych z wykorzystaniem HTML5 pamięci lokalnej wykorzystując aplikacja off cache. Mamy limit 5 MB na lokalne przechowywanie, ale dla niektórych przeglądarek może to być nawet 2,5 MB.

2. Aplikacja internetowa przez PhoneGap do utworzenia aplikacji natywnej. Dużą zaletą jest to, że możemy używać systemu plików do przechowywania. Wadą jest to, że będzie musiał przejść przez App Store (w szczególności dla systemu iOS) - 30% przepustowość przychodów z aplikacji subskrypcji dla Apple

3. Tworzymy aplikację przy użyciu MonoTouch dla Androida i iOS. Dobrze - C# i .Net możemy to zrobić. Zły - no Blackberry

Pytanie

jestem stara się zobaczyć jakieś prawdziwe zalety korzystania MonoTouch nad PhoneGap w tej instancji. Czym oni są? Czy są jakieś?

Jako przykład w tym przypadku byłoby naprawdę przydatne, aby zapisać dane w systemie plików, ale uważam, że luka telefoniczna może to zrobić poprzez File object. Oczywiście monoTouch wykorzystałby System.IO.

Czy istnieją przypadki, w których istnieje określona dodatkowa funkcjonalność w MonoTouch - szczególnie funkcje przydatne dla urządzeń mobilnych, np. Funkcje geolokacyjne lub funkcje aparatu? Czy też luka telefoniczna ma wiele wspólnego z tymi problemami.

Cheeky Dodatkowe pytania

Czy istnieją jakieś inne opcje nie zostały pominięte lub jakiekolwiek inne główne zalety/wady dla trzech podejściach Mam nakreślonych że zapomnieli o?

Dzięki za ekspertyzy każdego

Answer 1

Właśnie zakończyliśmy bardzo intensywną aplikację danych napisaną w MonoTouch. Aplikacja uzyskuje dostęp do danych SAP za pośrednictwem warstwy pośredniej i udostępnia je w aplikacji. Umożliwia również bezpośrednie aktualizacje z aplikacji do systemu SAP, ponownie za pośrednictwem tej samej warstwy środkowej.

Jesteśmy w trakcie przenoszenia tego na Windows Phone i Android przy użyciu MonoDroid.

Zajęło mi trochę czasu, aby przekonać szefa, że ​​MonoTouch była droga do przodu, a my próbowaliśmy kilka różnych produktów wcześniej w tym jQuery telefonu, ExtJS i Obj C

czas starałem się przekonać go było czas przejęcia Attachmate i wyglądało, jakby MonoTouch był skazany. Na szczęście dla nas (mnie), Xamarin podniósł się jak przysłowiowy Feniks z płomieni i dalej rozwijali Mono * do tego, czym jest dzisiaj.

Jako programista C# (i entuzjasta Mono) główną wygraną nad Obj C lub jakimkolwiek HTML/JavaScript był fakt, że mogłem użyć C#, aby wykonać zadanie. Dokumentacja była bardzo dobra, a kiedy doco nie całkiem ją obniżyło (ostatnio zaktualizowano), zrobiła to społeczność.

Kanał IRC jest bardzo aktywny, a pracownicy Xamarin i ewangeliści społeczności zawsze są gotowi pomóc lub wnieść wgląd w problem. Podobnie jak listy mailingowe.

Kolejnym plusem są ekosystemy, które rozwijają się wokół MT. MT.Dialog sprawia, że ​​rozwijanie interfejsu użytkownika opartego na tabelach to absolutny powiew w porównaniu do odpowiednika XCode. Para z tym .Net BCL, która jest, co prawda, podzbiorem opartym na Silverlight, ale ma wszystko od serializacji, e-mailem do kryptografii itp. ... Jeśli .Net jej nie obejmuje lub nie ma konkretnego projektu Mono * , nadal możesz używać wtyczek ObjC z twoim kodem MT.

Nie zgadzam się z tym, że MT ma jeszcze "sprawdzić się" jako sprawdzona platforma. Używamy go i chociaż jesteśmy stosunkowo niewielką firmą, używa się go również w wielu większych firmach. Niektóre z aplikacji zaprezentowanych przez Apple w reklamach telewizyjnych w Aus są podobno napisane w języku angielskim.

Aby pozostać obiektywnym, 2 "minusy" MonoTouch'a dla mnie były takie, że nadal trzeba umieć czytać ObjC (chociaż, tbh, nie widzę tego jako con ... Programista "C#" Muszę być w stanie czytać i pisać mnóstwo języków w każdym razie) i fakt, że historycznie MonoDevelop był nieco błędny. Główne błędy wydają się być zmiażdżone, a ponieważ jest to projekt open source, zawsze możesz je naprawić i pomóc reszcie z nas!

Aby odebrać swoje obawy:

1. Będziemy musieli przechowywać sporo danych na kliencie

użyć klas System.IO .NET w języku C#. Jeśli nie jesteś pewien z nich, MSDN ma nadmiar przykładów (MT ukrywa realizację iOS przechowywania plików)

1. Klient chce aplikację do pracy w trybie offline

wszystkie one mogą to zrobić, ale Aplikacja natywna zawsze będzie się lepiej czuła w mojej opinii.

1. Nasz zestaw umiejętności to bardzo dużo tworzenia stron internetowych C# ASP.Net. Zdecydowanie nie Cel C

MonoTouch to C# - zagraj w swoje mocne strony i korzystaj z aplikacji już od tygodni, a nie miesięcy!

Moje 2 grosze! Nie wahałbym się ponownie wybierać tej samej trasy.

Answer 2

Użyłem PhoneGap na chwilę teraz (na WP7), ale nie używane MonoTouch, jednak jestem doświadczonym C#/programista Silverlight.

Kilka zalety MonoTouch:

• kod skutkuje native UI, dając najlepszą jakość na wszystkich platformach
• C# jest językiem programowania „przedsiębiorczy wytrzymałości”.Jest dobrze przystosowany do opracowywania aplikacji intensywnie korzystających z danych
• Twoje obecne zestawy umiejętności będą Ci dobrze służyć tutaj
• Dostępne są numerous applications written with MonoTouch dostępne w sklepie z aplikacjami.

Kilka wady MonoTouch:

• Piszesz C# kod ponownie Apis iPhone, dlatego do portu na Androida, musisz mieć osobne warstwy interfejsu użytkownika dla MonoDroid.

Zalety PhoneGap:

• To zaczyna wyglądać całkiem dojrzałym ram, z numerous applications written using PhoneGap całym zakresie obsługiwanych systemów operacyjnych.
• Istnieje dobra pomoc dla społeczności PhoneGap
• Używa HTML5, który wielu postrzega jako technologię przyszłości. Jest to dość ogólne stwierdzenie, jednak większość dużych graczy (Microsoft, Adobe, ...) popiera to.

Wady PhoneGap:

• Wykorzystuje JavaScript, prawdopodobnie most misunderstood language in widespread use!
• Interfejs użytkownika jest napisany w HTML. Pomimo najlepszych starań frameworków takich jak jQuery Mobile nigdy nie będzie natywna.
• Ponieważ ma specyficzny dla platformy kod typu "shim", zapewniający spójny interfejs API, można znaleźć problemy związane z platformą. Jednakże odkryłem, że zespół PhoneGap naprawia je dość szybko.

Podsumowując, trudny wybór!

Osobiście wybrałbym PhoneGap, ale nie staram się emulować wygląd i działanie konkretnego systemu operacyjnego, a raczej stworzyć własny interfejs użytkownika, który działa dobrze dla aplikacji i używać go na wszystkich platformach.

Answer 3

Pojawiła się nowa wersja MonoTouch, która ukazała się wczoraj (8 lutego 2012 r.) - 5.2. Wiele nowych funkcji ułatwiających i przyspieszających tworzenie aplikacji na iOS. Szczegółowe informacje na ten temat można uzyskać pod tym adresem: http://blog.xamarin.com/

Jedną z rzeczy, która sprawia, że ​​MonoTouch jest szczególnie interesującą technologią, jest możliwość opracowania kilku ładnych, wyrafinowanych aplikacji, które mogą działać bez konieczności połączenia z Internetem. To może być biggie.