Как стать автором
Обновить

Что разработчики Xamarin должны знать на начало 2017 года

Время на прочтение 8 мин
Количество просмотров 34K
Всего голосов 34: ↑33 и ↓1 +32
Комментарии 41

Комментарии 41

Запилите уже общий UI, не так уж сильно андроид от огрызка отличается.
Уже есть, Xamarin.Forms называется. Содержит то, что работает на всех платформах. Т.е. плюхи, которые реализованы под конкретную платформу и возможности — недоступны. Иными словами, хотите красивый интерфейс по гайдлайнам платформы — пилите под конкретную платформу.

А, ну да, самая «мякотка». Под Андроид и iOS доступна куча библиотек для работы с БД, интерфейсом и сетью. Всего этого Xamarin лишен. А подключение нативных библиотек достойно пера самого Маркиза Де Сада.
Т.е. плюхи, которые реализованы под конкретную платформу и возможности — недоступны.
не недоступны, а доступны труднее. Кастомные контролы с кастомными рендерами ещё никто не отменял.

А, ну да, самая «мякотка». Под Андроид и iOS доступна куча библиотек для работы с БД, интерфейсом и сетью. Всего этого Xamarin лишен. А подключение нативных библиотек достойно пера самого Маркиза Де Сада.
Для БД есть SQLite и Realm, что ещё надо? С сетью .Net самостоятельно прекрасно справляется.
Подключение большинства UI библииотек не такое уж сложное: pod через консольную утилиту прогнал на iOS, на android там ещё проще.
Кастомные контролы с кастомными рендерами ещё никто не отменял.

Ну то есть рисовать заново то, что уже есть.
Для БД есть SQLite и Realm, что ещё надо?

А 640Кб памяти хватит всем.
С сетью .Net самостоятельно прекрасно справляется.

Вот только прослойки для подключения к REST сервисам приходится писать самостоятельно, вместо того чтобы взять готовую.
Подключение большинства UI библииотек не такое уж сложное: pod через консольную утилиту прогнал на iOS, на android там ещё проще.

Это только в документации все просто. Реальность куда хуже, подключение кастомных бибилиотек для того же Андроида часто выливается в большую головную боль из-за того что неправильно понимаются дженерики и анонимные классы. И плюс ко всему все равно для разных платформ приходится подключать разные библиотеки, потому что для Xamarin ничего толкового не написали. Например, библиотеки для отрисовки графиков.
Например, библиотеки для отрисовки графиков.
OxyPlot чем не устроил?
Возможностей и видов графиков недостаточно.
Я вот давно мучаюсь с байндингами для Zendesk SDKs. Точнее как, оно работает почти всегда, но иногда даже запустить приложение не удаётся, так как что-то не до конца работает, а их поддержка отказывается помогать, так как они не работают с Xamarin. Ну и сам процесс создания отличается сильно от справочной статьи в худшую сторону.
Ну так-то с вопросами биндинга надо в саппорт Xamarin обрщаться. (ну или на их форум и SO). 
Приходилось натыкаться на момент, когда отдельные компоненты тянули разные версии базовых библиотек и на этапе компиляции это не отлавливалось. Но валилось при первом же запуске и в логе эта несогласованность видна была отчетливо.
А 640Кб памяти хватит всем.
 не понимаю вашего сарказма. Есть ещё тормозной couchbase который тоже Xamarin поддерживает. Де факто ничего на мобилах больше и нет.

Вот только прослойки для подключения к REST сервисам приходится писать самостоятельно, вместо того чтобы взять готовую.
 А все .net-библиотеки куда-то резко пропали? 

Не знаю, что там у вас с андроидом не получается, все что мы хотели сбиндить — сбиндилось. А графики — вообще фиговый пример, из не только под ксамарин нормальных нет. Их и так днем с огнем не сыщешь.
не понимаю вашего сарказма. Есть ещё тормозной couchbase который тоже Xamarin поддерживает. Де факто ничего на мобилах больше и нет.

OrmLite, ActiveAndroid, SugarORM, GreenDAO, это только из тех что я вспомнил, что рассматривали.
А все .net-библиотеки куда-то резко пропали?

Библиотеки не-PCL не работают под Xamarin.
Не знаю, что там у вас с андроидом не получается, все что мы хотели сбиндить — сбиндилось. А графики — вообще фиговый пример, из не только под ксамарин нормальных нет. Их и так днем с огнем не сыщешь.

Как раз с Андроидом все бы получилось, а вот разработка под Xamarin вышла сильно дороже.
OrmLite, ActiveAndroid, SugarORM, GreenDAO,
 Прекрасно, и в чем принципиальное преимущество перед SQLite.net?

Библиотеки не-PCL не работают под Xamarin.

не PCL, не .Net Standart, не Xamarin и не OpenSource.

а вот разработка под Xamarin вышла сильно дороже.
 в краткосрочной перспективе она и дороже, как и практически любая кросс-платформенная разработка. Есть задачи для которых Xamarin вообще не подходит. что уж тут скажешь.

Прекрасно, и в чем принципиальное преимущество перед SQLite.net?

С ним нормально не работал апдейт базы. И в sqlite.net, на тот, момент, были проблемы с передачей параметров.
в краткосрочной перспективе она и дороже, как и практически любая кросс-платформенная разработка. Есть задачи для которых Xamarin вообще не подходит. что уж тут скажешь.

Xamarin был выбран как возможность упростить переиспользование кода между Android и iOS, а по факту, как раз написание этого немногочисленного «общего» кода заняло меньше всего времени. Больше всего ушло на подключение библиотек для отображения графиков и создание интерфейса по гайдлайнам.
Самое смешное, что одну из основных проблем при работе с интерфейсом, Xamarin, как раз, не решает — динамическая подгрузка разметки экранов. Была надежда что с доведением до ума Xamarin.Forms, это удастся, но нет.
Xamarin был выбран как возможность упростить переиспользование кода между Android и iOS, а по факту, как раз написание этого немногочисленного «общего» кода заняло меньше всего времени. Больше всего ушло на подключение библиотек для отображения графиков и создание интерфейса по гайдлайнам.
Вот сходу 2 ошибки: использование кросс-платформы для проекта без логики. Использование общего UI для проекта с высоким требованием к соответствию гайдлайнам.

Спасибо вам, сейчас как раз готовлю презентацию по Xamarin. Обязательно приведу вас в пример.
Вот сходу 2 ошибки: использование кросс-платформы для проекта без логики. Использование общего UI для проекта с высоким требованием к соответствию гайдлайнам.

Не читайте по диагонали. Как раз этих ошибок не было. Проект имеет общую логику работы с веб-сервисом и в нем не используются Xamarin.Forms, как раз по причине следования гайдлайнам.
Проект имеет общую логику работы с веб-сервисом
Судя по вашим комментам, это минималная часть приложения, а основной упор делается на UI. Xamarin в таком случает преимуществ не дает. Ну кроме языка разработки, но это на вкус и цвет, как говорится.  
Эта часть важна, хоть и заняла меньше всего времени от общего количества часов, и не хотелось ее переписывать каждый раз при обновлении и вообще писать повторно.
Это известная причина для того чтоб посмотреть в сторону кросс-платформы. Но в вашем случае, лучше, конечно, было смотреть в сторону c++/Qt.
Ну то есть рисовать заново то, что уже есть.
 xто рисовать-то? берешь любой существующий контрол и оборачиваешь в рендер. Там сейчас даже в xaml можно нативные контролы вставлять. https://blog.xamarin.com/adding-bindable-native-views-directly-to-xaml/
Ну так о том и речь, без натива никуда.
Я так понимаю, вы просто не провели надлежащий анализ перед выбором инструмента и теперь страдаете.
Платформа сильно переоценена. И страдания начинаются от того, что в реальности сталкиваешься с кучей нюансов, которые в документации либо не описаны, либо просто и быстро не решаются.
И анализ как раз был проведен, но то как был продавлен Xamarin — отдельная история.

Да все там норм уже давно, если не пытаться действительно делать платформонезависимый UI, оно под это не заточено. Два проекта с общей бэкендовой библиотекой, но своим UI — пашет только в путь.

Например. UI строится как в нормальных XAML-платформах (все контролы выражены через шаблоны). Рисуется через вышеупомянутую Skia.
На мобилках, правда, пока в зачаточном состоянии — не работают попапы (надеюсь починить к очередному выпуску), обработчик тач-событий изображает из себя мышь, ну и подтормаживает (сейчас в процессе инфраструктура рендеринга только-того-что-поменялось и в фоновом потоке).
Вот и кроссплатформенный WPF подъехал. Потрясающе!)
Это же то! о чем я всегда мечтал!!!
Давайте дружить :-)
С радостью бы портировал GUI нашего https://icons8.com/lunacy на net core

Давайте. Заходите в наш уютный чатик — https://gitter.im/AvaloniaUI/Avalonia
Инструкции и пример использования из .NET Core тут.


Всё это счастье пока доступно только из nightly-фида (прописан в NuGet.config) в примерах. То, что на nuget.org работает только на обычном дотнете и Mono. Как стабилизируется новый студийный тулинг для .NET Core, планируем выпустить очередную версию и уже нормально это дело анонсировать.


Сейчас уже портируют на .NET Core вот эту штуку. Ещё на авалонии умеет работать вот этот редактор диаграмм, который идейно ближе к вашему проекту.

У нас есть одна супер-оптимизированная среда выполнения .NET, которая доставляет .NET на iOS, Android, macOS, IoT, Linux, PS4, Xbox и т. д. Она реализует .NET API и приводит в действие .NET Standard, поэтому вам не придется беспокоиться о реализации «под капотом».
Mono
супер-оптимизированная
И это в блоге Microsoft. Дожили.

Что тебе не нравится, Никита? :)

Тормоза. Мне не нравятся тормоза.

А переведите кто-нибудь ту статью про дотнет, о которой автор упоминает в начале?

Если будет интерес, переведём конечно.
Почему, для Android не используется AOT?

Потому что у вас галочка в настройках сборки проекта соответствующая не стоит.

речь про Xamarin? Подскажите где эта галочка?

project

Вот тут написано:
This option requires an Enterprise license and is only available when Use Fast Deployment is disabled.

А у меня Community. Ну да ладно, все равно пока использую для изучения и домашних поделок.
добавлю изображение
Скрин того же окна
image

В версии Xamarin Android 5.1 добавлена поддержка AOT как экспериментальная, но судя по описанию к релизу Xamarin Android 6.1 функция отключена из-за проблем, обещают включить в будущих релизах. На данный момент опция AOT все еще отсутствует в Xamarin Studio. Остается ждать новых релизов)
Ссылки в статье сломались:(
Зарегистрируйтесь на Хабре , чтобы оставить комментарий