Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 204
Верстать на iOS — боль. Посему Xamarin Forms оказался находкой. Еще сыро, местами приходится долго и мучительно обходить стандартное поведение компонентов. Особенно когда у разработчиков Xamarin Forms ООП головного мозга, и огромная часть реализации компонентов скрыта от пользователя с помощью private, internal, в следствии чего просто взять переопределить метод неполучится, но бывает спасает шарповская магия. Но ради XAML можно и помучаться на старте.
Начиная с Xcode 5.1 «верстать» с автолэйаутом вполне удобно
Это да, но все равно неочевидность этих автолэйаутов зашкаливает. Да и посмотрите, как constraints описываются ручками. И еще момент. В сториборде рисовать — это, конечно, здорово но ради элементарной кастомизации внешнего вида кнопки нужно лезть в императивный код. При этом с завистью смотришь на веб-разработчиков, на WP и андроид (именно в плане описания UI).
Да и посмотрите, как constraints описываются ручками.
На Swift, кстати, вполне приятно описываются: github.com/robb/Cartography.
но ради элементарной кастомизации внешнего вида кнопки нужно лезть в императивный код
UIAppearance же, основную массу кастомизации можно локализовать и поддерживать в одном месте.
Про WP/Android не скажу, толком не работал с ними, но веб-разработчикам завидовать, извините, не получается.
Только вот Xamarin.Forms нехило так отличается от WPF
Может с написанием кода все так и есть, но значимым фактом это станет не ранее того, как доля виндофонов вырастет до хоть сколько то заметной величины на фоне айфонов…
Так xamarin же. Нет?
Ну в статье же речь о WPF идет, а не о ксамарине. Я про сравнение удобства нативной разработки.
Нативная разработка, надеюсь, постепенно уйдет в прошлое. В том смысле, что можно выбрать себе язык + фреймворк, и писать под все платформы. Примерно как сейчас С++ Qt, и с некоторой натяжкой web.
Да вот как-то не похоже на то. Сам phonegap использую, несколько ориентируюсь.
Примерно как сейчас С++ QtНу я пробовал на Qt писать под Андроид! Да, это реально работает и совсем несложно. Но. Получившееся приложение — во первых знать ничего не желает о стилях, размере экрана, DPI и прочих нюансах интерфейса. Во-вторых практически ничего не может сделать с ОС — даже банальный Intent кинуть. Да можно, сделать гибридное приложение. Или использовать ужасный JNI. Но в чем тогда профит от кроссплатформенности? Мобильное приложение это процентов на 90 UI и связанные с ним вещи. А UI на сегодняшний момент, извините, только нативно можно сделать качественным и конкурентоспособным.
Кроме UI, есть ещё работа с сервисом, которая не зависит от платформы. Хранение данных, которое тоже не слишком-то зависит от платформы. Бизнес-логика, которая у большинства приложений от платформы зависит не сильно (хотя тут, конечно много исключений).
Если в вашем приложении главное UI — интерфейс, конечно, лучше писать нативно (системными средствами). Но при этом, все ещё можно использовать, к примеру Xamarin. Тут надо для каждого приложения в отдельности решать, оправдывает ли соотношение общей логики к платформозависимой части использование кроссплатформенных движков, или нет.
Кроме того, для многих приложений вполне оправдано применение phonegap, где о нативности интерфейса вообще речи нет. Например у IBM есть корпоративные решения построенные на его основе.
Если в вашем приложении главное UI — интерфейс, конечно, лучше писать нативно (системными средствами). Но при этом, все ещё можно использовать, к примеру Xamarin. Тут надо для каждого приложения в отдельности решать, оправдывает ли соотношение общей логики к платформозависимой части использование кроссплатформенных движков, или нет.
Кроме того, для многих приложений вполне оправдано применение phonegap, где о нативности интерфейса вообще речи нет. Например у IBM есть корпоративные решения построенные на его основе.
Кроме UI, есть ещё работа с сервисом, которая не зависит от платформы. Хранение данных, которое тоже не слишком-то зависит от платформы. Бизнес-логика, которая у большинства приложений от платформы зависит не сильноЭто и есть 10% трудозатрат.
Конечно, я уверен, есть приложения где эта цифра достигает 50%, там наверное имеет смысл.
Кроме того, для многих приложений вполне оправдано применение phonegap, где о нативности интерфейса вообще речи нет.На PhoneGap можно делать нативно выглядящий интерфейс — есть соответствующие виджеты. И да, в ряде случаев кроссплатформенные средства действительно предпочтительнее, я об этом недавно писал: habrahabr.ru/post/229559/#comment_7772177
Я имел ввиду кросплатформенность среди «целевых» платформ. Т.е. в случае Qt это возможность написать программу (desktop), которая скомпилируется под винду, мак, линукс. В случае html — это разные браузеры под разными ОС. Создать язык (и фрэймворк), который позволит писать программы вообще для всего (десктоп, мобаил, веб) — это вряд ли пока возможно, цена за универсальность будет высокой.
Я имел ввиду кросплатформенность среди «целевых» платформ. Т.е. в случае Qt это возможность написать программу (desktop)Справедливости ради, Qt когда-то развивался именно как мобильный инструмент — для Symbian. Сейчас да, десктоп
Создать язык (и фрэймворк), который позволит писать программы вообще для всего (десктоп, мобаил, веб) — это вряд ли пока возможно, цена за универсальность будет высокой.Может и хорошо — есть конкуренция технологий, есть развитие. Хотя конечно было бы здорово иметь один мощный язык для всего.
Справедливости ради, Qt когда-то развивался именно как мобильный инструмент — для Symbian. Сейчас да, десктоп
Вот уж не нужно. Когда начали разрабатывать Qt, мобильные телефоны только начинали распространяться в массы. А то что НОКИА купила QT и сбоку прилепила Mobile SDK — это еще не повод делать такие глобальные выводы.
Хороший пример, подтверждающий, что .net (и WPF в частности) — удобная штука. Для меня остается загадкой только одно: почему применение C# до сих пор ограничено практически только одним Enterprise…
{удалено}
Часто используемых где?) При разработке внутреннего софта компаний, реализующего бизнес-процессы (т.е. Enterprise). Да, где-то WinForms, но все больше WPF (кроме США, у них WPF почему-то не любят). Mono — не очень популярен, имхо. Вы много видели популярных (не внутрекорпоративных) программ на C#? Игры, и другие высокопроизводительные приложения (CAD, обработка видео и пр.) еще как-то понятно почему (и то в умелых руках C# может работать резво). Но берем что угодно другое: редакторы, файловые менеджеры, мессенджеры, почтовые клиенты, утилитки всякие, переводчики, и прочие няшки — все это практически всегда C++ или Delphi. Почему?
Тот же Autocad на wpf написан частично по крайне мере.
Autocad и Visual Studio — это два примера приложений написанных на WPF. Все. Более того, я предполагаю, что Autocad написан на WPF так же, как и сама Visual Studio, что там только XAML parser и core используется, а все контролы и окна свои.
удалено, ответ не по сути комментария
>> там только XAML parser и core используется, а все контролы и окна свои.
В случае VS это не так. Там свои тулбары и меню (хотя и то не с нуля, а сильно кастомизованные — штатными средствами, через наследовение и шаблоны — стандартные контролы). Потом tool windows (рамка), и все, что связано с их докингом. Редактор, разумеется.
Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема (которую может легко подключить себе любое расширение).
В случае VS это не так. Там свои тулбары и меню (хотя и то не с нуля, а сильно кастомизованные — штатными средствами, через наследовение и шаблоны — стандартные контролы). Потом tool windows (рамка), и все, что связано с их докингом. Редактор, разумеется.
Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема (которую может легко подключить себе любое расширение).
Это я и имел ввиду, под WPF Core я имел ввиду все уровня FrameworkElement.
> Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема
Команды без проблем могут использовать все прелести WPF. Для этого, на сколько я понимаю, Visual Studio и переписывали на WPF, чтобы командам было проще. Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
> Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема
Команды без проблем могут использовать все прелести WPF. Для этого, на сколько я понимаю, Visual Studio и переписывали на WPF, чтобы командам было проще. Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
>> Команды без проблем могут использовать все прелести WPF. Для этого, на сколько я понимаю, Visual Studio и переписывали на WPF, чтобы командам было проще.
Не совсем. Использовать WPF можно было и до того — например, все связанное с WPF-дизайнером в VS 2008 уже было на WPF. Переписывание шелла и редактора было связано скорее с желанием уйти от старого и трудноподдерживаемого Win32-кода, ну и заодно получить профит в виде themability, поддержки high-DPI, и тому подобных штук. Для авторов расширений это упростило некоторые вещи за счет того, например, что главный message pump в VS стал понимать некоторые WPF-специфичные вещи, но это было не столь принципиально.
При этом в VS осталось полно кода на Win32 и WinForms — задачу переписать все разом никто не ставил. Вот картинка с состоянием дел на момент релиза VS 2010:
Сейчас WPF стало больше, а остального — меньше (напр., Solution Explorer уже два релиза как WPF, опять же новый UI для тестов...). Плюс появились куски на HTML5. Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.
>> Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
И тогда, и сейчас — VS Platform, в котором несколько команд, на самом деле. Редактор на WPF переводила его же команда, а всем остальным заведовал VS Platform Shell team.
Насчет остального же у вас неверная информация. Про меню и тулбары я могу сказать совершенно точно просто потому, что был одним из тех людей, кто их делал :) там действительно весьма монструозные хаки в шаблонах (чтобы обеспечить поведение, максимально эквивалентное старым «офисным» коммандбарам в VS 2008), но все же это Menu и MenuItem. Комбо-боксы на тулбарах — это тоже ComboBox (точнее, отнаследованный от него класс с кастомизацией).
Причем больше всего кастомизации именно в тулбарах и меню. В диалогах (напр. «Customize Toolbar») практически все контролы — самые обычные.
Не совсем. Использовать WPF можно было и до того — например, все связанное с WPF-дизайнером в VS 2008 уже было на WPF. Переписывание шелла и редактора было связано скорее с желанием уйти от старого и трудноподдерживаемого Win32-кода, ну и заодно получить профит в виде themability, поддержки high-DPI, и тому подобных штук. Для авторов расширений это упростило некоторые вещи за счет того, например, что главный message pump в VS стал понимать некоторые WPF-специфичные вещи, но это было не столь принципиально.
При этом в VS осталось полно кода на Win32 и WinForms — задачу переписать все разом никто не ставил. Вот картинка с состоянием дел на момент релиза VS 2010:
Сейчас WPF стало больше, а остального — меньше (напр., Solution Explorer уже два релиза как WPF, опять же новый UI для тестов...). Плюс появились куски на HTML5. Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.
>> Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
И тогда, и сейчас — VS Platform, в котором несколько команд, на самом деле. Редактор на WPF переводила его же команда, а всем остальным заведовал VS Platform Shell team.
Насчет остального же у вас неверная информация. Про меню и тулбары я могу сказать совершенно точно просто потому, что был одним из тех людей, кто их делал :) там действительно весьма монструозные хаки в шаблонах (чтобы обеспечить поведение, максимально эквивалентное старым «офисным» коммандбарам в VS 2008), но все же это Menu и MenuItem. Комбо-боксы на тулбарах — это тоже ComboBox (точнее, отнаследованный от него класс с кастомизацией).
Причем больше всего кастомизации именно в тулбарах и меню. В диалогах (напр. «Customize Toolbar») практически все контролы — самые обычные.
Точно VS Platform Shell team.
> Насчет остального же у вас неверная информация.
Ну ок. 2 года назад с этим работал. В любом случае, удачи там.
> Плюс появились куски на HTML5.
Ага, я как раз был в одной из команд, которые пилили эти первые куски. ;)
> Насчет остального же у вас неверная информация.
Ну ок. 2 года назад с этим работал. В любом случае, удачи там.
> Плюс появились куски на HTML5.
Ага, я как раз был в одной из команд, которые пилили эти первые куски. ;)
Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.
Помню как после обновления IE с 6 до 8 версии визарды перестали работать, выкидывая браузерную ошибку. Спас hotfix.
Как бы Unity 3D. Один из самых популярных движков для разработки игр. Построен на базе mono. Основной язык — C#. Разработка для всех больших платформ и мобильников. Проходил слух про нативный шарп на PS4. Все консоли MS поддерживают разработку на шарпе. В мире игр C# играет очень заметную роль.
Недавно была статистика, что 17% рунета это ASP.NET. Да, это не 80% PHP, но это дикий перевес над любыми другими платформами.
В общем, C# используется очень много где. Просто об этом не все задумываются.
Недавно была статистика, что 17% рунета это ASP.NET. Да, это не 80% PHP, но это дикий перевес над любыми другими платформами.
В общем, C# используется очень много где. Просто об этом не все задумываются.
17% ASP
80% PHP
Вы хотите сказать, что Java, Ruby и Python вместе взятые — всего 3%? o_O
80% PHP
Вы хотите сказать, что Java, Ruby и Python вместе взятые — всего 3%? o_O
Пруф про 17% киньте. Попахивает наглым пиз##жом
Не успел отредактировать предыдущий пост. По этой статистике у ASP.NET 28.2%, PHP 70.7, а остальные делят жалкие 1.1%
Глянул по линку. Таем указано что nytimes.com написан на ASP.NET, а там apache и php.
Интересно, у них там вся статистика собрана так?
Еще забавно что по второй ссылке доля IIS — 13%, а ASP.NET — 28%.
Они на апаче ASP.NET сайты заводят?
Интересно, у них там вся статистика собрана так?
Еще забавно что по второй ссылке доля IIS — 13%, а ASP.NET — 28%.
Они на апаче ASP.NET сайты заводят?
Про XNA не забывайте
Как минимум, на мобильных платформах C# обычно на 4-5 месте после JavaScript, Java, Objective-C, C/C++.
Всю жизнь думал, что там Java всех задавила.
Не, в Enterprise примерно 50/50 Java и C#. Пропорция немного разная в России, США и Европе, но в целом C# довольно популярен, и популярность растет. Есть даже и такое мнение.
Не WPFом единым. Жду не дождусь ASP.NET vNEXT (http://www.asp.net/vnext)
WPF, конечно, здорово выглядит в данном конкретном примере.
Что насчёт «реальных приложений»? Как поведет себя автоматическое скачивание изображений, когда вам нужно будет ресайзить картинку налету в несколько типоразмеров, сохранять в кастомный кэш, и т.д.?
Что насчёт «реальных приложений»? Как поведет себя автоматическое скачивание изображений, когда вам нужно будет ресайзить картинку налету в несколько типоразмеров, сохранять в кастомный кэш, и т.д.?
Чуть больше кода, но ни как не простыни =)
Для этих задач есть конвертеры, поведения и триггеры.
ресайзить картинку налету в несколько типоразмеров
Два действия: подписка на одно событие и внутри метода подгрузка сообщений в зависимости от конечного размера контейнера.
сохранять в кастомный кэш
ObjectCache cache = MemoryCache.Default;
string fileContents = cache["filecontents"] as string;
Ну, и т.д., соответственно
Когда зайдёт речь о реальных приложениях, тогда НЕЗАВИСИМО от технологии/языка, вам придётся применить весь свой интеллект, чтобы оптимизировать проблемные места.
Мой пример — даже не competition, а вообще попытка сваять что-то похожее — я подозревал, что будет проще и короче, но не настолько. :)
Мой пример — даже не competition, а вообще попытка сваять что-то похожее — я подозревал, что будет проще и короче, но не настолько. :)
Так и хочется спросить: А толку? :)
Дело в том, что в Microsoft уж очень все проработано в плане красивых и быстрых примеров. А как на деле начнешь что-то более или менее серьезное писать, там то и начинаются проблемы… И все становится в разы сразу сложнее. Понятия не имею, так ли дело обстоит с Swift & Apple. Просто хотелось дополнить.
Дело в том, что в Microsoft уж очень все проработано в плане красивых и быстрых примеров. А как на деле начнешь что-то более или менее серьезное писать, там то и начинаются проблемы… И все становится в разы сразу сложнее. Понятия не имею, так ли дело обстоит с Swift & Apple. Просто хотелось дополнить.
У эпл верстка сильно напоминает WinForms. Очень не хватает простых контейнеров. Таблица — очень мощный контрол, но чересчур уж сложный для простых случаев. И я сейчас очень опасаюсь так называемых Varible Sizes девайсов в iOS8
Как-то очень обще звучит. Microsoft для разработки ПО предлагает большой стек технологий, работающих из коробки (установка в пара кликов, безо всяких допилов):
C#.net, WPF, WCF, LINQ, TPL и пр. + Visual Studio + MS SQL + EntityFramework. Это даже без крутых внешних библиотек, расширяющих возможности (Catel, Prism, AutoMappers, NUnit, NLog, NValidator, CodeGuard и пр.). На этом стеке пишутся enterprise-решения, с многослойной архитектурой, где слой базы может содержать терабайты данных и сложные запросы (у нас OLAP например прогоняет просто дикие объемы), слой WCF-сервисов содержит сколь угодно сложную бизнесовую логику, многопоточность, и все это еще и кластеризуется, в т.ч. в Azure-облаке, слой UI содержит сколько угодно навороченные окна, с эффектами и пр.
Так вот, о чем я. Не припомню, что в процессе всего этого дела возникали проблемы. Были с Telerik проблемы, но не с тем, что от MS. Если enterpise — это не «более-менее серьезное», тогда что? Софт для адронного коллайдера? Или ИИ?
C#.net, WPF, WCF, LINQ, TPL и пр. + Visual Studio + MS SQL + EntityFramework. Это даже без крутых внешних библиотек, расширяющих возможности (Catel, Prism, AutoMappers, NUnit, NLog, NValidator, CodeGuard и пр.). На этом стеке пишутся enterprise-решения, с многослойной архитектурой, где слой базы может содержать терабайты данных и сложные запросы (у нас OLAP например прогоняет просто дикие объемы), слой WCF-сервисов содержит сколь угодно сложную бизнесовую логику, многопоточность, и все это еще и кластеризуется, в т.ч. в Azure-облаке, слой UI содержит сколько угодно навороченные окна, с эффектами и пр.
Так вот, о чем я. Не припомню, что в процессе всего этого дела возникали проблемы. Были с Telerik проблемы, но не с тем, что от MS. Если enterpise — это не «более-менее серьезное», тогда что? Софт для адронного коллайдера? Или ИИ?
Очень голословное утверждение.
C# и .NET — весьма приятная платформа для разработки. На нем пишут серьезный софт, и проблем там начинается как минимум не больше, чем где-то еще. В минусы .NET можно записывать привязку к платформе, и много чего еще можно наскрести. Но точно не «Microsoft хочет всех одурачить красивыми примерчиками, а на деле C#-говно». Все там очень хорошо и со сложными приложениями, и куча написанного на .NET софта это подтверждает.
Конкретно в данном сравнении видно что:
— у Swift пока имеются проблемы с работой с legacy-API от objC, который динамический, и плохо работает вместе со статически-типизированным языком. Все вот эти NSDictionary явно выглядят чужеродными.
— сами эти API не самые удобные — та же работа с http, или обработка ошибок сделана ближе к C, и требует много рутинного кода
— десериализация JSON делается врукопашную
— в Swift идет рукопашная работа с асинхронным кодом, через колбеки
Учитывая что задачи в примерах весьма типовые, вполне можно сделать определенные выводы. Мне кажется что пока Apple не напишет нормальные обертки для своих нетипизированных API, и пока Swift не обрастет жирком библиотек, C# и .NET выглядят куда более в выгодном свете.
C# и .NET — весьма приятная платформа для разработки. На нем пишут серьезный софт, и проблем там начинается как минимум не больше, чем где-то еще. В минусы .NET можно записывать привязку к платформе, и много чего еще можно наскрести. Но точно не «Microsoft хочет всех одурачить красивыми примерчиками, а на деле C#-говно». Все там очень хорошо и со сложными приложениями, и куча написанного на .NET софта это подтверждает.
Конкретно в данном сравнении видно что:
— у Swift пока имеются проблемы с работой с legacy-API от objC, который динамический, и плохо работает вместе со статически-типизированным языком. Все вот эти NSDictionary явно выглядят чужеродными.
— сами эти API не самые удобные — та же работа с http, или обработка ошибок сделана ближе к C, и требует много рутинного кода
— десериализация JSON делается врукопашную
— в Swift идет рукопашная работа с асинхронным кодом, через колбеки
Учитывая что задачи в примерах весьма типовые, вполне можно сделать определенные выводы. Мне кажется что пока Apple не напишет нормальные обертки для своих нетипизированных API, и пока Swift не обрастет жирком библиотек, C# и .NET выглядят куда более в выгодном свете.
хотелось бы побольше конкретики, но ладно )
Вы имели ввиду WPF в целом? тогда могу согласиться — некоторые очевидные вещи могут превратиться в серьезное углубление и управление как Visual Tree, так и Logical Tree.
Однако! Если мы рассматриваем тот же ASP.NET (и MVC), то инфраструктура просто замечательная. возможности расширения практически везде.
Vendor lock-in отсутствует вовсе.
Нужно написать распределенный рантайм для обработки данных? Берите C#, Reactive Extensions + ваша фантазия.
Думаю последний пункт можно отнести к любому языку/платформе/ваше_определение.
Просто C# и .NET намного (!!!) удобнее и более проработаны в плане синтаксиса, архитектуры, чем конкуренты.
А семимильное развитие дает ощущение новизны.
Вы имели ввиду WPF в целом? тогда могу согласиться — некоторые очевидные вещи могут превратиться в серьезное углубление и управление как Visual Tree, так и Logical Tree.
Однако! Если мы рассматриваем тот же ASP.NET (и MVC), то инфраструктура просто замечательная. возможности расширения практически везде.
Vendor lock-in отсутствует вовсе.
Нужно написать распределенный рантайм для обработки данных? Берите C#, Reactive Extensions + ваша фантазия.
Думаю последний пункт можно отнести к любому языку/платформе/ваше_определение.
Просто C# и .NET намного (!!!) удобнее и более проработаны в плане синтаксиса, архитектуры, чем конкуренты.
А семимильное развитие дает ощущение новизны.
WPF как раз наглядный пример оверинжиниринга — там очень много всего под капотом для того, чтобы стандартные средства были настолько гибкими, что покрывали даже самые безумные сценарии (ну, например, если вам нужен текстбокс внутри нажимабельной кнопки, это делается в две строчки). Плюс к этому очень много extensibility везде. Так что как раз на полноразмерных примерах он раскрывается в полную силу.
Грустно, что Silverlight и Windows XAML далеко не такие гибкие, несмотря на внешнее сходство.
Грустно, что Silverlight и Windows XAML далеко не такие гибкие, несмотря на внешнее сходство.
Это все банальности, даже mvvm не панацея в некоторых случаях. Вот например, чтобы сделать самое простое — множественный выбор из DataGrid, уже не забиндишь SelectedItems на коллекцию, придется либо делать это в code-behind, либо использовать Interactivity, либо свои велосипеды писать. И чем дальше пишешь, тем больше сталкиваешься с этим.
Не вижу проблем в использовании Interactivity и Code Behind для таких частных случаев.
Ни одна платформа не может предложить готовые решения на все случаи жизни.
Ни одна платформа не может предложить готовые решения на все случаи жизни.
Кстати, постил behaviour для решения подобных проблем: habrahabr.ru/post/215249/
Как по мне, можно один раз сделать behaviour и больше не париться.
Как по мне, можно один раз сделать behaviour и больше не париться.
Код
XAML:
C#:
Behaviour из статьи:
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
xmlns:local="clr-namespace:WpfApplication1"
Title="MainWindow" Height="350" Width="525">
<DockPanel>
<ListBox
DockPanel.Dock="Bottom"
ItemsSource="{Binding Selected}"
Height="150"
/>
<DataGrid ItemsSource="{Binding Collection}">
<i:Interaction.Behaviors>
<local:DependecyPropertyBehavior
UpdateEvent="SelectionChanged"
Property="SelectedItems"
Binding="{Binding Selected}"
/>
</i:Interaction.Behaviors>
</DataGrid>
</DockPanel>
</Window>
C#:
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Windows;
namespace WpfApplication1
{
public partial class MainWindow : Window, INotifyPropertyChanged
{
private ObservableCollection<object> _selected;
public ObservableCollection<object> Collection { get; set; }
public ObservableCollection<object> Selected
{
get { return _selected; }
set
{
_selected = value;
OnPropertyChanged("Selected");
}
}
public MainWindow()
{
InitializeComponent();
Collection = new ObservableCollection<object>
{
new { Col1 = "Hello11", Col2 = "Hello12", Col3 = "Hello13" },
new { Col1 = "Hello21", Col2 = "Hello22", Col3 = "Hello23" },
new { Col1 = "Hello31", Col2 = "Hello32", Col3 = "Hello33" },
new { Col1 = "Hello41", Col2 = "Hello42", Col3 = "Hello43" },
};
Selected = new ObservableCollection<object>();
DataContext = this;
}
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string propertyName)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
}
}
}
Behaviour из статьи:
using System;
using System.Diagnostics;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;
using System.Windows;
using System.Windows.Interactivity;
using Expression = System.Linq.Expressions.Expression;
namespace WpfApplication1
{
public class DependecyPropertyBehavior : Behavior<DependencyObject>
{
private Delegate _handler;
private EventInfo _eventInfo;
private PropertyInfo _propertyInfo;
public static readonly DependencyProperty BindingProperty = DependencyProperty.RegisterAttached(
"Binding",
typeof(object),
typeof(DependecyPropertyBehavior),
new FrameworkPropertyMetadata { BindsTwoWayByDefault = true }
);
public object Binding
{
get { return GetValue(BindingProperty); }
set { SetValue(BindingProperty, value); }
}
public string Property { get; set; }
public string UpdateEvent { get; set; }
protected override void OnAttached()
{
Type elementType = AssociatedObject.GetType();
// Getting property.
if (Property == null)
{
PresentationTraceSources.DependencyPropertySource.TraceData(
TraceEventType.Error,
1,
"Target property not defined."
);
return;
}
_propertyInfo = elementType.GetProperty(Property, BindingFlags.Instance | BindingFlags.Public);
if (_propertyInfo == null)
{
PresentationTraceSources.DependencyPropertySource.TraceData(
TraceEventType.Error,
2,
string.Format("Property \"{0}\" not found.", Property)
);
return;
}
// Getting event.
if (UpdateEvent == null) return;
_eventInfo = elementType.GetEvent(UpdateEvent);
if (_eventInfo == null)
{
PresentationTraceSources.MarkupSource.TraceData(
TraceEventType.Error,
3,
string.Format("Event \"{0}\" not found.", UpdateEvent)
);
return;
}
_handler = CreateDelegateForEvent(_eventInfo, EventFired);
_eventInfo.AddEventHandler(AssociatedObject, _handler);
}
protected override void OnDetaching()
{
if (_eventInfo == null) return;
if (_handler == null) return;
_eventInfo.RemoveEventHandler(AssociatedObject, _handler);
}
protected override void OnPropertyChanged(DependencyPropertyChangedEventArgs e)
{
if (e.Property.Name != "Binding") return;
if (AssociatedObject == null) return;
if (_propertyInfo == null) return;
object oldValue = _propertyInfo.GetValue(AssociatedObject, null);
if (oldValue.Equals(e.NewValue)) return;
if (_propertyInfo.CanWrite)
_propertyInfo.SetValue(AssociatedObject, e.NewValue, null);
base.OnPropertyChanged(e);
}
private static Delegate CreateDelegateForEvent(EventInfo eventInfo, Action action)
{
ParameterExpression[] parameters =
eventInfo
.EventHandlerType
.GetMethod("Invoke")
.GetParameters()
.Select(parameter => Expression.Parameter(parameter.ParameterType))
.ToArray();
return Expression.Lambda(
eventInfo.EventHandlerType,
Expression.Call(Expression.Constant(action), "Invoke", Type.EmptyTypes),
parameters
)
.Compile();
}
private void EventFired()
{
if (AssociatedObject == null) return;
if (_propertyInfo == null) return;
Binding = _propertyInfo.GetValue(AssociatedObject, null);
}
}
}
А причем здесь MVVM? MVVM — это архитектура, которая не привязана вообще к MS и WPF. DataGrid — это какой-то частный контрол. Если чем-то не устраивает — напишите свой или найдите/купите подходящий в интернетах.
Кстати, на Xamarin есть либа, Appercode, что есть WPF под iOS/Android. Сам не трогал, но делают наши. Если что, можно по-русски пожучить в скайпе =)
Оххх… Можно и тут пожучить так-то. Но лучше в личке…
Я-то не собираюсь, поводов нету пока что =) Я имел ввиду иметь доступ к нативно говорящему саппорту всегда хорошо =)
Что вы думаете о Xamarin.Forms с их xaml дизайнером, ведь по сути они отбирают у вас хлеб, нет? :-)
1) мы, как сказали выше, пытаемся сделать вёрстку привычную для Silverlight/WPF разработчиков
2) денег мы за Appercode брать не планируем, так что хлеб отобрать в этом смысле трудно.
2) денег мы за Appercode брать не планируем, так что хлеб отобрать в этом смысле трудно.
1) ну там тоже верстка привычная для WPF, нет?
2) ну я имею ввиду целесообразность какая использовать ваш продукт, а не xamarin.forms?
2) ну я имею ввиду целесообразность какая использовать ваш продукт, а не xamarin.forms?
1) простой пример: аналогом свойства Height в Xamarin.Forms будет HeightRequest, Там нельзя сделать ScrollView, который будет скролиться по 2м направлениям (из-за ограничений андроида). Таких мелочей наберётся достаточно. Мы же стремимся обеспечить возможность копирования верески из WindowsPhone в Appercode с минимальными правками. Хотя у нас тоже есть куча проблем.
2) каждый выбирает для себя. Мы Appercode делаем тоже в первую очередь для внутреннего проекта. Ну и, как сказал выше, возможность применения знаний, которые уже есть, с минимальным изучением документации.
2) каждый выбирает для себя. Мы Appercode делаем тоже в первую очередь для внутреннего проекта. Ну и, как сказал выше, возможность применения знаний, которые уже есть, с минимальным изучением документации.
Ну, там C# со Swift сравнивается коственно. Ту же сериализацию на Swift также как в C# не сделать — там нет нужных фич. Причем в C# еще и код типизированный получается.
В целом для C#-проектов типично применение подобного метапрограммирования — сериализация, работа с БД, удобняшки на аттрибутах. Как писать без этого большие приложения — мне лично не ясно. Данные из БД достали — и тоже руками по объектам их раскладывать что-ли? Типа person.Name = resultSet[«person_name»]?
В целом для C#-проектов типично применение подобного метапрограммирования — сериализация, работа с БД, удобняшки на аттрибутах. Как писать без этого большие приложения — мне лично не ясно. Данные из БД достали — и тоже руками по объектам их раскладывать что-ли? Типа person.Name = resultSet[«person_name»]?
В Swift с типизацией все прекрасно, каких таких фич нет в Swift?
Интроспекция кода (рефлекшн) нужна. Либо макросы, либо что-то еще в compile-time. Короче метапрограммирования.
В C# сериализация работает так:
— ты говоришь JSON.Deserialize(stream), где Response — твой класс. Вероятно в твой класс вложены экземпляры других твоих классов. Вероятно какие-то поля помечены аттрибутами, влияющими на сериализацию — например имя в JSON отличается от имени поля в классе.
— при первом вызове, код сериализатора смотрит какие у тебя в классе поля, и генерирует код десериализации.
— код вызывается, читает строку на входе, на выходе ты получаешь экземпляр своего класса. Был JSON { name: «Ivan» }, стал объект с obj.Name == 'Ivan'. И дальше работаешь с ним как с любым другим C#-объектом
Т.е. ты не пишешь ничего типа response.Name = parsedUntypedJsonDOM['Name'], все мэппится само.
Точно также дела обстоят с мэппингом классов на результат запроса к БД.
Такого в Swift, как я понимаю, не сделать — управляемого рантайма вообще нет. Можно, наверное, делать в compile-time, но тогда надо чтобы компилятор имел API и отдавал метаданные по нужным классам. Этого, я так понимаю, тоже нет и не предвидится. Лучшее что можно сделать в Swift с текущими его фичами — это генерацию классов самого Swift по какой-нибудь схеме данных в JSON.
В C# сериализация работает так:
— ты говоришь JSON.Deserialize(stream), где Response — твой класс. Вероятно в твой класс вложены экземпляры других твоих классов. Вероятно какие-то поля помечены аттрибутами, влияющими на сериализацию — например имя в JSON отличается от имени поля в классе.
— при первом вызове, код сериализатора смотрит какие у тебя в классе поля, и генерирует код десериализации.
— код вызывается, читает строку на входе, на выходе ты получаешь экземпляр своего класса. Был JSON { name: «Ivan» }, стал объект с obj.Name == 'Ivan'. И дальше работаешь с ним как с любым другим C#-объектом
Т.е. ты не пишешь ничего типа response.Name = parsedUntypedJsonDOM['Name'], все мэппится само.
Точно также дела обстоят с мэппингом классов на результат запроса к БД.
Такого в Swift, как я понимаю, не сделать — управляемого рантайма вообще нет. Можно, наверное, делать в compile-time, но тогда надо чтобы компилятор имел API и отдавал метаданные по нужным классам. Этого, я так понимаю, тоже нет и не предвидится. Лучшее что можно сделать в Swift с текущими его фичами — это генерацию классов самого Swift по какой-нибудь схеме данных в JSON.
про интроспекцию и рефлексию я с вами полностью согласен, но это никакого отношения к системе типов не имеет.
runtime codegen на ios запрещен, поэтому если писать на C# под Monotouch будет рефлекш повсюду в десериализации, скорость будет просто слезная. Тут можно долго рассуждать об удобствах дотнетов, только классические варианты с кодегеном десериализатора перед компиляцией порвут любой дотнетовский rtti-based подход по скорости раз в 5.
Если сравнивать компилированный вариант с рефлекшном — он порвет, да. Если с генерацией байткода — зависит от того насколько будет ли эффективнее компилятор дотнетовского JIT-а. Но разница будет уже не принципиальная.
Короче то что есть сейчас в Swift для сериализации — печаль-печаль. В будущем скорее всего будет генерация в compile-time, она может будет и пошустрее, но точно менее удобная.
Короче то что есть сейчас в Swift для сериализации — печаль-печаль. В будущем скорее всего будет генерация в compile-time, она может будет и пошустрее, но точно менее удобная.
Дело в том, что я в разработке под Apple вообще ни бум-бум, можете вместо iOS подставить любое правильное слово. Но чтобы понять смысл поста, почитайте оригинальный tutorial (в посте есть ссылка) и сравните с тем, как абсолютно такое же приложение пишется на WPF/C#.
> К тому же на задаче уровня Hello World
Вот тут не надо! Задача очень даже реальная: UI+INet. UI сделан гибким, используются байндинги, модели, сервис аппстора. То есть подобные элементы вы найдёте почти в каждом сетевом приложении. Оно простое, но просто обвешивая его дополнительным функционалом (не меняя общей структуры!) можно написать вполне коммерческое ПО. Даже автор сам пишет: «На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View». По-моему, на таких базовых знаниях можно половину приложений сделать — чем тут «хелловорлд»??
Я вряд ли буду тратить время на создание «ещё более впечатляющего» приложения, показывающего преимущество WPF, вы сами можете всё сравнить — напишите Swift приложение и его аналог на WPF, могу помочь в проблемных местах с WPF — тогда сразу увидите разницу.
> К тому же на задаче уровня Hello World
Вот тут не надо! Задача очень даже реальная: UI+INet. UI сделан гибким, используются байндинги, модели, сервис аппстора. То есть подобные элементы вы найдёте почти в каждом сетевом приложении. Оно простое, но просто обвешивая его дополнительным функционалом (не меняя общей структуры!) можно написать вполне коммерческое ПО. Даже автор сам пишет: «На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View». По-моему, на таких базовых знаниях можно половину приложений сделать — чем тут «хелловорлд»??
Я вряд ли буду тратить время на создание «ещё более впечатляющего» приложения, показывающего преимущество WPF, вы сами можете всё сравнить — напишите Swift приложение и его аналог на WPF, могу помочь в проблемных местах с WPF — тогда сразу увидите разницу.
Это было бы честным сравнением, если бы Автор свою поделку еще запустил на iOS девайсе. А так это сравнение ракетки и ракеты. Относительно количества кода — для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF, а уж бинарный файл и того меньше на порядки (для C# нужно еще .Net framework установить в каталог с приложением). Это не говоря уж о том, что Swift короче Objective-C, а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.
.Net framework установить в каталог с приложениемКуда-куда установить?
На большинстве современных систем .net framework давно стоит по умолчанию, или скачивается из интернета инсталлятором.
Причём тут WPF и iOS?? Вы совсем не понимаете что и с чем я сравниваю? Оторвитесь от платформ вообще, взгляните на приложение как на абстрактную утилиту, которая делает свою работу. Её можно написать хоть на Рефале под PDP-11, её полезности это не изменит. А вот СЛОЖНОСТЬ РАЗРАБОТКИ может отличаться в разы — вот про это и пост, читайте внимательнее.
> для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF
Правда? Может, чтобы не быть голословным, приведёте точное количество строк для iOS? (пример для iOS я точно сам не напишу)
> для C# нужно еще .Net framework установить в каталог с приложением
Во-первых, вы не владеете темой и пишете ерунду. .NET FW ставится ОДИН раз в каталог винды и используется ВСЕМИ приложениями. Оттого они и получаются маленькие.
Во-вторых, FW на винде — не более обременителен, чем Cocoa поверх XNU — ровно такой же фрэймворк. И кстати, с Винды-7 фрэймворк идёт в комплекте — ничего дополнительно устанавливать не нужно.
> а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.
Опять ерунду пишете. В данном случае была обучалка не Swift'у, а вообще созданию приложений под iOS! Внимательно прочтите оригинал, с которого я писал код — там нет ничего про свифт, тупо «как накликать приложение в XCode».
> для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF
Правда? Может, чтобы не быть голословным, приведёте точное количество строк для iOS? (пример для iOS я точно сам не напишу)
> для C# нужно еще .Net framework установить в каталог с приложением
Во-первых, вы не владеете темой и пишете ерунду. .NET FW ставится ОДИН раз в каталог винды и используется ВСЕМИ приложениями. Оттого они и получаются маленькие.
Во-вторых, FW на винде — не более обременителен, чем Cocoa поверх XNU — ровно такой же фрэймворк. И кстати, с Винды-7 фрэймворк идёт в комплекте — ничего дополнительно устанавливать не нужно.
> а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.
Опять ерунду пишете. В данном случае была обучалка не Swift'у, а вообще созданию приложений под iOS! Внимательно прочтите оригинал, с которого я писал код — там нет ничего про свифт, тупо «как накликать приложение в XCode».
И кстати, с Винды-7 фрэймворк идёт в комплекте — ничего дополнительно устанавливать не нужно.
Он практически всегда шёл в комлекте, просто предустановленная версия может устареть как ИЕ, если отрубить обновления оси или сидеть на ископаемой оси…
Ну как причем тут WPF и iOS? Мы, конечно, можем порадоваться за windows мир, но если у тебя стоит iOS — придется же все равно мучится и забыть о существовании WPF? Или тут намек, что надо выкидывать iPad на свалку? Я то за, но все ли так думают…
tac, почему у вас логика и выводы как у школьника? Разве мой пост такой непонятный? Русским по-белому написал:
«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»
Есть способ — пожалуйста, поделитесь. Нет — ДА И ФИГ С НИМ! :) Я не решаю ничьих проблем, я не пишу под мобилы, но мой проект хорошо показывает, НАСКОЛЬКО ПРОСТО должна быть разработка под любые платформы, благо есть конкретный практический пример — WPF. То, что под iOS нужно столько гемороиться, лишь показывает несостоятельность эппловского инструментария — вот и пусть он сдохнет в забвении! Пока МЫ ВСЕ не пошлём нафиг их сложности, Эппл так и будет нас снабжать лобзиками для валки леса. (это если вам захотелось глобальных выводов) Если кто-то хочет продолжать есть кактус — ССЗБ, почему мы должны переживать за их судьбу?
«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»
Есть способ — пожалуйста, поделитесь. Нет — ДА И ФИГ С НИМ! :) Я не решаю ничьих проблем, я не пишу под мобилы, но мой проект хорошо показывает, НАСКОЛЬКО ПРОСТО должна быть разработка под любые платформы, благо есть конкретный практический пример — WPF. То, что под iOS нужно столько гемороиться, лишь показывает несостоятельность эппловского инструментария — вот и пусть он сдохнет в забвении! Пока МЫ ВСЕ не пошлём нафиг их сложности, Эппл так и будет нас снабжать лобзиками для валки леса. (это если вам захотелось глобальных выводов) Если кто-то хочет продолжать есть кактус — ССЗБ, почему мы должны переживать за их судьбу?
Ну, для начала, сообщу Вам, что я программирую на C# c 2005 года. Сетевые приложение писал и c сокетами, и с REST, и с WCF / WF как для WinForm, так и для WPF и Silverlight. Так что кто еще не владеет темой — отдельный вопрос.
Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки». Последние годы он включен в винду, но чтоб это же приложения работали под Linux/FreeBSD/Solaris/OSX или Android / iOS вам необходим Mono/Monotoch который копируется в каталог приложения. И, в общей сложности увеличивает размер бинарника в сотни раз. А без него него — никак.
Из этого следует:
1) Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
2) Говорить о том, что все «из коробки» — это тоже fail.
Ну это были так, азы, для тех кто в теме.
Далее, относительно объема кода:
Чтоб отобразить таблицу необходимо и достаточно реализовать всего три метода:
— получить количество секций
— получить количество строк в секции
— получить ячейку и сделать ей кастомизацию, вычитав данные из словаря.
Чтобы получить словарь — достаточно одного метода для GET запроса, и одного метода для превращения JSON в NSDictionary.
ВСЕ!
При всем при этом, XCode предоставляет шаблонный код, где вообще почти ничего не нужно менять.
Будете считать строки кода в переносами на другую строку и открывающей/закрывающей фигурной скобкой?
Только полный профан будет на столь элементарных примерах доказывать преимущество одного языка, над другим.
ИТОГО:
сравнение платформ: fail
сравнение языков: fail.
Поговорим о производительности WPF кода под iOS, или пойдете читать учебники?
Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки». Последние годы он включен в винду, но чтоб это же приложения работали под Linux/FreeBSD/Solaris/OSX или Android / iOS вам необходим Mono/Monotoch который копируется в каталог приложения. И, в общей сложности увеличивает размер бинарника в сотни раз. А без него него — никак.
Из этого следует:
1) Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
2) Говорить о том, что все «из коробки» — это тоже fail.
Ну это были так, азы, для тех кто в теме.
Далее, относительно объема кода:
Чтоб отобразить таблицу необходимо и достаточно реализовать всего три метода:
— получить количество секций
— получить количество строк в секции
— получить ячейку и сделать ей кастомизацию, вычитав данные из словаря.
Чтобы получить словарь — достаточно одного метода для GET запроса, и одного метода для превращения JSON в NSDictionary.
ВСЕ!
При всем при этом, XCode предоставляет шаблонный код, где вообще почти ничего не нужно менять.
Будете считать строки кода в переносами на другую строку и открывающей/закрывающей фигурной скобкой?
Только полный профан будет на столь элементарных примерах доказывать преимущество одного языка, над другим.
ИТОГО:
сравнение платформ: fail
сравнение языков: fail.
Поговорим о производительности WPF кода под iOS, или пойдете читать учебники?
почему вы складываете в одну кучу настольные системы («Linux/FreeBSD/Solaris/OSX») и мобильные (Android / iOS)?
проблема интеграции рантайма на мобильных системах абсолютно идентична и Adobe AIR, например.
Если рассматривать настольные системы, то Mono устанавливается как и обычный .NET, позволяя запускать приложения на Linux, Mac OS (и через терминал также).
Размер бинарников .NET — просто маленький, однако это особенность самих файлов. Нативные сборки в 10x раз больше.
>>Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки»
а разве ОС не делает за Вас все из коробки (потоки, память, виртуализация памяти, файлы, сеть и т.д.).
Фреймворки предоставляют лишь абстракции (если это class library для OS API).
>>Поговорим о производительности WPF кода под iOS
он уже существует под iOS ?)
проблема интеграции рантайма на мобильных системах абсолютно идентична и Adobe AIR, например.
Если рассматривать настольные системы, то Mono устанавливается как и обычный .NET, позволяя запускать приложения на Linux, Mac OS (и через терминал также).
Размер бинарников .NET — просто маленький, однако это особенность самих файлов. Нативные сборки в 10x раз больше.
>>Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки»
а разве ОС не делает за Вас все из коробки (потоки, память, виртуализация памяти, файлы, сеть и т.д.).
Фреймворки предоставляют лишь абстракции (если это class library для OS API).
>>Поговорим о производительности WPF кода под iOS
он уже существует под iOS ?)
Это не я складываю, а автор топика который пытается сравнивать десктопную векторную платформу, работающую на x86 архитектуре, с растровой ARM iOS платформой. Перечислением платформ я лишь пытался показать перечень того, где нет встроенного .NET.
Про размер файлов я знаю. Но в сумме они дают слишком высокий прирост.
Фреймворки не только предоставляют абстракции, но и обеспечивают большим количеством прикладного кода. Автор, к примеру, апеллирует к тому, насколько плохо в IOS обеспечена поддержка JSON. Так если выкинуть из .Net сборки по сериализации, там тоже ничего работать без костылей не будет. И именно это создает богатство платформы. В IOS SDK они не меньше, просто пример для Swift показан минимальными средствами.
Конечно WPF под iOS не существует, хотя бы потому, что повсеместно используется растровая графика, а не векторная как в WPF. Но в целом Monotouch и Mono существенно уступает в производительности нативному решению (а в винде, это предмет бесконечных споров). Так что все сравнение некорректно от начала до конца. Хотя начало статьи — действительно приковывает внимание.
Про размер файлов я знаю. Но в сумме они дают слишком высокий прирост.
Фреймворки не только предоставляют абстракции, но и обеспечивают большим количеством прикладного кода. Автор, к примеру, апеллирует к тому, насколько плохо в IOS обеспечена поддержка JSON. Так если выкинуть из .Net сборки по сериализации, там тоже ничего работать без костылей не будет. И именно это создает богатство платформы. В IOS SDK они не меньше, просто пример для Swift показан минимальными средствами.
Конечно WPF под iOS не существует, хотя бы потому, что повсеместно используется растровая графика, а не векторная как в WPF. Но в целом Monotouch и Mono существенно уступает в производительности нативному решению (а в винде, это предмет бесконечных споров). Так что все сравнение некорректно от начала до конца. Хотя начало статьи — действительно приковывает внимание.
Человек, написавший хотя бы хелловорлд на C#, никогда не напишет ахинею вроде этой:
нужно еще .Net framework установить в каталог с приложением
Какой смысл после драки рассказывать свою биографию? Свою квалификацию вы уже осветили, спасибо, свободны.
Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
сравнение языков: fail.
Приведите цитату в посте, где я сравниваю какие-то бинарники или языки. Не увижу цитаты — можете сами себя послать на **** и больше на мои темы не отвечать — всё равно будете в игноре.
PS
Как же тупая школота утомила…
нужно еще .Net framework установить в каталог с приложением
Какой смысл после драки рассказывать свою биографию? Свою квалификацию вы уже осветили, спасибо, свободны.
Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
сравнение языков: fail.
Приведите цитату в посте, где я сравниваю какие-то бинарники или языки. Не увижу цитаты — можете сами себя послать на **** и больше на мои темы не отвечать — всё равно будете в игноре.
PS
Как же тупая школота утомила…
Вот вам цитата из ВАШЕГО текста про объем кода:
Итого, 30 строчек XAML + 44 C# кода. Я нарочно не стал делать всякую асинхронщину, т.к. глупо жать кнопку и тут же что-то менять — нужно дождаться результата, но если кому чешется, можете для async/await прибавить ещё 4 строчки.
В любом случае, полученный код явно компактнее и проще Swift-оригинала, да и сам проект — всего одна форма:
К Вашему сведению, .net работает не только в Windows. И сравнивать языки программирования, в том числе и по объему написанного кода можно только в том случае, если Вы можете воспроизвести ОБА примера на одной и той же платформе. То что Вы называете ахинеей — это реальность, о которой Вы не знаете просто потому что кроме Windows никогда ничего не видели. Да, в винде Framework встроенный, но на любой другой ОС, его нужно копировать к полученному бинарнику. (ужа надоело это даже писать), и без него НИЧЕГО работать не будет. Swift с которым Вы сравниваете работает только на OSX и iOS. Так что, прежде чем называть меня школотой, потрудитесь отвечать за свои слова и запустите свою поделку на любой из этих платформ.
Итого, 30 строчек XAML + 44 C# кода. Я нарочно не стал делать всякую асинхронщину, т.к. глупо жать кнопку и тут же что-то менять — нужно дождаться результата, но если кому чешется, можете для async/await прибавить ещё 4 строчки.
В любом случае, полученный код явно компактнее и проще Swift-оригинала, да и сам проект — всего одна форма:
К Вашему сведению, .net работает не только в Windows. И сравнивать языки программирования, в том числе и по объему написанного кода можно только в том случае, если Вы можете воспроизвести ОБА примера на одной и той же платформе. То что Вы называете ахинеей — это реальность, о которой Вы не знаете просто потому что кроме Windows никогда ничего не видели. Да, в винде Framework встроенный, но на любой другой ОС, его нужно копировать к полученному бинарнику. (ужа надоело это даже писать), и без него НИЧЕГО работать не будет. Swift с которым Вы сравниваете работает только на OSX и iOS. Так что, прежде чем называть меня школотой, потрудитесь отвечать за свои слова и запустите свою поделку на любой из этих платформ.
Вот что в Swift нет generic-ов, а соответственно — человеческого способа сделать API сериализаторов — это вообще печаль.
Печаль еще в том, что кроме generic-ов нужно reflection+runtime code generation, либо нормальные макросы в компиляторе, либо еще что-то чтобы этот API и реализацию сгенерировать по типам. А этого, я так понимаю, не предвидится даже в будущем.
Разработчики могли бы зайти в динамическую типизацию — что-то типа dynamic в C#, типа нет типизации — сделать чтобы не было мучительно больно работать с динамическими API хотя-бы. Но нет — в примерах тех же сериализаторов уродливые лукапы по строкам в словарях, явные приведения типов — вот это всё.
Короче очень все печально в swift как минимум с сериализацией, ну и с метапрограммированием в целом.
Печаль еще в том, что кроме generic-ов нужно reflection+runtime code generation, либо нормальные макросы в компиляторе, либо еще что-то чтобы этот API и реализацию сгенерировать по типам. А этого, я так понимаю, не предвидится даже в будущем.
Разработчики могли бы зайти в динамическую типизацию — что-то типа dynamic в C#, типа нет типизации — сделать чтобы не было мучительно больно работать с динамическими API хотя-бы. Но нет — в примерах тех же сериализаторов уродливые лукапы по строкам в словарях, явные приведения типов — вот это всё.
Короче очень все печально в swift как минимум с сериализацией, ну и с метапрограммированием в целом.
А что, разве Swift типизированный язык? Мне казалось, так как на ObjC в массив можно пихать что угодно, соответственно не очень-то и нужны дженерики
Давайте отделять мух от котлет. Objective-C имеет динамическую типизацию, Swift – статическую, причем система типов богаче C#.
Забавно, минусы за объективные факты :)
Чего чего там богаче С#??? Или ты не знаешь C# или ты не знаешь SWIFT
Алгебраические типы данных с паттерн-матчингом, например.
Ответ: enum
enum в C# может иметь связанные данные? И их можно извлекать с помощью swift/case?
это костыль, а не ADT
Ладна ну раз костыль так костыль… Если так подумать тогда они в С# не нужны есть LINQ который их полностью заменяет + даёт ещё кучу нужный вещей которые к сожалению програмистам на Swift не доступны. Да там ещё куча чего не доступно даже взять видимость членов класса. Я не умоляю язык Swift — но мне кажеться он ещё оооочень молодой и говорить что в нём есть что-то чего нет в С# — бесмысленый спор
А добавленные две ссылки вообще с примерами на F#.
не знаю, как это относится к алгебраическим типам, но именно связанные данные в enuma-х (да и вообще в чем угодно) вполне можно засунуть в атрибуты, и извлекать их при помощи рефлексии, например, так легко превратить enum в список описаний, который отображается в комбобоксе, но значениями его являются значения enum'а, которые мы редактируем в одном месте.
Не, Enum это не то. В C# действительно нет ADT и pattern matching. Если очень нужно — есть F#, там уж точно полный фарш и с ADT и прочими типами.
Pattern-matching вероятно скоро будет и в C#: roslyn.codeplex.com/discussions/546465 (там про typeswitch)
Pattern-matching вероятно скоро будет и в C#: roslyn.codeplex.com/discussions/546465 (там про typeswitch)
Ну если очень понадобится «зайти в динамическую типизацию», можно написать модуль на Objective-C и использовать его в Swift-коде. А через пару релизов языка глядишь и introspection или макросы сделают.
Там все не так просто. Swift — компилируемый язык, так что рефлекшна и рантайм-кодогенерации я бы там не ждал. Compile-time-макросы или что-то типа Roslyn — тоже слабо верится. Скорее всего закроют самое необходимое генерацией кода Swift из какой-нибудь JSON Schema отдельной тулзой. Как это было в .NET с датасетами и XMLSerializer-ом.
А можете заняться небольшим просвещением? Что такое runtime кодогенерация я себе еще могу представить, хотя и с трудом представляю, зачем вообще это может быть полезно. Не могли бы вы привести пару примеров? И, если не затруднит, reflection. А то в каждом третьем комментарии говорится об этих «чудовищных» недостатках Swift, что даже интересно стало, настолько ли они «чудовищны» и почему я раньше об этом ничего не слышал. Спасибо!
Reflection — возможность получить во время работы программы информацию о самой программе. Например спросить какие есть поля в определенном классе, какие у них типы, пройтись по ним циклом, и что-нибудь сделать полезного.
Runtime code generation — возможность сгенерировать код во время работы программы. Например сказать какие команды для виртуальной машины записать в функцию, и получить ссылку на эту функцию, которую можно потом вызывать.
В примере в оригинальной статьи про Swift делается десериализация JSON, причем кода весьма много, и он не очень приятен — присутствуют приведения типов, присутствует доставание значений по константной строке-ключу.
В C# этого кода фактически нет — объявляются классы, у которых поля по имени и типу совпадают с полями в JSON, дальше десериализатор генерируется библиотекой на лету.
Runtime code generation — возможность сгенерировать код во время работы программы. Например сказать какие команды для виртуальной машины записать в функцию, и получить ссылку на эту функцию, которую можно потом вызывать.
В примере в оригинальной статьи про Swift делается десериализация JSON, причем кода весьма много, и он не очень приятен — присутствуют приведения типов, присутствует доставание значений по константной строке-ключу.
В C# этого кода фактически нет — объявляются классы, у которых поля по имени и типу совпадают с полями в JSON, дальше десериализатор генерируется библиотекой на лету.
Спасибо, познавательно, видимо, я слишком привык к С++ :) А кроме десериализации это может быть чем-то полезным? Здесь согласен, это действительно должно сильно сокращать код.
Работа с БД, в плане мэппинга классов на результаты запросов, чтение конфигов, чтение полей из HTTP-запросов. Хотя это тоже считай сериализация. Есть еще штуки типа AutoMapper — копирует разные классы друг в друга, используя как вход соглашения о наименовании: одинаковые поля копируем друг в друга, Person.Name копируем в PersonName, и т.п.
Плюс есть еще смежные с этими фичи:
— аттрибуты. Ты можешь на метод, класс, поле или параметр повесить при компиляции экземпляр своего класса, в который запихать любую метаинформацию. Которую потом как-то использовать в рантайме. Например:
или
Применяется очень широко — валидация, настройка сериализации, метаинформация для UI (как label назвать, каким контролом редактировать), контроль доступа, подсовывание данных для юнит-тестов, и т.п.
ExpressionTree. Ты можешь получить в рантайме синтаксическое дерево лямбда выражения. Применяется тоже широко. Например через это делают типизированные ссылки на свойства и метаданные: передаем вроде как лямбду, достающую значение свойства: createTextInput(model => model.Name). А на самом деле внутри получаем дерево этой лямбды, а из нее — делаем сеттер этого поля, плюс имя поля, плюс аттрибуты.
Ну и LinqToSQL весь работает на всех этих фичах — фактически он конвертирует вызовы методов и лямбд в дерево выражения, которое потом транслирует в SQL и выполняет на сервере.
Короче метапрограммирование в C# цветет и пахнет. И хотя немного порой выглядит как магия, жизнь упрощает очень сильно.
Плюс есть еще смежные с этими фичи:
— аттрибуты. Ты можешь на метод, класс, поле или параметр повесить при компиляции экземпляр своего класса, в который запихать любую метаинформацию. Которую потом как-то использовать в рантайме. Например:
[AdminOnly]
public ActionResult ShowLogs() ...
или
[Required]
[ValidateString(Pattern = '...')]
[Label("Cell or work phone")]
public string Phone
Применяется очень широко — валидация, настройка сериализации, метаинформация для UI (как label назвать, каким контролом редактировать), контроль доступа, подсовывание данных для юнит-тестов, и т.п.
ExpressionTree. Ты можешь получить в рантайме синтаксическое дерево лямбда выражения. Применяется тоже широко. Например через это делают типизированные ссылки на свойства и метаданные: передаем вроде как лямбду, достающую значение свойства: createTextInput(model => model.Name). А на самом деле внутри получаем дерево этой лямбды, а из нее — делаем сеттер этого поля, плюс имя поля, плюс аттрибуты.
Ну и LinqToSQL весь работает на всех этих фичах — фактически он конвертирует вызовы методов и лямбд в дерево выражения, которое потом транслирует в SQL и выполняет на сервере.
Короче метапрограммирование в C# цветет и пахнет. И хотя немного порой выглядит как магия, жизнь упрощает очень сильно.
а какой ROI от этого?
Декларативный код меньше подвержен ошибкам. И, C# в отличии от той же java с XML во все концы, имеет инструменты сделать декларативный код строго-типизированным.
Вклад при этом минимален — все что нужно простым пацанам уже есть в библиотеках. От них только требуется класс написать, и аттрибутами закастомизировать поведение всех этих сериализаторов и валидаторов. Это даже проще чем конфиги какие править.
А профит в том, что кода меньше: меньше ошибок, меньше работы, дешевле разработка, дешевле поддержка.
Вот как пример — я регулярно рефакторю схему БД, с которой работаю через Entity Framework. Например вот переименовал я для красоты поле UserID в ID для однородности, чисто рефакторингом студии. Сложно себе предствить как такое было бы возможно, если бы не все ссылки на это поле были бы строго-типизированны, и весь возможный boilerplate-код не сидел бы в библиотеках. Например если был бы SQL в строках «select * from users where userid = » + id, или были бы поля во вьюхах типа
Вклад при этом минимален — все что нужно простым пацанам уже есть в библиотеках. От них только требуется класс написать, и аттрибутами закастомизировать поведение всех этих сериализаторов и валидаторов. Это даже проще чем конфиги какие править.
А профит в том, что кода меньше: меньше ошибок, меньше работы, дешевле разработка, дешевле поддержка.
Вот как пример — я регулярно рефакторю схему БД, с которой работаю через Entity Framework. Например вот переименовал я для красоты поле UserID в ID для однородности, чисто рефакторингом студии. Сложно себе предствить как такое было бы возможно, если бы не все ссылки на это поле были бы строго-типизированны, и весь возможный boilerplate-код не сидел бы в библиотеках. Например если был бы SQL в строках «select * from users where userid = » + id, или были бы поля во вьюхах типа
<input type='hidden' value='@data["userid"]'> — я бы за рефакторинг схемы брался бы только основательно с бизнесом поторговавшись, за отдельную оплату.меньше работы, дешевле разработка, дешевле поддержкаМеньше заработок? :)
я регулярно рефакторю схему БД,Семь раз отмерь, один раз отрежь? :)
«Меньше работы — меньше заработок» — это ты видимо пошутил. Меньше работы на единицу функционала => больше проекты => квадратично больше бабла.
Рефакторить БД нужно не только из-за изначальных ошибок проектирования, а еще потому что требования меняются. И я могу себе позволить поменять схему и смигрировать данные, а не хранить зайчиков в осликах.
Рефакторить БД нужно не только из-за изначальных ошибок проектирования, а еще потому что требования меняются. И я могу себе позволить поменять схему и смигрировать данные, а не хранить зайчиков в осликах.
удалено. ошибся веткой
Вот что в Swift нет generic-ов, а соответственно — человеческого способа сделать API сериализаторов — это вообще печаль.
В Swift есть женерики. Посмотрите обучающие примеры.
В Swift есть женерики. Посмотрите обучающие примеры.
А почему собственно WPF с iOs сравнивается? Пишите тогда уж на Silverlight for Windows Phone. В конкретно данном примере конечно будет мало различий, но разработка WPF и WinPhone совершенно разные.
Между прочим, чистый WPF в некоторых кейсах проигрывает UITableView. А вот в Windows Phone напротив есть столь же мощный LongListSelector.
Позволю себе не согласиться. Скорее, подмножества XAML немного разные, каких-то компонентов WPF в Silverlight или разработке под WinRT нету, но подход-то к разработке один и тот же остается. Тот же xaml, тот же C#, те же библиотеки типа Caliburn.Micro для облегчения MVVM, которые используются одинаковым образом. Да даже Linq2sql из коробки работает на WinPhone.
Ну а на iOS работает CoreData из коробки. Тоже еще аргумент. Swift сырой язык — с этим может спорить только тот, кто не программирует на iOS. Он еще даже не вышел в первой версии — он был только презентован. При его создании использовали опыт в том числе и C#, так же как сам C# был создан при участии разработчиков Delphi и почерпнул оттуда многие свои идеи. Дискуссия здесь холиварна просто потому, что невозможно сравнивать что-то простое и неработающее, с чем-то менее интуитивным в вполне работоспособным. Вот когда автор топика запустит свое приложение под IOS, разработав его под WPF, тогда и будет смысл сравнивать ПРОСТОТУ программирования и объем кода. Пока что, автор показал одно, а в заголовке написал совсем другое.
Ну не правда же:)
На телефоне всегда надо думать о выделенной памяти. Если на декстопе все это работает быстро и можно захавать пол гига на 1 минуту, то в телефоне такого нельзя. Второе, тот же ReactiveExtensions работают немного но по-другому. Я не буду говорить о том, что там нету Emitа, а значит все маппинги происходят засчет рефлексии. И да, контролы там другие и работают они по-другому. Не как в WPF, собственно об этом и была речь.
На телефоне всегда надо думать о выделенной памяти. Если на декстопе все это работает быстро и можно захавать пол гига на 1 минуту, то в телефоне такого нельзя. Второе, тот же ReactiveExtensions работают немного но по-другому. Я не буду говорить о том, что там нету Emitа, а значит все маппинги происходят засчет рефлексии. И да, контролы там другие и работают они по-другому. Не как в WPF, собственно об этом и была речь.
Соглашусь, тут отличие есть. Правда, о памяти надо думать всегда, в случае с десктопом 2003 года выпуска с 512 Мб памяти или каким-нибудь eee-pc это даже более актуально, чем в случае с телефоном. Bloatware — зло, и я сейчас временами очень страдаю, когда хочу запустить хотя бы браузер на стареньком eee-pc. Риторический вопрос — как так получается, что 3-д игра 2001 года, или *любое другое приложение старого года выпуска* на нем работают быстрее, чем прокручивается лента комментариев на новостном сайте (по кадру в 3 секунды)?
+1
Я так понял, людям надо просто докопаться до идеала :) Ну вот вышло так, что под WPF решение получилось намного проще — значит нужно искать какие-нибудь тухлые отговорки, лишь бы его обкакать! (как будто это хоть на грош облегчит жизнь iOS бедолагам :)) )
Я так понял, людям надо просто докопаться до идеала :) Ну вот вышло так, что под WPF решение получилось намного проще — значит нужно искать какие-нибудь тухлые отговорки, лишь бы его обкакать! (как будто это хоть на грош облегчит жизнь iOS бедолагам :)) )
Почему мне должно быть дело до Сервелата? То, что M$ что-то там позиционирует (и реализует через анус) — это их интимное дело. Я реализовал всё на WPF — чем он вам не угодил? Что в нём такого «десктопного», чего нельзя реализовать на мобильной платформе? Весь код — выше, можете тыкнуть в конкретную строку и объяснить.
Покажите свой код работающий на iOS тогда и поговорим. Ну хотяяяяяяябыыы под OSX.
Таки речь шла о том, что свифту есть к чему стремиться, а не о том, что WPF круче
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет. Но за пару лет Objective-C взял такой разгон, что были основания полагать, что скоро C# придется догонять… А поведение Балмерт и уход автора C# из Microsoft только усугубил кризис. Это вообще не предмет дискуссии. Но вот что значит стремится? Нужно ли Apple переходить к векторной графике? До тех пор пока я не начал программировать на IOS я был уверен, что за векторной графикой будущее. Но растр у Microsoft не делает десятой части того, что делает у Apple. В таком случае, в чем смысл? А именно это позволило обрести WPF/Siverlight такую популярность. Да, у Apple отсуствует декларативное программирование. Это очень не привычно, в современном мире. С другой стороны, пробовали Вы сделать сложную декларативную графику без Microsoft Blend? Вот и посудите, а оно надо? Все равно же будут использовать посроители интерфейса, как это делает Apple. Ну и в завершении, что делает WPF таковой, что резко сокращает количество кода — бандинги! А скажете ли Вы что MVVM легче для понимания и работы в очень сложной форме чем MVC? Думаю что нет. Так нужно ли идти по этой дороге?
Никто не говорил про нюансы векторной и растровой графики. Автор всего лишь заметил, что iOS-разработчиков в 2014 году продолжают заставлять писать тонны ненужного кода
пробовали Вы сделать сложную декларативную графику без Microsoft Blend?
Я пробовал и делал. Более того, большинство разработчиков, которых я видел, пишут интерфейсы напрямую в xaml, остальные, ЕЩЕ не пишут. Но есть встречный вопрос, пробовали ли вы Делать сложную графику ТОЛЬКО в IB?
Но растр у Microsoft не делает десятой части того, что делает у Apple. В таком случае, в чем смысл?
Пример?
iOS-разработчикам не мешало бы иногда задумываться о MVVM, глядишь в среднее качество кода по больнице увеличилось бы.
Боюсь нормальный MVVM там не получится — нет привязок данных. Есть для Xamarin MVVMCross и MVVMLight но это не совсем честный MVVM.
Эппл форсирует использование MVC в iOS. Но опять же не все разрабы следуют этой архитектуре.
Эппл форсирует использование MVC в iOS. Но опять же не все разрабы следуют этой архитектуре.
Есть ReactiveCocoa с биндингами, но это Objective-C и макросы. Что и как будет в Swift – не знаю пока.
Тут нет самого главного: декларативных привязок. Все равно надо это из кода задавать. И я не совсем понимаю, там реализован контекст данных? без него тоже не MVVM
Если очень захотеть, можно задавать эти привязки в Interface Builder (через runtime attributes), я всё-таки предпочитаю в коде, пусть это и не так «правильно» и «декларативно». По моему мнению, суть всё-таки в декларативном описании dataflow, а не задании привязок в удобном UI-редакторе (хотя это тоже здорово, конечно)
С .NET толком не работал, поэтому про контекст ничего ответить не смогу, возможно у нас просто терминология другая.
Вот небольшой примерчик, как может выглядеть view model на Objective-C с использованием RAC.
С .NET толком не работал, поэтому про контекст ничего ответить не смогу, возможно у нас просто терминология другая.
Вот небольшой примерчик, как может выглядеть view model на Objective-C с использованием RAC.
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.
Для тех, кто в танке… В каком смысле «отставал»? Второму же всего чуть больше 20 лет ))) Как же «первый может отставать», он что только что появился? ))))…
В пользу второго можно сказать, что ко второму постоянно придумывают новые framework-и, которые сильно облегчают жизнь… Это не столько развитие общей структуры кода, сколько чисто заточенные вещи под мобильные устройства и не только устройства…
Я просто не знаю, что в этом плане может нам предложить «первый» ))).
C# — 2000
Obj-C — 1983
Кому из них чуть более 20?
Obj-C — 1983
Кому из них чуть более 20?
Извините, обшибся, но тогда вот эта фраза
совсем непонятна.
Первый — это Objective-C, как он может отставать от C# — на два десятка лет, если C# всего 14 лет?
Это подразумевается, что он старее? Типо старьё ))) Или что он с тех пор не развивался, а только в недавнее время стал развиваться?
Я C# к сожалению профессионально не занимался, но когда на курсах изучал, нам там прямо сказали, C# полностью всё ворует у Java и учиться на чужих, то есть java вских ошибках… Не знаю на сколько это имеет место быть, показалось достаточно забавным…
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.
совсем непонятна.
Первый — это Objective-C, как он может отставать от C# — на два десятка лет, если C# всего 14 лет?
Это подразумевается, что он старее? Типо старьё ))) Или что он с тех пор не развивался, а только в недавнее время стал развиваться?
Я C# к сожалению профессионально не занимался, но когда на курсах изучал, нам там прямо сказали, C# полностью всё ворует у Java и учиться на чужих, то есть java вских ошибках… Не знаю на сколько это имеет место быть, показалось достаточно забавным…
> C# полностью всё ворует у Java
хихи :) Пошутист!
Насколько я могу судить по результатам, дело было примерно так:
МС сделала Жабу на своей платформе. Потом стала её проприетарить. Сан обиделся и стал судиться. МС схлопнула проект, но исходники-то остались! И вот кому-то очень умному вступило переплюнуть Жабу. Как? Ведь Жаба — уже развитый язык и платформа. И МС решила сделать многоязыковую платформу! (взять количеством) Так что да, корни у C# вполне жабские. НО(!) в последущие годы шарп сделал ГРОМАДНЫЙ рывок вперёд! Такой, что Жаба осталась кашлять на обочине. В довесок, Вижуал Студия — тоже раз от разу всё хорошела, что писать код стало просто сказкой (я работал с этим 10 лет). В это время Жаба просто сидела в своём «интыпрайзе» и посмеивалась на «одноплатформенный дотнет», а когда ей сказали «подвинься», тут у неё пятки и загорелись! Тут же стали кипишиться, язык развивать… да куда там — поздно! Уже выросло поколение шарповодов, которые к жабе на километр не подойдут. Вот такие пироги…
Что в это время делала Эппл? СКРУГЛЯЛА УГЛЫ :) ОбжСи как был скобочным ужасом, так и остался до сих пор. Разработка визуальной части тоже, как видно, была в режиме «работает — и ладно!». Так что на сегодня по удобству и скорости VS+C# практически непревзойдённый инструмент.
хихи :) Пошутист!
Насколько я могу судить по результатам, дело было примерно так:
МС сделала Жабу на своей платформе. Потом стала её проприетарить. Сан обиделся и стал судиться. МС схлопнула проект, но исходники-то остались! И вот кому-то очень умному вступило переплюнуть Жабу. Как? Ведь Жаба — уже развитый язык и платформа. И МС решила сделать многоязыковую платформу! (взять количеством) Так что да, корни у C# вполне жабские. НО(!) в последущие годы шарп сделал ГРОМАДНЫЙ рывок вперёд! Такой, что Жаба осталась кашлять на обочине. В довесок, Вижуал Студия — тоже раз от разу всё хорошела, что писать код стало просто сказкой (я работал с этим 10 лет). В это время Жаба просто сидела в своём «интыпрайзе» и посмеивалась на «одноплатформенный дотнет», а когда ей сказали «подвинься», тут у неё пятки и загорелись! Тут же стали кипишиться, язык развивать… да куда там — поздно! Уже выросло поколение шарповодов, которые к жабе на километр не подойдут. Вот такие пироги…
Что в это время делала Эппл? СКРУГЛЯЛА УГЛЫ :) ОбжСи как был скобочным ужасом, так и остался до сих пор. Разработка визуальной части тоже, как видно, была в режиме «работает — и ладно!». Так что на сегодня по удобству и скорости VS+C# практически непревзойдённый инструмент.
Вы можете удалить классы StoreReply и AppInfo, для этого приложения хватит и JObject. :)
Вопрос к С# разработчикам:
При создании коммерческого ПО сейчас используются обфускаторы или сейчас все пошли на open source? Как они совмещаются с динамическим мета программированием? Можно часть кода оставить «чистым», а часть обфускарнуть?
Извините, если не по теме…
При создании коммерческого ПО сейчас используются обфускаторы или сейчас все пошли на open source? Как они совмещаются с динамическим мета программированием? Можно часть кода оставить «чистым», а часть обфускарнуть?
Извините, если не по теме…
Естественно используются обфускаторы.
Естественно большая их часть позволяет выбрать игнорируемые классы.
Естественно большая их часть позволяет выбрать игнорируемые классы.
1. Обфускаторы используются (зависит от паранойи, видел софт и без обфускации, все живы).
2. Обфускаторы настраиваются (очень детально, потому что усложняют некоторые сценарии).
3. Обфускаторы не защищают (см. de4dot и иже, .NET архитектурно нельзя хорошо защитить, ибо JIT).
4. Обфускаторы не нужны (в 99% софта 0% ноу-хау, всем на ваш говнокод пофиг, там без обфускатора чёрт ногу сломит).
2. Обфускаторы настраиваются (очень детально, потому что усложняют некоторые сценарии).
3. Обфускаторы не защищают (см. de4dot и иже, .NET архитектурно нельзя хорошо защитить, ибо JIT).
4. Обфускаторы не нужны (в 99% софта 0% ноу-хау, всем на ваш говнокод пофиг, там без обфускатора чёрт ногу сломит).
С таким инструментом точно не возникнет желания наполнять аппстор чем-то полезным — слишком уж дорого эта польза даётся. Напомню, это мнение программиста на WPF/WinForms, так что ждём ответов из стана Apple!
Ответ из стана Apple таков: нафиг вы нужны в AppStore со своим шлаком :) Лучше порадуйте mixen тем, что вам нравятся примочки С#, и как стек .net выгодно отличается от Swift/iOS. Наполняйте «чем-то полезным» Marketplace, т.к. даже earlyadopter-ы Windows Phone сидящие начиная с WP7 готовый уйти куда-то, из-за того, что приложения на Windows Phone в функциональном плане не дотягивают до аналогичных на конкурентных платформах.
А если серьёзно, то
Terminator 2 снят без C#, рефлекшенов и байдингов.
Doom2 написан без C#, рефлекшенов и байдингов.
Google написан без C#, рефлекшенов и байдингов.
Facebook написан без C#, рефлекшенов и байдингов.
iOS написан без C#, рефлекшенов и байдингов.
Instagram написан без C#, рефлекшенов и байдингов.
Windows 8 написан без C#, рефлекшенов и байдингов.
Куча программистов с приложениями в AppStore уже получила много $$$ без C#, рефлекшенов и байдингов.
Т.е. классные вещи можно сделать не завися от инструмента.
Как гик, я разделяю восторг от «магии» C#, но как apple-фил могу сказать, что цена этой магии = 0. Без какой-то реальной пользы для end-user-а, а не для программиста, всё это мелочность.
Холивор в коментариях выше для стана Apple, извините :), но выглядит примерно как знаменитое видео с разработчиками из Microsoft:
хо-хо-хо
Т.е. какой классный С# и какой плохой Swift :)
Только вот Microsoft с 1997 года всё больше и больше проявляет зависть к тому, как растёт база преданных пользователей Apple готовых нести свои $$$ в «секту», а Microsoft всё в офисах, энтепрайзах, биндингах, эктив дайрокти, и т.п.
>>Instagram написан без C#, рефлекшенов и байдингов.
Hello, world вообще можно написать на bash'e.
В Excel можно рисовать.
iOS интерфейс можно воссоздать в Word'e.
>>Куча программистов с приложениями в AppStore уже получила много $$$ без C#, рефлекшенов и байдингов.
не эти ли 20% разработчиков игр для App Store, которые получают 97% всех денег?
>>а Microsoft всё в офисах, энтепрайзах, биндингах, эктив дайрокти, и т.п.
похоже Вы не знаете объемы денег этих самих «энтепрайзах». Apple держится за счет большой маржи, которая неизвестно сколько продержится (извините за тавтологию).
Hello, world вообще можно написать на bash'e.
В Excel можно рисовать.
iOS интерфейс можно воссоздать в Word'e.
>>Куча программистов с приложениями в AppStore уже получила много $$$ без C#, рефлекшенов и байдингов.
не эти ли 20% разработчиков игр для App Store, которые получают 97% всех денег?
>>а Microsoft всё в офисах, энтепрайзах, биндингах, эктив дайрокти, и т.п.
похоже Вы не знаете объемы денег этих самих «энтепрайзах». Apple держится за счет большой маржи, которая неизвестно сколько продержится (извините за тавтологию).
не эти ли 20% разработчиков игр для App Store, которые получают 97% всех денег?1) Очень круто ссылаться в 2014 году на исследования 2011. Чуть-чуть свежая информация: 57% игр в магазинах приложений зарабатывают менее 500 долларов в месяц. но при этом 80% выручки в магазинах — от игр.
2) Эти 20% или другие, но пару недель назад тут, на Хабре, один из пользователей описывал свою историю, что разрабатывая игры по вечерам для Android, он имеет пассивный доход в $$$$.
похоже Вы не знаете объемы денег этих самих «энтепрайзах».Вопрос в том — сколько из них попадет к c# разработчикам :) А объёмы знаю, т.к. сам из этого мира.
Apple держится за счет большой маржи,У MSFT маржа в 2 раза больше.
которая неизвестно сколько продержитсяМожет IBM поможет? :)
ответил чуть ниже
Скажите, вы глупый или невнимательный? Я ожидал определённой доли непонимания, но не до такого же тупизма! Прочтите ещё раз, пожалуйста:
«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»
Пожалуй, придётся писать очень грустный постскриптум к посту. :((
(уже написал, вы бы ознакомились что ли)
«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»
Пожалуй, придётся писать очень грустный постскриптум к посту. :((
(уже написал, вы бы ознакомились что ли)
Т.е. а вы у нас такой умный и пушистый ставя желание разрабатывать приложения
в зависимость от возможностей/сложностей инструмента
не возникнет желания наполнять аппстор чем-то полезным — слишком уж дорого эта польза даётся.
в зависимость от возможностей/сложностей инструмента
Чего ж так сложно, господа?.. предложите ПРОСТОЙ СПОСОБ сделать аналогичное приложение. Если его нет — упаси небо, я никого винить не буду, будем считать, что Apple уделила недостаточное внимание удобству разработки
>> Чуть-чуть свежая информация: 57% игр в магазинах приложений зарабатывают менее 500 долларов в месяц. но при этом 80% выручки в магазинах — от игр.
ok, но $500 не является джек-потом :)
>>А объёмы знаю, т.к. сам из этого мира.
и я тоже :)
>>У MSFT маржа в 2 раза больше.
Apple проводит очень хитрую экономическую политику — выплаты налогов составляют где 10-12 % от валовой прибыли. причем, денежные фонды аккумулируются непонятно где (!!!). Сравните их прибыль (не выручку) и темпы накопления денежных фондов.
p.s.
и да MSFT (67.52%), AAPL (39.36%), что есть marge = 1.71 :)
ok, но $500 не является джек-потом :)
>>А объёмы знаю, т.к. сам из этого мира.
и я тоже :)
>>У MSFT маржа в 2 раза больше.
Apple проводит очень хитрую экономическую политику — выплаты налогов составляют где 10-12 % от валовой прибыли. причем, денежные фонды аккумулируются непонятно где (!!!). Сравните их прибыль (не выручку) и темпы накопления денежных фондов.
p.s.
и да MSFT (67.52%), AAPL (39.36%), что есть marge = 1.71 :)
промах
Посмотрел внимательно на верстку в статье, я бы за такое по рукам бил. На десктопе конечно много мегагерцев и оперативы, но для мобильного приложения верстка слишком усложнена.
Зачем тут все обернуто в DockPanel? Какой в этом смысл? Все это месиво из контейнеров нужно заменить одним!
Вот так, если нигде не ошибся:
<DockPanel LastChildFill="True">
<Grid Width="70">
<Image DockPanel.Dock="Left" Source="{Binding artworkUrl60}" /><!-- никакой ручной работы - изображение загрузится само! -->
</Grid>
<StackPanel Orientation="Vertical">
<TextBlock Text="{Binding trackName}" FontWeight="Bold" FontSize="20" Padding="4"/>
<TextBlock Text="{Binding formattedPrice}" FontSize="16" Padding="4" />
<Rectangle Stroke="LightGray" Height="2" Width="250" HorizontalAlignment="Center" />
</StackPanel>
</DockPanel>
Зачем тут все обернуто в DockPanel? Какой в этом смысл? Все это месиво из контейнеров нужно заменить одним!
Вот так, если нигде не ошибся:
<Grid Width="70">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="70"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<Image Grid.Rowspan="3" Source="{Binding artworkUrl60}" /><!-- никакой ручной работы - изображение загрузится само! -->
<TextBlock Grid.Column="1" Text="{Binding trackName}" FontWeight="Bold" FontSize="20" Padding="4"/>
<TextBlock Grid.Column="1" Grid.Row="1" Text="{Binding formattedPrice}" FontSize="16" Padding="4" />
<Rectangle Grid.Column="1" Grid.Row="2" Stroke="LightGray" Height="2" Width="250" HorizontalAlignment="Center" />
</Grid>
А вы меряли производительность? Картинка в гриде — это жесть, конечно, но вообще DockPanel и StackPanel несравнимо проще, чем Grid (в гриде 3000 строк кода, в DockPanel — 300).
Я говорил в первую очередь про мобильники. Там я производительность мерил и лишний вложенный контейнер дает нехилую нагрузку, особенно в темплейтах списков.
DockPanel, к сожалению, в WindowsPhone нет. Возможно с ним было бы и производительнее. Но как показывает профайлер, чем меньше вложенность, тем лучше.
DockPanel, к сожалению, в WindowsPhone нет. Возможно с ним было бы и производительнее. Но как показывает профайлер, чем меньше вложенность, тем лучше.
Ага, и плодить RowDefinition каждый раз, когда добавляем строку.
Дима, ты откуда такой крутой? Паспорт получил — теперь всё можно что ли? е****ло своё завали и когда впредь будешь ко мне обращаться, во-первых, постарайся употреблять местоимение «вы», а во-вторых, «по рукам» свою жену бей, я тебе сам такое отобью, всю жизнь приставными шагами ходить будешь! ОК?
Если хочешь дать ТЕХНИЧЕСКИЙ СОВЕТ, пыл свой поумерь, «20-летний сеньор», а потом напиши свои претензии в ВЕЖЛИВОЙ ФОРМЕ.
По сути претензии не буду ничего слушать, пока не увижу реальные бенчмарки «якобы» тормозящих контейнеров. Кроме того, прежде чем выёживаться, бельмы подыми и почитай — приложение ДЕСКТОПНОЕ, сделано на WPF. Никаких «мобильных» оптимизаций я даже не думал делать. Так что претензия дважды не в кассу.
Сиди, думай.
Если хочешь дать ТЕХНИЧЕСКИЙ СОВЕТ, пыл свой поумерь, «20-летний сеньор», а потом напиши свои претензии в ВЕЖЛИВОЙ ФОРМЕ.
По сути претензии не буду ничего слушать, пока не увижу реальные бенчмарки «якобы» тормозящих контейнеров. Кроме того, прежде чем выёживаться, бельмы подыми и почитай — приложение ДЕСКТОПНОЕ, сделано на WPF. Никаких «мобильных» оптимизаций я даже не думал делать. Так что претензия дважды не в кассу.
Сиди, думай.
Ну и зачем суицид после recovery-mode?
А был ли recovery? На откровенно холиварном топике-то? Я карму автора поглядывал из спортивного интереса, и непохоже, что она в какую-либо сторону ощутимо сдвинулась.
Ребят, чего вам моя карма? :) Это должно заботить хабровладельцев — когда адекватных авторов школота сливает. Не поменяют правила — останутся с тусой кармадрочеров, способных только лайкать (т.е. потреблять контент). А у меня есть ЖЖ — пусть почти не посещаемый, но с людьми, с которыми приятно общаться.
Я большой ценитель холиваров, культурного мордобоя и содержательных побоищ, поэтому слив кармы идеологических сторонников не может меня не беспокоить. Recovery mode работает только до определённого порога, и вы запросто можете через него перевалить (если уже не). Вам-то, конечно, пофиг, а я бы предпочёл иметь разносторонние топики и обсуждения на Хабре, а не ловить их по закоулкам нетематических блогов.
Приятно слышать, спасибо. Но мы, юзеры, просто игрушки в психологической машине «надрочи побольше карму». Эти крысиные бега с оглядкой «а что скажут хаброжители» не для людей, привыкших открыто выражать своё мнение.
Мне тоже нравится спорить и читать интересные топики, но чтобы общение на сайте приносило удовольствие, карма категорически не должна трогать моих свобод — количество комментов, «богатство форматирования», право голосования и т.п. Это я не вам говорю, а так, в робкой надежде быть услышаным.
Поэтому если хабр будет «выжимать» топики из юзеров, «отжимки» и получатся.
Мне тоже нравится спорить и читать интересные топики, но чтобы общение на сайте приносило удовольствие, карма категорически не должна трогать моих свобод — количество комментов, «богатство форматирования», право голосования и т.п. Это я не вам говорю, а так, в робкой надежде быть услышаным.
Поэтому если хабр будет «выжимать» топики из юзеров, «отжимки» и получатся.
Полностью Вас поддерживаю, в последнию неделю и моей кармы коснулась такая участь, вот подумываю наверно уйти с хабра, хотя иногда приличные люди тут встречаются :)
Уже была известная всем попытка: freehabr.ru
Тонкость в том, что без финансовой подпитки даже самый лучший ресурс стухнет. А там всё держится на одном человеке без спонсоров.
Я вижу последнюю надежду в том, что хабровладельцы наконец поймут, что их детские игры в кармомерство не являются главным двигателем ресурса.
Тонкость в том, что без финансовой подпитки даже самый лучший ресурс стухнет. А там всё держится на одном человеке без спонсоров.
Я вижу последнюю надежду в том, что хабровладельцы наконец поймут, что их детские игры в кармомерство не являются главным двигателем ресурса.
Поддержу. Зачем понижать карму, когда можно просто поставить отрицательный рейтинг комментарию?
Написал письмо в редакцию: пастебин слэш Pyv3LPE1
Во-первых, они бестолково суммируются
Наведите мышкой на само число.
Спасибо за подсказку! Вся ирония в том, что ХОРОШИЙ интерфейс не должен жить на подсказках — он сам должен быть подсказкой и максимально удобным. Так что нет, «наведи мышку» — не решение. Должны быть два числа и уже с них (попутно поменяв курсор мыши) чтобы можно было, например, посмотреть список голосовавших.
Я думаю, что коммент заминусовали за грубость, а не за собственное мнение, отличающееся от других. Все-таки «е**** завали» — это уровень необразованной гопоты, а никак не ученого человека, считаю, что на хабре дискуссии в такой форме недопустимы.
Сейчас, _когда_я_уже_остыл_, я тоже считаю, что ответил грубее, чем требовалось — ПРОШУ ПРОЩЕНИЯ.
В оправдание, у меня есть мой топик и куча ПОСТОРОННИХ комментариев, оставленных какими-то неадекватами с узколобым мышлением.
Вот сейчас, когда вы решили порассуждать, скажите, какова главная цель топика? А теперь пройдитесь по всем комментам и скажите, найдётся хотя бы пять комментов, ПО ДЕЛУ отвечающих на вопрос топика?
Заметьте: я — один, а штопаных комментаторов, решивших «блеснуть интеллектом» (как вот этот «отрыватель рук») — десятки! Троих олухов я ещё поставлю на место в вежливой форме, но я — человек, у меня тоже есть нервы. Более того — я — профессионал и по долгу службы общаюсь с людьми, примерно равными мне по уровню. Поэтому от людей общей со мной профессии я жду если не полного понимания, то хотя бы адекватных, аргументированных суждений. Ну и само собой, эти суждения не должны скатываться в наиглупейшие частности — люди должны уметь видеть ГЛАВНОЕ. Всё равно, что ты хвалишься собранным квадрокоптером, а потом набегает десяток кретинов и говорят: «у тебя лопасти плохо покрашены!» — вот так примерно я себя чувствую после ответов на, казалось бы, вполне однозначный топик. Как думаете, могу я немного приструнить этих «малолетних сеньоров», чтобы сначала думали, а потом писали? (см. постскриптум топика — СПЕЦИАЛЬНО попросил!)
Кстати, вот даже вы сейчас смотрите на один мой коммент, хотя проблему я поднял гораздо шире — неужто я так плохо выражаюсь, что вы не осознали широту проблемы? Вот про это и речь — я не обсуждаю с домохозяйками цвет щей, я хочу, чтобы люди мыслили глобально и конкретно, не в обиду вам будет сказано.
Или вот ещё каких-то два **** заминусятили моё «письмо в редакцию» — ответьте прямо здесь, ЧТО В НЁМ НЕПРАВИЛЬНОГО? Каким надо быть пустоголовым, чтобы не понимать, что Хабр _сейчас_ никак не способствует повышению качества статей? (и никак не защищает авторов от праздной школоты) Вот про то и речь — пишешь и думаешь: кому?.. зачем?..
В оправдание, у меня есть мой топик и куча ПОСТОРОННИХ комментариев, оставленных какими-то неадекватами с узколобым мышлением.
Вот сейчас, когда вы решили порассуждать, скажите, какова главная цель топика? А теперь пройдитесь по всем комментам и скажите, найдётся хотя бы пять комментов, ПО ДЕЛУ отвечающих на вопрос топика?
Заметьте: я — один, а штопаных комментаторов, решивших «блеснуть интеллектом» (как вот этот «отрыватель рук») — десятки! Троих олухов я ещё поставлю на место в вежливой форме, но я — человек, у меня тоже есть нервы. Более того — я — профессионал и по долгу службы общаюсь с людьми, примерно равными мне по уровню. Поэтому от людей общей со мной профессии я жду если не полного понимания, то хотя бы адекватных, аргументированных суждений. Ну и само собой, эти суждения не должны скатываться в наиглупейшие частности — люди должны уметь видеть ГЛАВНОЕ. Всё равно, что ты хвалишься собранным квадрокоптером, а потом набегает десяток кретинов и говорят: «у тебя лопасти плохо покрашены!» — вот так примерно я себя чувствую после ответов на, казалось бы, вполне однозначный топик. Как думаете, могу я немного приструнить этих «малолетних сеньоров», чтобы сначала думали, а потом писали? (см. постскриптум топика — СПЕЦИАЛЬНО попросил!)
Кстати, вот даже вы сейчас смотрите на один мой коммент, хотя проблему я поднял гораздо шире — неужто я так плохо выражаюсь, что вы не осознали широту проблемы? Вот про это и речь — я не обсуждаю с домохозяйками цвет щей, я хочу, чтобы люди мыслили глобально и конкретно, не в обиду вам будет сказано.
Или вот ещё каких-то два **** заминусятили моё «письмо в редакцию» — ответьте прямо здесь, ЧТО В НЁМ НЕПРАВИЛЬНОГО? Каким надо быть пустоголовым, чтобы не понимать, что Хабр _сейчас_ никак не способствует повышению качества статей? (и никак не защищает авторов от праздной школоты) Вот про то и речь — пишешь и думаешь: кому?.. зачем?..
Я написал где вы неправы. А вы проигнорировали.
А на что можно надеяться с топиком, который затрагивает только самые основы?
Могу предположить, что если бы был выложен туториал по созданию настоящего WPF-приложения, с mvvm типа Caliburn, IoC типа MEF, асинхронными репозиториями и юнитофворками, xaml-стилями, а то и всякими контрактами и WCF, это бы сразу отсекло здоровскую часть холиварщиков и остались бы только те, кому это интересно.
Если же цель была заинтересовать и показать преимущество технологии, то странно ожидать реакцию «да, это здорово, все, что я до этого писал на php/js/паскале — туфта, вот он, мой новый путь». А вот грубость этому никак не способствует. На самом деле и слова про «руки отрывать» тоже ошибочны. Но корень тут один — нежелание видеть и принимать/понимать точку зрения оппонента. Тут надо терпеливо и доходчиво объяснять, в чем плюсы и в чем минусы в каждом конкретном применении, а если этого не получается сделать — тогда смириться с тем, что не всем это нравится и кто-то продолжит писать приложения для айфонов, а кто-то — рассчетные программы на матлабе. Ну или отправлять на stackoverflow. Модель саморегуляции там более жесткая.
Могу предположить, что если бы был выложен туториал по созданию настоящего WPF-приложения, с mvvm типа Caliburn, IoC типа MEF, асинхронными репозиториями и юнитофворками, xaml-стилями, а то и всякими контрактами и WCF, это бы сразу отсекло здоровскую часть холиварщиков и остались бы только те, кому это интересно.
Если же цель была заинтересовать и показать преимущество технологии, то странно ожидать реакцию «да, это здорово, все, что я до этого писал на php/js/паскале — туфта, вот он, мой новый путь». А вот грубость этому никак не способствует. На самом деле и слова про «руки отрывать» тоже ошибочны. Но корень тут один — нежелание видеть и принимать/понимать точку зрения оппонента. Тут надо терпеливо и доходчиво объяснять, в чем плюсы и в чем минусы в каждом конкретном применении, а если этого не получается сделать — тогда смириться с тем, что не всем это нравится и кто-то продолжит писать приложения для айфонов, а кто-то — рассчетные программы на матлабе. Ну или отправлять на stackoverflow. Модель саморегуляции там более жесткая.
NeoNN, давайте перейдём на личности — для большей понятности: вот этот топик «Генерация схем для вышивания крестиком на WinPhone» — вы всерьёз думаете, что написали что-то фундаментальное? Встающие зрители с апплодисментами? ДАЛЕКО НЕ. Собственно, 90% топиков Хабра и есть подобного уровня лажа, без которой мир не станет хуже. Мой пост — ОЧЕВИДНО не самоучитель и я не понимаю, с какого похмелья вы решили, что я вам должен выкатывать «туториал по созданию настоящего WPF-приложения, с mvvm типа Caliburn». Ещё раз спрашиваю: вы СМЫСЛ топика поняли? Я не могу с вами переписькиваться, потому что карму обосрали, но вы говорите о чём-то своём, начисто игнорируя смысл оригинального поста — так мы взаимопонимания не добьёмся.
Прочтите ещё раз внимательно пост и скажите главный вопрос, который я в нём поднял — без понимания этого я не вижу смысла говорить о вещах, которые вы сами себе придумали и меня же в них обвиняете. ПОСТ — НОРМАЛЬНЫЙ, не хуже ваших крестиков, начните с осознания хотя бы этого — потом возвращайтесь к моему посту.
> Тут надо терпеливо и доходчиво…
Уже объяснял — школоте место В ШКОЛЕ, это там «терпеливо и доходчиво». «Здесь — взрослый мир, детка!» КАЖДАЯ профессиональная область требует определённых познаний. Нет знаний — ПРОХОДИ МИМО, значит этот топик не для тебя и не твоего уровня (простая мысль, да?). Но нет, «набИгают иксперды», чтобы пёрнуть в теме, в которой сами едва разбираются. Не противно такое наблюдать?
Прочтите ещё раз внимательно пост и скажите главный вопрос, который я в нём поднял — без понимания этого я не вижу смысла говорить о вещах, которые вы сами себе придумали и меня же в них обвиняете. ПОСТ — НОРМАЛЬНЫЙ, не хуже ваших крестиков, начните с осознания хотя бы этого — потом возвращайтесь к моему посту.
> Тут надо терпеливо и доходчиво…
Уже объяснял — школоте место В ШКОЛЕ, это там «терпеливо и доходчиво». «Здесь — взрослый мир, детка!» КАЖДАЯ профессиональная область требует определённых познаний. Нет знаний — ПРОХОДИ МИМО, значит этот топик не для тебя и не твоего уровня (простая мысль, да?). Но нет, «набИгают иксперды», чтобы пёрнуть в теме, в которой сами едва разбираются. Не противно такое наблюдать?
Странную тему вы выбрали, к тому же из неиндексируемого «я пиарюсь». Почему не «распознавание рукописного математического ввода», например, или «запись при помощи Directshow.Net»? Если переходить на личности, то я скажу, что судя по уровню общения вы очень едкий и злой и я не хотел бы с вами работать ни в одной команде, ни в одной компании. За сим прошу больше не писать.
> Ещё раз спрашиваю: вы СМЫСЛ топика поняли?
Судя по сливу, нет. Зачем тогда тратили моё время, а сейчас позорно прикрываетесь вменяемыми мне качествами? Заметьте — я ни слова не сказал ни про вас как человека, ни про то, что ваш топик хуже — он одинаково поверхностный со всеми. И уж точно не лучше моего — это просто как пример того, что вы просите больше, чем сами умеете.
Я _иногда_ едкий, но уж точно не глупый — потому и раздражает тупая посредственность.
Спасибо, что больше не прикидываетесь серьёзным, размышляющим человеком. ;]
Судя по сливу, нет. Зачем тогда тратили моё время, а сейчас позорно прикрываетесь вменяемыми мне качествами? Заметьте — я ни слова не сказал ни про вас как человека, ни про то, что ваш топик хуже — он одинаково поверхностный со всеми. И уж точно не лучше моего — это просто как пример того, что вы просите больше, чем сами умеете.
Я _иногда_ едкий, но уж точно не глупый — потому и раздражает тупая посредственность.
Спасибо, что больше не прикидываетесь серьёзным, размышляющим человеком. ;]
Миша, бить по рукам это идиома. Да тут она лишняя извини. Но и принимать её так близко к сердцу не стоит.
Насчёт WPF. Выше уже не однократно писали, что сравнивать iOS с десктопом по меньшей мере некорректно. Тем более, что есть windows phone. (Хотя честно говоря, коллеги, которые работали с маком, говорят что там все ещё хуже, чем в iOS).
Насчёт тестов. Могу попробовать показать результаты профилировщика, но это не раньше следующей недели.
Насчёт WPF. Выше уже не однократно писали, что сравнивать iOS с десктопом по меньшей мере некорректно. Тем более, что есть windows phone. (Хотя честно говоря, коллеги, которые работали с маком, говорят что там все ещё хуже, чем в iOS).
Насчёт тестов. Могу попробовать показать результаты профилировщика, но это не раньше следующей недели.
Дима, вы пояснение читали? Я всё никак не могу донести простую мысль (или вы, в своём упоении «некорректностью сравнения» не хотите слушать). Давайте я разжую как для детсада:
Мы сравниваем ДВА РАЗНЫХ ПУТИ к ОДНОЙ ЦЕЛИ. Нам нужно перевезти человека из А в Б. У нас есть F1 и Белаз. Человек садится в каждую из машин и едет. В пункте Б мы спрашиваем: «насколько легко было преодолеть это расстояние?». Очевидно, что с Белазом всё было намного сложнее. Итак, что неправильного в использовании этих двух машин?? Разные рули штоле?
Мы сравниваем ДВА РАЗНЫХ ПУТИ к ОДНОЙ ЦЕЛИ. Нам нужно перевезти человека из А в Б. У нас есть F1 и Белаз. Человек садится в каждую из машин и едет. В пункте Б мы спрашиваем: «насколько легко было преодолеть это расстояние?». Очевидно, что с Белазом всё было намного сложнее. Итак, что неправильного в использовании этих двух машин?? Разные рули штоле?
Вы привели прекрасное сравнение. Замечательное, мне нравится. Вот только вы по-умолчанию, почему-то, едете по гоночной трассе. Я же предлагаю сравнивать Белаз с Камазом на бездорожье, а Феррари с Макларен на трассе.
Это ваши личные додумки. Пути — два, а значит каждый может ехать именно там, где ему удобно. Разве я заставляю разрабов iOS писать из-под DOS? Нет. Они вольны в своём выборе. Вот и WPF волен писаться под Windows. Запомните, здесь одна — только ЦЕЛЬ — браузер аппсторовских приложений. Это именно то, что видит ПОЛЬЗОВАТЕЛЬ. Ему пофиг, ехали вы по бездорожью или гребли руками — перед ним должен быть список приложений и строка поиска, всё. Как вы этого добились — он не только не видит, но и не желает знать. Это-то понятно?
Покажите мне хоть одного пользователя который видел WPF приложение в Appstore. Ну хотя бы на картинке. Я даже не прошу показать само приложение.
Вот вы опять путаете, пути, машины. Если вы хотите показать как на WPF круто делать именно такие приложения вне зависимости от платформы, то найдется пара конструкторов, на которых это можно сделать вообще без программирования. И WPF оказывается в лузерах.
А вот если я вас попрошу сделать на список контактов как в iOS то тут вам либо писать кучу кода, либо искать дополнительные библиотеки, когда в iOS это всего лишь написать 3-4 метода на 3 строчки.
Пользователю не пофиг где работает приложение.
И заметьте, я не спорю, что UIKit'у иногда не хватает каких-то простых вещей вроде СтекПанели, но и всю мощь WPF вместить в телефон не получилось даже у MS
А вот если я вас попрошу сделать на список контактов как в iOS то тут вам либо писать кучу кода, либо искать дополнительные библиотеки, когда в iOS это всего лишь написать 3-4 метода на 3 строчки.
Пользователю не пофиг где работает приложение.
И заметьте, я не спорю, что UIKit'у иногда не хватает каких-то простых вещей вроде СтекПанели, но и всю мощь WPF вместить в телефон не получилось даже у MS
Спасибо, поржал. То есть сейчас вы мне объясняете смысл моей же статьи?? Может, пора уже осознать, что вы стучитесь в стену, хотя вас упорно тащат в калитку?
> то найдется пара конструкторов
И ЧТО? Ну найдётся, разве это плохо? Чем от этого WPF решение стало хуже-то?
> сделать на список контактов как в iOS
Что тут грамматически делает предлог «на»?
Функция «список контактов» — это просто список контактов, сделаю без проблем. Ключевой вопрос здесь (и в статье) — то, какой кровью обходится создание каждой фичи. Я уже всем показал, что WPF'ный вариант на порядок проще и это объективная реальность. Вы же продолжаете натягивать какие-то невразумительные условия, когда речь всего-лишь про функцию «браузер аппстора». Я понимаю, вам трудно принять факт выйгрыша WPF — хотите, дам телефон хорошего психиатора?
> но и всю мощь WPF вместить в телефон не получилось даже у MS
Да мне наплевать, что там «вмещал» мелкософт — посмотрите на приложение — вы видите в нём какие-то гипертяжёлые, сугубо «десктопные» фичи, которые нереально сделать в телефоне? Вот и я не вижу.
О чём мы спорим? Что вы никак не можете абстрагироваться от платформы, чтобы понять, что сделано идентичное приложение? Ну почитайте теоретиков что ли… не всё же по уши в коде торчать!
> то найдется пара конструкторов
И ЧТО? Ну найдётся, разве это плохо? Чем от этого WPF решение стало хуже-то?
> сделать на список контактов как в iOS
Что тут грамматически делает предлог «на»?
Функция «список контактов» — это просто список контактов, сделаю без проблем. Ключевой вопрос здесь (и в статье) — то, какой кровью обходится создание каждой фичи. Я уже всем показал, что WPF'ный вариант на порядок проще и это объективная реальность. Вы же продолжаете натягивать какие-то невразумительные условия, когда речь всего-лишь про функцию «браузер аппстора». Я понимаю, вам трудно принять факт выйгрыша WPF — хотите, дам телефон хорошего психиатора?
> но и всю мощь WPF вместить в телефон не получилось даже у MS
Да мне наплевать, что там «вмещал» мелкософт — посмотрите на приложение — вы видите в нём какие-то гипертяжёлые, сугубо «десктопные» фичи, которые нереально сделать в телефоне? Вот и я не вижу.
О чём мы спорим? Что вы никак не можете абстрагироваться от платформы, чтобы понять, что сделано идентичное приложение? Ну почитайте теоретиков что ли… не всё же по уши в коде торчать!
Вы сравниваете не понятно что не понятно с чем. Взяли какой-то говнокод-хрень-пример и написали «тот же функционал» на другом языке какбэ. Слишком сложно для «упрощенного» языка говорите было? А вы знаете в чём «упрощенность» Swift чтобы сравнивать? И вообще что такое «упрощенность» в ЯП чтобы как то её определять? И почему вы сравниваете технологии, фреймворки, инструменты, а не возможности языков, а говорите о языках? Мне кажется вы попытались найти плёвую лазейку для своей мании величия, а попались на свою неграмотность в постановке цели. Отличное сравнение, поздравляю!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
iOS vs WPF — сложное против мелкомягкого