Обновить
68
2.8
nagg@Nagg

Разработчик

Отправить сообщение
Да, у меня бы тоже язык не повернулся назвать класс с кучей библиотечно-зависимых атрбиутов POCO.
Ок, но меня интересует применимость для моего случая — у меня много линейных больших DTO, которые я сериализую протобафом. Вот и вопрос — имеет ли смысл пробовать ваш сериализатор для моего случая.
А сами тесты производительности есть в Гите? и почему в самих результатах нет Protobuf?
Именно. В свое время убил почти 2 года на эту платформу, а она до сих пор никому не нужна. Теперь пишу на Java и C#/Xamarin. Часто вижу заказы на Xamarin только на ios и android. при предложении до кучи сделать еще и WP8 где собственно сам C# нативен — отказываются мотивируя ненужностью.
Думаю, правильнее спросить — какая судьба ждёт нативные средства разработки под Вин10 (XAML, etc) т.е. зачем париться и писать замл, если можно просто портировать андроид.
Так ведь в шарп уже завезли Null-conditional operators:

customer?.Orders?[5]
Меня тоже посещает мысль о том, что было бы не плохо иметь такой общий протокол т.к. мессенджеров развелось уже неприлично много (сам работал над одним из таких). В качестве примера хорошо взять XMPP, но переделать. Сделать упор на поддержку мультидевайсов, быстрого восстановления сессии в условиях обрыва соединения при сворачивании/разворачивании, сделать на уровне протокола обязательное подтверждения доставки сообщения и вообще любых действий (уровня протокола, а не только TCP). Как оказалось — в хмпп это не считали обязательной штукой. Но увы, скорее всего это будет Картинка про еще один стандарт.jpg
Опечатался, имел ввиду github.com/orfjackal/retrolambda
Я что-то не очень понял последнюю картинку — послали пакет на соединение по UDP и всё — будь что будет? (и как это эквивалентно TLS — где обмен ключами?)
Вот если бы в андроид это дело всё. без уретралямбд всяких.
Ну это как раз легко сделать сделав свой грид с домино и поэтессами ;-)
Хотя да, хотелось бы чтобы на такие простые вещи из коробки была поддержка менее громоздкого синтаксиса.
XAML порой ужасен, я бы вообще взял за основу QML, а то полотно XML иногда вообще не читаемо. Описывать стили — это вообще геморой. Как сделать стиль для тесктового поля, который описал бы размер шрифта и градиентную закраску? нет ничего проще:
<Style BasedOn="{StaticResource {x:Type TextBlock}}"
       TargetType="TextBlock"
       x:Key="TitleText">
  <Setter Property="FontSize" Value="26"/>
  <Setter Property="Foreground">
  <Setter.Value>
      <LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1">
        <LinearGradientBrush.GradientStops>
          <GradientStop Offset="0.0" Color="#90DDDD" />
          <GradientStop Offset="1.0" Color="#5BFFFF" />
        </LinearGradientBrush.GradientStops>
      </LinearGradientBrush>
    </Setter.Value>
  </Setter>
</Style>


А так, да, главное:
1) Перфоманс (скорость запуска и рендеринг сложных форм)
2) Шрифты — вырвиглазное мыло (с обычным, офисным DPI).
3) Унификация с windows 8, wp8
4) И, желательно, всё в опен сорс.
Вместо того, чтобы самому руками в коде поделить текст на Run и Hyperlink, вы генерируется руками хмл, который потом, тратя перфоманс, распаршивается во всё теже Run и Hyperlink.
и даже без DataContext, решарпер (будем считать, что это нативная поддеркжа) будет следить за тем, что бы биндинги тоже переименовывались после переименовки свойств во вьюмодели.
и даже без DataContext, решарпер (будем считать, что это нативная поддеркжа) будет следить за тем, что бы биндинги тоже переименовывались после переименовки свойств во вьюмодели.
Интересное решение, спасибо за объяснение. Давно не использовал WPF. Но все равно биндинг немного монструозненько выглядит для такой простой операции.
Выглядит интересно, но нет нативной поддержки — не type safe (переименовки, подсказчик при написании лямбды).
И вопрос перфоманса интересует, используется GenerateCodeFromCompileUnit (а wpf и так медленный).
На мобильном XAML (wp8, win8) такое и работать в принципе не будет.
Во-первых, более громоздко, да. Во-вторых, в WP8/Win8 даже дататриггеры не завезли.
Кстати, в том же Android+MvvmCross такой биндинг бы выглядел так:
local:MvxBind="Enabled Inverse(IsBusy)"
Есть еще новый www.telerik.com/nativescript он выглядит горааааздо интереснее Xamarin.Forms (который за год так и не стал менее унылым).
У обычного Xamarin ниша есть и спрос растёт, но не будет большим. На нем имеет смысл писать только при двух условиях:
— много общей логики на клиенте
— у вас под рукой дешевый дотнетчик
при этом оно не будет запускаться мгновенно и вы будете бороться с кучей утекающих грефов при сложном интерфейсе (android).
Увы, это правда. Даже жалко времени, потраченного на XAML related технологии (wpf, sl, wp8, win8). Прошло много лет — ничего не поменялось.
2015ый год, чтобы забиндить !IsBusy на IsEnabled мы пишем:
"{Binding IsBusy, Converter={StaticResource InverseBooleanConverter}}"

SL мёртв (даже презентации МС проводит во флеше), WPF жив старыми ентерпрайзоными проектами, WP8 имеет долю в пару процентов в мире. Win8 приложения вообще никому не нужны.
Опять ждать/надеятся на Вин10, как ждали вп8+вин8… нет сил.
Как не прискорбно, но будущее видется за js.

Информация

В рейтинге
1 088-й
Зарегистрирован
Активность