Статья подготовлена нашими партнерами, ребятами из EGO.
Xamarin — удобный набор инструментов для разработки кросс-платформенных мобильных приложений на C# с использованием .NET. Он поддерживает iOS, Android и Windows Phone.
Для разработки приложения на основе Xamarin вам не потребуется досконально знать специфические языки отдельных платформ. Кроме того, при работе с какой-либо платформой у вас будет полный доступ к возможностям ее пакета SDK и встроенным механизмам создания пользовательских интерфейсов.
Таким образом, Xamarin позволяет создавать приложения, которые почти не отличаются от нативных аналогов, а значит, вполне подходят для распространения через официальные магазины (например, Google Play и App Store).
Кроме того, по словам разработчиков Xamarin, готовое решение не будет существенно уступать и в плане производительности.
Рассмотрим составные части Xamarin.
- Xamarin.IOS — библиотека классов C#, предоставляющая разработчикам доступ к пакету SDK для iOS.
- Xamarin.Android — библиотека классов C#, предоставляющая разработчикам доступ к пакету SDK для Android.
- Компилятор C#.
- .NET Framework.
- Инструменты IDE (встроены в Visual Studio для Mac OS и Windows).
В этой статье подробно описаны семь существенных причин использовать Xamarin для кросс-платформенной разработки.
Дополнительные материалы: сравнение Xamarin и PhoneGap.
1. Простота освоения
На что в первую очередь следует обращать внимание при выборе платформы? Конечно, на сложность ее освоения. Вряд ли найдется много желающих тратить время на освоение особенностей синтаксиса (например, для достаточно уверенного владения Angular требуется изучать эту платформу как минимум несколько месяцев). Поэтому если создание качественного кода требует чрезвычайно серьезной подготовки, то многим новичкам попросту не удается в полной мере овладеть средой разработки. А вот начать работу с Xamarin совсем просто: вам не придется учить язык Xamarin или что-нибудь в таком духе.
using Xamarin.Forms;
RootPage.Children.Add(new ContentPage
{
Content = new Label
{
Text = "Sketches in Forms",
BackgroundColor = Color.Yellow,
TextColor = Color.Blue,
Font = Font.SystemFontOfSize(NamedSize.Large),
VerticalOptions = LayoutOptions.CenterAndExpand,
HorizontalOptions = LayoutOptions.CenterAndExpand,
}
});Достаточно знать язык C# с его императивным стилем написания программ, свободно чувствовать себя в среде .NET и изучить несколько классов, связанных с конкретными платформами.
using System.Diagnostics;
using Foundation;
using UIKit;
namespace NeonPlayerConcept.iOS
{
[Register("AppDelegate")]
public class AppDelegate : UIApplicationDelegate
{
public override UIWindow Window { get; set; }
public static void Main(string[] args)
{
UIApplication.Main(args, null, "AppDelegate");
}
}
}Источник.
Для создания полностью «родного» приложения для той или иной платформы вам потребуется в достаточной мере владеть языком Java (в случае Android) или Objective-C/Swift (для iOS). В некоторых случаях это может стать серьезным препятствием. Давайте посмотрим, как одна и та же задача, подразумевающая создание строки атрибутов, решается в Objective-C и в C#.
В Objective-C:
CFStringRef stringKeys[] *
{
kCTFontAttributeName,
kCTForegroundColorAttributeName
};
CFTypeRef stringValues[] *
{
myListFontRef,
COColorGetConstantColor(kCOColorWhite)
};
attr = CFDictionaryCreate (kCGAllocatorDefault,
(const void **) &stringKeys,
(const void **) &stringValues,
sizeof(stringKeys) / sizeof(stringKeys[0]),
&kCFTypeDictionaryKeyCallbacks,
&kCFTypeDictionaryValueCallbacks);
astr = CFAttributedStringCreate(kCFAllocatorDefault, CFSTR(“Hello from ego team!”), attr);В C#:
var stringAttributes = new CFStringAttributes
{
Font = myFont,
ForegroundColor = UIColor.White.CGColor
};
var myString = new NSAttributedString (“Hello from EGO team!”, attrs);Если вы не используете возможности кросс-платформенной разработки Xamarin, то для создания коммерческого проекта, который обладал бы достаточной производительностью на обеих платформах, может потребоваться применять сразу два разных подхода. А значит, и затраты практически удваиваются.
2. Снижение расходов на проект
Исходя из описанных выше преимуществ можно отметить, что кросс-платформенная разработка с использованием Xamarin требует примерно в 1,5 раза меньше времени (и денег), чем создание отдельного специализированного проекта под каждую платформу.
Конечно, некоторые фрагменты кода (например, служебные компоненты) будут одинаковыми в обеих версиях, а часть других (в частности, бизнес-логика, не использующая специализированные функции пользовательского устройства) потребует лишь незначительных изменений. Однако общая ситуация немного сложнее. Некоторые компоненты вашего приложения неизбежно придется писать с нуля для каждой ОС. При создании и развертывании двух приложений для двух платформ практически всегда необходимо нанимать две команды разработчиков. При использовании Xamarin все гораздо проще:
благодаря не зависящим от платформы интерфейсам API примерно 70% кода будет написано в универсальном формате.
В этом примере класс MainPage использует интерфейс ITextToSpeech для выбора нужной функции на конкретной платформе:
ITextToSpeech.cs:
public interface ITextToSpeech
{
void Speak (string text);
}
TextToSpeech_Android.cs:
[assembly: Dependency (typeof (TextToSpeech_Android))]
namespace UsingDependencyService.Android
{
public class TextToSpeech_Android : Java.Lang.Object, ITextToSpeech
{
TextToSpeech speaker;
string toSpeak;
public TextToSpeech_Android () {}
public void Speak (string text)
{
\\Android-specific code
}
}
}
TextToSpeech_iOS.cs:
[assembly: Dependency (typeof (TextToSpeech_iOS))]
namespace UsingDependencyService.iOS
{
public class TextToSpeech_iOS : ITextToSpeech
{
TextToSpeech speaker;
string toSpeak;
public TextToSpeech_Android () {}
public void Speak (string text)
{
… \\iOS-specific code
}
}
}
MainPage.cs:
public class MainPage : ContentPage
{
public MainPage []
{
var speak = new Button
{
Text = “Hello, world!”,
VerticalOptions = LayoutOptions.CenterAndExpand,
HorizontalOptions = LayoutOptions.CenterAndExpand,
};
speak.Clicked += (sender, e) =>
{
DependencyService.Get<ITextToSpeech>().Speak("Hello from Xamarin Forms");
};
Content = speak;
}
}3. Возможность создавать пользовательские интерфейсы, подобные «родным»
Одна из основных причин, по которым разработчики избегают инструментов кросс-платформенной разработки, заключается в том, что такие средства не позволяют пользоваться всем спектром возможностей конкретных сред. В первую очередь это относится к дизайну (Flat Design в iOS, Material Design в Android) и к интеллектуальным возможностям пользовательских устройств (доступ приложения к контактам, камере, данным GPS и т. п.).
Конечное кросс-платформенное решение не будет обладать высокой производительностью (этот недостаток присущ практически всем приложениям, созданным с помощью кросс-платформенных веб-инструментов) и не сможет пользоваться преимуществами конкретных платформ (а это значит, что некоторые возможности, изначально запланированные создателем проекта, могут быть реализованы не полностью).
Однако все иначе при использовании инструментов Xamarin для кросс-платформенной разработки «родных» приложений. В этом случае вы не столкнетесь с вышеописанными проблемами. Разработчикам доступны не только стандартные классы .NET: они могут с легкостью подключить и классы, поддерживаемые конкретной мобильной платформой (они содержатся в библиотеках C# для Xamarin.Android и Xamarin.iOS соответственно). Это значит, что при использовании Xamarin для разработки приложений под iOS и Android в вашем распоряжении будет весь набор возможностей этих платформ. При этом не потребуется использовать сторонние (и обычно платные) инструменты.
4. Оптимальные условия для тестирования
Тестирование продукта, который готовится к выпуску, — задача нетривиальная, особенно когда речь идет о платформе Android. Форматы экранов пользовательских устройств iOS четко определены и известны заранее, а вот устройства Android бывают самыми разными. Если приложение не было протестировано на определенном устройстве, его интерфейс в некоторых случаях может «разъехаться». Создатели Xamarin предложили решение для этой проблемы.
В частности, для пользователей платформы также доступна среда Test Cloud, позволяющая эмулировать более 2000 устройств. Это решение не бесплатно, но затраты на него будут оправданы.
Дополнительные материалы: девять лучших инструментов тестирования мобильных приложений для iOS и Android.
5. Идеальная совместимость с устройствами «Интернета вещей»
Если вы хотите, чтобы ваше приложение получало данные о местоположении пользователя, показания гироскопа, акселерометра или других встроенных датчиков, то Xamarin станет отличным выбором.
private void Instance_Ranged(object sender,
System.Collections.Generic.IEnumerable<IBeacon> e)
{
Try
{
var data = string.Empty;
foreach (var beacon in e)
{
data = $@”region id: {beacon}
}
_labelContent.Text = data;
LogStatus(@”Ranged”);
}
catch (Exception exception)
{
LogStatus(exception.ToString());
}
}Эта среда разработки полностью совместима с устройствами IoT (например, с Estimote), позволяющими получать данные о местоположении, а значит, вам не придется настраивать интеграцию со сторонними решениями (тем более что такой возможности не будет в принципе).
6. Качественная документация и большое сообщество
Для Xamarin доступна отлично организованная документация с практическими примерами, фрагментами кода и пошаговыми инструкциями.
Разумеется, на некоторые вопросы найти ответ в ней не получится. В этом случае вам поможет онлайн-сообщество. Существует два официальных сообщества Xamarin: на официальном сайте платформы и на портале StackOverflow.
Если и здесь вам не удалось получить интересующую информацию (некоторые разработчики жалуются, что эксперты сообществ не очень активны), вы можете обратиться в частную службу технической поддержки, доступную для обладателей бизнес-лицензий Xamarin. Специалисты ответят вам уже через несколько часов и предложат не просто набор стандартных процедур, которые редко помогают полностью устранить проблему, а подробные пошаговые инструкции по решению именно вашей задачи.
7. Безупречная интеграция с Microsoft Windows
Практически в каждой ИТ-компании есть развитая инфраструктура используемого ПО на платформе Windows.
Для всех редакций Visual Studio (для Mac OS и Windows) с весны 2016 года в рамках подписки предоставляется и Xamarin. Если вы уже используете Visual Studio для разработки, вносить дополнительную оплату не потребуется.
Недостатки Xamarin
Мы постарались подробно рассказать о сильных сторонах Xamarin и рассмотрели ряд его очевидных преимуществ. Однако нам бы хотелось сделать этот обзор более объективным, так что обратимся к слабым сторонам решения. На самом деле внимания заслуживает лишь один недостаток: размер приложений, написанных с помощью Xamarin, обычно немного превышает объем нативных аналогов. Тем не менее оптимизация никогда не бывает лишней.
Итак, насколько эффективен Xamarin?
Xamarin обладает рядом преимуществ и отлично подходит для масштабных проектов по разработке сложных с точки зрения архитектуры кросс-платформенных приложений, аналогичных нативным решениям.
Комментарии (49)
Fengol
04.07.2018 11:50Для разработки приложения на основе Xamarin вам не потребуется досконально знать специфические языки отдельных платформ.
То есть на c# я могу покрыть все случаи выходящие за границы HelloWorldApp по работе с платформой?
Xamarin требует примерно в 1,5 раза меньше времени (и денег), чем создание отдельного специализированного проекта под каждую платформу.
В первую очередь это относится к дизайну (Flat Design в iOS, Material Design в Android)
… и metro (если не ошибаюсь) для windows. И того три разных дизайна + в три раза дольше время на создание дизайна + три раза больше денег на создание трех разных дизайнов.
И кто сказал что разный дизайн одного приложения это круто? Наверное программисты, которым всегда трудно реализовывать дизайнерские идеи? Я не думаю чтобы дизайнер был доволен если бы его работа заключалась только в ресовании унифицированных схем с надписями «кнопка» и «селект».
А как же uix? Как можно разработать uix интерфейс, если интерфейс на каждой платформе разный?
И angular позволяет с api платформ на js работать. При чем оно по времени обновляется практически одновременно с платформой.
И невозможно не зная компонентной системы платформ и их api работать с ними. Даже в случаи кросплатформенных инструментов. Не нужно людей обманывать!ZAMnoTEX
04.07.2018 12:31Если не хотите разный дизайн — Xamarin Forms вам самое то. Вообще платформ-специфичного кода будет процентов 5
ZAMnoTEX
04.07.2018 12:39Платформы знать конечно же нужно. Но разговор о том, что бизнес-логику не нужно переписывать с Java на Swift. А в некоторых приложениях это львиная доля кода
roboter
04.07.2018 14:02Ну для справедливости надо сказать что у каждой платформы свои гайдлайны по дизайну, никто вам не запрещает сделать один дизайн для всех платформ, только вот в магазины их не выложить.
Simplevolk
04.07.2018 11:59А мне, наоборот, легче освоить Android SDK, чем держать в голове сразу и XAML и Android разом.
Плюс, насколько легко там подключать сторонние Android библиотеки? Особенно, если они тянут зависимости.
В Android Studio это решается простым добавлением строки в gradle. А что в Xamarin?
Насколько я знаю, там это нужно делать руками.mayorovp
04.07.2018 12:17Что значит «руками»? По идее, точно так же должна добавляться строка в файл проекта…
ZAMnoTEX
04.07.2018 12:33+1XAML? за все время работы с Xamarin ни разу с ним не работал. XAML нужен только для Forms, в Xamarin.Android и Xamarin.iOS используются «нативные» layout'ы и StoryBoard'ы
ZAMnoTEX
04.07.2018 12:34+2зависимости? Про NuGet слышали? 2 клика мыши
Simplevolk
04.07.2018 13:05А причем тут Nuget? Мне нужны платформозависимые библиотеки. Например, retrofit.
ZAMnoTEX
04.07.2018 13:08+1А при том, что все зависимости тащятся из Nuget. Ну или ссылка на проект в солюшене. Или библиотека из .NET фреймворка. Платформозависимые библиотеки оборачиваются в Nuget пакеты.
З.Ы. в Xamarin вы будете пользоваться не retrofit, а HttpClient (.NET из framework) или RestSharp из того же Nuget
worldbeater
05.07.2018 18:05Если хочется собирать API сервис из аннотаций, лучше, всё-таки, использовать Refit (https://github.com/reactiveui/refit), эдакий Retrofit для .NET. Если нужна производительность, то имеет смысл посмотреть в сторону ModernHttpClient (https://github.com/paulcbetts/ModernHttpClient)
Atreides07
04.07.2018 13:37При желании можно подключить любую нативную библиотеку написанную на 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
VolCh
04.07.2018 12:05А с Linux какая интеграция, ну или с MacOS? Если нет развитой Windows инфраструктуры, максимум в бухгалтерии используется, то:
а) насколько реально полноценно разрабатывать без приобретения Windows и VisualStudio?
б) если не реально, то сколько будет стоит комплект софта для разработчика в розницу?ZAMnoTEX
04.07.2018 12:36Visual Studio «приобретать» нужно далеко не всегда. Очень часто достаточно бесплатной Community версии
VasiliySS
05.07.2018 11:44Есть Visual Studio Code, для мака и линкуса. Xamarin работает там без проблем, по крайней мере — на маке точно.
ZAMnoTEX
04.07.2018 12:29У меня есть опыт работы в достаточно серьезной компании над вполне крупным приложением на Xamarin с навороченной бизнес-логикой. Вот что я скажу: насчет плюсов — согласен. Допилить какую-то фичу под другую платформу — это процентов 10-20 от времени работы над фичей. Одна команда универсальных солдат. Причем команда частенько ротировалась с десктопной командой (там WPF). Большая часть кода бизнес-логики шарилась с десктопом. Родной C#, MVVM фреймворк (MVVMCross), процесс разработки — одно удовольствие (если не считать глюков и лагов коннекта с Маком для сборки проекта под iOS — да-да, для сборки под iOS без Мака никуда, а работа со всем этим хозяйством — это то еще удовольствие).
НО! Приложение на не самых быстрых андроид-устройствах грузилось до 15 секунд!!!
Вы можете себе представить, чтобы какой-нибудь фейсбук грузился 15 секунд? Да вы, как пользователь, пошлете к чертям такое приложение, если это не B2B сектор, и вам НАДО с этим приложением работать. Конечно, там не только проблема фреймворка, там было много наших косяков, и с бубном удалось на пару секунд сократить загрузку, но все же… Например такой факт: гугл сделал DI контейнер Dagger 2, который работает на кодогенерации, и соответственно, в рантайме времени на поднятие контейнера не тратится. А нам приходилось работать с Autofac, который работает на рефлексии, и поднятие контейнера занимало при запуске несколько секунд!
З.Ы. простите за многабукаф, ИТОГО: мое мнение — Xamarin очень хорош, если у вас B2B сектор, готовая .NET команда, и нужно шарить код с десктопом. А главный критерий — сценарий использования приложения — как часто юзер будет его открывать и как долго с ним работать. Если открывать 20 раз в день чтобы ответить на сообщение и закрыть — Xamarin использовать нельзя.lassana
04.07.2018 13:5215 секунд сold start — это, конечно, вы неправильно готовили своё приложение. Даже запуск приложений, написанных на Forms, занимает секунд 5-6, а с Xamarin Classic + AOT запуск на андроидах не занимает более пары секунд.
ZAMnoTEX
04.07.2018 14:22полностью согласен, что не так делали, но: если даже сделать пустое приложение Xamarin.Adnroid, оно будет стартовать около секунды, т.е. заметно. Инициализацию mono никто не отменял. А если еще навернуть какой-нибудь фреймворк типа MVVMcross, то еще дольше. В туториалах MVVMCross сразу же объясняют, как сделать splash screen!
И попробуйте создать пустой проект в Android Studio, запустите — приложение будет стартовать мгновенно.
Atreides07
04.07.2018 13:55Я часто сталкивался с аналогичной проблемой когда консультировал команды на Xamarin. Не обязательно все что может понадобиться и не понадобиться использовать на старте и инициализировать все. Можно декомпозировать приложение, сделать Lazy инициализацию компонент, выделить модули и приложение начнет запускаться намного быстрее.
mayorovp
05.07.2018 13:12Если у них и правда тормозит сам этап настройки контейнера Autofac — это не поможет. Тут надо или смириться — или переходить с Autofac на что-нибудь еще.
Oleg_123
06.07.2018 00:38У нас тоже была похожая проблема, когда мы пытались полностью загрузить все связи и включить основной функционал во время старта приложения. Проект был средним, занимал на обычном (вроде за 12к руб) телефоне 5-7 сек. Тот же Autofac, легко позволил запускать построения всех зависимостей в фоне, что скинуло около 2 сек, для нормального отображения и пользования. Не думаю что загрузка приложения за 15 сек, это в основном проблема Xamarin и Autofac. Хоть, так сложилось что я больше не пишу на Xamarin промышленно, но рад что познакомился с этой платфомой и думаю у неё большое будущее. Считаю что использования данного фреймворка в бизнес-решениях, действительно хорошая идея и возможно даже не много выгоднее, чем держать 2 команды которые разрабатываю по сути одно и тоже.
tapoton
04.07.2018 12:33-3А вы уверены, что если приводишь примеры «сложной» разработки при помощи нативных средств, и при этом, чтобы показать, какая она сложная, используешь низкоуровневые библиотеки, которыми никто давно не пользуется, то тебя никто не раскусит? :)
aFanOfSwift
04.07.2018 13:42Так тоже убило сравнили C# и Objective-С, а почему код на Swift не привели в пример? Потому, что код на Swift по размеру будет, как и С#, но это конечно мелочь, но не нужны точки с запятой в конце каждой строки.
aknew
04.07.2018 14:00Даже честный код на obj-c был бы того же размера по строкам (если по символам считать то чуть больше), да и вообще отличался бы только в синтаксисе самого языка. К тому же это ведь второй заход с этой статьей (первый собрал кучу вопросов и ушел в черновики, если это перевод — не понятно почему просто не послать к статье-оригиналу вместо этого) и автору уже об этом писали.
lassana
04.07.2018 13:44+1Я лишь напомню, что Profiler для Xamarin (базовая вещь!) доступен только в Visual Studio Enterprise за $3k/год за пользователя.
NightMan665
04.07.2018 15:25Тут Microsoft, конечно, обнаглели. Но разработчики бодаются с ними, вот здесь например. Посмотрим, насколько успешно это выйдет…
lassana
04.07.2018 16:12Крайне в этом сомневаюсь. Эти ребята даже сделали опцию AOT-компиляции для Android доступной только в Enterprise-версии. К счастью, AOT — это часть опенсорсного Xamarin.Android, и пока что можно включить вручную в csproj.
xRay
04.07.2018 13:54-1А отладчик нормальный в котором видно значения переменных и объектов в Xamarin завезли?
ZAMnoTEX
04.07.2018 14:10отладчик Visual Studio. Все там видно.
Вообще, большинство вопросов здесь — от незнания того, как работает Xamarin. Xamarin приложение на Android — это, по сути, приложение Mono, т.е., это то же .NET приложение, только в среде Linux. В iOS немного сложнее. Это если в двух словах. Интересующимся — доки.VolCh
04.07.2018 14:26Если Mono, то почему Windows обязателен, ну или MacOS?
ZAMnoTEX
04.07.2018 14:28Visual Studio есть только для винды и macOS
VolCh
04.07.2018 14:44Есть MonoDevelop. Или таки тесная интеграция с Visual Studio это в целом не плюс, а минус в виде vendor lock-in?
lassana
04.07.2018 16:04Xamarin Studio от monodevelop всегда отличало наличие плагинов для разработки iOS и Android приложений. Microsoft, разумеется, исходники этих плагинов не открыли ни после покупки Xamarin, ни при ребрендинге Xamarin Studio > Visual Studio for Mac, поэтому разработка Xamarin-приложений на линуксах невозможна. Vendor-lock во всей красе.
Но, вообще говоря, вы можете собирать Xamarin.Android-приложения в среде Linux, т.к. msbuild уже кроссплатформенный, и вы даже можете попробовать использовать Rider от JetBrains для разработки.
xRay
04.07.2018 16:54Отлаживал как-то broadcast активити в Android Studio и похожий проект на Xamarin в Visual Studio. Может с тех пор лучше стало.
V1tol
04.07.2018 15:13Специально что ли выбрали самый вырвиглазный пример с attributed string? Никто в обычном проекте не пишет строку с помощью CoreFoundation. Нормальный пример выглядит так:
NSDictionary *attributes = @{NSFontAttributeName: [UIFont systemFontOfSize:16], NSForegroundColorAttributeName: UIColor.whiteColor}; NSAttributedString *string = [[NSAttributedString alloc] initWithString:@"Hello from ego team!" attributes:attributes];
geekmetwice
04.07.2018 22:25-1Многоплатформенность — это самый отстойный хайп последних лет. Запудрили мозги миллионам людей, а сами даже инструментов нормальных поставить не могут.
Есть десктоп-венда и считай, это 100% юзеров. С мониками от 20", мышой и относительно мощными ПК. Пишешь приложение строго для венды, со всеми гайдами, дизайном, темами и поэтессами. И очевидно, это будет классное rich-приложение, потому что не только look, но и feel.
Если вдруг вы обнаружили большой спрос на какой-нть ведроид или макакось, только тогда имеет смысл рассматривать разработку для других платформ! Ещё раз: сначала спрос, потом предложение. Потому что ИТ — это не «ещё более новый шампунь», здесь всё серьёзно и разрабатывается годами. Ни один бизнесмен не будет рисковать проторённым путём и прыгать на неполовозрелые идейки «а что если нас захотят запустить на Линукс?».
Захотят — тогда начнётся серьёзное исследование, где будут заданы крайне неудобные вопросы, на которые ни один усатый «сеньёр» 25-ти лет не даст внятного ответа — ибо скудоум в силу возраста:
1. Какой примерный прицент юзеров нашей программы хочет линупсы/макоси/ведроиды? Это серьёзный процент или это 1% маргиналов, которым лишь бы повопить «а давайте запустим эту хрень на моём 100-долларовом андроиде!»?
2. Какова вообще ЦА другой платформы? Её платёжеспособность? Желание вообще что-либо покупать? Как часто они готовы платить? Есть ли там бизнес сектор? Какие перспективы расширения?
3. Насколько гетерогенной будет разработка? Можно что-то перенести из венды? Какой ценой? Сколько на рынке есть специалистов по данной платформе? Сколько они хотят? Сколько это занимает времени?
4. Поддержка. Мрачный саппорт, тупорылость которого зашкаливает даже по джамшутным меркам. На венде ещё как-то люди ориентируются, где брать «недоайтишнегов» на маках? линуксе? Они вообще адекватные? По вендовой версии может саппортить даже программист, а что он будет делать с макофилами??
5. Платформы. Они РАЗНЫЕ и очень. И не надо вешать лапшу про «везде есть кнопки» — есть, да только это не составляет и 1% трудностей, которые нужно преодолеть! Это и «нативное поведение контролов» (чего не умеет НИ ОДНА кросс-библиотека), и специфичные механизмы (трэды, семафоры, сокеты, секьюрити, да чё говорить — не везде даже файлы доступны!). Только нативное приложение, разработанное профессионалами данной платформы, не будет вызывать тошноту у юзеров этой же платформы. Потому что этому учатся ГОДАМИ! Малолетние хипстеры со своими Qt/wxWidgets и прочими Кзамаринами просто «подаваны» по сравнению с теми, кто работал и развивался в каждой конкретной среде.
6. Отдельно коснусь мобильного мира: это совсем другая планета, товарищ! Забудь про аршинные тулбары и драгндропы, про «onMouseOver» и тонюсенькие, будто идиотом точенные, скроллбары — в «пальцетыке» это не прокатит. Только кнопки, свайпы и иконки на пол-экрана! И «никакая» производительность с «никакой» же памятью. Никакой тебе мемоизации, кэша и прочих плюшек. Выкусил? Только наивный Чебурашка будет думать, что вот сейчас он наскочит со своими кзамаринами и залепит аппликуху на всё, что только можно назвать компьютером! Мобильное ПО — это коренным образом отличающийся софт, который неизбежно надо проектировать с нуля, учитывая все ньюансы взаимодействия и ограничений.
Windows 10 — вот пример «ИТ урода», где кто-то не очень умный решил скрестить десктоп с мобилами — никому не нужный павлиноуткаёж просто галопом несётся в анал (не анналы!) истории.
Короче, грустно наблюдать весь этот тупняк, распаление ресурсов и натягивание совы на глобус — индустрия категорически не хочет думать — все хотят только баблосос на очередном хайпе. Прогресс/наука и бизнес — они несовместимы!VasiliySS
05.07.2018 16:57Вы что-то путаете: не надо изучать спрос, чтобы понять, что выгоднее иметь приложение одновременно и под Android, и под iOS. А именно это замарин и предлагает в первую очередь. Возможность получать вин-приложение на нем — плюшка, мне тоже непонятная.
А так он дает глобально две вещи:
- возможность писать, использую нативное для платформы API, но используя C# и весь .Net за ним. Лично для меня это большой плюс — изучать андроид и джаву одновременно, или макос и objective-c несколько затратнее, чем просто одну платформу. Плюс, если вы делаете приложение одновременно для обеих платформ, вы можете пошарить между ними часть не UI-кода;
- при использовании Xamarin.Forms позволяет еще и иметь довольно большое количество общего UI-кода. Вы пишете UI, используя его абстракции, а не конкретной платформы. А он уже генерирует вам нативный UI, с учетом особенностей в отображении для разных платформ.
gcnew
05.07.2018 09:49Не буду сжигать ведьм на костре. Мы используем xamarin натив. Приложения действительно совсем разные. Не понял в чем проблема у предыдущего поста. Все пункты абсолютно вписываются в Xamarin натив. По перформансу нареканий нет. Про мобильные устройства тоже не согласен. Надо смириться с фактом, что мобильные устройства на первом месте, компьютер на втором (хотя бы количеству устройств). Про нативные специфичные механизмы — dependency injection в помощь. Разные вещи делай в платформозависимых библиотеках, одинаковые в Portable переноси. Xamarin Forms 3.0 позволяет одинаковые формы выносить в Portable и эмбедить их в Xamarin натив.
Из минусов Xamarin — еще один слой с еще одним слоем багов. IDE отстают от нативных (Android Studio, XCode). Visual Studio и Visual Studio Mac — совершенно разные IDE.
Из чисто нативной разработки минусы: разные платформы — разные баги, рассинхрон и несовместимость приложений на разных платформах.
Не нравится C# — котлин есть еще.
makasin4ik
05.07.2018 10:54Мы уже 6 лет пишем на xamarin ( notissimus.com ) — чтобы не быть голословным — такие приложения, как ФК ЗЕНИТ и ХК СКА написаны сейчас именно на Xamarin и мы видим в этом огромные плюсы именно в части кросс-платформенности. На Xamarin мы написали и продолжаем развивать конструктор приложений для розничных компаний appropio.com — не сталкивались мы еще с трудностями в бизнес-приложениях, которые не смогли решить на Xamarin. Так что из нашего опыта — рекомендуем.
Bringoff
Мне кажется, или раздел недостатков слегка
сильнонедописан?sahsAGU Автор
Это — мнение ребят из EGO. Делитесь своим. Мы всегда рады получать отзывы и стараться улучшить платформу. :)
A__D
Статья просто выглядит как недописанный черновик в конце…