Летно-технические качества этого самолета по сравнению с другими представителями реактивной авиации достаточно посредственные мягко говоря. Поэтому вызывает непонимание у любителей авиации и программирования одновременно )
Оценка экономии трудозатрат в количестве строк shared-кода это несколько лукаво.
Лукаво прежде всего потому что (как минимум в случае Xamarin) нет линейной зависимости между человеко-часами и итоговым количеством строк кода — и IDE играет в этой зависимости далеко не последнюю роль.
Из особенностей Xamarin, которые солидно увеличивают количество человеко-часов можно отметить:
— иногда бесконечное время сборки проекта (как правило это лечится удалением папок bin / obj)
— периодическими отваливаниями отладчика после обновлений Xamarin
Ваши контролы нормально переживают специфику Android Activity/Fragment Lifecycle?
Тесты при включенной опции «Don't Keep Activities» в настройках разработчика все проходятся или есть нюансы?
Уточнение — проблема с DateTime.Now имеет место в платформе Xamarin (не в .NET) на некоторых моделях устройств. Связана с тем как Xamarin.Android парсит инфо о часовых поясах, полученную от ОС Android
Можно сказать, что это все мелкие вопросы, и каждый решаем, если досаждает.
Но слишком много недоработок для базового типа.
В случае с DateTime.Now все намного хуже — тут без правок в самой платформе проблема нерешаема. Даже если в самом приложении явно не вызывать DateTime.Now, то проблема все-равно остается — например, при обращении к серверу по https (т.е. любая .NET-библиотека, использующая внутри себя DateTime.Now будет крашить приложение).
Из других неприятных вещей:
— необходимость ручной замены некоторых файлов в IDE (если упремся в лимит 64к классов на Android)
— ужасающе медленная работа axml-редактора в VS (настолько, что порой проще axml-руками поправить)
Тут хотелось бы уточнить — дело даже не в «толщине» прослойки, а в самом факте ее существования и законе Мерфи.
Самый яркий пример (было это года два тому назад) — приложение падало при запуске на некоторых моделях смартфонов, причем падало при вызове такого базового функционала как DateTime.Now. Спустя месяц или два для Xamarin был выпущен багфикс. Но оказывается что проблема актуальна для некоторых моделей до сих пор и даже исключение то же самое выбрасывается.
"до температуры 110°C на стороне, обращённой к Солнцу"
Ведь сейчас максимальная температура около 56°C - откуда 110°C возьмется?
www.x509.ru/forum/viewtopic.php?id=14889
Лукаво прежде всего потому что (как минимум в случае Xamarin) нет линейной зависимости между человеко-часами и итоговым количеством строк кода — и IDE играет в этой зависимости далеко не последнюю роль.
Из особенностей Xamarin, которые солидно увеличивают количество человеко-часов можно отметить:
— иногда бесконечное время сборки проекта (как правило это лечится удалением папок bin / obj)
— периодическими отваливаниями отладчика после обновлений Xamarin
Судя по их примечанию — уязвимость содержится в самом протоколе, т.е. даже 100% корректная реализация протокола уязвима
Тесты при включенной опции «Don't Keep Activities» в настройках разработчика все проходятся или есть нюансы?
В случае с DateTime.Now все намного хуже — тут без правок в самой платформе проблема нерешаема. Даже если в самом приложении явно не вызывать DateTime.Now, то проблема все-равно остается — например, при обращении к серверу по https (т.е. любая .NET-библиотека, использующая внутри себя DateTime.Now будет крашить приложение).
Из других неприятных вещей:
— необходимость ручной замены некоторых файлов в IDE (если упремся в лимит 64к классов на Android)
— ужасающе медленная работа axml-редактора в VS (настолько, что порой проще axml-руками поправить)
Самый яркий пример (было это года два тому назад) — приложение падало при запуске на некоторых моделях смартфонов, причем падало при вызове такого базового функционала как DateTime.Now. Спустя месяц или два для Xamarin был выпущен багфикс. Но оказывается что проблема актуальна для некоторых моделей до сих пор и даже исключение то же самое выбрасывается.
Поэтому мой выбор — Java/Swift.