Comments 50
Мне кажется, или раздел недостатков слегка сильно недописан?
Слишком много недостатков
Для разработки приложения на основе Xamarin вам не потребуется досконально знать специфические языки отдельных платформ.
То есть на c# я могу покрыть все случаи выходящие за границы HelloWorldApp по работе с платформой?
Xamarin требует примерно в 1,5 раза меньше времени (и денег), чем создание отдельного специализированного проекта под каждую платформу.
В первую очередь это относится к дизайну (Flat Design в iOS, Material Design в Android)
… и metro (если не ошибаюсь) для windows. И того три разных дизайна + в три раза дольше время на создание дизайна + три раза больше денег на создание трех разных дизайнов.
И кто сказал что разный дизайн одного приложения это круто? Наверное программисты, которым всегда трудно реализовывать дизайнерские идеи? Я не думаю чтобы дизайнер был доволен если бы его работа заключалась только в ресовании унифицированных схем с надписями «кнопка» и «селект».
А как же uix? Как можно разработать uix интерфейс, если интерфейс на каждой платформе разный?
И angular позволяет с api платформ на js работать. При чем оно по времени обновляется практически одновременно с платформой.
И невозможно не зная компонентной системы платформ и их api работать с ними. Даже в случаи кросплатформенных инструментов. Не нужно людей обманывать!
Если не хотите разный дизайн — Xamarin Forms вам самое то. Вообще платформ-специфичного кода будет процентов 5
Платформы знать конечно же нужно. Но разговор о том, что бизнес-логику не нужно переписывать с Java на Swift. А в некоторых приложениях это львиная доля кода
Ну для справедливости надо сказать что у каждой платформы свои гайдлайны по дизайну, никто вам не запрещает сделать один дизайн для всех платформ, только вот в магазины их не выложить.
Итого не три новых дизайна, а шесть новых дизайнов.
Ещё WPF, GDK и Tizen.
Ещё WPF, GDK и Tizen.
А мне, наоборот, легче освоить Android SDK, чем держать в голове сразу и XAML и Android разом.
Плюс, насколько легко там подключать сторонние Android библиотеки? Особенно, если они тянут зависимости.
В Android Studio это решается простым добавлением строки в gradle. А что в Xamarin?
Насколько я знаю, там это нужно делать руками.
Плюс, насколько легко там подключать сторонние Android библиотеки? Особенно, если они тянут зависимости.
В Android Studio это решается простым добавлением строки в gradle. А что в Xamarin?
Насколько я знаю, там это нужно делать руками.
Что значит «руками»? По идее, точно так же должна добавляться строка в файл проекта…
XAML? за все время работы с Xamarin ни разу с ним не работал. XAML нужен только для Forms, в Xamarin.Android и Xamarin.iOS используются «нативные» layout'ы и StoryBoard'ы
зависимости? Про NuGet слышали? 2 клика мыши
А причем тут Nuget? Мне нужны платформозависимые библиотеки. Например, retrofit.
А при том, что все зависимости тащятся из Nuget. Ну или ссылка на проект в солюшене. Или библиотека из .NET фреймворка. Платформозависимые библиотеки оборачиваются в Nuget пакеты.
З.Ы. в Xamarin вы будете пользоваться не retrofit, а HttpClient (.NET из framework) или RestSharp из того же Nuget
З.Ы. в Xamarin вы будете пользоваться не retrofit, а HttpClient (.NET из framework) или RestSharp из того же Nuget
простите, опечатка: (из .NET framework)
Если хочется собирать API сервис из аннотаций, лучше, всё-таки, использовать Refit (https://github.com/reactiveui/refit), эдакий Retrofit для .NET. Если нужна производительность, то имеет смысл посмотреть в сторону ModernHttpClient (https://github.com/paulcbetts/ModernHttpClient)
При желании можно подключить любую нативную библиотеку написанную на Java
https://docs.microsoft.com/ru-ru/xamarin/android/platform/binding-java-library/
Так же для большинства наиболее популярных библиотек есть готовые обертки которые можно подключить из nuget-а.
Однако в случае retorfit проще использовать порт этой библиотеки на .net
https://www.nuget.org/packages/refit/
https://github.com/reactiveui/refit
А с Linux какая интеграция, ну или с MacOS? Если нет развитой Windows инфраструктуры, максимум в бухгалтерии используется, то:
а) насколько реально полноценно разрабатывать без приобретения Windows и VisualStudio?
б) если не реально, то сколько будет стоит комплект софта для разработчика в розницу?
а) насколько реально полноценно разрабатывать без приобретения Windows и VisualStudio?
б) если не реально, то сколько будет стоит комплект софта для разработчика в розницу?
У меня есть опыт работы в достаточно серьезной компании над вполне крупным приложением на Xamarin с навороченной бизнес-логикой. Вот что я скажу: насчет плюсов — согласен. Допилить какую-то фичу под другую платформу — это процентов 10-20 от времени работы над фичей. Одна команда универсальных солдат. Причем команда частенько ротировалась с десктопной командой (там WPF). Большая часть кода бизнес-логики шарилась с десктопом. Родной C#, MVVM фреймворк (MVVMCross), процесс разработки — одно удовольствие (если не считать глюков и лагов коннекта с Маком для сборки проекта под iOS — да-да, для сборки под iOS без Мака никуда, а работа со всем этим хозяйством — это то еще удовольствие).
НО! Приложение на не самых быстрых андроид-устройствах грузилось до 15 секунд!!!
Вы можете себе представить, чтобы какой-нибудь фейсбук грузился 15 секунд? Да вы, как пользователь, пошлете к чертям такое приложение, если это не B2B сектор, и вам НАДО с этим приложением работать. Конечно, там не только проблема фреймворка, там было много наших косяков, и с бубном удалось на пару секунд сократить загрузку, но все же… Например такой факт: гугл сделал DI контейнер Dagger 2, который работает на кодогенерации, и соответственно, в рантайме времени на поднятие контейнера не тратится. А нам приходилось работать с Autofac, который работает на рефлексии, и поднятие контейнера занимало при запуске несколько секунд!
З.Ы. простите за многабукаф, ИТОГО: мое мнение — Xamarin очень хорош, если у вас B2B сектор, готовая .NET команда, и нужно шарить код с десктопом. А главный критерий — сценарий использования приложения — как часто юзер будет его открывать и как долго с ним работать. Если открывать 20 раз в день чтобы ответить на сообщение и закрыть — Xamarin использовать нельзя.
НО! Приложение на не самых быстрых андроид-устройствах грузилось до 15 секунд!!!
Вы можете себе представить, чтобы какой-нибудь фейсбук грузился 15 секунд? Да вы, как пользователь, пошлете к чертям такое приложение, если это не B2B сектор, и вам НАДО с этим приложением работать. Конечно, там не только проблема фреймворка, там было много наших косяков, и с бубном удалось на пару секунд сократить загрузку, но все же… Например такой факт: гугл сделал DI контейнер Dagger 2, который работает на кодогенерации, и соответственно, в рантайме времени на поднятие контейнера не тратится. А нам приходилось работать с Autofac, который работает на рефлексии, и поднятие контейнера занимало при запуске несколько секунд!
З.Ы. простите за многабукаф, ИТОГО: мое мнение — Xamarin очень хорош, если у вас B2B сектор, готовая .NET команда, и нужно шарить код с десктопом. А главный критерий — сценарий использования приложения — как часто юзер будет его открывать и как долго с ним работать. Если открывать 20 раз в день чтобы ответить на сообщение и закрыть — Xamarin использовать нельзя.
15 секунд сold start — это, конечно, вы неправильно готовили своё приложение. Даже запуск приложений, написанных на Forms, занимает секунд 5-6, а с Xamarin Classic + AOT запуск на андроидах не занимает более пары секунд.
полностью согласен, что не так делали, но: если даже сделать пустое приложение Xamarin.Adnroid, оно будет стартовать около секунды, т.е. заметно. Инициализацию mono никто не отменял. А если еще навернуть какой-нибудь фреймворк типа MVVMcross, то еще дольше. В туториалах MVVMCross сразу же объясняют, как сделать splash screen!
И попробуйте создать пустой проект в Android Studio, запустите — приложение будет стартовать мгновенно.
И попробуйте создать пустой проект в Android Studio, запустите — приложение будет стартовать мгновенно.
Я часто сталкивался с аналогичной проблемой когда консультировал команды на Xamarin. Не обязательно все что может понадобиться и не понадобиться использовать на старте и инициализировать все. Можно декомпозировать приложение, сделать Lazy инициализацию компонент, выделить модули и приложение начнет запускаться намного быстрее.
У нас тоже была похожая проблема, когда мы пытались полностью загрузить все связи и включить основной функционал во время старта приложения. Проект был средним, занимал на обычном (вроде за 12к руб) телефоне 5-7 сек. Тот же Autofac, легко позволил запускать построения всех зависимостей в фоне, что скинуло около 2 сек, для нормального отображения и пользования. Не думаю что загрузка приложения за 15 сек, это в основном проблема Xamarin и Autofac. Хоть, так сложилось что я больше не пишу на Xamarin промышленно, но рад что познакомился с этой платфомой и думаю у неё большое будущее. Считаю что использования данного фреймворка в бизнес-решениях, действительно хорошая идея и возможно даже не много выгоднее, чем держать 2 команды которые разрабатываю по сути одно и тоже.
А вы уверены, что если приводишь примеры «сложной» разработки при помощи нативных средств, и при этом, чтобы показать, какая она сложная, используешь низкоуровневые библиотеки, которыми никто давно не пользуется, то тебя никто не раскусит? :)
Так тоже убило сравнили C# и Objective-С, а почему код на Swift не привели в пример? Потому, что код на Swift по размеру будет, как и С#, но это конечно мелочь, но не нужны точки с запятой в конце каждой строки.
Даже честный код на obj-c был бы того же размера по строкам (если по символам считать то чуть больше), да и вообще отличался бы только в синтаксисе самого языка. К тому же это ведь второй заход с этой статьей (первый собрал кучу вопросов и ушел в черновики, если это перевод — не понятно почему просто не послать к статье-оригиналу вместо этого) и автору уже об этом писали.
У вас опечатка в названии конструктора класса
class TextToSpeech_iOS Я лишь напомню, что Profiler для Xamarin (базовая вещь!) доступен только в Visual Studio Enterprise за $3k/год за пользователя.
Тут Microsoft, конечно, обнаглели. Но разработчики бодаются с ними, вот здесь например. Посмотрим, насколько успешно это выйдет…
Крайне в этом сомневаюсь. Эти ребята даже сделали опцию AOT-компиляции для Android доступной только в Enterprise-версии. К счастью, AOT — это часть опенсорсного Xamarin.Android, и пока что можно включить вручную в csproj.
А отладчик нормальный в котором видно значения переменных и объектов в Xamarin завезли?
отладчик Visual Studio. Все там видно.
Вообще, большинство вопросов здесь — от незнания того, как работает Xamarin. Xamarin приложение на Android — это, по сути, приложение Mono, т.е., это то же .NET приложение, только в среде Linux. В iOS немного сложнее. Это если в двух словах. Интересующимся — доки.
Вообще, большинство вопросов здесь — от незнания того, как работает Xamarin. Xamarin приложение на Android — это, по сути, приложение Mono, т.е., это то же .NET приложение, только в среде Linux. В iOS немного сложнее. Это если в двух словах. Интересующимся — доки.
Если Mono, то почему Windows обязателен, ну или MacOS?
Visual Studio есть только для винды и macOS
Есть MonoDevelop. Или таки тесная интеграция с Visual Studio это в целом не плюс, а минус в виде vendor lock-in?
ничего не могу сказать про поддержку Xamarin в MonoDevelop
Xamarin Studio от monodevelop всегда отличало наличие плагинов для разработки iOS и Android приложений. Microsoft, разумеется, исходники этих плагинов не открыли ни после покупки Xamarin, ни при ребрендинге Xamarin Studio → Visual Studio for Mac, поэтому разработка Xamarin-приложений на линуксах невозможна. Vendor-lock во всей красе.
Но, вообще говоря, вы можете собирать Xamarin.Android-приложения в среде Linux, т.к. msbuild уже кроссплатформенный, и вы даже можете попробовать использовать Rider от JetBrains для разработки.
Но, вообще говоря, вы можете собирать Xamarin.Android-приложения в среде Linux, т.к. msbuild уже кроссплатформенный, и вы даже можете попробовать использовать Rider от JetBrains для разработки.
Отлаживал как-то broadcast активити в Android Studio и похожий проект на Xamarin в Visual Studio. Может с тех пор лучше стало.
Специально что ли выбрали самый вырвиглазный пример с attributed string? Никто в обычном проекте не пишет строку с помощью CoreFoundation. Нормальный пример выглядит так:
NSDictionary *attributes = @{NSFontAttributeName: [UIFont systemFontOfSize:16], NSForegroundColorAttributeName: UIColor.whiteColor};
NSAttributedString *string = [[NSAttributedString alloc] initWithString:@"Hello from ego team!" attributes:attributes];
Многоплатформенность — это самый отстойный хайп последних лет. Запудрили мозги миллионам людей, а сами даже инструментов нормальных поставить не могут.
Есть десктоп-венда и считай, это 100% юзеров. С мониками от 20", мышой и относительно мощными ПК. Пишешь приложение строго для венды, со всеми гайдами, дизайном, темами и поэтессами. И очевидно, это будет классное rich-приложение, потому что не только look, но и feel.
Если вдруг вы обнаружили большой спрос на какой-нть ведроид или макакось, только тогда имеет смысл рассматривать разработку для других платформ! Ещё раз: сначала спрос, потом предложение. Потому что ИТ — это не «ещё более новый шампунь», здесь всё серьёзно и разрабатывается годами. Ни один бизнесмен не будет рисковать проторённым путём и прыгать на неполовозрелые идейки «а что если нас захотят запустить на Линукс?».
Захотят — тогда начнётся серьёзное исследование, где будут заданы крайне неудобные вопросы, на которые ни один усатый «сеньёр» 25-ти лет не даст внятного ответа — ибо скудоум в силу возраста:
1. Какой примерный прицент юзеров нашей программы хочет линупсы/макоси/ведроиды? Это серьёзный процент или это 1% маргиналов, которым лишь бы повопить «а давайте запустим эту хрень на моём 100-долларовом андроиде!»?
2. Какова вообще ЦА другой платформы? Её платёжеспособность? Желание вообще что-либо покупать? Как часто они готовы платить? Есть ли там бизнес сектор? Какие перспективы расширения?
3. Насколько гетерогенной будет разработка? Можно что-то перенести из венды? Какой ценой? Сколько на рынке есть специалистов по данной платформе? Сколько они хотят? Сколько это занимает времени?
4. Поддержка. Мрачный саппорт, тупорылость которого зашкаливает даже по джамшутным меркам. На венде ещё как-то люди ориентируются, где брать «недоайтишнегов» на маках? линуксе? Они вообще адекватные? По вендовой версии может саппортить даже программист, а что он будет делать с макофилами??
5. Платформы. Они РАЗНЫЕ и очень. И не надо вешать лапшу про «везде есть кнопки» — есть, да только это не составляет и 1% трудностей, которые нужно преодолеть! Это и «нативное поведение контролов» (чего не умеет НИ ОДНА кросс-библиотека), и специфичные механизмы (трэды, семафоры, сокеты, секьюрити, да чё говорить — не везде даже файлы доступны!). Только нативное приложение, разработанное профессионалами данной платформы, не будет вызывать тошноту у юзеров этой же платформы. Потому что этому учатся ГОДАМИ! Малолетние хипстеры со своими Qt/wxWidgets и прочими Кзамаринами просто «подаваны» по сравнению с теми, кто работал и развивался в каждой конкретной среде.
6. Отдельно коснусь мобильного мира: это совсем другая планета, товарищ! Забудь про аршинные тулбары и драгндропы, про «onMouseOver» и тонюсенькие, будто идиотом точенные, скроллбары — в «пальцетыке» это не прокатит. Только кнопки, свайпы и иконки на пол-экрана! И «никакая» производительность с «никакой» же памятью. Никакой тебе мемоизации, кэша и прочих плюшек. Выкусил? Только наивный Чебурашка будет думать, что вот сейчас он наскочит со своими кзамаринами и залепит аппликуху на всё, что только можно назвать компьютером! Мобильное ПО — это коренным образом отличающийся софт, который неизбежно надо проектировать с нуля, учитывая все ньюансы взаимодействия и ограничений.
Windows 10 — вот пример «ИТ урода», где кто-то не очень умный решил скрестить десктоп с мобилами — никому не нужный павлиноуткаёж просто галопом несётся в анал (не анналы!) истории.
Короче, грустно наблюдать весь этот тупняк, распаление ресурсов и натягивание совы на глобус — индустрия категорически не хочет думать — все хотят только баблосос на очередном хайпе. Прогресс/наука и бизнес — они несовместимы!
Есть десктоп-венда и считай, это 100% юзеров. С мониками от 20", мышой и относительно мощными ПК. Пишешь приложение строго для венды, со всеми гайдами, дизайном, темами и поэтессами. И очевидно, это будет классное rich-приложение, потому что не только look, но и feel.
Если вдруг вы обнаружили большой спрос на какой-нть ведроид или макакось, только тогда имеет смысл рассматривать разработку для других платформ! Ещё раз: сначала спрос, потом предложение. Потому что ИТ — это не «ещё более новый шампунь», здесь всё серьёзно и разрабатывается годами. Ни один бизнесмен не будет рисковать проторённым путём и прыгать на неполовозрелые идейки «а что если нас захотят запустить на Линукс?».
Захотят — тогда начнётся серьёзное исследование, где будут заданы крайне неудобные вопросы, на которые ни один усатый «сеньёр» 25-ти лет не даст внятного ответа — ибо скудоум в силу возраста:
1. Какой примерный прицент юзеров нашей программы хочет линупсы/макоси/ведроиды? Это серьёзный процент или это 1% маргиналов, которым лишь бы повопить «а давайте запустим эту хрень на моём 100-долларовом андроиде!»?
2. Какова вообще ЦА другой платформы? Её платёжеспособность? Желание вообще что-либо покупать? Как часто они готовы платить? Есть ли там бизнес сектор? Какие перспективы расширения?
3. Насколько гетерогенной будет разработка? Можно что-то перенести из венды? Какой ценой? Сколько на рынке есть специалистов по данной платформе? Сколько они хотят? Сколько это занимает времени?
4. Поддержка. Мрачный саппорт, тупорылость которого зашкаливает даже по джамшутным меркам. На венде ещё как-то люди ориентируются, где брать «недоайтишнегов» на маках? линуксе? Они вообще адекватные? По вендовой версии может саппортить даже программист, а что он будет делать с макофилами??
5. Платформы. Они РАЗНЫЕ и очень. И не надо вешать лапшу про «везде есть кнопки» — есть, да только это не составляет и 1% трудностей, которые нужно преодолеть! Это и «нативное поведение контролов» (чего не умеет НИ ОДНА кросс-библиотека), и специфичные механизмы (трэды, семафоры, сокеты, секьюрити, да чё говорить — не везде даже файлы доступны!). Только нативное приложение, разработанное профессионалами данной платформы, не будет вызывать тошноту у юзеров этой же платформы. Потому что этому учатся ГОДАМИ! Малолетние хипстеры со своими Qt/wxWidgets и прочими Кзамаринами просто «подаваны» по сравнению с теми, кто работал и развивался в каждой конкретной среде.
6. Отдельно коснусь мобильного мира: это совсем другая планета, товарищ! Забудь про аршинные тулбары и драгндропы, про «onMouseOver» и тонюсенькие, будто идиотом точенные, скроллбары — в «пальцетыке» это не прокатит. Только кнопки, свайпы и иконки на пол-экрана! И «никакая» производительность с «никакой» же памятью. Никакой тебе мемоизации, кэша и прочих плюшек. Выкусил? Только наивный Чебурашка будет думать, что вот сейчас он наскочит со своими кзамаринами и залепит аппликуху на всё, что только можно назвать компьютером! Мобильное ПО — это коренным образом отличающийся софт, который неизбежно надо проектировать с нуля, учитывая все ньюансы взаимодействия и ограничений.
Windows 10 — вот пример «ИТ урода», где кто-то не очень умный решил скрестить десктоп с мобилами — никому не нужный павлиноуткаёж просто галопом несётся в анал (не анналы!) истории.
Короче, грустно наблюдать весь этот тупняк, распаление ресурсов и натягивание совы на глобус — индустрия категорически не хочет думать — все хотят только баблосос на очередном хайпе. Прогресс/наука и бизнес — они несовместимы!
Вы что-то путаете: не надо изучать спрос, чтобы понять, что выгоднее иметь приложение одновременно и под Android, и под iOS. А именно это замарин и предлагает в первую очередь. Возможность получать вин-приложение на нем — плюшка, мне тоже непонятная.
А так он дает глобально две вещи:
А так он дает глобально две вещи:
- возможность писать, использую нативное для платформы API, но используя C# и весь .Net за ним. Лично для меня это большой плюс — изучать андроид и джаву одновременно, или макос и objective-c несколько затратнее, чем просто одну платформу. Плюс, если вы делаете приложение одновременно для обеих платформ, вы можете пошарить между ними часть не UI-кода;
- при использовании Xamarin.Forms позволяет еще и иметь довольно большое количество общего UI-кода. Вы пишете UI, используя его абстракции, а не конкретной платформы. А он уже генерирует вам нативный UI, с учетом особенностей в отображении для разных платформ.
Не буду сжигать ведьм на костре. Мы используем xamarin натив. Приложения действительно совсем разные. Не понял в чем проблема у предыдущего поста. Все пункты абсолютно вписываются в Xamarin натив. По перформансу нареканий нет. Про мобильные устройства тоже не согласен. Надо смириться с фактом, что мобильные устройства на первом месте, компьютер на втором (хотя бы количеству устройств). Про нативные специфичные механизмы — dependency injection в помощь. Разные вещи делай в платформозависимых библиотеках, одинаковые в Portable переноси. Xamarin Forms 3.0 позволяет одинаковые формы выносить в Portable и эмбедить их в Xamarin натив.
Из минусов Xamarin — еще один слой с еще одним слоем багов. IDE отстают от нативных (Android Studio, XCode). Visual Studio и Visual Studio Mac — совершенно разные IDE.
Из чисто нативной разработки минусы: разные платформы — разные баги, рассинхрон и несовместимость приложений на разных платформах.
Не нравится C# — котлин есть еще.
Из минусов Xamarin — еще один слой с еще одним слоем багов. IDE отстают от нативных (Android Studio, XCode). Visual Studio и Visual Studio Mac — совершенно разные IDE.
Из чисто нативной разработки минусы: разные платформы — разные баги, рассинхрон и несовместимость приложений на разных платформах.
Не нравится C# — котлин есть еще.
Мы уже 6 лет пишем на xamarin ( notissimus.com ) — чтобы не быть голословным — такие приложения, как ФК ЗЕНИТ и ХК СКА написаны сейчас именно на Xamarin и мы видим в этом огромные плюсы именно в части кросс-платформенности. На Xamarin мы написали и продолжаем развивать конструктор приложений для розничных компаний appropio.com — не сталкивались мы еще с трудностями в бизнес-приложениях, которые не смогли решить на Xamarin. Так что из нашего опыта — рекомендуем.
Sign up to leave a comment.
Достоинства и недостатки Xamarin