cigan Jul 29 2014 at 05:02

iOS vs WPF — сложное против мелкомягкого

5 min

29K

Programming*.NET*Swift*

Recovery Mode

+43

204

Comments 204

NayZaK Jul 29 2014 at 06:04

Верстать на iOS — боль. Посему Xamarin Forms оказался находкой. Еще сыро, местами приходится долго и мучительно обходить стандартное поведение компонентов. Особенно когда у разработчиков Xamarin Forms ООП головного мозга, и огромная часть реализации компонентов скрыта от пользователя с помощью private, internal, в следствии чего просто взять переопределить метод неполучится, но бывает спасает шарповская магия. Но ради XAML можно и помучаться на старте.

corristo Jul 29 2014 at 08:01

Начиная с Xcode 5.1 «верстать» с автолэйаутом вполне удобно

NayZaK Jul 29 2014 at 08:24

Это да, но все равно неочевидность этих автолэйаутов зашкаливает. Да и посмотрите, как constraints описываются ручками. И еще момент. В сториборде рисовать — это, конечно, здорово но ради элементарной кастомизации внешнего вида кнопки нужно лезть в императивный код. При этом с завистью смотришь на веб-разработчиков, на WP и андроид (именно в плане описания UI).

corristo Jul 29 2014 at 08:35

Да и посмотрите, как constraints описываются ручками.

На Swift, кстати, вполне приятно описываются: github.com/robb/Cartography.

но ради элементарной кастомизации внешнего вида кнопки нужно лезть в императивный код

UIAppearance же, основную массу кастомизации можно локализовать и поддерживать в одном месте.

Про WP/Android не скажу, толком не работал с ними, но веб-разработчикам завидовать, извините, не получается.

UFO just landed and posted this here

ad1Dima Jul 29 2014 at 09:16

Только вот Xamarin.Forms нехило так отличается от WPF

webself Jul 29 2014 at 08:00

Может с написанием кода все так и есть, но значимым фактом это станет не ранее того, как доля виндофонов вырастет до хоть сколько то заметной величины на фоне айфонов…

TimeCoder Jul 29 2014 at 08:14

Так xamarin же. Нет?

webself Jul 29 2014 at 08:16

Ну в статье же речь о WPF идет, а не о ксамарине. Я про сравнение удобства нативной разработки.

TimeCoder Jul 29 2014 at 08:25

Нативная разработка, надеюсь, постепенно уйдет в прошлое. В том смысле, что можно выбрать себе язык + фреймворк, и писать под все платформы. Примерно как сейчас С++ Qt, и с некоторой натяжкой web.

webself Jul 29 2014 at 08:27

Да вот как-то не похоже на то. Сам phonegap использую, несколько ориентируюсь.

ad1Dima Jul 29 2014 at 09:57

Phonegap хорош в нескольких случаях(особенно учитывая количество поддерживаемых платформ), но, в основном, далеко не самое лучшее стредство для кроссплатформенной разработки.

ncix Jul 30 2014 at 00:53

Примерно как сейчас С++ Qt

Ну я пробовал на Qt писать под Андроид! Да, это реально работает и совсем несложно. Но. Получившееся приложение — во первых знать ничего не желает о стилях, размере экрана, DPI и прочих нюансах интерфейса. Во-вторых практически ничего не может сделать с ОС — даже банальный Intent кинуть. Да можно, сделать гибридное приложение. Или использовать ужасный JNI. Но в чем тогда профит от кроссплатформенности? Мобильное приложение это процентов на 90 UI и связанные с ним вещи. А UI на сегодняшний момент, извините, только нативно можно сделать качественным и конкурентоспособным.

ad1Dima Jul 30 2014 at 06:46

Кроме UI, есть ещё работа с сервисом, которая не зависит от платформы. Хранение данных, которое тоже не слишком-то зависит от платформы. Бизнес-логика, которая у большинства приложений от платформы зависит не сильно (хотя тут, конечно много исключений).

Если в вашем приложении главное UI — интерфейс, конечно, лучше писать нативно (системными средствами). Но при этом, все ещё можно использовать, к примеру Xamarin. Тут надо для каждого приложения в отдельности решать, оправдывает ли соотношение общей логики к платформозависимой части использование кроссплатформенных движков, или нет.

Кроме того, для многих приложений вполне оправдано применение phonegap, где о нативности интерфейса вообще речи нет. Например у IBM есть корпоративные решения построенные на его основе.

ncix Jul 30 2014 at 11:48

Кроме UI, есть ещё работа с сервисом, которая не зависит от платформы. Хранение данных, которое тоже не слишком-то зависит от платформы. Бизнес-логика, которая у большинства приложений от платформы зависит не сильно

Это и есть 10% трудозатрат.

Конечно, я уверен, есть приложения где эта цифра достигает 50%, там наверное имеет смысл.

Кроме того, для многих приложений вполне оправдано применение phonegap, где о нативности интерфейса вообще речи нет.

На PhoneGap можно делать нативно выглядящий интерфейс — есть соответствующие виджеты. И да, в ряде случаев кроссплатформенные средства действительно предпочтительнее, я об этом недавно писал: habrahabr.ru/post/229559/#comment_7772177

TimeCoder Jul 30 2014 at 08:28

Я имел ввиду кросплатформенность среди «целевых» платформ. Т.е. в случае Qt это возможность написать программу (desktop), которая скомпилируется под винду, мак, линукс. В случае html — это разные браузеры под разными ОС. Создать язык (и фрэймворк), который позволит писать программы вообще для всего (десктоп, мобаил, веб) — это вряд ли пока возможно, цена за универсальность будет высокой.

ncix Jul 30 2014 at 11:53

Я имел ввиду кросплатформенность среди «целевых» платформ. Т.е. в случае Qt это возможность написать программу (desktop)

Справедливости ради, Qt когда-то развивался именно как мобильный инструмент — для Symbian. Сейчас да, десктоп

Создать язык (и фрэймворк), который позволит писать программы вообще для всего (десктоп, мобаил, веб) — это вряд ли пока возможно, цена за универсальность будет высокой.

Может и хорошо — есть конкуренция технологий, есть развитие. Хотя конечно было бы здорово иметь один мощный язык для всего.

SZolotov Jul 30 2014 at 20:23

Справедливости ради, Qt когда-то развивался именно как мобильный инструмент — для Symbian. Сейчас да, десктоп

Вот уж не нужно. Когда начали разрабатывать Qt, мобильные телефоны только начинали распространяться в массы. А то что НОКИА купила QT и сбоку прилепила Mobile SDK — это еще не повод делать такие глобальные выводы.

ncix Jul 30 2014 at 21:47

Я специально написал «развивался» а нe «создавался». Вы же не будете отрицать что во времена нокии Qt развивался, и весьма активно.

TimeCoder Jul 29 2014 at 08:18

Хороший пример, подтверждающий, что .net (и WPF в частности) — удобная штука. Для меня остается загадкой только одно: почему применение C# до сих пор ограничено практически только одним Enterprise…

Newbilius Jul 29 2014 at 08:22

{удалено}

UFO just landed and posted this here

TimeCoder Jul 29 2014 at 08:30

Часто используемых где?) При разработке внутреннего софта компаний, реализующего бизнес-процессы (т.е. Enterprise). Да, где-то WinForms, но все больше WPF (кроме США, у них WPF почему-то не любят). Mono — не очень популярен, имхо. Вы много видели популярных (не внутрекорпоративных) программ на C#? Игры, и другие высокопроизводительные приложения (CAD, обработка видео и пр.) еще как-то понятно почему (и то в умелых руках C# может работать резво). Но берем что угодно другое: редакторы, файловые менеджеры, мессенджеры, почтовые клиенты, утилитки всякие, переводчики, и прочие няшки — все это практически всегда C++ или Delphi. Почему?

agranom555 Jul 29 2014 at 08:37

Тот же Autocad на wpf написан частично по крайне мере.

outcoldman Jul 29 2014 at 09:02

Autocad и Visual Studio — это два примера приложений написанных на WPF. Все. Более того, я предполагаю, что Autocad написан на WPF так же, как и сама Visual Studio, что там только XAML parser и core используется, а все контролы и окна свои.

EpeTuK Jul 29 2014 at 10:01

удалено, ответ не по сути комментария

int19h Jul 30 2014 at 03:38

>> там только XAML parser и core используется, а все контролы и окна свои.

В случае VS это не так. Там свои тулбары и меню (хотя и то не с нуля, а сильно кастомизованные — штатными средствами, через наследовение и шаблоны — стандартные контролы). Потом tool windows (рамка), и все, что связано с их докингом. Редактор, разумеется.

Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема (которую может легко подключить себе любое расширение).

outcoldman Jul 30 2014 at 06:02

Это я и имел ввиду, под WPF Core я имел ввиду все уровня FrameworkElement.

> Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема

Команды без проблем могут использовать все прелести WPF. Для этого, на сколько я понимаю, Visual Studio и переписывали на WPF, чтобы командам было проще. Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.

int19h Jul 30 2014 at 08:21

>> Команды без проблем могут использовать все прелести 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») практически все контролы — самые обычные.

outcoldman Jul 30 2014 at 10:55

Точно VS Platform Shell team.

> Насчет остального же у вас неверная информация.

Ну ок. 2 года назад с этим работал. В любом случае, удачи там.

> Плюс появились куски на HTML5.

Ага, я как раз был в одной из команд, которые пилили эти первые куски. ;)

bmforce Jul 30 2014 at 11:02

Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.

Помню как после обновления IE с 6 до 8 версии визарды перестали работать, выкидывая браузерную ошибку. Спас hotfix.

Keeperovod Jul 29 2014 at 11:30

Как бы Unity 3D. Один из самых популярных движков для разработки игр. Построен на базе mono. Основной язык — C#. Разработка для всех больших платформ и мобильников. Проходил слух про нативный шарп на PS4. Все консоли MS поддерживают разработку на шарпе. В мире игр C# играет очень заметную роль.

Недавно была статистика, что 17% рунета это ASP.NET. Да, это не 80% PHP, но это дикий перевес над любыми другими платформами.

В общем, C# используется очень много где. Просто об этом не все задумываются.

TimeCoder Jul 29 2014 at 19:07

17% ASP
80% PHP
Вы хотите сказать, что Java, Ruby и Python вместе взятые — всего 3%? o_O

Keeperovod Jul 30 2014 at 11:23

Да. Именно так. Ссылки есть в комментарии ниже.

GrigoryPerepechko Jul 30 2014 at 10:53

Пруф про 17% киньте. Попахивает наглым пиз##жом

Keeperovod Jul 30 2014 at 11:22

Пришлось напрячься, чтобы вспомнить, где видел: линк. В общем, мопед не мой, вопросы следует задавать автору топика по ссылке.

Но если погуглить по «ASP.NET Share», то по первой же ссылке получаем 17.2%.

Keeperovod Jul 30 2014 at 11:26

Не успел отредактировать предыдущий пост. По этой статистике у ASP.NET 28.2%, PHP 70.7, а остальные делят жалкие 1.1%

GrigoryPerepechko Jul 30 2014 at 11:42

Глянул по линку. Таем указано что nytimes.com написан на ASP.NET, а там apache и php.
Интересно, у них там вся статистика собрана так?

Еще забавно что по второй ссылке доля IIS — 13%, а ASP.NET — 28%.
Они на апаче ASP.NET сайты заводят?

exvel Jul 30 2014 at 16:40

www.mono-project.com/ASP.NET

xakpc Jul 29 2014 at 18:00

Про XNA не забывайте

Headmast Jul 30 2014 at 00:25

Хна умерла, пусть живет моно…

Mairon Jul 29 2014 at 23:55

Как минимум, на мобильных платформах C# обычно на 4-5 месте после JavaScript, Java, Objective-C, C/C++.

NayZaK Jul 29 2014 at 08:26

Всю жизнь думал, что там Java всех задавила.

TimeCoder Jul 29 2014 at 08:34

Не, в Enterprise примерно 50/50 Java и C#. Пропорция немного разная в России, США и Европе, но в целом C# довольно популярен, и популярность растет. Есть даже и такое мнение.

ncix Jul 30 2014 at 00:57

в Enterprise примерно 50/50 Java и C#

Да прям, как будто больше ничего нет.

Пропорция немного разная в России, США и Европе

Угу, в России 80% Enterprise'а это 1С. Остальные жалкие крохи делят от мэйнстримовых Java и C# до динозавров вроде Delphi 7 и даже FoxPro.

marshinov Jul 30 2014 at 16:09

Не WPFом единым. Жду не дождусь ASP.NET vNEXT (http://www.asp.net/vnext)

corristo Jul 29 2014 at 08:38

WPF, конечно, здорово выглядит в данном конкретном примере.

Что насчёт «реальных приложений»? Как поведет себя автоматическое скачивание изображений, когда вам нужно будет ресайзить картинку налету в несколько типоразмеров, сохранять в кастомный кэш, и т.д.?

DragonFire Jul 29 2014 at 08:57

Чуть больше кода, но ни как не простыни =)

ad1Dima Jul 29 2014 at 09:17

Для этих задач есть конвертеры, поведения и триггеры.

Maxmyd Jul 29 2014 at 12:09

ресайзить картинку налету в несколько типоразмеров

Два действия: подписка на одно событие и внутри метода подгрузка сообщений в зависимости от конечного размера контейнера.

сохранять в кастомный кэш


ObjectCache cache = MemoryCache.Default;
string fileContents = cache["filecontents"] as string;

Ну, и т.д., соответственно

cigan Jul 29 2014 at 13:11

Когда зайдёт речь о реальных приложениях, тогда НЕЗАВИСИМО от технологии/языка, вам придётся применить весь свой интеллект, чтобы оптимизировать проблемные места.
Мой пример — даже не competition, а вообще попытка сваять что-то похожее — я подозревал, что будет проще и короче, но не настолько. :)

outcoldman Jul 29 2014 at 09:08

Так и хочется спросить: А толку? :)

Дело в том, что в Microsoft уж очень все проработано в плане красивых и быстрых примеров. А как на деле начнешь что-то более или менее серьезное писать, там то и начинаются проблемы… И все становится в разы сразу сложнее. Понятия не имею, так ли дело обстоит с Swift & Apple. Просто хотелось дополнить.

ad1Dima Jul 29 2014 at 09:19

У эпл верстка сильно напоминает WinForms. Очень не хватает простых контейнеров. Таблица — очень мощный контрол, но чересчур уж сложный для простых случаев. И я сейчас очень опасаюсь так называемых Varible Sizes девайсов в iOS8

TimeCoder Jul 29 2014 at 09:25

Как-то очень обще звучит. 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 — это не «более-менее серьезное», тогда что? Софт для адронного коллайдера? Или ИИ?

outcoldman Jul 29 2014 at 10:45

Про «более-менее серьезное», наверное, не совсем верно выразился. Enterprise soft — это, конечно же, серьезно. Серьезно в плане разработки, но не в плане технологий и отступа от стандартов платформ и фреймворков. Если понимаете о чем я.

jakobz Jul 29 2014 at 12:23

Очень голословное утверждение.

C# и .NET — весьма приятная платформа для разработки. На нем пишут серьезный софт, и проблем там начинается как минимум не больше, чем где-то еще. В минусы .NET можно записывать привязку к платформе, и много чего еще можно наскрести. Но точно не «Microsoft хочет всех одурачить красивыми примерчиками, а на деле C#-говно». Все там очень хорошо и со сложными приложениями, и куча написанного на .NET софта это подтверждает.

Конкретно в данном сравнении видно что:
— у Swift пока имеются проблемы с работой с legacy-API от objC, который динамический, и плохо работает вместе со статически-типизированным языком. Все вот эти NSDictionary явно выглядят чужеродными.
— сами эти API не самые удобные — та же работа с http, или обработка ошибок сделана ближе к C, и требует много рутинного кода
— десериализация JSON делается врукопашную
— в Swift идет рукопашная работа с асинхронным кодом, через колбеки

Учитывая что задачи в примерах весьма типовые, вполне можно сделать определенные выводы. Мне кажется что пока Apple не напишет нормальные обертки для своих нетипизированных API, и пока Swift не обрастет жирком библиотек, C# и .NET выглядят куда более в выгодном свете.

corristo Jul 29 2014 at 12:33

дополню про коллбэки: основная масса асинхронных проблем решается с помощью promise-библиотек или ReactiveCocoa.

C#, конечно, однозначно круче в этом плане (async/await, LINQ), просто хотелось уточнить, что мы тут тоже не по уши в лапше погрязли.

szKarlen Jul 29 2014 at 21:56

хотелось бы побольше конкретики, но ладно )

Вы имели ввиду WPF в целом? тогда могу согласиться — некоторые очевидные вещи могут превратиться в серьезное углубление и управление как Visual Tree, так и Logical Tree.

Однако! Если мы рассматриваем тот же ASP.NET (и MVC), то инфраструктура просто замечательная. возможности расширения практически везде.
Vendor lock-in отсутствует вовсе.

Нужно написать распределенный рантайм для обработки данных? Берите C#, Reactive Extensions + ваша фантазия.
Думаю последний пункт можно отнести к любому языку/платформе/ваше_определение.

Просто C# и .NET намного (!!!) удобнее и более проработаны в плане синтаксиса, архитектуры, чем конкуренты.
А семимильное развитие дает ощущение новизны.

int19h Jul 30 2014 at 03:41

WPF как раз наглядный пример оверинжиниринга — там очень много всего под капотом для того, чтобы стандартные средства были настолько гибкими, что покрывали даже самые безумные сценарии (ну, например, если вам нужен текстбокс внутри нажимабельной кнопки, это делается в две строчки). Плюс к этому очень много extensibility везде. Так что как раз на полноразмерных примерах он раскрывается в полную силу.

Грустно, что Silverlight и Windows XAML далеко не такие гибкие, несмотря на внешнее сходство.

NeoNN Jul 29 2014 at 09:20

Это все банальности, даже mvvm не панацея в некоторых случаях. Вот например, чтобы сделать самое простое — множественный выбор из DataGrid, уже не забиндишь SelectedItems на коллекцию, придется либо делать это в code-behind, либо использовать Interactivity, либо свои велосипеды писать. И чем дальше пишешь, тем больше сталкиваешься с этим.

exvel Jul 29 2014 at 09:35

Не вижу проблем в использовании Interactivity и Code Behind для таких частных случаев.
Ни одна платформа не может предложить готовые решения на все случаи жизни.

exvel Jul 29 2014 at 10:08

Кстати, постил behaviour для решения подобных проблем: habrahabr.ru/post/215249/
Как по мне, можно один раз сделать behaviour и больше не париться.

Код

XAML:

<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);
        }
    }
}

kosmos89 Jul 29 2014 at 12:40

А причем здесь MVVM? MVVM — это архитектура, которая не привязана вообще к MS и WPF. DataGrid — это какой-то частный контрол. Если чем-то не устраивает — напишите свой или найдите/купите подходящий в интернетах.

sidristij Jul 29 2014 at 09:35

Кстати, на Xamarin есть либа, Appercode, что есть WPF под iOS/Android. Сам не трогал, но делают наши. Если что, можно по-русски пожучить в скайпе =)

ad1Dima Jul 29 2014 at 09:50

Оххх… Можно и тут пожучить так-то. Но лучше в личке…

sidristij Jul 29 2014 at 09:59

Я-то не собираюсь, поводов нету пока что =) Я имел ввиду иметь доступ к нативно говорящему саппорту всегда хорошо =)

Nagg Jul 29 2014 at 11:29

Что вы думаете о Xamarin.Forms с их xaml дизайнером, ведь по сути они отбирают у вас хлеб, нет? :-)

ad1Dima Jul 29 2014 at 12:03

1) мы, как сказали выше, пытаемся сделать вёрстку привычную для Silverlight/WPF разработчиков
2) денег мы за Appercode брать не планируем, так что хлеб отобрать в этом смысле трудно.

Nagg Jul 29 2014 at 12:22

1) ну там тоже верстка привычная для WPF, нет?
2) ну я имею ввиду целесообразность какая использовать ваш продукт, а не xamarin.forms?

ad1Dima Jul 29 2014 at 13:08

1) простой пример: аналогом свойства Height в Xamarin.Forms будет HeightRequest, Там нельзя сделать ScrollView, который будет скролиться по 2м направлениям (из-за ограничений андроида). Таких мелочей наберётся достаточно. Мы же стремимся обеспечить возможность копирования верески из WindowsPhone в Appercode с минимальными правками. Хотя у нас тоже есть куча проблем.

2) каждый выбирает для себя. Мы Appercode делаем тоже в первую очередь для внутреннего проекта. Ну и, как сказал выше, возможность применения знаний, которые уже есть, с минимальным изучением документации.

UFO just landed and posted this here

jakobz Jul 29 2014 at 10:57

Ну, там C# со Swift сравнивается коственно. Ту же сериализацию на Swift также как в C# не сделать — там нет нужных фич. Причем в C# еще и код типизированный получается.

В целом для C#-проектов типично применение подобного метапрограммирования — сериализация, работа с БД, удобняшки на аттрибутах. Как писать без этого большие приложения — мне лично не ясно. Данные из БД достали — и тоже руками по объектам их раскладывать что-ли? Типа person.Name = resultSet[«person_name»]?

corristo Jul 29 2014 at 11:06

В Swift с типизацией все прекрасно, каких таких фич нет в Swift?

jakobz Jul 29 2014 at 11:26

Интроспекция кода (рефлекшн) нужна. Либо макросы, либо что-то еще в 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.

corristo Jul 29 2014 at 11:35

про интроспекцию и рефлексию я с вами полностью согласен, но это никакого отношения к системе типов не имеет.

jakobz Jul 29 2014 at 11:41

Про типизацию я имел ввиду то, что в примере на Swift с JSON работают нетипизированно — через что-то типа JSON DOM, доставая поля и вложенные массивы по их имени. Вызвано это не отсутствием типов, конечно.

GrigoryPerepechko Jul 30 2014 at 11:14

runtime codegen на ios запрещен, поэтому если писать на C# под Monotouch будет рефлекш повсюду в десериализации, скорость будет просто слезная. Тут можно долго рассуждать об удобствах дотнетов, только классические варианты с кодегеном десериализатора перед компиляцией порвут любой дотнетовский rtti-based подход по скорости раз в 5.

jakobz Jul 30 2014 at 11:42

Если сравнивать компилированный вариант с рефлекшном — он порвет, да. Если с генерацией байткода — зависит от того насколько будет ли эффективнее компилятор дотнетовского JIT-а. Но разница будет уже не принципиальная.

Короче то что есть сейчас в Swift для сериализации — печаль-печаль. В будущем скорее всего будет генерация в compile-time, она может будет и пошустрее, но точно менее удобная.

cigan Jul 29 2014 at 14:17

Дело в том, что я в разработке под Apple вообще ни бум-бум, можете вместо iOS подставить любое правильное слово. Но чтобы понять смысл поста, почитайте оригинальный tutorial (в посте есть ссылка) и сравните с тем, как абсолютно такое же приложение пишется на WPF/C#.

> К тому же на задаче уровня Hello World

Вот тут не надо! Задача очень даже реальная: UI+INet. UI сделан гибким, используются байндинги, модели, сервис аппстора. То есть подобные элементы вы найдёте почти в каждом сетевом приложении. Оно простое, но просто обвешивая его дополнительным функционалом (не меняя общей структуры!) можно написать вполне коммерческое ПО. Даже автор сам пишет: «На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View». По-моему, на таких базовых знаниях можно половину приложений сделать — чем тут «хелловорлд»??

Я вряд ли буду тратить время на создание «ещё более впечатляющего» приложения, показывающего преимущество WPF, вы сами можете всё сравнить — напишите Swift приложение и его аналог на WPF, могу помочь в проблемных местах с WPF — тогда сразу увидите разницу.

Demtriy Jul 29 2014 at 10:07

Это было бы честным сравнением, если бы Автор свою поделку еще запустил на iOS девайсе. А так это сравнение ракетки и ракеты. Относительно количества кода — для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF, а уж бинарный файл и того меньше на порядки (для C# нужно еще .Net framework установить в каталог с приложением). Это не говоря уж о том, что Swift короче Objective-C, а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.

impwx Jul 29 2014 at 10:56

.Net framework установить в каталог с приложением

Куда-куда установить?
На большинстве современных систем .net framework давно стоит по умолчанию, или скачивается из интернета инсталлятором.

Demtriy Jul 29 2014 at 11:12

На IOS как Вы его установите? Даже на OSX. Видимо, Вы это никогда не делали. ВЕСЬ Mono/Monotouch укладывается в каталог приложения.

cigan Jul 29 2014 at 15:18

Причём тут WPF и iOS?? Вы совсем не понимаете что и с чем я сравниваю? Оторвитесь от платформ вообще, взгляните на приложение как на абстрактную утилиту, которая делает свою работу. Её можно написать хоть на Рефале под PDP-11, её полезности это не изменит. А вот СЛОЖНОСТЬ РАЗРАБОТКИ может отличаться в разы — вот про это и пост, читайте внимательнее.

> для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF

Правда? Может, чтобы не быть голословным, приведёте точное количество строк для iOS? (пример для iOS я точно сам не напишу)

> для C# нужно еще .Net framework установить в каталог с приложением

Во-первых, вы не владеете темой и пишете ерунду. .NET FW ставится ОДИН раз в каталог винды и используется ВСЕМИ приложениями. Оттого они и получаются маленькие.
Во-вторых, FW на винде — не более обременителен, чем Cocoa поверх XNU — ровно такой же фрэймворк. И кстати, с Винды-7 фрэймворк идёт в комплекте — ничего дополнительно устанавливать не нужно.

> а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.

Опять ерунду пишете. В данном случае была обучалка не Swift'у, а вообще созданию приложений под iOS! Внимательно прочтите оригинал, с которого я писал код — там нет ничего про свифт, тупо «как накликать приложение в XCode».

Athari Jul 29 2014 at 15:23

И кстати, с Винды-7 фрэймворк идёт в комплекте — ничего дополнительно устанавливать не нужно.

Он практически всегда шёл в комлекте, просто предустановленная версия может устареть как ИЕ, если отрубить обновления оси или сидеть на ископаемой оси…

int19h Jul 30 2014 at 03:43

Он не шел в комплекте с XP. Что очень долгое время было равносильно «не идет в комплекте у большинства потенциальных пользователей».

Athari Jul 30 2014 at 10:18

Хм, глянул — и правда, в «основных» версиях XP дотнет насильно не ставился. Впрочем, смысла в предустновленной версии всё равно мало, потому что оказываешься привязан к старой версии. Половина удовольствия от использования дотнета теряется.

tac Jul 29 2014 at 15:42

Ну как причем тут WPF и iOS? Мы, конечно, можем порадоваться за windows мир, но если у тебя стоит iOS — придется же все равно мучится и забыть о существовании WPF? Или тут намек, что надо выкидывать iPad на свалку? Я то за, но все ли так думают…

cigan Jul 29 2014 at 17:30

tac, почему у вас логика и выводы как у школьника? Разве мой пост такой непонятный? Русским по-белому написал:

«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»

Есть способ — пожалуйста, поделитесь. Нет — ДА И ФИГ С НИМ! :) Я не решаю ничьих проблем, я не пишу под мобилы, но мой проект хорошо показывает, НАСКОЛЬКО ПРОСТО должна быть разработка под любые платформы, благо есть конкретный практический пример — WPF. То, что под iOS нужно столько гемороиться, лишь показывает несостоятельность эппловского инструментария — вот и пусть он сдохнет в забвении! Пока МЫ ВСЕ не пошлём нафиг их сложности, Эппл так и будет нас снабжать лобзиками для валки леса. (это если вам захотелось глобальных выводов) Если кто-то хочет продолжать есть кактус — ССЗБ, почему мы должны переживать за их судьбу?

tac Jul 29 2014 at 19:43

Да, я согласен. Да хотелось глобальных выводов «пошлём нафиг их сложности, Эппл так и будет нас снабжать лобзиками для валки леса» — теперь ваша позиция понятна :)

ДА И ФИГ С НИМ!

Demtriy Jul 29 2014 at 17:29

Ну, для начала, сообщу Вам, что я программирую на 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, или пойдете читать учебники?

szKarlen Jul 29 2014 at 22:13

почему вы складываете в одну кучу настольные системы («Linux/FreeBSD/Solaris/OSX») и мобильные (Android / iOS)?

проблема интеграции рантайма на мобильных системах абсолютно идентична и Adobe AIR, например.

Если рассматривать настольные системы, то Mono устанавливается как и обычный .NET, позволяя запускать приложения на Linux, Mac OS (и через терминал также).

Размер бинарников .NET — просто маленький, однако это особенность самих файлов. Нативные сборки в 10x раз больше.

>>Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки»

а разве ОС не делает за Вас все из коробки (потоки, память, виртуализация памяти, файлы, сеть и т.д.).
Фреймворки предоставляют лишь абстракции (если это class library для OS API).

>>Поговорим о производительности WPF кода под iOS

он уже существует под iOS ?)

Demtriy Jul 29 2014 at 23:33

Это не я складываю, а автор топика который пытается сравнивать десктопную векторную платформу, работающую на x86 архитектуре, с растровой ARM iOS платформой. Перечислением платформ я лишь пытался показать перечень того, где нет встроенного .NET.

Про размер файлов я знаю. Но в сумме они дают слишком высокий прирост.

Фреймворки не только предоставляют абстракции, но и обеспечивают большим количеством прикладного кода. Автор, к примеру, апеллирует к тому, насколько плохо в IOS обеспечена поддержка JSON. Так если выкинуть из .Net сборки по сериализации, там тоже ничего работать без костылей не будет. И именно это создает богатство платформы. В IOS SDK они не меньше, просто пример для Swift показан минимальными средствами.

Конечно WPF под iOS не существует, хотя бы потому, что повсеместно используется растровая графика, а не векторная как в WPF. Но в целом Monotouch и Mono существенно уступает в производительности нативному решению (а в винде, это предмет бесконечных споров). Так что все сравнение некорректно от начала до конца. Хотя начало статьи — действительно приковывает внимание.

cigan Jul 30 2014 at 00:37

Человек, написавший хотя бы хелловорлд на C#, никогда не напишет ахинею вроде этой:

нужно еще .Net framework установить в каталог с приложением

Какой смысл после драки рассказывать свою биографию? Свою квалификацию вы уже осветили, спасибо, свободны.

Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
сравнение языков: fail.

Приведите цитату в посте, где я сравниваю какие-то бинарники или языки. Не увижу цитаты — можете сами себя послать на **** и больше на мои темы не отвечать — всё равно будете в игноре.

PS
Как же тупая школота утомила…

Demtriy Jul 30 2014 at 09:51

Вот вам цитата из ВАШЕГО текста про объем кода:

Итого, 30 строчек XAML + 44 C# кода. Я нарочно не стал делать всякую асинхронщину, т.к. глупо жать кнопку и тут же что-то менять — нужно дождаться результата, но если кому чешется, можете для async/await прибавить ещё 4 строчки.
В любом случае, полученный код явно компактнее и проще Swift-оригинала, да и сам проект — всего одна форма:

К Вашему сведению, .net работает не только в Windows. И сравнивать языки программирования, в том числе и по объему написанного кода можно только в том случае, если Вы можете воспроизвести ОБА примера на одной и той же платформе. То что Вы называете ахинеей — это реальность, о которой Вы не знаете просто потому что кроме Windows никогда ничего не видели. Да, в винде Framework встроенный, но на любой другой ОС, его нужно копировать к полученному бинарнику. (ужа надоело это даже писать), и без него НИЧЕГО работать не будет. Swift с которым Вы сравниваете работает только на OSX и iOS. Так что, прежде чем называть меня школотой, потрудитесь отвечать за свои слова и запустите свою поделку на любой из этих платформ.

jakobz Jul 29 2014 at 10:45

Вот что в Swift нет generic-ов, а соответственно — человеческого способа сделать API сериализаторов — это вообще печаль.

Печаль еще в том, что кроме generic-ов нужно reflection+runtime code generation, либо нормальные макросы в компиляторе, либо еще что-то чтобы этот API и реализацию сгенерировать по типам. А этого, я так понимаю, не предвидится даже в будущем.

Разработчики могли бы зайти в динамическую типизацию — что-то типа dynamic в C#, типа нет типизации — сделать чтобы не было мучительно больно работать с динамическими API хотя-бы. Но нет — в примерах тех же сериализаторов уродливые лукапы по строкам в словарях, явные приведения типов — вот это всё.

Короче очень все печально в swift как минимум с сериализацией, ну и с метапрограммированием в целом.

ad1Dima Jul 29 2014 at 11:04

А что, разве Swift типизированный язык? Мне казалось, так как на ObjC в массив можно пихать что угодно, соответственно не очень-то и нужны дженерики

corristo Jul 29 2014 at 11:08

Давайте отделять мух от котлет. Objective-C имеет динамическую типизацию, Swift – статическую, причем система типов богаче C#.

corristo Jul 29 2014 at 11:21

Забавно, минусы за объективные факты :)

Bl00dra1n Jul 29 2014 at 11:24

Чего чего там богаче С#??? Или ты не знаешь C# или ты не знаешь SWIFT

corristo Jul 29 2014 at 11:25

Алгебраические типы данных с паттерн-матчингом, например.

Bl00dra1n Jul 29 2014 at 11:43

Ответ: enum

corristo Jul 29 2014 at 11:43

enum в C# может иметь связанные данные? И их можно извлекать с помощью swift/case?

Bl00dra1n Jul 29 2014 at 11:45

blogs.msdn.com/b/vorov/archive/2011/05/25/10168139.aspx
blogs.msdn.com/b/vorov/archive/2011/05/26/10168703.aspx
blogs.msdn.com/b/vorov/archive/2011/05/31/10169673.aspx

corristo Jul 29 2014 at 11:46

это костыль, а не ADT

Bl00dra1n Jul 29 2014 at 11:56

Ладна ну раз костыль так костыль… Если так подумать тогда они в С# не нужны есть LINQ который их полностью заменяет + даёт ещё кучу нужный вещей которые к сожалению програмистам на Swift не доступны. Да там ещё куча чего не доступно даже взять видимость членов класса. Я не умоляю язык Swift — но мне кажеться он ещё оооочень молодой и говорить что в нём есть что-то чего нет в С# — бесмысленый спор

mibori Jul 29 2014 at 13:10

«видимость членов класса»

Это вы про это developer.apple.com/swift/blog/?id=5?

Bl00dra1n Jul 29 2014 at 14:24

Да да, я просто не в курсе был про обнову

int19h Jul 30 2014 at 03:44

Каким образом LINQ заменяет ADT?

corristo Jul 29 2014 at 11:52

А добавленные две ссылки вообще с примерами на F#.

Bl00dra1n Jul 29 2014 at 11:57

Я кучу вещей могу написать на F# и потом использовать в основной программе на С#

NeoNN Jul 29 2014 at 12:08

не знаю, как это относится к алгебраическим типам, но именно связанные данные в enuma-х (да и вообще в чем угодно) вполне можно засунуть в атрибуты, и извлекать их при помощи рефлексии, например, так легко превратить enum в список описаний, который отображается в комбобоксе, но значениями его являются значения enum'а, которые мы редактируем в одном месте.

DragonFire Jul 29 2014 at 12:10

А если не забыть закешировать все что достается рефлексией, то это еще и очень быстро работать будет =)

jakobz Jul 29 2014 at 12:28

Не, Enum это не то. В C# действительно нет ADT и pattern matching. Если очень нужно — есть F#, там уж точно полный фарш и с ADT и прочими типами.

Pattern-matching вероятно скоро будет и в C#: roslyn.codeplex.com/discussions/546465 (там про typeswitch)

corristo Jul 29 2014 at 11:15

Ну если очень понадобится «зайти в динамическую типизацию», можно написать модуль на Objective-C и использовать его в Swift-коде. А через пару релизов языка глядишь и introspection или макросы сделают.

jakobz Jul 29 2014 at 11:33

Там все не так просто. Swift — компилируемый язык, так что рефлекшна и рантайм-кодогенерации я бы там не ждал. Compile-time-макросы или что-то типа Roslyn — тоже слабо верится. Скорее всего закроют самое необходимое генерацией кода Swift из какой-нибудь JSON Schema отдельной тулзой. Как это было в .NET с датасетами и XMLSerializer-ом.

dimitrimus Jul 29 2014 at 11:43

А можете заняться небольшим просвещением? Что такое runtime кодогенерация я себе еще могу представить, хотя и с трудом представляю, зачем вообще это может быть полезно. Не могли бы вы привести пару примеров? И, если не затруднит, reflection. А то в каждом третьем комментарии говорится об этих «чудовищных» недостатках Swift, что даже интересно стало, настолько ли они «чудовищны» и почему я раньше об этом ничего не слышал. Спасибо!

jakobz Jul 29 2014 at 12:00

Reflection — возможность получить во время работы программы информацию о самой программе. Например спросить какие есть поля в определенном классе, какие у них типы, пройтись по ним циклом, и что-нибудь сделать полезного.
Runtime code generation — возможность сгенерировать код во время работы программы. Например сказать какие команды для виртуальной машины записать в функцию, и получить ссылку на эту функцию, которую можно потом вызывать.

В примере в оригинальной статьи про Swift делается десериализация JSON, причем кода весьма много, и он не очень приятен — присутствуют приведения типов, присутствует доставание значений по константной строке-ключу.

В C# этого кода фактически нет — объявляются классы, у которых поля по имени и типу совпадают с полями в JSON, дальше десериализатор генерируется библиотекой на лету.

dimitrimus Jul 29 2014 at 12:32

Спасибо, познавательно, видимо, я слишком привык к С++ :) А кроме десериализации это может быть чем-то полезным? Здесь согласен, это действительно должно сильно сокращать код.

jakobz Jul 29 2014 at 13:07

Работа с БД, в плане мэппинга классов на результаты запросов, чтение конфигов, чтение полей из HTTP-запросов. Хотя это тоже считай сериализация. Есть еще штуки типа AutoMapper — копирует разные классы друг в друга, используя как вход соглашения о наименовании: одинаковые поля копируем друг в друга, Person.Name копируем в PersonName, и т.п.

Плюс есть еще смежные с этими фичи:
— аттрибуты. Ты можешь на метод, класс, поле или параметр повесить при компиляции экземпляр своего класса, в который запихать любую метаинформацию. Которую потом как-то использовать в рантайме. Например:

[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# цветет и пахнет. И хотя немного порой выглядит как магия, жизнь упрощает очень сильно.

olegi Jul 29 2014 at 13:27

а какой ROI от этого?

jakobz Jul 29 2014 at 14:05

Декларативный код меньше подвержен ошибкам. И, C# в отличии от той же java с XML во все концы, имеет инструменты сделать декларативный код строго-типизированным.

Вклад при этом минимален — все что нужно простым пацанам уже есть в библиотеках. От них только требуется класс написать, и аттрибутами закастомизировать поведение всех этих сериализаторов и валидаторов. Это даже проще чем конфиги какие править.

А профит в том, что кода меньше: меньше ошибок, меньше работы, дешевле разработка, дешевле поддержка.

Вот как пример — я регулярно рефакторю схему БД, с которой работаю через Entity Framework. Например вот переименовал я для красоты поле UserID в ID для однородности, чисто рефакторингом студии. Сложно себе предствить как такое было бы возможно, если бы не все ссылки на это поле были бы строго-типизированны, и весь возможный boilerplate-код не сидел бы в библиотеках. Например если был бы SQL в строках «select * from users where userid = » + id, или были бы поля во вьюхах типа <input type='hidden' value='@data["userid"]'> — я бы за рефакторинг схемы брался бы только основательно с бизнесом поторговавшись, за отдельную оплату.

olegi Jul 29 2014 at 16:14

меньше работы, дешевле разработка, дешевле поддержка

Меньше заработок? :)

я регулярно рефакторю схему БД,

Семь раз отмерь, один раз отрежь? :)

jakobz Jul 29 2014 at 16:29

«Меньше работы — меньше заработок» — это ты видимо пошутил. Меньше работы на единицу функционала => больше проекты => квадратично больше бабла.

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

Demtriy Jul 29 2014 at 11:41

удалено. ошибся веткой

jakobz Jul 29 2014 at 11:44

Да, этот момент я как-то прошляпил, каюсь. Почему-то запало в голову что их там нет, видимо спутал с чем-то еще новым.

Demtriy Jul 29 2014 at 11:50

Вот что в Swift нет generic-ов, а соответственно — человеческого способа сделать API сериализаторов — это вообще печаль.

В Swift есть женерики. Посмотрите обучающие примеры.

Shersh Jul 29 2014 at 12:47

А почему собственно WPF с iOs сравнивается? Пишите тогда уж на Silverlight for Windows Phone. В конкретно данном примере конечно будет мало различий, но разработка WPF и WinPhone совершенно разные.

ad1Dima Jul 29 2014 at 13:11

Между прочим, чистый WPF в некоторых кейсах проигрывает UITableView. А вот в Windows Phone напротив есть столь же мощный LongListSelector.

Shersh Jul 29 2014 at 13:13

с утечками памяти при использовании картинок и без SelectedItem ))

ad1Dima Jul 29 2014 at 13:28

без SelectedItem

эээ, что?

А насчёт утечек, не знаю, не ловил.

Shersh Jul 29 2014 at 13:29

Он не DependencyProperty и поэтому к нему нельзя применить Binding. Вот я о чем.

ad1Dima Jul 29 2014 at 13:59

Ну, это уже страшнее но не на много. К тому же это можно обойти с помощью behavior.

Shersh Jul 29 2014 at 14:02

Ну конечно можно. C# и XAML очень мощные инструменты. Просто из таких мелочей складывается сама разработка и ощущения разрыва между «большим .net» и мобильным.

SZolotov Jul 29 2014 at 13:37

Утечки памяти — это проблема BitmapImage и соответственно Image, но не LongListSelector

Shersh Jul 29 2014 at 13:46

Возможно, но в самом обыкновенном ListBox такого не происходит.

NeoNN Jul 29 2014 at 13:25

Позволю себе не согласиться. Скорее, подмножества XAML немного разные, каких-то компонентов WPF в Silverlight или разработке под WinRT нету, но подход-то к разработке один и тот же остается. Тот же xaml, тот же C#, те же библиотеки типа Caliburn.Micro для облегчения MVVM, которые используются одинаковым образом. Да даже Linq2sql из коробки работает на WinPhone.

Demtriy Jul 29 2014 at 13:42

Ну а на iOS работает CoreData из коробки. Тоже еще аргумент. Swift сырой язык — с этим может спорить только тот, кто не программирует на iOS. Он еще даже не вышел в первой версии — он был только презентован. При его создании использовали опыт в том числе и C#, так же как сам C# был создан при участии разработчиков Delphi и почерпнул оттуда многие свои идеи. Дискуссия здесь холиварна просто потому, что невозможно сравнивать что-то простое и неработающее, с чем-то менее интуитивным в вполне работоспособным. Вот когда автор топика запустит свое приложение под IOS, разработав его под WPF, тогда и будет смысл сравнивать ПРОСТОТУ программирования и объем кода. Пока что, автор показал одно, а в заголовке написал совсем другое.

Shersh Jul 29 2014 at 13:51

Ну не правда же:)

На телефоне всегда надо думать о выделенной памяти. Если на декстопе все это работает быстро и можно захавать пол гига на 1 минуту, то в телефоне такого нельзя. Второе, тот же ReactiveExtensions работают немного но по-другому. Я не буду говорить о том, что там нету Emitа, а значит все маппинги происходят засчет рефлексии. И да, контролы там другие и работают они по-другому. Не как в WPF, собственно об этом и была речь.

NeoNN Jul 29 2014 at 15:40

Соглашусь, тут отличие есть. Правда, о памяти надо думать всегда, в случае с десктопом 2003 года выпуска с 512 Мб памяти или каким-нибудь eee-pc это даже более актуально, чем в случае с телефоном. Bloatware — зло, и я сейчас временами очень страдаю, когда хочу запустить хотя бы браузер на стареньком eee-pc. Риторический вопрос — как так получается, что 3-д игра 2001 года, или *любое другое приложение старого года выпуска* на нем работают быстрее, чем прокручивается лента комментариев на новостном сайте (по кадру в 3 секунды)?

cigan Jul 29 2014 at 16:28

+1
Я так понял, людям надо просто докопаться до идеала :) Ну вот вышло так, что под WPF решение получилось намного проще — значит нужно искать какие-нибудь тухлые отговорки, лишь бы его обкакать! (как будто это хоть на грош облегчит жизнь iOS бедолагам :)) )

Demtriy Jul 29 2014 at 17:35

Оно не проще. оно НЕРАБОТОСПОСОБНОЕ для той платформы с которой вы производите сравнение.

cigan Jul 29 2014 at 18:55

Почему мне должно быть дело до Сервелата? То, что M$ что-то там позиционирует (и реализует через анус) — это их интимное дело. Я реализовал всё на WPF — чем он вам не угодил? Что в нём такого «десктопного», чего нельзя реализовать на мобильной платформе? Весь код — выше, можете тыкнуть в конкретную строку и объяснить.

Demtriy Jul 29 2014 at 19:33

Покажите свой код работающий на iOS тогда и поговорим. Ну хотяяяяяяябыыы под OSX.

kottt Jul 29 2014 at 23:23

Таки речь шла о том, что свифту есть к чему стремиться, а не о том, что WPF круче

Demtriy Jul 29 2014 at 23:47

Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет. Но за пару лет Objective-C взял такой разгон, что были основания полагать, что скоро C# придется догонять… А поведение Балмерт и уход автора C# из Microsoft только усугубил кризис. Это вообще не предмет дискуссии. Но вот что значит стремится? Нужно ли Apple переходить к векторной графике? До тех пор пока я не начал программировать на IOS я был уверен, что за векторной графикой будущее. Но растр у Microsoft не делает десятой части того, что делает у Apple. В таком случае, в чем смысл? А именно это позволило обрести WPF/Siverlight такую популярность. Да, у Apple отсуствует декларативное программирование. Это очень не привычно, в современном мире. С другой стороны, пробовали Вы сделать сложную декларативную графику без Microsoft Blend? Вот и посудите, а оно надо? Все равно же будут использовать посроители интерфейса, как это делает Apple. Ну и в завершении, что делает WPF таковой, что резко сокращает количество кода — бандинги! А скажете ли Вы что MVVM легче для понимания и работы в очень сложной форме чем MVC? Думаю что нет. Так нужно ли идти по этой дороге?

kottt Jul 29 2014 at 23:58

Никто не говорил про нюансы векторной и растровой графики. Автор всего лишь заметил, что iOS-разработчиков в 2014 году продолжают заставлять писать тонны ненужного кода

ad1Dima Jul 30 2014 at 06:59

пробовали Вы сделать сложную декларативную графику без Microsoft Blend?

Я пробовал и делал. Более того, большинство разработчиков, которых я видел, пишут интерфейсы напрямую в xaml, остальные, ЕЩЕ не пишут. Но есть встречный вопрос, пробовали ли вы Делать сложную графику ТОЛЬКО в IB?

Но растр у Microsoft не делает десятой части того, что делает у Apple. В таком случае, в чем смысл?

Пример?

corristo Jul 30 2014 at 08:46

iOS-разработчикам не мешало бы иногда задумываться о MVVM, глядишь в среднее качество кода по больнице увеличилось бы.

ad1Dima Jul 30 2014 at 09:10

Боюсь нормальный MVVM там не получится — нет привязок данных. Есть для Xamarin MVVMCross и MVVMLight но это не совсем честный MVVM.

Эппл форсирует использование MVC в iOS. Но опять же не все разрабы следуют этой архитектуре.

corristo Jul 30 2014 at 09:12

Есть ReactiveCocoa с биндингами, но это Objective-C и макросы. Что и как будет в Swift – не знаю пока.

ad1Dima Jul 30 2014 at 09:20

Тут нет самого главного: декларативных привязок. Все равно надо это из кода задавать. И я не совсем понимаю, там реализован контекст данных? без него тоже не MVVM

corristo Jul 30 2014 at 11:30

Если очень захотеть, можно задавать эти привязки в Interface Builder (через runtime attributes), я всё-таки предпочитаю в коде, пусть это и не так «правильно» и «декларативно». По моему мнению, суть всё-таки в декларативном описании dataflow, а не задании привязок в удобном UI-редакторе (хотя это тоже здорово, конечно)

С .NET толком не работал, поэтому про контекст ничего ответить не смогу, возможно у нас просто терминология другая.

Вот небольшой примерчик, как может выглядеть view model на Objective-C с использованием RAC.

Botu Jul 30 2014 at 10:12

Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.

Для тех, кто в танке… В каком смысле «отставал»? Второму же всего чуть больше 20 лет ))) Как же «первый может отставать», он что только что появился? ))))…

В пользу второго можно сказать, что ко второму постоянно придумывают новые framework-и, которые сильно облегчают жизнь… Это не столько развитие общей структуры кода, сколько чисто заточенные вещи под мобильные устройства и не только устройства…

Я просто не знаю, что в этом плане может нам предложить «первый» ))).

ad1Dima Jul 30 2014 at 10:20

C# — 2000
Obj-C — 1983

Кому из них чуть более 20?

Botu Jul 30 2014 at 10:38

Извините, обшибся, но тогда вот эта фраза

Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.

совсем непонятна.

Первый — это Objective-C, как он может отставать от C# — на два десятка лет, если C# всего 14 лет?

Это подразумевается, что он старее? Типо старьё ))) Или что он с тех пор не развивался, а только в недавнее время стал развиваться?

Я C# к сожалению профессионально не занимался, но когда на курсах изучал, нам там прямо сказали, C# полностью всё ворует у Java и учиться на чужих, то есть java вских ошибках… Не знаю на сколько это имеет место быть, показалось достаточно забавным…

cigan Jul 30 2014 at 15:39

> C# полностью всё ворует у Java

хихи :) Пошутист!
Насколько я могу судить по результатам, дело было примерно так:
МС сделала Жабу на своей платформе. Потом стала её проприетарить. Сан обиделся и стал судиться. МС схлопнула проект, но исходники-то остались! И вот кому-то очень умному вступило переплюнуть Жабу. Как? Ведь Жаба — уже развитый язык и платформа. И МС решила сделать многоязыковую платформу! (взять количеством) Так что да, корни у C# вполне жабские. НО(!) в последущие годы шарп сделал ГРОМАДНЫЙ рывок вперёд! Такой, что Жаба осталась кашлять на обочине. В довесок, Вижуал Студия — тоже раз от разу всё хорошела, что писать код стало просто сказкой (я работал с этим 10 лет). В это время Жаба просто сидела в своём «интыпрайзе» и посмеивалась на «одноплатформенный дотнет», а когда ей сказали «подвинься», тут у неё пятки и загорелись! Тут же стали кипишиться, язык развивать… да куда там — поздно! Уже выросло поколение шарповодов, которые к жабе на километр не подойдут. Вот такие пироги…
Что в это время делала Эппл? СКРУГЛЯЛА УГЛЫ :) ОбжСи как был скобочным ужасом, так и остался до сих пор. Разработка визуальной части тоже, как видно, была в режиме «работает — и ладно!». Так что на сегодня по удобству и скорости VS+C# практически непревзойдённый инструмент.

ad1Dima Jul 30 2014 at 15:55

к слову, пару лет назад Obj-C стал чуть менее скобочным: они упростили декларирование массивов.

Athari Jul 29 2014 at 13:46

Вы можете удалить классы StoreReply и AppInfo, для этого приложения хватит и JObject. :)

Botu Jul 29 2014 at 17:20

Вопрос к С# разработчикам:

При создании коммерческого ПО сейчас используются обфускаторы или сейчас все пошли на open source? Как они совмещаются с динамическим мета программированием? Можно часть кода оставить «чистым», а часть обфускарнуть?

Извините, если не по теме…

xakpc Jul 29 2014 at 18:16

Естественно используются обфускаторы.
Естественно большая их часть позволяет выбрать игнорируемые классы.

Athari Jul 29 2014 at 19:44

1. Обфускаторы используются (зависит от паранойи, видел софт и без обфускации, все живы).
2. Обфускаторы настраиваются (очень детально, потому что усложняют некоторые сценарии).
3. Обфускаторы не защищают (см. de4dot и иже, .NET архитектурно нельзя хорошо защитить, ибо JIT).
4. Обфускаторы не нужны (в 99% софта 0% ноу-хау, всем на ваш говнокод пофиг, там без обфускатора чёрт ногу сломит).

olegi Jul 29 2014 at 17:38

С таким инструментом точно не возникнет желания наполнять аппстор чем-то полезным — слишком уж дорого эта польза даётся. Напомню, это мнение программиста на 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 всё в офисах, энтепрайзах, биндингах, эктив дайрокти, и т.п.

szKarlen Jul 29 2014 at 22:27

>>Instagram написан без C#, рефлекшенов и байдингов.

Hello, world вообще можно написать на bash'e.
В Excel можно рисовать.
iOS интерфейс можно воссоздать в Word'e.

>>Куча программистов с приложениями в AppStore уже получила много $$$ без C#, рефлекшенов и байдингов.

не эти ли 20% разработчиков игр для App Store, которые получают 97% всех денег?

>>а Microsoft всё в офисах, энтепрайзах, биндингах, эктив дайрокти, и т.п.

похоже Вы не знаете объемы денег этих самих «энтепрайзах». Apple держится за счет большой маржи, которая неизвестно сколько продержится (извините за тавтологию).

olegi Jul 29 2014 at 22:50

не эти ли 20% разработчиков игр для App Store, которые получают 97% всех денег?

1) Очень круто ссылаться в 2014 году на исследования 2011. Чуть-чуть свежая информация: 57% игр в магазинах приложений зарабатывают менее 500 долларов в месяц. но при этом 80% выручки в магазинах — от игр.
2) Эти 20% или другие, но пару недель назад тут, на Хабре, один из пользователей описывал свою историю, что разрабатывая игры по вечерам для Android, он имеет пассивный доход в $$$$.

похоже Вы не знаете объемы денег этих самих «энтепрайзах».

Вопрос в том — сколько из них попадет к c# разработчикам :) А объёмы знаю, т.к. сам из этого мира.

Apple держится за счет большой маржи,

У MSFT маржа в 2 раза больше.

которая неизвестно сколько продержится

Может IBM поможет? :)

szKarlen Jul 29 2014 at 23:06

ответил чуть ниже

cigan Jul 30 2014 at 05:49

Скажите, вы глупый или невнимательный? Я ожидал определённой доли непонимания, но не до такого же тупизма! Прочтите ещё раз, пожалуйста:

«Цель — сравнить сложность разработки и возможно кто-то поделится более простым методом для iOS (если он есть).»

Пожалуй, придётся писать очень грустный постскриптум к посту. :((
(уже написал, вы бы ознакомились что ли)

olegi Jul 30 2014 at 10:29

Т.е. а вы у нас такой умный и пушистый ставя желание разрабатывать приложения

не возникнет желания наполнять аппстор чем-то полезным — слишком уж дорого эта польза даётся.

в зависимость от возможностей/сложностей инструмента

Чего ж так сложно, господа?.. предложите ПРОСТОЙ СПОСОБ сделать аналогичное приложение. Если его нет — упаси небо, я никого винить не буду, будем считать, что Apple уделила недостаточное внимание удобству разработки

szKarlen Jul 29 2014 at 23:05

>> Чуть-чуть свежая информация: 57% игр в магазинах приложений зарабатывают менее 500 долларов в месяц. но при этом 80% выручки в магазинах — от игр.

ok, но $500 не является джек-потом :)

>>А объёмы знаю, т.к. сам из этого мира.
и я тоже :)

>>У MSFT маржа в 2 раза больше.

Apple проводит очень хитрую экономическую политику — выплаты налогов составляют где 10-12 % от валовой прибыли. причем, денежные фонды аккумулируются непонятно где (!!!). Сравните их прибыль (не выручку) и темпы накопления денежных фондов.

p.s.
и да MSFT (67.52%), AAPL (39.36%), что есть marge = 1.71 :)

olegi Jul 29 2014 at 23:40

и да MSFT (67.52%), AAPL (39.36%), что есть marge = 1.71 :)

Скорее всего Nokia виновата :)

olegi Jul 29 2014 at 23:39

промах

ad1Dima Jul 30 2014 at 07:11

Посмотрел внимательно на верстку в статье, я бы за такое по рукам бил. На десктопе конечно много мегагерцев и оперативы, но для мобильного приложения верстка слишком усложнена.

                     <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>

Athari Jul 30 2014 at 10:30

А вы меряли производительность? Картинка в гриде — это жесть, конечно, но вообще DockPanel и StackPanel несравнимо проще, чем Grid (в гриде 3000 строк кода, в DockPanel — 300).

ad1Dima Jul 30 2014 at 12:21

Я говорил в первую очередь про мобильники. Там я производительность мерил и лишний вложенный контейнер дает нехилую нагрузку, особенно в темплейтах списков.

DockPanel, к сожалению, в WindowsPhone нет. Возможно с ним было бы и производительнее. Но как показывает профайлер, чем меньше вложенность, тем лучше.

NeoNN Jul 30 2014 at 11:53

Ага, и плодить RowDefinition каждый раз, когда добавляем строку.

ad1Dima Jul 30 2014 at 12:21

Это не такая большая проблема, а вложенность сильно бьёт по производительности.

cigan Jul 30 2014 at 19:54

Дима, ты откуда такой крутой? Паспорт получил — теперь всё можно что ли? е****ло своё завали и когда впредь будешь ко мне обращаться, во-первых, постарайся употреблять местоимение «вы», а во-вторых, «по рукам» свою жену бей, я тебе сам такое отобью, всю жизнь приставными шагами ходить будешь! ОК?
Если хочешь дать ТЕХНИЧЕСКИЙ СОВЕТ, пыл свой поумерь, «20-летний сеньор», а потом напиши свои претензии в ВЕЖЛИВОЙ ФОРМЕ.

По сути претензии не буду ничего слушать, пока не увижу реальные бенчмарки «якобы» тормозящих контейнеров. Кроме того, прежде чем выёживаться, бельмы подыми и почитай — приложение ДЕСКТОПНОЕ, сделано на WPF. Никаких «мобильных» оптимизаций я даже не думал делать. Так что претензия дважды не в кассу.
Сиди, думай.

NeoNN Jul 30 2014 at 20:10

Ну и зачем суицид после recovery-mode?

Athari Aug 2 2014 at 17:45

А был ли recovery? На откровенно холиварном топике-то? Я карму автора поглядывал из спортивного интереса, и непохоже, что она в какую-либо сторону ощутимо сдвинулась.

cigan Aug 2 2014 at 18:16

Ребят, чего вам моя карма? :) Это должно заботить хабровладельцев — когда адекватных авторов школота сливает. Не поменяют правила — останутся с тусой кармадрочеров, способных только лайкать (т.е. потреблять контент). А у меня есть ЖЖ — пусть почти не посещаемый, но с людьми, с которыми приятно общаться.

Athari Aug 4 2014 at 00:46

Я большой ценитель холиваров, культурного мордобоя и содержательных побоищ, поэтому слив кармы идеологических сторонников не может меня не беспокоить. Recovery mode работает только до определённого порога, и вы запросто можете через него перевалить (если уже не). Вам-то, конечно, пофиг, а я бы предпочёл иметь разносторонние топики и обсуждения на Хабре, а не ловить их по закоулкам нетематических блогов.

cigan Aug 4 2014 at 01:53

Приятно слышать, спасибо. Но мы, юзеры, просто игрушки в психологической машине «надрочи побольше карму». Эти крысиные бега с оглядкой «а что скажут хаброжители» не для людей, привыкших открыто выражать своё мнение.
Мне тоже нравится спорить и читать интересные топики, но чтобы общение на сайте приносило удовольствие, карма категорически не должна трогать моих свобод — количество комментов, «богатство форматирования», право голосования и т.п. Это я не вам говорю, а так, в робкой надежде быть услышаным.
Поэтому если хабр будет «выжимать» топики из юзеров, «отжимки» и получатся.

tac Aug 4 2014 at 02:07

Полностью Вас поддерживаю, в последнию неделю и моей кармы коснулась такая участь, вот подумываю наверно уйти с хабра, хотя иногда приличные люди тут встречаются :)

cigan Aug 4 2014 at 03:01

Уже была известная всем попытка: freehabr.ru
Тонкость в том, что без финансовой подпитки даже самый лучший ресурс стухнет. А там всё держится на одном человеке без спонсоров.
Я вижу последнюю надежду в том, что хабровладельцы наконец поймут, что их детские игры в кармомерство не являются главным двигателем ресурса.

agranom555 Aug 4 2014 at 07:53

Поддержу. Зачем понижать карму, когда можно просто поставить отрицательный рейтинг комментарию?

cigan Aug 4 2014 at 15:52

Написал письмо в редакцию: пастебин слэш Pyv3LPE1

peinguin Aug 4 2014 at 15:59

Во-первых, они бестолково суммируются

Наведите мышкой на само число.

cigan Aug 4 2014 at 19:49

Спасибо за подсказку! Вся ирония в том, что ХОРОШИЙ интерфейс не должен жить на подсказках — он сам должен быть подсказкой и максимально удобным. Так что нет, «наведи мышку» — не решение. Должны быть два числа и уже с них (попутно поменяв курсор мыши) чтобы можно было, например, посмотреть список голосовавших.

NeoNN Aug 4 2014 at 16:22

Я думаю, что коммент заминусовали за грубость, а не за собственное мнение, отличающееся от других. Все-таки «е**** завали» — это уровень необразованной гопоты, а никак не ученого человека, считаю, что на хабре дискуссии в такой форме недопустимы.

cigan Aug 4 2014 at 18:16

Сейчас, _когда_я_уже_остыл_, я тоже считаю, что ответил грубее, чем требовалось — ПРОШУ ПРОЩЕНИЯ.
В оправдание, у меня есть мой топик и куча ПОСТОРОННИХ комментариев, оставленных какими-то неадекватами с узколобым мышлением.
Вот сейчас, когда вы решили порассуждать, скажите, какова главная цель топика? А теперь пройдитесь по всем комментам и скажите, найдётся хотя бы пять комментов, ПО ДЕЛУ отвечающих на вопрос топика?
Заметьте: я — один, а штопаных комментаторов, решивших «блеснуть интеллектом» (как вот этот «отрыватель рук») — десятки! Троих олухов я ещё поставлю на место в вежливой форме, но я — человек, у меня тоже есть нервы. Более того — я — профессионал и по долгу службы общаюсь с людьми, примерно равными мне по уровню. Поэтому от людей общей со мной профессии я жду если не полного понимания, то хотя бы адекватных, аргументированных суждений. Ну и само собой, эти суждения не должны скатываться в наиглупейшие частности — люди должны уметь видеть ГЛАВНОЕ. Всё равно, что ты хвалишься собранным квадрокоптером, а потом набегает десяток кретинов и говорят: «у тебя лопасти плохо покрашены!» — вот так примерно я себя чувствую после ответов на, казалось бы, вполне однозначный топик. Как думаете, могу я немного приструнить этих «малолетних сеньоров», чтобы сначала думали, а потом писали? (см. постскриптум топика — СПЕЦИАЛЬНО попросил!)
Кстати, вот даже вы сейчас смотрите на один мой коммент, хотя проблему я поднял гораздо шире — неужто я так плохо выражаюсь, что вы не осознали широту проблемы? Вот про это и речь — я не обсуждаю с домохозяйками цвет щей, я хочу, чтобы люди мыслили глобально и конкретно, не в обиду вам будет сказано.

Или вот ещё каких-то два **** заминусятили моё «письмо в редакцию» — ответьте прямо здесь, ЧТО В НЁМ НЕПРАВИЛЬНОГО? Каким надо быть пустоголовым, чтобы не понимать, что Хабр _сейчас_ никак не способствует повышению качества статей? (и никак не защищает авторов от праздной школоты) Вот про то и речь — пишешь и думаешь: кому?.. зачем?..

peinguin Aug 4 2014 at 18:34

Я написал где вы неправы. А вы проигнорировали.

cigan Aug 4 2014 at 20:58

Месье, вы это серьёзно?? Вы ПОСТАВИЛИ МИНУС ЗА ТО, ЧТО ЧЕЛОВЕК УКАЗАЛ НА НЕДОСТАТОК ИНТЕРФЕЙСА ХАБРА?
Тогда ясно, что вы за аудитория, вопросов больше нет.

NeoNN Aug 4 2014 at 18:37

А на что можно надеяться с топиком, который затрагивает только самые основы?

Могу предположить, что если бы был выложен туториал по созданию настоящего WPF-приложения, с mvvm типа Caliburn, IoC типа MEF, асинхронными репозиториями и юнитофворками, xaml-стилями, а то и всякими контрактами и WCF, это бы сразу отсекло здоровскую часть холиварщиков и остались бы только те, кому это интересно.

Если же цель была заинтересовать и показать преимущество технологии, то странно ожидать реакцию «да, это здорово, все, что я до этого писал на php/js/паскале — туфта, вот он, мой новый путь». А вот грубость этому никак не способствует. На самом деле и слова про «руки отрывать» тоже ошибочны. Но корень тут один — нежелание видеть и принимать/понимать точку зрения оппонента. Тут надо терпеливо и доходчиво объяснять, в чем плюсы и в чем минусы в каждом конкретном применении, а если этого не получается сделать — тогда смириться с тем, что не всем это нравится и кто-то продолжит писать приложения для айфонов, а кто-то — рассчетные программы на матлабе. Ну или отправлять на stackoverflow. Модель саморегуляции там более жесткая.

cigan Aug 4 2014 at 22:20

NeoNN, давайте перейдём на личности — для большей понятности: вот этот топик «Генерация схем для вышивания крестиком на WinPhone» — вы всерьёз думаете, что написали что-то фундаментальное? Встающие зрители с апплодисментами? ДАЛЕКО НЕ. Собственно, 90% топиков Хабра и есть подобного уровня лажа, без которой мир не станет хуже. Мой пост — ОЧЕВИДНО не самоучитель и я не понимаю, с какого похмелья вы решили, что я вам должен выкатывать «туториал по созданию настоящего WPF-приложения, с mvvm типа Caliburn». Ещё раз спрашиваю: вы СМЫСЛ топика поняли? Я не могу с вами переписькиваться, потому что карму обосрали, но вы говорите о чём-то своём, начисто игнорируя смысл оригинального поста — так мы взаимопонимания не добьёмся.
Прочтите ещё раз внимательно пост и скажите главный вопрос, который я в нём поднял — без понимания этого я не вижу смысла говорить о вещах, которые вы сами себе придумали и меня же в них обвиняете. ПОСТ — НОРМАЛЬНЫЙ, не хуже ваших крестиков, начните с осознания хотя бы этого — потом возвращайтесь к моему посту.

> Тут надо терпеливо и доходчиво…

Уже объяснял — школоте место В ШКОЛЕ, это там «терпеливо и доходчиво». «Здесь — взрослый мир, детка!» КАЖДАЯ профессиональная область требует определённых познаний. Нет знаний — ПРОХОДИ МИМО, значит этот топик не для тебя и не твоего уровня (простая мысль, да?). Но нет, «набИгают иксперды», чтобы пёрнуть в теме, в которой сами едва разбираются. Не противно такое наблюдать?

NeoNN Aug 4 2014 at 23:20

Странную тему вы выбрали, к тому же из неиндексируемого «я пиарюсь». Почему не «распознавание рукописного математического ввода», например, или «запись при помощи Directshow.Net»? Если переходить на личности, то я скажу, что судя по уровню общения вы очень едкий и злой и я не хотел бы с вами работать ни в одной команде, ни в одной компании. За сим прошу больше не писать.

cigan Aug 5 2014 at 01:21

> Ещё раз спрашиваю: вы СМЫСЛ топика поняли?

Судя по сливу, нет. Зачем тогда тратили моё время, а сейчас позорно прикрываетесь вменяемыми мне качествами? Заметьте — я ни слова не сказал ни про вас как человека, ни про то, что ваш топик хуже — он одинаково поверхностный со всеми. И уж точно не лучше моего — это просто как пример того, что вы просите больше, чем сами умеете.
Я _иногда_ едкий, но уж точно не глупый — потому и раздражает тупая посредственность.
Спасибо, что больше не прикидываетесь серьёзным, размышляющим человеком. ;]

ad1Dima Jul 31 2014 at 06:20

Миша, бить по рукам это идиома. Да тут она лишняя извини. Но и принимать её так близко к сердцу не стоит.

Насчёт WPF. Выше уже не однократно писали, что сравнивать iOS с десктопом по меньшей мере некорректно. Тем более, что есть windows phone. (Хотя честно говоря, коллеги, которые работали с маком, говорят что там все ещё хуже, чем в iOS).

Насчёт тестов. Могу попробовать показать результаты профилировщика, но это не раньше следующей недели.

cigan Aug 1 2014 at 14:15

Дима, вы пояснение читали? Я всё никак не могу донести простую мысль (или вы, в своём упоении «некорректностью сравнения» не хотите слушать). Давайте я разжую как для детсада:

Мы сравниваем ДВА РАЗНЫХ ПУТИ к ОДНОЙ ЦЕЛИ. Нам нужно перевезти человека из А в Б. У нас есть F1 и Белаз. Человек садится в каждую из машин и едет. В пункте Б мы спрашиваем: «насколько легко было преодолеть это расстояние?». Очевидно, что с Белазом всё было намного сложнее. Итак, что неправильного в использовании этих двух машин?? Разные рули штоле?

ad1Dima Aug 1 2014 at 15:02

Вы привели прекрасное сравнение. Замечательное, мне нравится. Вот только вы по-умолчанию, почему-то, едете по гоночной трассе. Я же предлагаю сравнивать Белаз с Камазом на бездорожье, а Феррари с Макларен на трассе.

cigan Aug 1 2014 at 15:20

Это ваши личные додумки. Пути — два, а значит каждый может ехать именно там, где ему удобно. Разве я заставляю разрабов iOS писать из-под DOS? Нет. Они вольны в своём выборе. Вот и WPF волен писаться под Windows. Запомните, здесь одна — только ЦЕЛЬ — браузер аппсторовских приложений. Это именно то, что видит ПОЛЬЗОВАТЕЛЬ. Ему пофиг, ехали вы по бездорожью или гребли руками — перед ним должен быть список приложений и строка поиска, всё. Как вы этого добились — он не только не видит, но и не желает знать. Это-то понятно?

Demtriy Aug 1 2014 at 15:25

Покажите мне хоть одного пользователя который видел WPF приложение в Appstore. Ну хотя бы на картинке. Я даже не прошу показать само приложение.

ad1Dima Aug 1 2014 at 19:56

Вот вы опять путаете, пути, машины. Если вы хотите показать как на WPF круто делать именно такие приложения вне зависимости от платформы, то найдется пара конструкторов, на которых это можно сделать вообще без программирования. И WPF оказывается в лузерах.

А вот если я вас попрошу сделать на список контактов как в iOS то тут вам либо писать кучу кода, либо искать дополнительные библиотеки, когда в iOS это всего лишь написать 3-4 метода на 3 строчки.

Пользователю не пофиг где работает приложение.

И заметьте, я не спорю, что UIKit'у иногда не хватает каких-то простых вещей вроде СтекПанели, но и всю мощь WPF вместить в телефон не получилось даже у MS

cigan Aug 1 2014 at 21:14

Спасибо, поржал. То есть сейчас вы мне объясняете смысл моей же статьи?? Может, пора уже осознать, что вы стучитесь в стену, хотя вас упорно тащат в калитку?

> то найдется пара конструкторов

И ЧТО? Ну найдётся, разве это плохо? Чем от этого WPF решение стало хуже-то?

> сделать на список контактов как в iOS

Что тут грамматически делает предлог «на»?
Функция «список контактов» — это просто список контактов, сделаю без проблем. Ключевой вопрос здесь (и в статье) — то, какой кровью обходится создание каждой фичи. Я уже всем показал, что WPF'ный вариант на порядок проще и это объективная реальность. Вы же продолжаете натягивать какие-то невразумительные условия, когда речь всего-лишь про функцию «браузер аппстора». Я понимаю, вам трудно принять факт выйгрыша WPF — хотите, дам телефон хорошего психиатора?

> но и всю мощь WPF вместить в телефон не получилось даже у MS

Да мне наплевать, что там «вмещал» мелкософт — посмотрите на приложение — вы видите в нём какие-то гипертяжёлые, сугубо «десктопные» фичи, которые нереально сделать в телефоне? Вот и я не вижу.

О чём мы спорим? Что вы никак не можете абстрагироваться от платформы, чтобы понять, что сделано идентичное приложение? Ну почитайте теоретиков что ли… не всё же по уши в коде торчать!

kostyl Aug 1 2014 at 23:22

Вы сравниваете не понятно что не понятно с чем. Взяли какой-то говнокод-хрень-пример и написали «тот же функционал» на другом языке какбэ. Слишком сложно для «упрощенного» языка говорите было? А вы знаете в чём «упрощенность» Swift чтобы сравнивать? И вообще что такое «упрощенность» в ЯП чтобы как то её определять? И почему вы сравниваете технологии, фреймворки, инструменты, а не возможности языков, а говорите о языках? Мне кажется вы попытались найти плёвую лазейку для своей мании величия, а попались на свою неграмотность в постановке цели. Отличное сравнение, поздравляю!

cigan Aug 1 2014 at 23:31

Это не для средних умов, торгующих в переходе мобилами — проходи мимо, кретин.