Спасибо за статью. Расскажите, пожалуйста, как вы работаете с формами ввода.
Как и откуда тянутся данные для условного dropdown?
Можете привести пример, как сейчас выглядит блок events для связанных полей? Если выбор в одном dropdown должен повлиять на данные в другом dropdown. Например, выбор города в одном dropdown, а другой dropdown должен отображать список улиц (в идеале подгружать с сервера справочник улиц для выбранного города).
Как работает хендлер Submit? Есть ли какой-то контракт, описывающий какой объект (JSON) должен отправляться из формы на сервер и как форма должна реагировать на условный 400 Bad Request?
Для стартапа действуют немного другие правила. Когда Amazon был всего сотней людей, я работал иначе. У меня был микро-контроль, я знал каждый процесс.
Прислушиваться к его совету, можно только имея продуктовую компанию на сотню сотрудников. Это, мягко говоря, фантастика в наши дни. Начиная от Tilda до Notion.so. Учитывая, что в Notion работает не более 10 человек на сегодняшней день.
Notion, a startup that operates a workplace productivity platform, has raised $50 million from Index Ventures and other investors at a $2 billion valuation.
Xamarin дает возможность использовать платформо-независимые контролы
Нативный Xamarin не дает. Но в Xamarin.Forms попробовать можно, и в нем можно использовать нативные контролы в отдельных случаях.
можно использовать как нативные либы для конкретной платформы
Если есть силы и нервы.
nuget пакеты
Если есть сборка под Xamarin, либо если сходятся пространства имен, то просто dll.
То есть получается, что вы можете использовать подмножество либ под конкретную платформу+.net библиотеки.
Вы можете, но вопрос получится ли в конкретном случая.
До сих пор много спорных моментов. За 1,5 года никаких практических улучшений, только Alpha-анонсы и ребрендинги. Но в целом, если вы .Net-тчик и учитесь или у вас простое UI-приложение и интеграция с бэкендом средней тяжести — о выборе не пожалеете точно.
Вообще интересный вопрос, как быть с космическим мусором, столкновение с метеорами, радиация (марсоход-то чуть не потеряли один раз).
В принципе, уверен, вопросы решаемы, но 100% надежности не дадут.
Говорят, что на орбите +4 C, а в теньке (на обратной стороне) до -160 С. Время облета МКС вокруг Земли — 90 минут. Думаю, если напрячься, то можно управлять мощность, и «давать газку» на темной стороне. Тынц
Apple Way — не всегда упрощение) С сonstraints также достаточно мороки, если интерфейс сложнее типовых вариантов.
Вопрос скорее про отношение к разработчикам. Пока это выглядит так: «Сделали хорошее приложение для iOS? Заходите к нам (Android), переделывать (как минимум дизайн и навигацию) и переучиваться (язык и построение интерфейса) почти не придется.
Вообще это обычная история, когда Android-разработчики пытаются править разметку в Storyboard или xib -файлах, и наоборот, iOS-разработчики немного конфузятся, когда им предлагают язык разметки AXML и отбирают „мышку“.
То что основывается в корнях на RelativeLayout очевидно, но понятно под какую аудиторию затачивается и откуда срисовано.
RelativeLayout — совсем не тоже самое. Речь идет о части «построения интерфейса через Constraints мышкой», т.е. «The Apple Way».
за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса.
К тому моменту для большинства может встать один единственный, и страшный вопрос: «а зачем, если есть Swift?»
C# никуда не денется, как и Xamarin, но может стать своеобразным «шахматным клубом».
А на данный момент можно расслабиться, Google от слов к делу пока не перешел. Так что сейчас Xamarin, это «Уникальное предложение… Только сейчас… Вы сможете без труда… и т.д.» :-)
Ну окей, постараемся отбросить все предрассудки и посмотрим на вещи как они есть на самом деле.
Если есть желание писать под все мобильные платформы (iOS, Android, и, возможно, Windows Phone) на C#, то вероятно речь идет о silver bullet в лице Xamarin. Говорить о нем можно бесконечно, при этом как хваля его, так и презирая. Объективно, чтобы создать приложение, нужно:
1. Какая-то IDE для проектирования интерфейса;
2. Знание жизненного цикла приложения на мобильной ос;
3. Знание нативных библиотек;
«Мираж» Xamarin в том, что для того чтобы написать что-то на C#, вам, хотите вы или нет, придется разобраться в пунктах 1, 2 и 3. При этом на май 2016 года ни Xamarin Studio, ни Visual Studio нет нормального дизайнера.
— Для iOS вам придется использовать XCode Interface Builder, так как Storyboard формируются криво, а работа с Constraints начинает утомлять неточностью;
— Для Android вам придется использовать Android Studio и линковать xml-файлы обратно в Xamarin Studio, так как «IntelliSense» работает не очень хорошо, а для ресурсных xml не работает вовсе. Если конечно вы не ниндзя и пишете без подсказок в коде.
Далее вам будет необходимо использовать стандартные функции фреймворка или даже наследоваться:
— Из мира iOS вас теплыми объятиями встретит именование Objective-C функций, binding'а, интересные конструкторы с указателями;
— Из мира Android вас повстречает обязательное наследование от Java.Lang.Object и увлекательное жонглирование интерфейсами;
Ну и вишенка конечно — вопросы многопоточности, работы с сетью и хранения данных. Тут вы быстро попытаетесь спрятаться в уютном .NET домике. Он будет настолько теплым, что вы начнете выстраивать в нем свою параллельную вселенную, которая действительно будет работать.
Потратив значительное время на изучение нативных инструментов разработки, зазубривание нативного API и библиотек, а также переиначивая их на C#-лад, вы сделаете свое первое мобильное приложение, которое будет работать как надо. И будет выглядеть как нативное.
Но в этот момент *гифка где Гендальф-Белый плачет на фоне Хельмовой Пади, дождавшись помощи Эомера с войском рохирримов* — вы оглянетесь и скажете «я сделал это!», но встретившись глазами со своим боевым конем Xamarin'ом проскользнет секундная неловкость, и вы скажете: «Спасибо друг, дальше я сам», и нативная разработка станет для вас не такой страшной и более привлекательной.
Вытерев скупую мужскую слезу с мужественной щеки и, оценив перспективы C#, понимаешь, что он имеет крайне нишевое применение в мобильной разработке. Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. Вероятно это случится к 5 или 6 версии Swift года через два-три. И новые программисты вряд ли будут выбирать C# для этой связки.
Мое субъективное мнение — Swift на текущий момент слишком дорого обходится в промышленном использовании. Перепиливание проекта после каждой новой версии требует вливание человека-часов, конвертируемых в $. Тот же Xamarin стабильнее.
Objective-C не такой страшный как кажется на первый взгляд, и не такой «динозавр» как можно подумать. Если понимать как он работает внутри, то у него много общего с тем же C#.
C# отличный язык, мой любимый. И я фанат Miguel de Icaza. Но я понимаю, что доля C# в мобильной разработке даже в среднесрочной перспективе имеет форму дули. Но, тем не менее, Xamarin — это фантастическая штука, через которую я бы советовал пройти каждому C#/.NET программисту, который хочет приоткрыть для себя дивный мир мобильной разработки.
Спасибо за статью. Расскажите, пожалуйста, как вы работаете с формами ввода.
Как и откуда тянутся данные для условного dropdown?
Можете привести пример, как сейчас выглядит блок events для связанных полей? Если выбор в одном dropdown должен повлиять на данные в другом dropdown. Например, выбор города в одном dropdown, а другой dropdown должен отображать список улиц (в идеале подгружать с сервера справочник улиц для выбранного города).
Как работает хендлер Submit? Есть ли какой-то контракт, описывающий какой объект (JSON) должен отправляться из формы на сервер и как форма должна реагировать на условный 400 Bad Request?
Прислушиваться к его совету, можно только имея продуктовую компанию на сотню сотрудников. Это, мягко говоря, фантастика в наши дни. Начиная от Tilda до Notion.so. Учитывая, что в Notion работает не более 10 человек на сегодняшней день.
Образно говоря, советы небожителей недоступны 99% Землян)
Немаловажно, надо заметить.
Нативный Xamarin не дает. Но в Xamarin.Forms попробовать можно, и в нем можно использовать нативные контролы в отдельных случаях.
Если есть силы и нервы.
Если есть сборка под Xamarin, либо если сходятся пространства имен, то просто dll.
Вы можете, но вопрос получится ли в конкретном случая.
До сих пор много спорных моментов. За 1,5 года никаких практических улучшений, только Alpha-анонсы и ребрендинги. Но в целом, если вы .Net-тчик и учитесь или у вас простое UI-приложение и интеграция с бэкендом средней тяжести — о выборе не пожалеете точно.
В принципе, уверен, вопросы решаемы, но 100% надежности не дадут.
Вопрос скорее про отношение к разработчикам. Пока это выглядит так: «Сделали хорошее приложение для iOS? Заходите к нам (Android), переделывать (как минимум дизайн и навигацию) и переучиваться (язык и построение интерфейса) почти не придется.
Вообще это обычная история, когда Android-разработчики пытаются править разметку в Storyboard или xib -файлах, и наоборот, iOS-разработчики немного конфузятся, когда им предлагают язык разметки AXML и отбирают „мышку“.
RelativeLayout — совсем не тоже самое. Речь идет о части «построения интерфейса через Constraints мышкой», т.е. «The Apple Way».
Мне кажется или Google готовится к чему-то?
1. Слизывание гайдланов у Apple — Bottom navigation bars
2. Планы по переводу Android на Swift — Source
3. Внедрение ConstraintLayout как аналог AutoLayout — Auto Layout Guide
4.… профит?
К тому моменту для большинства может встать один единственный, и страшный вопрос: «а зачем, если есть Swift?»
C# никуда не денется, как и Xamarin, но может стать своеобразным «шахматным клубом».
А на данный момент можно расслабиться, Google от слов к делу пока не перешел. Так что сейчас Xamarin, это «Уникальное предложение… Только сейчас… Вы сможете без труда… и т.д.» :-)
Если есть желание писать под все мобильные платформы (iOS, Android, и, возможно, Windows Phone) на C#, то вероятно речь идет о silver bullet в лице Xamarin. Говорить о нем можно бесконечно, при этом как хваля его, так и презирая. Объективно, чтобы создать приложение, нужно:
1. Какая-то IDE для проектирования интерфейса;
2. Знание жизненного цикла приложения на мобильной ос;
3. Знание нативных библиотек;
«Мираж» Xamarin в том, что для того чтобы написать что-то на C#, вам, хотите вы или нет, придется разобраться в пунктах 1, 2 и 3. При этом на май 2016 года ни Xamarin Studio, ни Visual Studio нет нормального дизайнера.
— Для iOS вам придется использовать XCode Interface Builder, так как Storyboard формируются криво, а работа с Constraints начинает утомлять неточностью;
— Для Android вам придется использовать Android Studio и линковать xml-файлы обратно в Xamarin Studio, так как «IntelliSense» работает не очень хорошо, а для ресурсных xml не работает вовсе. Если конечно вы не ниндзя и пишете без подсказок в коде.
Далее вам будет необходимо использовать стандартные функции фреймворка или даже наследоваться:
— Из мира iOS вас теплыми объятиями встретит именование Objective-C функций, binding'а, интересные конструкторы с указателями;
— Из мира Android вас повстречает обязательное наследование от Java.Lang.Object и увлекательное жонглирование интерфейсами;
Ну и вишенка конечно — вопросы многопоточности, работы с сетью и хранения данных. Тут вы быстро попытаетесь спрятаться в уютном .NET домике. Он будет настолько теплым, что вы начнете выстраивать в нем свою параллельную вселенную, которая действительно будет работать.
Потратив значительное время на изучение нативных инструментов разработки, зазубривание нативного API и библиотек, а также переиначивая их на C#-лад, вы сделаете свое первое мобильное приложение, которое будет работать как надо. И будет выглядеть как нативное.
Но в этот момент *гифка где Гендальф-Белый плачет на фоне Хельмовой Пади, дождавшись помощи Эомера с войском рохирримов* — вы оглянетесь и скажете «я сделал это!», но встретившись глазами со своим боевым конем Xamarin'ом проскользнет секундная неловкость, и вы скажете: «Спасибо друг, дальше я сам», и нативная разработка станет для вас не такой страшной и более привлекательной.
Вытерев скупую мужскую слезу с мужественной щеки и, оценив перспективы C#, понимаешь, что он имеет крайне нишевое применение в мобильной разработке. Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. Вероятно это случится к 5 или 6 версии Swift года через два-три. И новые программисты вряд ли будут выбирать C# для этой связки.
Мое субъективное мнение — Swift на текущий момент слишком дорого обходится в промышленном использовании. Перепиливание проекта после каждой новой версии требует вливание человека-часов, конвертируемых в $. Тот же Xamarin стабильнее.
Objective-C не такой страшный как кажется на первый взгляд, и не такой «динозавр» как можно подумать. Если понимать как он работает внутри, то у него много общего с тем же C#.
C# отличный язык, мой любимый. И я фанат Miguel de Icaza. Но я понимаю, что доля C# в мобильной разработке даже в среднесрочной перспективе имеет форму дули. Но, тем не менее, Xamarin — это фантастическая штука, через которую я бы советовал пройти каждому C#/.NET программисту, который хочет приоткрыть для себя дивный мир мобильной разработки.
В полемику вступать не буду. Прошу меня извинить)