Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
В нашей компании — Touch Instinct — пишем, используя технологии Xamarin. В общем, все заказчики очень довольны :)
Интересный инструмент, надо обязательно попробовать, пожалуй, Obj-C и время вхождения — это все что меня останавливалось начать разработку на мобильных платформах.
ps Хорошо бы еще добавить прямые ссылки на скачку, я лично против сбора такой инфы через анкеты.
ps Хорошо бы еще добавить прямые ссылки на скачку, я лично против сбора такой инфы через анкеты.
Я так понимаю, разрабатывать на Xamarin имеет смысл только если приложение содержит много бизнес-логики, чтобы не надо было ее переносить между платформами?
Потому что UI в любом случае приходится разрабатывать отдельно под каждую платформу.
То есть например если у нас клиент-серверное приложение, и вся бизнес-логика на сервере а клиентская часть просто отображает данные, которые получает с сервера используя RESTful API — по сути, никакого особого выигрыша по сравнению с «нативной» разработкой под каждую платформу мы не получим?
Потому что UI в любом случае приходится разрабатывать отдельно под каждую платформу.
То есть например если у нас клиент-серверное приложение, и вся бизнес-логика на сервере а клиентская часть просто отображает данные, которые получает с сервера используя RESTful API — по сути, никакого особого выигрыша по сравнению с «нативной» разработкой под каждую платформу мы не получим?
Да, в этом случае выигрыш в плане переносимости кода будет несущественным. Однако опять же, если вы любите и пишете на C#, то вам в любом случае будет приятнее вести разработку на Xamarin.
По сути да. Малую часть кода перенести все же можно, но родные инструменты все же всегда лучше.
Процент общего кода можно ещё повысить если использовать библиотеки(фреймворки) вроде MVVMCross. Но, как всегда, инструмент нужно выбирать под задачу.
Кстати, вот недавно попытался создать PCL в Xamarin на Mac, но в таргетах можно выбрать только .net 4, silverlight, xbox 360, windows phone 7, и сборка даже не компилируется и никаких намеков на 4.5. Хотя обновил до последней версии, MDK до 3.2.0 обновил.
Вы случайно с такой проблемой не сталкивались?
Вы случайно с такой проблемой не сталкивались?
сравнение кода на Objective-C с C# — ересь полная. Маркетологи вступают в дело.
В Objective-C, конечно, побольше текста по сравнению с C#, но этот конкретный пример отстал от реальности эм… года на полтора
Objective-C вариант, наши дни:
В Objective-C, конечно, побольше текста по сравнению с C#, но этот конкретный пример отстал от реальности эм… года на полтора
Objective-C вариант, наши дни:
NSDictionary * attrs = @{
NSFontAttributeName : [UIFont systemFontOfSize:12],
NSForegroundColorAttributeName : [UIColor blackColor],
};
NSAttributedString * string = [[NSAttributedString alloc] initWithString:@"Hello, world" attributes:attrs];
Согласен, я долго думал, стоит ли включать это конкретное сравнение в статью. Когда мне приходится переносить некоторый код из objective-c на C#, объем кода отличается, но не в разы. Однако, стройный синтаксис C# в связке с лямбда выражениями делают его гораздо понятнее. Конечно, если вы не первый код пишете на Objective-C, для вас это может быть не слишком актуально.
Зря включили, статья сразу получила соответствующий уклон.
Насчет стройности итд — я бы лично поспорил. После нескольких лет работы с ObjC работать с ним получается очень удобно. У шарпа как и у Java есть свой минус — очень много лишней информации для стороннего программиста. В ObjC можно гораздо точнее разделять код, который стоит видеть другим программистам (.h) и реализацию. Плюс саму реализацию можно разделять хоть на 10 частей (файлов), если функционал уж совсем большой. На шарпе Partial не сильно выручают, потому что все равно реализация идет сразу с интерфейсом. Можно выделять интерфейсы, но тогда кода станет еще больше.
Все равно, работа с обычными типами — строками, датами — в ObjC ужасная, а на .NET — вменеямая. Например, сколько строк кода надо на ObjC чтобы написать
DateTime.UtcNow.ToShortDateString()?Можно подумать, что я собирался спорить, что на Obj-C писать меньше надо. Чаще всего больше. Может, быть даже всегда.
Я говорю о том, что создается ощущение, что примеры на Objective-C на Xamarin'е писали люди, ОЧЕНЬ давно писавшие на Objective-C, и не самым лучшим образом )
Xamarin сам по себе очень хорош. Но рекламировать его на таких примерах — это как по мне, немного грязный ход.
Я говорю о том, что создается ощущение, что примеры на Objective-C на Xamarin'е писали люди, ОЧЕНЬ давно писавшие на Objective-C, и не самым лучшим образом )
Xamarin сам по себе очень хорош. Но рекламировать его на таких примерах — это как по мне, немного грязный ход.
Ну наверно как-то так:
Но ведь можно определить для проекта свой
А как будет выглядеть на C# следующее объявление:
И очень хочется посмотреть на аналогичную C# реализацию вот такого кода:
Но ведь можно определить для проекта свой
[NSDateFormatter sharedFormatter] (например через категорию), и получим аналогичное решение в одну строчку.А как будет выглядеть на C# следующее объявление:
И очень хочется посмотреть на аналогичную C# реализацию вот такого кода:
Вот так, примерно:
UIView.Animate(0.25, () => someView.Alpha = 1, () => {
UIView.Animate(0.25, 3, (UIViewAnimationOptions)0, () => someView.Alpha = 0, () => someView.RemoveFromSuperview());
});
С async/await
Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
void async AnimateSome()
{
await UIView.AnimateAsync(0.25, ()=>someView.Alpha = 1)
await UIView.AnimateAsync(0.25, 3, (UIViewAnimationOptions)0, () => someView.Alpha = 0)
someView.RemoveFromSuperview()
}
Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
Разница лишь в привычке, кто к чему привык. При этом стоит помнить, что Objective-C только для Mac/iOS, а в данной ветке речь про C# для всех подряд платформ, включая и iOS, и тут сам язык не сравнить, т.к. он полностью зависит от разработчиков Mono и Xamarin, например упомянутый вами DateTime.UtcNow.ToShortDateString не работает под iOS, это баг. Так что может данный случай на C# и быстрее написать, но, как всегда с MSFT — он не работает.
При этом если сравнивать основные платформы ObjC и основные платформы C# то тут у шарпа шансов вообще нет.
При этом если сравнивать основные платформы ObjC и основные платформы C# то тут у шарпа шансов вообще нет.
Основы? это типа динамическая типизация и массивы всего чего угодно? Или специфические названия функций, которые в целом улучшают читаемость (дают большее представление о том что функция делает)?
Это все на вкус и цвет. Мне, например, не нравится, что очень часто ошибка проявляется только где-то в рантайме. (приходилось пару раз вечер после работы отлаживать чухой код, который на C# не скомпилируется с подобной ошибкой). Возвращение nil'ом nil тоже выглядит прикольно. Но опять же, скрывает некоторые ошибки до рантайма. Что опять же не есть гуд. Или вы имели ввиду что-то другое?
А что не так с DateTime.UtcNow.ToShortDateString? Всегда работало и сейчас только что проверил — работает. Был косяк в моно с MonthDayPattern для русского языка (было 30 Июль), но с последним релизом моно это исправили, правда они восстановили косяк сильверлайта (июля 30). Но это все можно обойти нативными функциями или вручную прописать шаблон.
Что мне нравится в Xamarin.iOs — это работа с CoreGraphics. Не нужно писать все в C-style (Да именно в C, а не C++ или Obj-C).
Это все на вкус и цвет. Мне, например, не нравится, что очень часто ошибка проявляется только где-то в рантайме. (приходилось пару раз вечер после работы отлаживать чухой код, который на C# не скомпилируется с подобной ошибкой). Возвращение nil'ом nil тоже выглядит прикольно. Но опять же, скрывает некоторые ошибки до рантайма. Что опять же не есть гуд. Или вы имели ввиду что-то другое?
А что не так с DateTime.UtcNow.ToShortDateString? Всегда работало и сейчас только что проверил — работает. Был косяк в моно с MonthDayPattern для русского языка (было 30 Июль), но с последним релизом моно это исправили, правда они восстановили косяк сильверлайта (июля 30). Но это все можно обойти нативными функциями или вручную прописать шаблон.
Что мне нравится в Xamarin.iOs — это работа с CoreGraphics. Не нужно писать все в C-style (Да именно в C, а не C++ или Obj-C).
Достоинства перечислять скучно, с ними все ясно :) Напишу про недостатки платформы, благо уже больше полугода плотно с ней работаю (помимо перечисленных).
1. Регулярное переколбашивание фреймворка и продуктов. Внезапное возникновение багов в тех местах, где они уже были пофикшены год назад. Это несколько утомляет.
2. Профайлер под Mono доступен только в бизнес версии, о чем на сайте ни слова. Однако нативный профайлер для iOS все равно намного лучше, так что это не проблема.
3. Интеграция с xcode сделана так себе, вызывает регулярные проблемы. С другой стороны, xcode в принципе это тихий ужас. В итоге интерфейсы лучше всего создавать из кода c#. Проще поддерживать и менять.
4. Очень своенравный сборщик мусора, к которому нужно приноравливаться. Имеет тенденцию поджирать объекты которые вы еще вовсю используете. Причем поведение разнится на реальном устройстве и в симуляторе.
Тем не менее, если бы я еще раз выбирал инструменты для мобильной разработки, выбор все так же однозначно упал бы на Xamarin.
1. Регулярное переколбашивание фреймворка и продуктов. Внезапное возникновение багов в тех местах, где они уже были пофикшены год назад. Это несколько утомляет.
2. Профайлер под Mono доступен только в бизнес версии, о чем на сайте ни слова. Однако нативный профайлер для iOS все равно намного лучше, так что это не проблема.
3. Интеграция с xcode сделана так себе, вызывает регулярные проблемы. С другой стороны, xcode в принципе это тихий ужас. В итоге интерфейсы лучше всего создавать из кода c#. Проще поддерживать и менять.
4. Очень своенравный сборщик мусора, к которому нужно приноравливаться. Имеет тенденцию поджирать объекты которые вы еще вовсю используете. Причем поведение разнится на реальном устройстве и в симуляторе.
Тем не менее, если бы я еще раз выбирал инструменты для мобильной разработки, выбор все так же однозначно упал бы на Xamarin.
Также сталкивался с проблемами 1 и 3. Но, последние обновления значительно улучшили ситуацию. Теперь сбои если и происходят, то редко. Насчет интеграции с Xcode. В качестве механизма для описания UI выбрал Storyboard и на текущий момент несколько раз уже пожалел. Во-первых это гигантский XML, который очень тяжело мерджится в случае, если над проектом работает несколько человек. Кроме того, как оказалось, пользы от «drag-n-drop» перетаскивания контролов на экраны практически никакой. Потому что практически на всех экранах используются кастомные View и динамическое добавление элементов управления. В итоге нашлась отличная библиотека для Xamarin — XibFree. Она значительно упрощает механизм создания интерфейса в коде, при этом позволяет избежать нудного рассчета положения каждого элемента при добавлении.
Черт, промахнулся веткой.
Черт, промахнулся веткой.
Спасибо за ссылку на XibFree, гляну. Т.к. проблема стоит в полный рост. От сторибордов действительно одни проблемы. Каркас накидать еще нормально, но делать что-то сложное — вешалка.
Лично я пользы от статических xib не вижу не только из-за динамического количества элементов, но и от того, что в iOS в отличие от того же WP контролы динамически не ресайзятся по содержимому и нет нормальных гридов. Это все нужно делать руками, в итоге рисование интерфейса в интерфейс билдере становится какой-то совершенно лишней стадией. Текущий проект начинал на storyboard+xib, сейчас же остался огрызок сториборда, а xib вообще все выкинул :)
Лично я пользы от статических xib не вижу не только из-за динамического количества элементов, но и от того, что в iOS в отличие от того же WP контролы динамически не ресайзятся по содержимому и нет нормальных гридов. Это все нужно делать руками, в итоге рисование интерфейса в интерфейс билдере становится какой-то совершенно лишней стадией. Текущий проект начинал на storyboard+xib, сейчас же остался огрызок сториборда, а xib вообще все выкинул :)
Аналогично. Сейчас от Storyboard остались только связи между экранами. В следующих проектах все буду делать исключительно через код и эту библиотеку. Работа с TableVIew в CocoaTouch вообще шокировала с плохой стороны.
Насчет динамического ресайза — Auto Layout не помогает?
Так это же все равно нужно все задать вручную. Сравните с гибкостью гридов в WP. Там просто верстаешь таблицами и не пытаешься издеваться над каждым из элементов.
Плюс, например, задачка: текстовое поле, увеличивать его до тех пор, пока в нем не будет трех строчек, а когда будет три строчки — обрезать. Я вот фиг знает, как это решать если не из кода.
Плюс, например, задачка: текстовое поле, увеличивать его до тех пор, пока в нем не будет трех строчек, а когда будет три строчки — обрезать. Я вот фиг знает, как это решать если не из кода.
Замените таблицы на View в качестве контейнеров с зависимостями между ними, получится то же самое. Гридами и таблицами — согласен, удобно, да и привычно еще с древних html времен. Но для мобильных интерфейсов и без гридов очень удобно.
Для текстового поля — задайте диапазон высоты элемента (min/max), чтобы влезало от 1 до 3 строк, и все.
Для текстового поля — задайте диапазон высоты элемента (min/max), чтобы влезало от 1 до 3 строк, и все.
А есть какие-нибудь удобные рисовалки/конструкторы GUI из компонентов?
Впечатление, что GUI создается так же неудобно как в Windows 3.1 API на C++
(там были какие-то вызовы, свой цикл обработки сообщений, файлы ресурсов, вообщем много всего «интересного и приятного»),
сравните с WInForms и WPF, но вот беда приложений под венду стало столько, что якобы уже тяжело «пробиться»
И наверно, когда мобильный GUI будет создаваться просто и удобно, инструменты будут доступны по цене,
приложений будет уже так же много как под венду, и появится ли к тому времени такой же сдвиг как MS->Google/Apple еще неизвестно
сейчас происходит смещение от Proprietary Windows к OpenSource Linux в области пользовательских смотрелок
а потом куда и зачем переходить, с линукса на freebsd? интерфейсы конечно будут очеловечиваться (общение словами и т.п.),
но наврядли Google сдаст свои позиции в ближайшие лет 10-20
С учетом этого, наверно, выгоднее использовать PhoneGap+asp.net+DevExpress наборы с уже существующими skils-ами, без всяких зависаний у разработчика
Впечатление, что GUI создается так же неудобно как в Windows 3.1 API на C++
(там были какие-то вызовы, свой цикл обработки сообщений, файлы ресурсов, вообщем много всего «интересного и приятного»),
сравните с WInForms и WPF, но вот беда приложений под венду стало столько, что якобы уже тяжело «пробиться»
И наверно, когда мобильный GUI будет создаваться просто и удобно, инструменты будут доступны по цене,
приложений будет уже так же много как под венду, и появится ли к тому времени такой же сдвиг как MS->Google/Apple еще неизвестно
сейчас происходит смещение от Proprietary Windows к OpenSource Linux в области пользовательских смотрелок
а потом куда и зачем переходить, с линукса на freebsd? интерфейсы конечно будут очеловечиваться (общение словами и т.п.),
но наврядли Google сдаст свои позиции в ближайшие лет 10-20
С учетом этого, наверно, выгоднее использовать PhoneGap+asp.net+DevExpress наборы с уже существующими skils-ами, без всяких зависаний у разработчика
т.е. заказные custom business приложения еще долго можно клепать на WinForms DevExpress, а чтобы что-то маленькое, полезное и не очень ресурсоемкое по разработке, наверно лучше пытаться популяризировать в растущем рынке мобил.
Ничего похожего на блендер для monotouch к сожалению нет.
Вы еще смотрите по скорости. Xamarin дает практически нативную скорость исполнения. Вам может показаться это не важным, но на мобильных устройствах проблема ресурсов стоит в полный рост. Самую банальную плавную прокрутку списка с «богатыми» элементами можно сделать хорошо на obj-C или на monotouch, а вот в webview уже не сделаешь.
Кто-нидудь в курсе, нету ли у Xamarin упрощённых лицензий для студентов, например с запретом на коммерческое использование или подобных?
А то очень хочется попробовать но цена даже за Indie кусается, а в ограничения Starter на размер и неподключение сторонних библиотек уже упёрся.
А то очень хочется попробовать но цена даже за Indie кусается, а в ограничения Starter на размер и неподключение сторонних библиотек уже упёрся.
После скачивания фреймворка первый месяц вы можете бесплатно пользоваться всеми фичами, доступными в Business-лицензии. За исключением приватной тех. поддержки, пожалуй. Про отдельные условия для студентов, к сожалению, нет ни слова.
Нет, только инди. Раньше была хорошая бесплатная лицензия в Monodevelop, которая позволяла разрабатывать сколько угодно до тех пор, пока тебе не нужно выкладывать код на реальное устройство, но кажется в феврале они обновили продукты + ограничили максимальный размер приложения, причем очень сильно. Как раз в это время пришлось купить лицензию.
Попробовать можно месяц бесплатно.
Попробовать можно месяц бесплатно.
Эх, жаль, спасибо за ответ.
Второй год пользуюсь бизнес версией Xamarin со студенческой скидкой. Что характерно, учусь заочно и не в первый раз, но формально, документы есть и их этот вариант устраивает.
Напишите им, спросите, обсудите варианты.
Напишите им, спросите, обсудите варианты.
Спасибо за наводку!
Собственно, вдруг кому ещё пригодится:
Do you have any student or academic pricing?
Собственно, вдруг кому ещё пригодится:
Do you have any student or academic pricing?
А еще Xamarin купили разработчиков Calaba.sh и продвигают тестирование приложений в своем облаке Xamarin Test Cloud. Облако — так себе, но Calabash стал развиваться побыстрее
для проекта, собранного на Xamarin, требуется устанавливать еще что-то дополнительное? Точнее где располагается иртуалная машина mono? Она добавляется в каждый проект или требует отдельной установки? Как при этом выглядит сам проект целиком — на сколько увеличивается размер при написании «родными» средами, на сколько уменьшается скорость выполнения при обработке в «параллельной» виртуальной машине? Проводили ли вы такое сравнение? Не интересует суперновые компоненты, которых нет среди стандартных. Но интересно сравнение по скорости и по объему кода для «хэллоу ворлд» с использованием допустим ListView и подобного аналога в Mono.
почему спрашиваю? сейчас у нас обсуждается перевод всех продуктов на C#, неплохо было бы еще достоинства и недостатки знать и учитывать.
почему спрашиваю? сейчас у нас обсуждается перевод всех продуктов на C#, неплохо было бы еще достоинства и недостатки знать и учитывать.
Mono Runtime тащится с собой в каждом приложении. Если я ничего не путаю, то это несколько мегабайт. Это, кстати, можно на бесплатной лицензии проверить.
По скорости работы, была проблема в Android при сборке мусора. Связана была с одновременной работой двух сборщиков: Mono и Dalvik. Но с этой проблемой сталкиваются не все.
По скорости работы, была проблема в Android при сборке мусора. Связана была с одновременной работой двух сборщиков: Mono и Dalvik. Но с этой проблемой сталкиваются не все.
Сейчас меня закидают помидорами, но как обстоят дела с лекарством? А то «пробовать» софт за 200 зелёных — жирно будет. Предпочёл бы пробовать без ограничений по размеру, времени и фичам, а покупать — если решусь.
насколько я в курсе, приложения до 64Кб можно разрабатывать халявно (Starter Edition)
Посмотришь на активность минусующих (в том числе особенно неленивых минусующих) — и создаётся впечатление, что на Хабре у всех только честно купленный лицензионный и опен-сорсный софт, а про Пиратскую Бухту и РуТрекер никто никогда не слышал.
Не верю. Не в стране, которая исправляет яркость фоток любимого кота в последней версии фотошопа.
Не верю. Не в стране, которая исправляет яркость фоток любимого кота в последней версии фотошопа.
На Хабре ж все типа разработчики и дизайнеры, поэтому пиратский софт и копирование чужого дизайна — это фу, а фильмы и музыка из торрентов — это ок.
Мнение по теме:
В продукте, основной фичей которого является кроссплатформенная разработка, брать деньги за каждую платформу отдельно — это как-то неправильно. И для некоммерческого использования (например, без права публикации в аппсторах и т.п.) можно было бы сделать бесплатную лицензию. Чтобы какой-нибудь начинающий разработчик мог полгодика поковыряться, накропать кроссплатформенное приложение не задумываясь о лицензии, потестить на собстенном устройстве, а перед публикацией уже купить подходящую лицензию.
Мнение по теме:
В продукте, основной фичей которого является кроссплатформенная разработка, брать деньги за каждую платформу отдельно — это как-то неправильно. И для некоммерческого использования (например, без права публикации в аппсторах и т.п.) можно было бы сделать бесплатную лицензию. Чтобы какой-нибудь начинающий разработчик мог полгодика поковыряться, накропать кроссплатформенное приложение не задумываясь о лицензии, потестить на собстенном устройстве, а перед публикацией уже купить подходящую лицензию.
По моему некультурно спрашивать про лекарство в комментарии к статье где рассказываться о продукте.
Разрабатывал игру на MonoGame, столкнулся с проблемой — подключение нативных Java библиотек, писать код по сути на JNI — тихий ужас.
В Xamarin.Android есть специальный тип проекта — Java Binding Library.
При этом получается использовать «нативные» Java-библиотеки очень просто — в Java Binding Library добавляется jar-файл, и после компиляции получается .Net dll-ка, содержащая необходимый нам Java-код с .Net-интерфейсом. При этом вся JNI-обертка делается автоматически.
При этом получается использовать «нативные» Java-библиотеки очень просто — в Java Binding Library добавляется jar-файл, и после компиляции получается .Net dll-ка, содержащая необходимый нам Java-код с .Net-интерфейсом. При этом вся JNI-обертка делается автоматически.
К сожалению с портабельностью кода на Windows Phone и Windows 8 не все просто — Microsoft уже сами ушли от System.Data, System.XML, System.IO, System.Graphics, к которым все привыкли и теперь код на Mono выходит даже «более .Net», чем для ".Net 4.5 For Windows Store". Решается, конечно, собственными Backwards Compatibility Library или еще более абстрактным уровнем в ядре приложения.
К сожалению отпугивает отсутствие бесплатной лицензии хотя бы для некоммерческих проектов. Для игр есть Unity 3D который тоже кроссплатформенный, тоже C# имеет достаточно мощную бесплатную версию почти для всех платформ (скоро будет поддерживать бесплатно Blackberry и Windows 8/Phone).
Ради самостоятельных неигровых экспериментов и некоммерческих проектов без конкретных целей по заработку платить 300 баксов как-то не хочется. Хотя конечно организаций это все не касается.
Ради самостоятельных неигровых экспериментов и некоммерческих проектов без конкретных целей по заработку платить 300 баксов как-то не хочется. Хотя конечно организаций это все не касается.
включая возможность одновременного импорта namespaces
== вот почему-то этой фичи не увидел. Подскажите, как она работает?
== вот почему-то этой фичи не увидел. Подскажите, как она работает?
А есть ли какие-то аналоги?
Для .NET — www.dot42.com
Для кроссплатформенности — QT и куча HTML хреновин.
Если ещё куча просто хреновин, но там все плохо, в основном.
Для кроссплатформенности — QT и куча HTML хреновин.
Если ещё куча просто хреновин, но там все плохо, в основном.
А можно ли как-то запустить свое приложение на iДевайсе без сертификата разработчика? В гугле нашел мануалы только для xcode
Уже около полугода используем Xamarin в нашей компании — Wellsoft. Запустили уже 2 мобильных приложения под iOS и Android. И ещё 3 мобильных приложения в разработке. В целом технологией довольны, но пока что сталкиваемся с некоторым количеством неприятных багов в самой платформе(
В принципе, эти баги можно отслеживать и запоминать, и разработка идёт довольно быстро.
Очень удобно то, что серверную часть, приложение для iOS и Android может писать один программист, т.к. разработка идёт на одном языке: c# и в одной среде разработки: Visual Studio.
В принципе, эти баги можно отслеживать и запоминать, и разработка идёт довольно быстро.
Очень удобно то, что серверную часть, приложение для iOS и Android может писать один программист, т.к. разработка идёт на одном языке: c# и в одной среде разработки: Visual Studio.
Очень удобно то, что серверную часть, приложение для iOS и Android может писать один программистВот после таких фраз бизнес плюётся от Xamarin из-за неоправданных ожиданий. Может писать один, но очень дорогой программист. Ну или что-то он будет делать очень плохо. Навыки и мышление серверного разработчика отличается от мобильного. Никто не хуже, просто они разные. Если человек может это совмещать, то он должен стоить дорого.
Все же, мобильный клиент отдельно, серверный бекенд отдельно. Так лучше. Но то, что писать взаимодействие клиента и сервера легче — это точно.
Согласен, что если приложение имеет сложную структуру или на это приложение планируется высокая нагрузка, то серверный бекенд не должен писать мобильный разработчик. Но замечательно, если этот бекенд будет писать программист из той же команды, на том же языке программирования, желательно сидящий рядом, чтобы не тратить время на долгие согласования формата обмена данными. Причём в некоторых случаях мобильный разработчик может сам что-то поправить в бекенде, не дожидаясь, когда освободится разработчик для бекенда.
А если приложение имеет простую структуру и низкую нагрузку(такое бывает очень часто), то для такого случая, бекенд вполне может написать мобильный разработчик. По крайней мере ему не придётся, ждать другого разработчика, и он может сделать всё сам.
Бизнес не будет плеваться на Xamarin, если команда разработки приложения содержит в себе и бекенд разработчиков и мобильных разработчиков, пишущих на одном языке, сидящих рядом.
Намного хуже когда серверный бекенд пишется, например, на PHP, приложение для iOS пишется на Swift, приложение для Android пишется на Java. А ещё хуже когда эти все программисты не объединены в одну команду. А найти такую команду, в которой будут собраны такие программисты, очень непросто. Намного чаще бывает, что команда пишет на каком-то одном языке программирования.
А если приложение имеет простую структуру и низкую нагрузку(такое бывает очень часто), то для такого случая, бекенд вполне может написать мобильный разработчик. По крайней мере ему не придётся, ждать другого разработчика, и он может сделать всё сам.
Бизнес не будет плеваться на Xamarin, если команда разработки приложения содержит в себе и бекенд разработчиков и мобильных разработчиков, пишущих на одном языке, сидящих рядом.
Намного хуже когда серверный бекенд пишется, например, на PHP, приложение для iOS пишется на Swift, приложение для Android пишется на Java. А ещё хуже когда эти все программисты не объединены в одну команду. А найти такую команду, в которой будут собраны такие программисты, очень непросто. Намного чаще бывает, что команда пишет на каком-то одном языке программирования.
Конструктор мобильных приложений appropio.com написан полностью на Xamarin. И на его основе собираются хорошие приложения даже крупным компаниям. Так что это рабочий инструмент, проверенный практикой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подробно о Xamarin