Comments 29
Лучше все таки заниматься нативной разработкой, а не придумывать вело-костыли.
Там основной костыль — это Xamarin.Forms, который из себя представляет просто рассадник багов. Если использовать только обёрки над нативными классами, то всё вполне стабильно и прилично.
Ну так вся фишка в Xamarin.Forms, нужна нативность UI на разных платформах.
Ну возможность хотя бы бизнес-логику не дублировать, а интерфейс сделать с нуля на каждой платформе — тоже неплохой путь. Мне вот теперь кажется, что это даже заметно лучший путь. Но об этом во второй части…
Луше и правда делать интерфейсы для каждой платформы своими, в большинстве случаев, т.к. пользователи iOS к примеру больше привыкли к меню с вкладками, а на Android к боковому меню. Ну и стилистика немного другая.
Только если вы дотнетчик, в остальных случаях лучше использовать нативные средства разработки.
Тут кстати наступает интересный момент. Вот например вам требуется приложения под iOS, Android и Windows Phone. Что выгоднее, дешевле и проще, если вы не хотите отдавать проект на аутсорс?
1) держать в команде 1-2-3 разработчиков-универсалов, хорошо знающих кишки каждой ОС и свободно пишущих на Java, Object-C и C#
2) столько же разработчиков, но каждый из них пишет на C# с помощью Xamarin
3) (крайний случай, но мало ли) по одному разработчику под каждую из платформ
Тут во втором вариенте плюс и во взаимозаменяемости, и в возможности проще найти нового разработчика, и в шаринге бизнес-кода между платформами… И шаринг кода тут не последний по значимости плюс: не будет ситуаций вида «поправили баг на Android, но упустили идентичный на iOS». Да и единый набор тестов, который не придётся писать трижды, тоже повод для радости.
1) держать в команде 1-2-3 разработчиков-универсалов, хорошо знающих кишки каждой ОС и свободно пишущих на Java, Object-C и C#
2) столько же разработчиков, но каждый из них пишет на C# с помощью Xamarin
3) (крайний случай, но мало ли) по одному разработчику под каждую из платформ
Тут во втором вариенте плюс и во взаимозаменяемости, и в возможности проще найти нового разработчика, и в шаринге бизнес-кода между платформами… И шаринг кода тут не последний по значимости плюс: не будет ситуаций вида «поправили баг на Android, но упустили идентичный на iOS». Да и единый набор тестов, который не придётся писать трижды, тоже повод для радости.
Разработка приложений по гайдлайнам Google/Apple с использованием Xamarin превращается в ад.
Он подходит только в случае если вы копируете приложение под все платформы, не реализуя нативный вид.
Он подходит только в случае если вы копируете приложение под все платформы, не реализуя нативный вид.
Что-то мне кажется, React Native тут уже выигрышнее выглядит.
Ну вот с Xamarin тоже не все так безоблачно, MS может в любой момент их выкупить и как там дальше пойдет — неизвестно. React Native, по крайней мере, open source.
и зачем им выкупать их?
Как раз, если MS решит их выкупить, то с будущим все будет хорошо. По крайней мере, оно(будущее) будет гораздо более стабильным, чем сейчас.
Это уже зависит от MS. В том-то и проблема, пока для разработчиков их продукт — флагман продаж, они делают все, чтобы держать его на плаву, даже если не очень получается. Но при поглощении большой фирмой для нее это просто еще один продукт. Начнутся сложные времена — могут и закрыть, что-то урезать или ограничить финансирование, перебросить деньги на другие проекты, но уж наврядли откроют исходники и отпустят в свободное плавание. Как Dropbox недавно решил закрыть Mailbox.
И в чем тут холивар? Я вообще фанат ruby, но RubyMotion пока не особо рассматриваю, например. Сейчас у меня как раз стоит выбор кросс-платформенного фреймворка для мобильного приложения и, по-моему, насколько хорошо он решает задачи гораздо важнее языка, который выучить недолго (по сравнению с изучением самого фреймворка).
С Xamarin самое печальное, что идея-то отличная, но со своими багами, которые не фиксятся, они просто теряют клиентов )
Тут людей не так уж много, а вот работы поддерживать кучу разных версий и все апдейты — много :) А хороших девелоперов надо кормить, это же нишевый продукт — не Angry Birds с сотнями миллионов пользователей.
Довольно обидно, когда глюкавит продукт за ~1000$ в год на 1 разработчика. Будь этот инструмент бесплатным или недорогим, можно было бы простить ему некоторые шероховатости. А с повышением цены повышается и уровень ожиданий. Сейчас он местами похож на платную бету, которую представляют как законченный продукт.
Если совсем устанете от Xamarin.Forms, рекомендую посмотреть на наш UI-фреймворк, который недавно таки завели на мобилках. В наличии нормальный XAML, lookless-контролы, своя система отрисовки и прочие свойственные WPF плюшки. Оно, конечно, всё ещё в альфе, но разработка идёт достаточно быстро, думаю, летом уже будет RC.
Мы недавно выпустили приложение на Xamarin.Forms, с упором на красивый дизайн.
Много кактусов, но выглядит очень хорошо. На слабых аппаратax андроида подтормаживает правда
itunes.apple.com/il/app/ydy-wt-hrwnwt/id912886096?mt=8
play.google.com/store/apps/details?id=com.yedioth.android
Много кактусов, но выглядит очень хорошо. На слабых аппаратax андроида подтормаживает правда
itunes.apple.com/il/app/ydy-wt-hrwnwt/id912886096?mt=8
play.google.com/store/apps/details?id=com.yedioth.android
>>К слову, бесплатная ознакомительная версия не позволяет собрать приложение размером более 64 килобайт
это так, но вы не упомянули про триал 30 дней + 30 дней манибэка. а так же иди лицензию за 25$ в мес.
Все проблемы с Xamarin Studio перестанут быть актуальными с приходом Xamarin Studio Roslyn (уже доступны preview)
>>так что вам придётся сидеть рядом с двумя ПК разом, тестируя приложение на одном и работая в отладчике на другом
TeamViewer — хорошая штука.
>>Но никто от разработчика эти особенности под абстракциями не прячет, так что повторяем, изучать каждую из платформ придётся.
в этом и суть — разработка как на нативных инструментах без всяких абстракций (не говорю про XForms) но на языке C# — я бы скорее назвал это фичей.
>>В данный момент под Xamarin уже написано немало компонентов, но под iOS и Android их всё-таки написано больше.
Objective Sharpe умеет генерит обертки из pods налету, а это умеет генерит обертки налету из jcenter/mavencentral и прочий гредл. Без сучков не будет — сами понимаете. Но Объектив Шарпи становится все лучше, ну а с явой проблемы связаны с разницей языков — они вроде похожи, но мелочи приносят боль.
это так, но вы не упомянули про триал 30 дней + 30 дней манибэка. а так же иди лицензию за 25$ в мес.
Все проблемы с Xamarin Studio перестанут быть актуальными с приходом Xamarin Studio Roslyn (уже доступны preview)
>>так что вам придётся сидеть рядом с двумя ПК разом, тестируя приложение на одном и работая в отладчике на другом
TeamViewer — хорошая штука.
>>Но никто от разработчика эти особенности под абстракциями не прячет, так что повторяем, изучать каждую из платформ придётся.
в этом и суть — разработка как на нативных инструментах без всяких абстракций (не говорю про XForms) но на языке C# — я бы скорее назвал это фичей.
>>В данный момент под Xamarin уже написано немало компонентов, но под iOS и Android их всё-таки написано больше.
Objective Sharpe умеет генерит обертки из pods налету, а это умеет генерит обертки налету из jcenter/mavencentral и прочий гредл. Без сучков не будет — сами понимаете. Но Объектив Шарпи становится все лучше, ну а с явой проблемы связаны с разницей языков — они вроде похожи, но мелочи приносят боль.
Про манибэк действительно не упомянул, дело говорите.
Но т.к. Xamarin Studio Roslyn ещё только в превью, а разработка под ней довольно больно, то поддержка Visual Studio — необходимость, поэтому инди-версию и не упомянул.
Честно, я на Roslyn-версию не смотрел, т.к. глядя местами на их релизные продукты, мне страшно представить, как там работает превью-версия. За счет чего стало намного лучше, можете поделиться? Однако любопытно.
TeamViewer — хорошая штука, да и альтернатив ему хватает. Более того, в статье упомянут вариант «Можно открыть удалённый сеанс » :-) Но всё-равно это несколько менее удобно, чем запуск нативного эмулятора того же Android'а.
«разработка как на нативных инструментах без всяких абстракций… фича»
Проблема в том, что мне довольно много знакомых разработчиков жаловалось, что с удивлением обнаружили необходимость подробно изучать особенности каждой ОС, мол это было не очевидно из рекламных компаний. Так что я решил лишний раз обратить внимание на этот момент.
Objective Sharpe я тоже в тексте упомянул, но для некоторых библиотек он выдаёт результат., требующий ооочень больших доработок. Я прекрасно понимаю, что без проблем не будет, но во многих презентациях упоминается, что «вы легко и без проблем сможете использовать нативные библиотеки». А на практике — да, использовать сможете, но далеко не всегда «легко и без проблем».
Но т.к. Xamarin Studio Roslyn ещё только в превью, а разработка под ней довольно больно, то поддержка Visual Studio — необходимость, поэтому инди-версию и не упомянул.
Честно, я на Roslyn-версию не смотрел, т.к. глядя местами на их релизные продукты, мне страшно представить, как там работает превью-версия. За счет чего стало намного лучше, можете поделиться? Однако любопытно.
TeamViewer — хорошая штука, да и альтернатив ему хватает. Более того, в статье упомянут вариант «Можно открыть удалённый сеанс » :-) Но всё-равно это несколько менее удобно, чем запуск нативного эмулятора того же Android'а.
«разработка как на нативных инструментах без всяких абстракций… фича»
Проблема в том, что мне довольно много знакомых разработчиков жаловалось, что с удивлением обнаружили необходимость подробно изучать особенности каждой ОС, мол это было не очевидно из рекламных компаний. Так что я решил лишний раз обратить внимание на этот момент.
Objective Sharpe я тоже в тексте упомянул, но для некоторых библиотек он выдаёт результат., требующий ооочень больших доработок. Я прекрасно понимаю, что без проблем не будет, но во многих презентациях упоминается, что «вы легко и без проблем сможете использовать нативные библиотеки». А на практике — да, использовать сможете, но далеко не всегда «легко и без проблем».
Спасибо за материал, интересно.
Для всех коммерческих проектов которые я видел, Xamarin это скорее экзотика, обычно (как упоминали выше), часть разработчиков пишет нативно под iOS, часть под Android, а на Windows Mobile просто забивают т.к. рынок крайне мал :)
После прочтения статьи возникло ощущение, что баги и сырость Xamarin пока что перевешивают его плюсы. Как в анекдоте, «народ настолько любит халяву, что готов платить за нее любые деньги» :) Мало того, что надо все равно с особенностями каждой ОС разбираться, так еще и с глюками системы бороться.
Что осталось неясным:
— Верстка UI в xib/storyboard, работает ли, и сильно ли сложно? Или весь UI в коде?
— Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать? Они сейчас вполне быстрые, и не такие уж дорогие (имхо потраченное на «удаленную отладку» время в итоге дороже стоит). Или xamarin такое не позволяет в принципе? Или вопрос жадности работодателя? (доводилось работать в компании, где даже 8Гб памяти надо было выбивать пару месяцев, не то что новый комп)
— Можно ли написать какую-то часть (например работу с БД) на Xamarin, затем оформить эту часть в виде lib/framework, подлинковать ее к XCode/Android Studio, и дальше писать уже нативно в нативной IDE?
— Цена IDE. Без покупки лицензии за килобакс я не могу даже дома что-то попробовать/потестить?
Для всех коммерческих проектов которые я видел, Xamarin это скорее экзотика, обычно (как упоминали выше), часть разработчиков пишет нативно под iOS, часть под Android, а на Windows Mobile просто забивают т.к. рынок крайне мал :)
После прочтения статьи возникло ощущение, что баги и сырость Xamarin пока что перевешивают его плюсы. Как в анекдоте, «народ настолько любит халяву, что готов платить за нее любые деньги» :) Мало того, что надо все равно с особенностями каждой ОС разбираться, так еще и с глюками системы бороться.
Что осталось неясным:
— Верстка UI в xib/storyboard, работает ли, и сильно ли сложно? Или весь UI в коде?
— Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать? Они сейчас вполне быстрые, и не такие уж дорогие (имхо потраченное на «удаленную отладку» время в итоге дороже стоит). Или xamarin такое не позволяет в принципе? Или вопрос жадности работодателя? (доводилось работать в компании, где даже 8Гб памяти надо было выбивать пару месяцев, не то что новый комп)
— Можно ли написать какую-то часть (например работу с БД) на Xamarin, затем оформить эту часть в виде lib/framework, подлинковать ее к XCode/Android Studio, и дальше писать уже нативно в нативной IDE?
— Цена IDE. Без покупки лицензии за килобакс я не могу даже дома что-то попробовать/потестить?
— Верстка UI в xib/storyboard, работает ли, и сильно ли сложно? Или весь UI в коде?
Если вы не используете Xamarin.Forms — можно использовать xib/storyboard для iOS и xml для Android. Получается нормальная нативная вёрстка.
Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать? Они сейчас вполне быстрые, и не такие уж дорогие (имхо потраченное на «удаленную отладку» время в итоге дороже стоит). Или xamarin такое не позволяет в принципе? Или вопрос жадности работодателя? (доводилось работать в компании, где даже 8Гб памяти надо было выбивать пару месяцев, не то что новый комп)
Сложность отладки в том, что Xamarin.Studio периодически глюкавит и отлаживать в ней код проблематично. Так что приходится юзать два компа или виртуалку с Windows и Visual Studio. Отлаживать в Xcode или другой нативной среде не удастся, сейчас альтернативы две: или Xamarin.Studio, или Visual studio.
Можно ли написать какую-то часть (например работу с БД) на Xamarin, затем оформить эту часть в виде lib/framework, подлинковать ее к XCode/Android Studio, и дальше писать уже нативно в нативной IDE?
Интересная идея :-) Но если я верно понимаю схему работы Xamarin — не сработает.
Цена IDE. Без покупки лицензии за килобакс я не могу даже дома что-то попробовать/потестить?
Без покупки у вас есть либо бесплатная версия с кошмарными ограничениями, либо полнофункциональный триал на 30 дней. Так что попробовать бесплатно можно)
>Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать?
На маке работать можно только через Xamarin Studio, а она сильно тормозная и глючная.
На маке работать можно только через Xamarin Studio, а она сильно тормозная и глючная.
Не нужно делать выводы по одной статье. Очень много написано приложений на замарине. особенно интерпрайз. Там где много клиентской логики он вне конкуренции. Тем более позволяет легко портануть код на десктопный Windows.
Sign up to leave a comment.
Xamarin и Xamarin.Forms – кактус в шоколаде. Часть 1