Comments 28
Можете поделиться вашим опытом.
1)Сокращаются ли сроки разработки используя Xamarin по сравнению с нативными средствами (пусть даже есть на совсем чуть-чуть)?
2)Много ли проблем всплывает при использовании Xamarin (возможно баги в самой платформе)?
3)В чем девелопите, Xamarin Studio или Visual Studio + MacOS?
4)На какие жертвы приходиться идти что бы сделать как можно больше частей приложения кросплатформенными (PCL, MVVMCross)?
1)Сокращаются ли сроки разработки используя Xamarin по сравнению с нативными средствами (пусть даже есть на совсем чуть-чуть)?
2)Много ли проблем всплывает при использовании Xamarin (возможно баги в самой платформе)?
3)В чем девелопите, Xamarin Studio или Visual Studio + MacOS?
4)На какие жертвы приходиться идти что бы сделать как можно больше частей приложения кросплатформенными (PCL, MVVMCross)?
Не от туда, но попробую ответить
1) сложно судить, ведь требуется специалисты разного уровня и платформенные особенности все равно выпирают наружу.
2) Баги в платформе есть (впрочем они есть и в Windows Phone SDK) так или иначе все встреченные баги обходились и яснее куда их репортить bugzilla.xamarin.com/
3) я использую и то, и то. До недавнего времени у меня часто студия не хотела деплоить на мак. Ну и на виндовой машине постоянно проблемы с лицензией ксамарина (как-то странно у них проверка отрабатывает) всплывают.
4) Жертвой умственных затрат: писать на 3 платформы тяжело — везде свои особенности. На проект с небольшим сроком поддержки не рекомендую MVVMCross. А если нужно поддерживать и обновлять длительный срок, то очень неплохой вариант.
Скажу что для меня писать под iOS на C# в разы приятнее, чем на Obj-c. Очень рассчитываю на грядущий редактор интерфейсов в XamarinStudio.
1) сложно судить, ведь требуется специалисты разного уровня и платформенные особенности все равно выпирают наружу.
2) Баги в платформе есть (впрочем они есть и в Windows Phone SDK) так или иначе все встреченные баги обходились и яснее куда их репортить bugzilla.xamarin.com/
3) я использую и то, и то. До недавнего времени у меня часто студия не хотела деплоить на мак. Ну и на виндовой машине постоянно проблемы с лицензией ксамарина (как-то странно у них проверка отрабатывает) всплывают.
4) Жертвой умственных затрат: писать на 3 платформы тяжело — везде свои особенности. На проект с небольшим сроком поддержки не рекомендую MVVMCross. А если нужно поддерживать и обновлять длительный срок, то очень неплохой вариант.
Скажу что для меня писать под iOS на C# в разы приятнее, чем на Obj-c. Очень рассчитываю на грядущий редактор интерфейсов в XamarinStudio.
1. Сокращаются. Хотя не сильно ощутимо, скорее упрощается поддержка проекта и уменьшается число ошибок
2. Бывает, но в целом все обходится. Пожалуй, самый большой минус — размер приложения под Android. Mono-машина дает +10 мегабайт
3. Xamarin Studio
4. Мы не используем кросс-платформенный UI, только нативный. Соответственно общий код это работа с API (есть в любом приложении) и бизнес-логика. До 30% кода общие.
2. Бывает, но в целом все обходится. Пожалуй, самый большой минус — размер приложения под Android. Mono-машина дает +10 мегабайт
3. Xamarin Studio
4. Мы не используем кросс-платформенный UI, только нативный. Соответственно общий код это работа с API (есть в любом приложении) и бизнес-логика. До 30% кода общие.
UFO just landed and posted this here
На Android C# работает быстрее Java из-за лучшего дизайна языка
Заинтриговали. А можно поподробнее? С реальными тестами.
Через месяц планируем сделать подробный пост с тестами.
Пока повторю ссылку blog.xamarin.com/android-in-c-sharp/#performance
Пока повторю ссылку blog.xamarin.com/android-in-c-sharp/#performance
Ребята из Xamarin как-то раз обработали андроид транслятором из явы в шарп и получили хороший такой рост производительности. См. XobotOS
Я использовал Xamarin + Android в течении 5 дней и вот, что я нашёл:
1) Нет автокомплита для XML в Xamarin. Так что всякие хеллоуворды со словами «ну мне сейчас долго печатать, вот я скопирую» писать можно, но когда дело доходит до реальной разработки — весь интерфейс вы будете писать по памяти. Я эти 5 дней переключался между окнами IntelliJ и Xamarin.
2) Все коллекции в C# неявно копируются в соответствующие коллекции Java, разве что вы специально используете специальные обёртки (разумеется, без всяких ништяков вроде параллельного foreach) — guides/android/advanced_topics/api_design.
3) Большая разница в API между платформами. В Windows Phone выпилено почти всё, так что если вы пишете под Xamarin Android на 100%, то у вас с Windows Phone будет не выше 60% совместимости. Я не знаю, как это вообще обходят, но вам придётся переписывать приложение заново. Кстати, есть такие ситуации, когда часть API есть под WP, но нет под Windows. И наоборот. Будьте очень осторожны.
1) Нет автокомплита для XML в Xamarin. Так что всякие хеллоуворды со словами «ну мне сейчас долго печатать, вот я скопирую» писать можно, но когда дело доходит до реальной разработки — весь интерфейс вы будете писать по памяти. Я эти 5 дней переключался между окнами IntelliJ и Xamarin.
2) Все коллекции в C# неявно копируются в соответствующие коллекции Java, разве что вы специально используете специальные обёртки (разумеется, без всяких ништяков вроде параллельного foreach) — guides/android/advanced_topics/api_design.
3) Большая разница в API между платформами. В Windows Phone выпилено почти всё, так что если вы пишете под Xamarin Android на 100%, то у вас с Windows Phone будет не выше 60% совместимости. Я не знаю, как это вообще обходят, но вам придётся переписывать приложение заново. Кстати, есть такие ситуации, когда часть API есть под WP, но нет под Windows. И наоборот. Будьте очень осторожны.
А самый большой недостаток цена продукта на обычного разработчика, 10К для того чтобы написать что то бесплатное не айс. Сделали бы первый год или одно приложение бесплатное чтобы можно было бесплатно разработать. Просто не очень понятно если я и так не получаю коммерческой выгоды, плачу за лицензию разработчика apple сто долларов еще и xamarin studio покупать считаю перебор, другое дело если я в приложение воткну баннеры или буду его продавать.
Работал в TI некоторое время. С тех пор писал несколько проектов на заказ и большое множество «для себя».
Все что написано в статье — тру. После пресного Java6, работать на .NET 4.5 это нечто.
Недостатки, само собой, есть. Но «плюсы» их перекрывают с лихвой.
Все что написано в статье — тру. После пресного Java6, работать на .NET 4.5 это нечто.
Недостатки, само собой, есть. Но «плюсы» их перекрывают с лихвой.
Интересно) Всегда нравился C#, но считал, что С++ популярнее… Не думал, что С# так станет популярен.
«На Android C# работает быстрее Java из-за лучшего дизайна языка (value types, real-generic types, невиртуальные методы по умолчанию) и более зрелой Mono Runtime в сравнении с молодым Dalvik.»
Ничто не мешает писать на андроиде с использованием C++. Причем как я понимаю большая часть фреймворков, библиотек и т.д. написаны на яве.
Также мне интересно. насколько легко и просто я смогу писать на C# под андроид, на Linux?
xamarin как я понял Linux'ом не поддерживается?
Насчет производительности я не уверен. Например гугл всегда может оптмизировать Dalwik дальше, и он как бы встроен в OS. В то же самое время виртуальная машина C# должна быть в самом приложении? Т.е. это + к размеру приложения. И если приложение не будет обновляться то работать быстрее оно не будет, хотя Java приложения будут работать быстрее из за оптимизиаций Dalwik.
Ничто не мешает писать на андроиде с использованием C++. Причем как я понимаю большая часть фреймворков, библиотек и т.д. написаны на яве.
Также мне интересно. насколько легко и просто я смогу писать на C# под андроид, на Linux?
xamarin как я понял Linux'ом не поддерживается?
Насчет производительности я не уверен. Например гугл всегда может оптмизировать Dalwik дальше, и он как бы встроен в OS. В то же самое время виртуальная машина C# должна быть в самом приложении? Т.е. это + к размеру приложения. И если приложение не будет обновляться то работать быстрее оно не будет, хотя Java приложения будут работать быстрее из за оптимизиаций Dalwik.
Все дело в фреймворке Mono for android, которым и занимается Xamarin. Этот фреймворк не что иное как обертка вызовов функций java машины.
Писать на чем бы то ни было кроме Java под андроид, это адский труд, потому как все вызовы к функциям API идут через JNI. Посмотрите на досуге что это такое. Я как то копнул в это болото и больше соваться туда нет никакого желания.
Писать на чем бы то ни было кроме Java под андроид, это адский труд, потому как все вызовы к функциям API идут через JNI. Посмотрите на досуге что это такое. Я как то копнул в это болото и больше соваться туда нет никакого желания.
Т.е. таки быстрее чем Java оно ну никак не может? Разве что если вообще не использовать API, но тут тогда проще C++ использовать еще быстрее будет.
Не верное суждение.
Вызовы API нужны не всегда. Это как правило дерганье UI и прочей специфичной требухи андроида. Но по мимо этого есть масса других вещей.
К примеру многопоточный код. Работа с файлами, сетью и т.д. Ведь mono это вся сила .net 4.5 фреймворка в ваших руках!
Вызовы API нужны не всегда. Это как правило дерганье UI и прочей специфичной требухи андроида. Но по мимо этого есть масса других вещей.
К примеру многопоточный код. Работа с файлами, сетью и т.д. Ведь mono это вся сила .net 4.5 фреймворка в ваших руках!
Может, Mono использует отдельную виртуальную машину, Java машина используется для нативных вызовов.
Рекомендую почитать blog.xamarin.com/android-in-c-sharp/#performance
Выдержки оттуда:
Java went with a full-backwards compatibility approach, while C# baked the support into the runtime. The C# approach led to a simple-to-use, simple-to-understand generics setup as well as being much more performant and complete.
Furthermore, Mono as a virtual machine has matured substantially in the last 10 years and is now considered to be on its 8th generation.
All of this adds up. You can see the massive difference in the performance of structs and generics in this benchmark we ran of a simple binary tree implementation in Java and C#:
НО на самом деле все это под вопросом. Кому нужна производительность структур и дженериков в мобильных приложениях? Основная нагрузка это сеть и UI, а эти вещи идут через Java-машину. По-моему, производительность Mono просто не хуже в реальных приложениях.
Рекомендую почитать blog.xamarin.com/android-in-c-sharp/#performance
Выдержки оттуда:
Java went with a full-backwards compatibility approach, while C# baked the support into the runtime. The C# approach led to a simple-to-use, simple-to-understand generics setup as well as being much more performant and complete.
Furthermore, Mono as a virtual machine has matured substantially in the last 10 years and is now considered to be on its 8th generation.
All of this adds up. You can see the massive difference in the performance of structs and generics in this benchmark we ran of a simple binary tree implementation in Java and C#:
НО на самом деле все это под вопросом. Кому нужна производительность структур и дженериков в мобильных приложениях? Основная нагрузка это сеть и UI, а эти вещи идут через Java-машину. По-моему, производительность Mono просто не хуже в реальных приложениях.
> Также мне интересно. насколько легко и просто я смогу писать на C# под андроид, на Linux?
Бои идут с момента выпуска Monodroid. Где-то когда-то читал, что Мигель считает, что линуксоиды не привыкли платить за софт, поэтому выпускать Xamarin для него не собирается. И вообще, разочаровался в линуксе.
Бои идут с момента выпуска Monodroid. Где-то когда-то читал, что Мигель считает, что линуксоиды не привыкли платить за софт, поэтому выпускать Xamarin для него не собирается. И вообще, разочаровался в линуксе.
Мой опыт по работе с Xamarin:
1. Общей кодовой базы между платформами мало, меньше чем они любят рекламировать.
2. Самая мозголомная часть кодовой базы как раз общая. Ядро, всякие обращения к БД, алгоритмы работы с данными.
3. Один язык очень сильно помогает дописывать все остальное.
4. Уметь читать нативный язык целевой платформы нужно, но это осваивается очень быстро.
1. Общей кодовой базы между платформами мало, меньше чем они любят рекламировать.
2. Самая мозголомная часть кодовой базы как раз общая. Ядро, всякие обращения к БД, алгоритмы работы с данными.
3. Один язык очень сильно помогает дописывать все остальное.
4. Уметь читать нативный язык целевой платформы нужно, но это осваивается очень быстро.
UFO just landed and posted this here
C# — лучший язык для мобильной разработкиА вот соберёт GNUstep Project на Кикстартере необходимую сумму, Obj-C снова вырвется вперёд :)
Sign up to leave a comment.
C# — лучший язык для мобильной разработки