Pull to refresh

Comments 20

Рад, что кому-то пригодилось!
Не очень знаком с мобильным фреймворком, подобное решение с WinRT совместимо?
Как есть, использовать точно не получится.

Сборка System.Windows.Interactivity для Win RT приложений отсутствует, но можно воспользоваться этой сторонней библиотекой.
Также у них своя рефлексия, нужно заменить многие вызовы на RT-шные.
После этого, у меня с ходу не получилось динамически добавить обработчик события методом AddEventHandler().
Выдает следующее исключение:
InvalidOperationException: Adding or removing event handlers dynamically is not supported on WinRT events.

Завтра вечером посмотрю, какие тут могут быть варианты решения.
Спасибо. Этот вариант требует 2013-ую студию?
Бился, бился, но в WinRT напрочь отказывается работать привязка к свойству поведения. При этом никаких ошибок нет, она просто не работает.
Не понимаю, баг это или фича, но в сети туча народу недовольны кривой работай привязок в WinRT.
Другие различные проблемы с рефлексией и классом поведений удалось решить сторонними пакетами. Спасибо DobroeZlo.
Создал бранч с моей неудачной попыткой: github.com/AndreyMikhailov/DependecyPropertyBehavior/tree/WinRT
Код стал короче. Если у кого есть идеи как его починить, то буду очень рад услышать.
Сам код
using System;
using System.Reactive.Linq;
using System.Reflection;
using Windows.UI.Interactivity;
using Windows.UI.Xaml;

namespace WindowsRTExample
{
    public class DependecyPropertyBehavior : Behavior<FrameworkElement>
    {
        private PropertyInfo _propertyInfo;

        public static readonly DependencyProperty BindingProperty = DependencyProperty.Register(
            "Binding",
            typeof(object),
            typeof(DependecyPropertyBehavior),
            new PropertyMetadata(null, PropertyChangedCallback)
            );

        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()
        {
            if (Property == null) return;

            _propertyInfo = AssociatedObject.GetType().GetTypeInfo().GetDeclaredProperty(Property);
            if (_propertyInfo == null) return;
            if (UpdateEvent == null) return;

            var eventInfo = Observable.FromEventPattern<RoutedEventArgs>(AssociatedObject, UpdateEvent);
            if (eventInfo == null) return;
            
            eventInfo.Subscribe(ep => EventFired());
        }

        private static void PropertyChangedCallback(DependencyObject sender, DependencyPropertyChangedEventArgs e)
        {
            var behavior = (DependecyPropertyBehavior)sender;
            PropertyInfo property = behavior.AssociatedObject.GetType().GetTypeInfo().GetDeclaredProperty(behavior.Property);
            if (property == null) return;

            object oldValue = property.GetValue(behavior.AssociatedObject);

            if (oldValue == null && e.NewValue == null) return;
            if (oldValue != null && oldValue.Equals(e.NewValue)) return;

            property.SetValue(behavior.AssociatedObject, e.NewValue);
        }

        private void EventFired()
        {
            Binding = _propertyInfo.GetValue(AssociatedObject, null);
        }
    }
}

Привязка для свойств отличных от свойств зависимостей

Пожалуйста, переведите это обратно, а то парсится с трудом
Готов поменять заголовок, если предложите лучшее название. Сам долго ломал голову как кратко написать, что речь идет про привязку в обычных свойствах .NET, но ничего лучше, кроме как противопоставить их свойствам зависимостей, где эта привязка доступна по умолчанию, не нашел.
А чем в общем-то плохи Binding, Property и DependencyProperty? Всё равно если не знаешь, что это такое, то и статью не поймешь.
Сама статья годная, большое спасибо :-)
Не за что.
Просто хотелось все на русском писать (не знаю почему), тем более есть устоявшийся перевод. В общем, дело вкуса. =)
Упростил заголовок. На большее меня вряд ли хватит. :-)
Вроде бы PasswordBox сделали недоступным для биндинга из соображений безопасности. Получается, что применительно к PasswordBox это решение ломает предусмотренную безопасность?
Тут есть два момента:

1. В теории, хранить незашифрованный пароль в памяти небезопасно.
На практике, если плохиши получили доступ к ОЗУ, то на передний план выходят проблемы похуже, кражи паролей.
Подробнее можно почитать это обсуждение на StackOverflow.

2. Можно привязаться к свойству для чтения SecurePassword имеющее тип SecureString. Это решит беспокойства по пункту 1. Правда в классе поведения нужно будет добавить проверку на доступность записи в свойство. Не подумал об этом заранее. Как будет время, отредактирую класс.
По пункту 1 согласен полностью, кажется что это чрезмерное усиление безопасности там, где не надо. Но я не спец по информационной безопасности и допускаю, что не мне об этом судить, поэтому и задал вопрос.
В приведенной Вами ссылке целовек пишет:
Keeping your password in plain text on the client machine RAM is a security no-no
Но он не говорит почему это так важно. Если есть доступ к RAM, то машина уже скомпроментирована, разве нет?
Человек пишет, но в комментариях его переубеждают. :-) Впрочем, тут обе позиции имеют право на существование.

Скомпрометирована ли машина, если у злоумышленника есть доступ к ОЗУ — это вопрос архитектуры приложения.
Можно предусмотреть шифрование памяти или отдельных ее блоков.
Но, в общем случае, можно считать, что да — машина скомпрометирована.
Хорошая статья, спасибо.
Только вот с этим не совсем согласен:
Тем не менее, часто приходится писать не разметку, а код, который помогает первой работать как надо. Хотелось бы этого избегать и писать чистый XAML, но до сих пор ни одно мое приложение сложнее простого не обходилось без различных хелперов (классов-помощников), написанных на C#. К счастью, есть распространенные случаи, где можно одним хелпером решить сразу группу проблем.

Я не скажу, что супер-скилловый разработчик на WPF, но по-моему опыту не то, что одним хелпером не получается решить проблему, а то, что костыли просто наслаиваются друг на друга, образуя сложную взаимосвязанную систему. Вспоминается старый прикол:
Обсуждение на ЛОРе «Какие ассоциации вызывает у вас Linux»:

xxx: большой костыль, созданный из миллиардов маленьких костылей подпирающих один другого. костыль свободно парит в невесомости.


Не буду перечислять, что мне не нравится в WPF пересказывать одноименную статью, однако я осуществил давнюю мечту и на windows camp 2013 на конференции WPF спросил, будет ли когда-нибудь введена фича, позволяющая вместо написания конвертеров на каждый чих использовать хотя бы примитивную арифметику и булевскую алгебру, неявная конвертация перечисления Visiblity в bool и прочее. Ответом было: идите нафиг, у нас есть более важные дела, например, сделать новый хаб для Modern UI. С тех пор я открыл для себя Asp.Net, как и автор той статьи, чего и вам желаю.

Когда мне нужно написать десктопное приложение, я беру WPF и пишу на нем. Но делаю это без того удовольствия, с которым я делаю странички Asp.Net.

Еще раз спасибо за статью.
Не за что! Да, согласен, что WPF совсем не развивается. Помню статья с год назад об этом была. Возможно, разработчики считают, что он уже вполне допилен. Жаль.
Тем не менее, WPF для меня до сих вполне неплохой вариант написания UI, даже со всеми его костылями. Наверное, потому что пока мало знаком с ASP и не с чем сравнивать. :-)

Sign up to leave a comment.

Articles