Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Xamarin.Forms очень интересная штука — попытка достигнуть 100% общего кода на шарпе под все платформы (правда, не без помощи костылей типа
причем страницы можно верстать прямо в XAML для всех платформ, а потом на каждой подправлять (если надо) при помощи Custom renderers. Пока сыровато, но ребята достаточно активно обновляют пакет в нугете и живенько отвечают на форуме.
// Accomodate iPhone status bar.
Padding = new Thickness(10, Device.OnPlatform(iOS: 20, Android: 0, WinPhone: 0), 10, 5);причем страницы можно верстать прямо в XAML для всех платформ, а потом на каждой подправлять (если надо) при помощи Custom renderers. Пока сыровато, но ребята достаточно активно обновляют пакет в нугете и живенько отвечают на форуме.
Что характерно, эти самые значения, которые так предлагают подменять через Device.OnPlatform, имеют разный физический смысл даже в пределах одной платформы — на iPhone и iPad используется единый тип юнитов, но по бóльшей стороне их 1024 на планшете и 480 либо 568 на телефоне, а значит надо проверять еще Device.Idiom и попытка сделать «универсальный» код в xaml превращается в страшную пытку, либо возврат к загрузке разных файлов интерфейса для разных устройств и dpi, но т.к. родных возможностей для этого нет, выходит такое себе занятное лапшестроение.
Я не так много случаев могу придумать, когда надо завязываться на размер экрана в пикселях. Есть grid, например, (который впрочем у них не работает как надо).
В большинстве случаев принципиально именно определить телефон это или планшет, а адаптивную верстку xaml позволяет сделать.
В большинстве случаев принципиально именно определить телефон это или планшет, а адаптивную верстку xaml позволяет сделать.
Не так важен размер экрана в юнитах. Важно то, что на разных устройствах помещается существенно разное количество этих юнитов на экран. Например, на Windows Phone мы знаем, что там от 800 до 853 «пикселей» в Xaml разметке, на Android есть device independent pixels и с некоторыми оговорками можно написать 20dp и знать, как это будет выглядеть на разных устройства, на iOS всего два с половиной размера экрана и можно делать отдельные nib файлы с едиными биндингами. Но тут мы пишем Padding=«20,0,0,0» и на iPhone это значит 5% экрана, а на iPad 2%. С размерами шрифтов все еще хуже: на Android есть юнит «sp», тут же размеры Medium, Large и пр., но они не подогнаны под устройства. Размер Large на iPad вполне нормален для кнопок и пр., а на iPhone кнопка с таким шрифтом может занимать четверть экрана.
Теоретически это можно было бы все пережить, если бы хорошо работали привязки к краям контейнера в лейаутах, но поведение HorizontalOptions в каждом контейнере особое, а описание формул для RelativeLayout в XAML коде выглядит как какой-то кошмар, еще и с константами в пикселях, если нам нужно, например, центрирование или привязка к правому краю.
Отдельный разговор про Grid, который по задумке хорош, но сейчас крашится если в размере столбца есть звездочка, а вообще будучи включенным в состав StackLayout не умеет перемасштабировать своих чайлдов, т.е. не подходит для «резинового» дизайна.
В целом, я не очень доволен фреймворком. У него есть потенциал, но нет еще абсолютно никакой гибкости. Подразумевалось, что как бы все вкусные фичи из UI разных платформ найдут там применение, но на деле получилось усреднение до того, что есть у всех этих платформ общего. Т.е. кнопки только без картинок, отсутствие бекграунд-изображений в принципе, отсутствие тап событий для не-кнопок (хотя тап-видимость они перекрывают), отсутствие декораций вроде скругленных углов, теней, бордюров, картинок и пр. на контролах, отсутствие жестов iOS, сложных лейаутов Android, стилей и темплейтов Windows Phone.
Теоретически это можно было бы все пережить, если бы хорошо работали привязки к краям контейнера в лейаутах, но поведение HorizontalOptions в каждом контейнере особое, а описание формул для RelativeLayout в XAML коде выглядит как какой-то кошмар, еще и с константами в пикселях, если нам нужно, например, центрирование или привязка к правому краю.
Отдельный разговор про Grid, который по задумке хорош, но сейчас крашится если в размере столбца есть звездочка, а вообще будучи включенным в состав StackLayout не умеет перемасштабировать своих чайлдов, т.е. не подходит для «резинового» дизайна.
В целом, я не очень доволен фреймворком. У него есть потенциал, но нет еще абсолютно никакой гибкости. Подразумевалось, что как бы все вкусные фичи из UI разных платформ найдут там применение, но на деле получилось усреднение до того, что есть у всех этих платформ общего. Т.е. кнопки только без картинок, отсутствие бекграунд-изображений в принципе, отсутствие тап событий для не-кнопок (хотя тап-видимость они перекрывают), отсутствие декораций вроде скругленных углов, теней, бордюров, картинок и пр. на контролах, отсутствие жестов iOS, сложных лейаутов Android, стилей и темплейтов Windows Phone.
Со второй частью поста полностью согласен — Фреймворк сырой.
Но насчёт пикселей. Эти 20 условных енотов можно спокойно домножать на коэффициент зависящий от dpi. Тогда на разных девайсах это будет физически (в мм) примерно одинаковое расстояние. То что это разный процент от экрана — нормально. В том же андроиде 20dip — разный процент экрана.
Со шрифтами реально сложнее. Особенно с кастомными. iOS может шрифт из того же файла рисовать отлично от Андроид или WP. Вероятно из-за такой фигни это пока не реализовали.
Но насчёт пикселей. Эти 20 условных енотов можно спокойно домножать на коэффициент зависящий от dpi. Тогда на разных девайсах это будет физически (в мм) примерно одинаковое расстояние. То что это разный процент от экрана — нормально. В том же андроиде 20dip — разный процент экрана.
Со шрифтами реально сложнее. Особенно с кастомными. iOS может шрифт из того же файла рисовать отлично от Андроид или WP. Вероятно из-за такой фигни это пока не реализовали.
20dip в андроиде это некая величина, имеющая смысл. Если говорить не о китайдевайсах, то ее можно пересчитать в миллиметры и будет она что-то значить, причем на устройствах с одной диагональю — одно и то же. Тут же еноты в разметке смысла не имеют и для каждого девайса их надо вручную в коде пересчитывать в проценты, миллиметры, физические пиксели или что-то еще, убивающее на корню смысл файлов разметки. Аналогично происходит и в нативном iOS, но там прозрачно можно менять файлы разметки для разных устройств и хорошо работают привязки к сторонам экрана.
А вот со шрифтами в Xamarin.Forms вообще все в зачаточном состоянии — кроме проблем с размерами, нет никаких настроек написания и только на iOS работают кастомы, а на других ОС хватаемся за голову и рисуем собственные рендереры.
А вот со шрифтами в Xamarin.Forms вообще все в зачаточном состоянии — кроме проблем с размерами, нет никаких настроек написания и только на iOS работают кастомы, а на других ОС хватаемся за голову и рисуем собственные рендереры.
Тут же еноты в разметке смысла не имеют и для каждого девайса их надо вручную в коде пересчитывать
Это можно учесть на уровне Фреймворка, они этого не сделали? (я не проверял).
PS. Вы сейчас пишите продукт на Xamarin.Forms???
Не сделали. Если бы можно было все юниты при старте на что-то умножить, сразу бы головняка стало меньше. Пока экспериментирую со скейлом всей страницы, но там есть баги.
Продукт надо писать, сейчас провожу ресерч, сделал пару страниц, но серьезно думаю о разделении на отдельно Xamarin.iOS и Xamarin.Droid.
Продукт надо писать, сейчас провожу ресерч, сделал пару страниц, но серьезно думаю о разделении на отдельно Xamarin.iOS и Xamarin.Droid.
Ради интереса, я так понимаю, для написания кода на С# платформы Android, Xamarin используют для бизнес приложений, а Unity3D для игр? Или их совмещают?
эмм, нет, Unity3D использует C# для скриптовки движка
и ничто не мешает использовать C# под Xamarin для рендеринга при помощи OpenGL
и ничто не мешает использовать C# под Xamarin для рендеринга при помощи OpenGL
В принципе Xamarin универсален и игры на нем тоже можно писать — были попытки портировать XNA в рамках MonoGame и даже Cocos2D-XNA на C#.
Но смысл не совсем понятен — Unity не только специализирован на играх и поддерживает ряд чисто игровых платформ вроде приставок, которые не поддерживает Xamarin, но и стоит намного дешевле. Минимальная лицензия Xamarin для инди — 300 долларов в год за платформу, Unity в базовой версии вообще бесплатен для большинства платформ.
А совмещать игры и бизнес-приложения — это как? В принципе Unity использует для скриптов на C# проект Mono который лежит в основе Xamarin, но надстройки над ними разные.
Но смысл не совсем понятен — Unity не только специализирован на играх и поддерживает ряд чисто игровых платформ вроде приставок, которые не поддерживает Xamarin, но и стоит намного дешевле. Минимальная лицензия Xamarin для инди — 300 долларов в год за платформу, Unity в базовой версии вообще бесплатен для большинства платформ.
А совмещать игры и бизнес-приложения — это как? В принципе Unity использует для скриптов на C# проект Mono который лежит в основе Xamarin, но надстройки над ними разные.
Да, но при этом Xamarin в разы дороже Unity который умеет все то же самое и еще много чего. Собственно говоря я не знаю как кратко описать разницу в цене между бесплатным Unity в базовой редакции и 300 долларов в год за каждую платформу для Xamarin.
Честно говоря так глубоко не вникал, ориентируюсь тупо на:
store.xamarin.com/
Жалко что на Unity бизнес-приложения нельзя писать. ))
$299 / year
Per platform, per developer
store.xamarin.com/
Жалко что на Unity бизнес-приложения нельзя писать. ))
почему это? а вот: habrahabr.ru/company/kelnik/blog/198572/ можно ещё найти несколько неигровых приложений, написанных на Юнити.
Юнити предназначена для создания 3d-миров, а не именно для игр. Игры — это только наиболее часто встречаемая сфера применения.
Вот ещё пример: habrahabr.ru/post/142180/ Тут даже не Юнити, а вообще Unreal Engine.
Юнити предназначена для создания 3d-миров, а не именно для игр. Игры — это только наиболее часто встречаемая сфера применения.
Вот ещё пример: habrahabr.ru/post/142180/ Тут даже не Юнити, а вообще Unreal Engine.
Скажите, 3 версия для разработки приложений под IOS в VS все так же требует наличия OSX в сети?
Скажите пожалуйста, каким образом код написанный на винде под iOS, компилируется, подписывается и выкладывается в стор? Все равно нужна мак машина или все таки нет? Новый Delphi XE5 позволяет подобное делать, в связи с чем, возник интерес
Нужен мак с запущенным на нем Build Host. Вся компиляция и дебаг под iOS происходит на маке по сети. И естественно если нужно дебажить на устройстве оно тоже должно быть подключенно к маку
То есть и Xamarin и XE работают аналогично? Разница только в том, что вместо мака каждому разработчику покупается один на всех, а разработчики сидят на винде?
Да. Но я не уверен насчет количества одновременно подключенных девелоперов к маку. Я просто игрался один мак+я за виндой.
Но тут кроется небольшой подвох это цена за такое использование. За возможность использования Visual Studio придется отдать 999$ в год. А на windows ios поддерживается только из под visual studio. в Xamarin Studio под Win можно только под Android писать. Но если у вас уже есть студия и заказчик адекватный и не жмот то использование Xamarin очень оправдан. Все таки на быстрее вы разработаете приложения под 3 платформы и можно вовремя выводить новые фичи\багфиксы на всех платформах.
Поставьте Xamarin, поиграйтесь (есть 30 дневный триал)
Но тут кроется небольшой подвох это цена за такое использование. За возможность использования Visual Studio придется отдать 999$ в год. А на windows ios поддерживается только из под visual studio. в Xamarin Studio под Win можно только под Android писать. Но если у вас уже есть студия и заказчик адекватный и не жмот то использование Xamarin очень оправдан. Все таки на быстрее вы разработаете приложения под 3 платформы и можно вовремя выводить новые фичи\багфиксы на всех платформах.
Поставьте Xamarin, поиграйтесь (есть 30 дневный триал)
К одному Билдхосту на маке может подключится только один экземпляр студии.
А мак обязательно реальный должен быть, или виртуалка хакинтошная тоже пойдет?
2SonkoDmitry
C учетом нехилой (имхо) стоимости Xamarin, покупка мака — не самая большая из проблем.
UPD: Xamarin Forms доступны от $299/год. В принципе — нормально, отбивается с одного проекта.
C учетом нехилой (имхо) стоимости Xamarin, покупка мака — не самая большая из проблем.
UPD: Xamarin Forms доступны от $299/год. В принципе — нормально, отбивается с одного проекта.
Самый большой минус Xamarin — это непредсказуемая и неадекватная ценовая политика.
Нет никакой гарантии, что к концу разработки они не повысят цену.
А так — и идея кросплатформенного C# замечательная, и реализация неплохая (с оговорками).
Нет никакой гарантии, что к концу разработки они не повысят цену.
А так — и идея кросплатформенного C# замечательная, и реализация неплохая (с оговорками).
Ничего, мне кажется что уже в этом году их купит Microsoft.
Мнe так же кажется, что все этого только и ждут :)
Мнe так же кажется, что все этого только и ждут :)
Не уверен, что так уж сильно. Пока они сохраняют самостоятельность есть определенная гарантия того, что они всегда останутся по-настоящему кросс-платформенными. А вот если их купит Microsoft то возникнет конфликт интересов — Microsoft надо свою платформу продвигать.
Сейчас, когда своя платформа у Microsoft полудохлая, они конечно заинтересованы скорее в переносе приложений с других платформ и играют в корпорацию добра, но что будет через несколько лет?
Ну или какой-нибудь очередной директор решит вообще отказаться от мобильного направления в духе IBM и Oracle.
Я все-таки надеюсь что Xamarin сам сделает платформу доступнее для некоммерческих разработчиков.
Сейчас, когда своя платформа у Microsoft полудохлая, они конечно заинтересованы скорее в переносе приложений с других платформ и играют в корпорацию добра, но что будет через несколько лет?
Ну или какой-нибудь очередной директор решит вообще отказаться от мобильного направления в духе IBM и Oracle.
Я все-таки надеюсь что Xamarin сам сделает платформу доступнее для некоммерческих разработчиков.
судя по очень близким источникам, покупать их не будут.
Зачем MSFT выкладывать $$$, когда Xamarin и так делает то, что им нужно, в очень тесном сотрудничестве
Зачем MSFT выкладывать $$$, когда Xamarin и так делает то, что им нужно, в очень тесном сотрудничестве
Витали слухи, что у Microsoft есть желание купить Xamarin. Да еще что б потом бесплатной сделать. Я думаю от этого бы выиграла и Microsoft и разработчики и потребители.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонсирован Xamarin 3