INotifyPropertyChange – notifying about change of all properties at once

2014-08-242016-01-30 TPodolakINotifyPropertyChanged, MVVM, Silverlight, WPF1 Comment

Today, working on a new feature for my pet project, I realized that I have to notify the view, that all properties in view model have changed. The most obvious way to achieve that would, of course be to rise PropertyChange event a bunch of times.

protected virtual void OnPropertyChanged(Expression<Func<object>> propertyExpression)
{
   //..
   //implementation
   //..
}

protected virtual void OnPropertyChanged(string propertyName)
{
   //..
   //implementation
   //..
}

public void Refresh()
{
   OnPropertyChanged(() => FirstProperty);
   OnPropertyChanged(() => SecondProperty);
   OnPropertyChanged(() => ThirdProperty);
   //and so on ...
}

protected virtual void OnPropertyChanged(Expression<Func<object>> propertyExpression)

{

//..

//implementation

//..

}

protected virtual void OnPropertyChanged(string propertyName)

{

//..

//implementation

//..

}

public void Refresh()

{

OnPropertyChanged(() => FirstProperty);

OnPropertyChanged(() => SecondProperty);

OnPropertyChanged(() => ThirdProperty);

//and so on ...

}

This is good solution for one time usage, however I was interested in something more general, something which could be extracted to base view model. Fortunately, it turns out that there is a simple trick to do that. All You have to do is use an empty string or null as a property name. So in my case this comes down to this one-liner

public void Refresh()
{
   OnPropertyChanged(string.Empty);
}

public void Refresh()

{

OnPropertyChanged(string.Empty);

}

Tworzenie bootstrappera aplikacji przy użyciu CaliburnMicro

2012-05-072016-01-31 TPodolakCaliburnMicro, MVVM, Silverlight5, Windows Phone, WPF

Witam po długiej przerwie. W dzisiejszym wpisie postaram się krótko opisać w jaki sposób stworzyć bootstrapper aplikacji przy użyciu CaliburnMicro. Ponadto przedstawię w jaki sposób skonfigurować bootstrapper w taki sposób, aby Caliburn wykorzystywał nasz własny kontener IOC.

1. Wstęp

CaliburnMicro jest to framework MVVM, który w znacznym stopniu ułatwia i przyśpiesza pisanie aplikacji pod WPF,Silverlight,WindowsPhone oraz WinRT. Zdecydowałem się poznać ten framework z uwagi na jego przenośność na różne platformy. Wcześniej całkiem sporo czasu poświęciłem Prismowi, jednakże z powodu licznych problemów z jego działaniem pod WindowsPhonem chciałem spróbować czegoś nowego.

2. Bootstrapper – Silverlight

Bootstrapper jest to ogólnie rzecz biorąc klasa inicjalizująca całą aplikację. W trakcie odpalania bootstrappera na ogół konfiguruje się kontener IOC(rejestruje wszystkie potrzebne typu), inicjalizuje się połączenie z serverem, oraz odpala się główne okno aplikacji – tzw. Shella. Dlatego też musimy odchudzić plik App.xaml.cs i zostawić w nim jedynie konstruktor wraz z wywołaniem funkcji InitializeComponents()

public partial class App : Application
{
    public App()
    {          
        InitializeComponent();
    }
}

public partial class App : Application

{

public App()

{

InitializeComponent();

}

Zacznijmy od utworzenia nowego projektu typu SilverlightApplication, do którego dodajemy referencje do dll-ek Cliburna. Możemy to zrobić poprzez NuGetta (niestety u mnie one nie działały :D), jak również możemy je ściągnąć z oficjalnej strony projektu http://caliburnmicro.codeplex.com/releases/view/81466. Następnie stwórzmy główne okno aplikacji(wspomnianego wcześniej Shella) oraz jego viewmodel. W tym celu dodajemy do projektu Silverlight User Control o nazwie ShellView

oraz nową klasę ShellViewModel.

Dorzućmy jeszcze jakiegoś TextBox-a do naszego ShellView, tak aby mieć pewność, że rzeczywiście odpowiednie okno jest widoczne przy starcie aplikacji

<UserControl x:Class="Loginv2.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro" mc:Ignorable="d" Height="516" Width="792">

    <Grid x:Name="LayoutRoot"  >
        <TextBox Text="oto jest shell"/>
    </Grid>
</UserControl>

<UserControl x:Class="Loginv2.ShellView"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro" mc:Ignorable="d" Height="516" Width="792">

</Grid>

</UserControl>

W kolejnym kroku musimy stworzyć właściwy bootstrapper – dodajmy nową klasę o nazwie SilverlightBootstrapper, która dziedziczyć będzie po klasie Bootstrapper

namespace Client.Silverlight
{
    public class SilverlightBootstrapper : Bootstrapper<ShellViewModel>
    {
    
    }
}

namespace Client.Silverlight

{

public class SilverlightBootstrapper : Bootstrapper<ShellViewModel>

{

}

Klasa Bootstrapper jest to klasa dostarczona przez CaliburnMicro, generyczny parametr T określa nam viewmodel na podstawie którego framework będzie wyszukiwał odpowiedni widok shella ze swojego wbudowanego kontenera IOC (Caliburn podczas uruchomienia aplikacji rejestruje dostępne typu w kontenerze). Zgodnie z domyślną konwencją, CaliburnMicro jako główne okno aplikacji ustawi widok, który nazywać się będzie ShellView. W celu odpalenia naszego bootstrappera musimy jeszcze umieścić go w zasobach aplikacji. Zmodyfikujmy zatem plik App.xaml aby wyglądał w następujący sposób

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Silverlight="clr-namespace:Client.Silverlight" x:Class="Client.Silverlight.App">
    <Application.Resources>
        <Silverlight:SilverlightBootstrapper x:Key="Bootstrapper"></Silverlight:SilverlightBootstrapper>
    </Application.Resources>
</Application>

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:Silverlight="clr-namespace:Client.Silverlight" x:Class="Client.Silverlight.App">

<Application.Resources>

<Silverlight:SilverlightBootstrapper x:Key="Bootstrapper"></Silverlight:SilverlightBootstrapper>

</Application.Resources>

</Application>

Kompilując, a następnie uruchamiając nasz projekt naszym oczom powinien ukazać się następujący widok

Powyżej przedstawiłem w jaki sposób stworzyć najprostszą wersję bootstrapera z wykorzystaniem CaliburnMicro oraz jego domyślnego kontenera IOC. Jednakże najczęściej jest tak, że w aplikacji wykorzystujemy już jakiś bardziej zaawansowany kontener i po prostu nie chcemy wykorzystywać jednego kontenera do “rozwiązywania” widoków, a drugiego do pozostałych rzeczy. Dlatego też pokaże teraz w jaki sposób skonfigurować napisany wcześniej bootstrapper tak aby widoki były wyciągane z naszego kontenera IOC. Zacznijmy do dodania do naszego projektu referencji do NInjecta, a następnie utwórzmy klasę IOCContainer (będącą naszym customowym kontenerem), wyglądającą w następujący sposób

public class IOCContainer
{
    private static readonly IKernel Kernel = new StandardKernel();

    protected IOCContainer()
    {

    }

    public static void Dispose()
    {
        Kernel.Dispose();
    }

    public static object Get(Type type)
    {
        return Kernel.Get(type);
    }

    public static object Get(Type type,string key)
    {
        return Kernel.Get(type, key);
    }
  
    public static IEnumerable<object>  GetAll(Type instanceType)
    {
        return Kernel.GetAll(instanceType);
    }
  
    public static void Bind<T, TS>() where TS : T
    {
        Kernel.Bind<T>().To<TS>();
    } 
}

public class IOCContainer

{

private static readonly IKernel Kernel = new StandardKernel();

protected IOCContainer()

{

}

public static void Dispose()

{

Kernel.Dispose();

}

public static object Get(Type type)

{

return Kernel.Get(type);

}

public static object Get(Type type,string key)

{

return Kernel.Get(type, key);

}

public static IEnumerable<object> GetAll(Type instanceType)

{

return Kernel.GetAll(instanceType);

}

public static void Bind<T, TS>() where TS : T

{

Kernel.Bind<T>().To<TS>();

}

Następnie w klasie SilverlightBootstraper musimy przeciążyć funkcję Configure,GetAllInstances oraz GetInstance. Jako, że będziemy korzystali z naszego własnego kontenera w funkcji Configure rejestrujemy wszystkie potrzebne nam viewmodele oraz widoki. Zatem funkcja Configure powinna od teraz wyglądać tak

protected override void Configure()
{
    IOCContainer.Bind<ShellView,ShellView>();
    IOCContainer.Bind<ShellViewModel,ShellViewModel>();
}

protected override void Configure()

{

IOCContainer.Bind<ShellView,ShellView>();

IOCContainer.Bind<ShellViewModel,ShellViewModel>();

}

Następnie musimy “pokazać” Caliburn-owi gdzie powinien szukać widoków. Dlatego też przeciążamy funkcje GetInstance oraz GetAllInstances i zmieniamy ich postać na następującą

protected override object GetInstance(Type serviceType, string key)
{
    return IOCContainer.Get(serviceType, key);
}

protected override IEnumerable<object> GetAllInstances(Type serviceType)
{
    return IOCContainer.GetAll(serviceType);
}

protected override object GetInstance(Type serviceType, string key)

{

return IOCContainer.Get(serviceType, key);

}

protected override IEnumerable<object> GetAllInstances(Type serviceType)

{

return IOCContainer.GetAll(serviceType);

}

Od tej pory, za każdym razem gdy użyjemy mechanizmów Caliburna do bindowania viewmodelu z widokiem itp.,Caliburm będzie szukał widoków oraz viewmodeli w naszym kontenerze IOC.

2.2 Własna konwencja wyszukiwania widoków

W przedstawionym powyżej przykładzie bootstrappera, nasz bootstrapper korzystał z domyślnej konwencji rozwiązywania widoków na podstawie viewmodeli (do ShellViewModel został dopasowany widok ShellView). Czasem jednak konwencja ta, nie pasuje do konwencji przyjętej w danym projekcie. Sam biorę udział w projekcie, w którym widoki w kontenerze są rejestrowane następujący sposób

IOCContainer.Bind<IView<ViewModel>,View>

1	IOCContainer.Bind<IView<ViewModel>,View>

Czy zatem oznacza to, że nie mogę korzystać już mechanizmów Caliburna i musze zrezygnować chociażby z bootstrappera ?Oczywiście,że nie. Framework dostarcza nam możliwość zdefiniowania własnej konwencji wyszukiwania widoków na podstawie viewmodeli. W celu zastąpienia domyślnej konwencji musimy podpiąć się pod propercję LocateForModelType znajdującą się w klasie ViewLocator i zdefiniować własną funkcję wyszukującą widok na podstawie viewmodelu. W moim przypadku wygląda to w następujący sposób

ViewLocator.LocateForModelType = (modelType, displayLocation, context) =>
                                                 {
                                                     string viewTypeName = string.Format("{0}[[{1}]],{2}", typeof(IView<>).FullName, modelType.AssemblyQualifiedName, typeof(IView<>).Assembly.FullName);
                                                     Type viewType = Type.GetType(viewTypeName);
                                                     if (viewType == null)
                                                         throw new ArgumentNullException(string.Format("Nie odnaleziono typu widoku dla viewModelu"), modelType.FullName);

                                                     return ViewLocator.GetOrCreateViewType(viewType);
                                                 };

ViewLocator.LocateForModelType = (modelType, displayLocation, context) =>

{

string viewTypeName = string.Format("{0}[[{1}]],{2}", typeof(IView<>).FullName, modelType.AssemblyQualifiedName, typeof(IView<>).Assembly.FullName);

Type viewType = Type.GetType(viewTypeName);

if (viewType == null)

throw new ArgumentNullException(string.Format("Nie odnaleziono typu widoku dla viewModelu"), modelType.FullName);

return ViewLocator.GetOrCreateViewType(viewType);

};

Funkcja ViewLocator.LocateForModelType odpalana jest za każdym razem, gdy CaliburnMicro chce wyszukać widok na podstawie viewmodleu. Najważniejszym argumentem funkcji LocateForModelType jest modelType – czyli typ viewmodelu, który posłuży nam do znalezienia widoku – a właściwie jego typu. Po odnalezieniu typu widoku, wywołujemy funkcję

ViewLocator.GetOrCreateViewType(viewType);

1	ViewLocator.GetOrCreateViewType(viewType);

(które z kolei znajdzie nam w kontenerze pożądanym przez nas typ widoku) i zwracamy jej rezultat.

3. Bootstrapper – Windows Phone

W przypadku bootstrappera dla Windows Phona sytuacja wygląda odrobinę inaczej. W celu utworzenia własnego bootstrappera musimy rozszerzyć klasę PhoneBootstrapper. Utwórzmy zatem nowy projekt typu Windows Phone Application, oraz dodajmy do niego nową kontrolkę typu Windows Phone Portrait Page.

Podobnie jak w przypadku projektu Silverlightowego dodajemy referencję do CaliburnMicro ,dorzucamy klasę viewmodelu (którą nazywamy ShellViewModel) oraz dodajemy jakiegoś textboxa do ShellView. Następnie musimy utworzyć nasz bootstrapper, dodajmy zatem klasę WindowsPhoneBootstrapper rozszerzającą klasę PhoneBootstrapper. Podobnie jak w przypadku bootstrappera silverlightowego przeciążamy funkcje odpowiedzialne za konfigurację kontenera IOC.

public class WindowsPhoneBootstrapper : PhoneBootstrapper
{
    protected override void Configure()
    {
      
       IOCContainer.BindToConstant<INavigationService>(new FrameAdapter(RootFrame));
       IOCContainer.BindToConstant<IPhoneService>(new PhoneApplicationServiceAdapter(RootFrame));
       IOCContainer.BindAsSingleton<ShellViewModel, ShellViewModel>();
    }

    protected override void OnExit(object sender, EventArgs e)
    {
        IOCContainer.Dispose();
        base.OnExit(sender, e);
    }

    protected override object GetInstance(Type serviceType, string key)
    {
        return IOCContainer.Get(serviceType, key);
    }

    protected override IEnumerable<object> GetAllInstances(Type serviceType)
    {
        return IOCContainer.GetAll(serviceType);
    }

    protected override void BuildUp(object instance)
    {
        IOCContainer.Inject(instance);
    }
}

public class WindowsPhoneBootstrapper : PhoneBootstrapper

{

protected override void Configure()

{

IOCContainer.BindToConstant<INavigationService>(new FrameAdapter(RootFrame));

IOCContainer.BindToConstant<IPhoneService>(new PhoneApplicationServiceAdapter(RootFrame));

IOCContainer.BindAsSingleton<ShellViewModel, ShellViewModel>();

}

protected override void OnExit(object sender, EventArgs e)

{

IOCContainer.Dispose();

base.OnExit(sender, e);

}

protected override object GetInstance(Type serviceType, string key)

{

return IOCContainer.Get(serviceType, key);

}

protected override IEnumerable<object> GetAllInstances(Type serviceType)

{

return IOCContainer.GetAll(serviceType);

}

protected override void BuildUp(object instance)

{

IOCContainer.Inject(instance);

}

Zwróćmy uwagę, że w kontenerze IOC zostały zarejestrowane usługi nawigacji Windows Phona, do których został przekazany RootFrame. RootFrame jest to główne okno aplikacji, zostaje ono utworzone przez CliburnMicro. Tak samo jak w przypadku projektu Silverlightowego w pliku App.xaml.cs zostawiamy jedynie konstruktor z wywołaniem funkcji InitializeComponents(). W celu ustawienia ShellView jako RootFram-a musimy zmodyfikować plik WMAppManifest.xml (znajdujący się w katalogu Properties). Odnajdujemy tam wpis

<DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/>

1	<DefaultTask Name ="_default" NavigationPage="MainPage.xaml"/>

i zamieniamy go na

<DefaultTask  Name ="_default" NavigationPage="ShellView.xaml"/>

1	<DefaultTask Name ="_default" NavigationPage="ShellView.xaml"/>

Jak widać WindowsPhone wymusza tutaj podejście ViewFirst. Przy uruchomieniu aplikacji mechanizm nawigacji WindowsPhona odpali widok ShellView (bez wiedzy Caliburn’a), natomiast CaliburnMicro dopasuje odpowiedni ViewModel do naszego widoku – na podstawie domyślnej konwencji. Jeżeli chcielibyśmy zmodyfikować sposób wyszukiwania ViewModeli do widoków musimy podpiąć się do propertisa LocateForViewType znajdującego się w klasie ViewModelLocator

ViewModelLocator.LocateForViewType = type => { return //tutaj zwroc odpowiedni viewmodel na podstawie parametru type; };

1	ViewModelLocator.LocateForViewType = type => { return //tutaj zwroc odpowiedni viewmodel na podstawie parametru type; };

W ostatnim kroku musimy jeszcze tylko dodać nasz bootstrapper do zasobów aplikacji

<Application.Resources>
        <Bootstrapper:WindowsPhoneBootstrapper x:Key="Bootstrapper"></Bootstrapper:WindowsPhoneBootstrapper>
</Application.Resources>

<Application.Resources>

<Bootstrapper:WindowsPhoneBootstrapper x:Key="Bootstrapper"></Bootstrapper:WindowsPhoneBootstrapper>

</Application.Resources>

odpalając teraz program naszym oczom powinien ukazać się taki oto widok

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

2012-01-212016-01-31 TPodolakLocalization, MarkupExtension, Silverlight5, WPF

W poprzednim wpisie przedstawiłem w jaki sposób można lokalizować aplikację napisaną w Silverlight 4 oraz Windows Phone, wykorzystując do tego ten sam mechanizm. Tym razem zademonstruje w jaki sposób można nieco uprościć składnie tłumaczenia wykorzystując do tego MarkupExtension.
Jeżeli kiedykolwiek pisałeś coś w Silverlighcie, Windows Phonie lub WPF-ie istnieje duża szansa, że używałeś już MarkupExtension. Do najpopularniejszych MarkupExtensions należą takie słowa kluczowe (używane w XAML-u) jak:

Binding
StaticResource
DynamicResource
TemplateBinding

Na potrzeby mechanizmu lokalizowania aplikacji WPF (ewentualnie Silverlight 5) stworzymy customowe MarkupExtenssion, które będzie odpowiedzialne za tłumaczenie elementów UI naszej aplikacji.
Zacznijmy od przygotowania plików zasobów. Podobnie jak w poprzednim wpisie utwórzmy trzy pliki:

Localization.resx
Localization.pl-PL.resx
Localization.en-US.resx

W plikach tych będziemy przechowywać nasze tłumaczenia. Następnie stwórzmy klasę Translator, która będzie dziedziczyła po klasie MarkupExtension.Do klasy tej dodajmy właściwość

public string Key{ get; set; }

1	public string Key{ get; set; }

,która będzie przechowywać klucz dzięki któremu z pliku zasobów wyciągniemy tekst w odpowiednim języku. W kolejnym kroku musimy przeciążyć funkcję

public abstract object ProvideValue(IServiceProvider serviceProvider)

1	public abstract object ProvideValue(IServiceProvider serviceProvider)

tak aby dostarczyła nam ona przetłumaczony tekst.W moim pierwszym podejściu funkcja ta wyglądała w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding(Key) { Source = new Localization(),Mode = BindingMode.OneWay};
    return binding.ProvideValue(serviceProvider);
}

public override object ProvideValue(IServiceProvider serviceProvider)

{

Binding binding = new Binding(Key) { Source = new Localization(),Mode = BindingMode.OneWay};

return binding.ProvideValue(serviceProvider);

}

Wadami takiego rozwiązania było:

duża liczba tworzonych obiektów – przy każdym tłumaczeniu tworzyłem nowy obiekt Localization(), który prawdopodobnie może być dość ciężkim obiektem (zwłaszcza gdy będzie przechowywał dużo tłumaczonego tekstu)
brak możliwości dynamicznej zmiany języka

Ostatecznie zatem zrezygnowałem z przedstawionej wyżej opcji i zdecydowałem się na metodę odrobinę bardziej zaawansowaną. Po pierwsze utworzyłem klasę TranslationManager

public class TranslationManager
{
    public event Action<CultureInfo> LanguageChanged = val => { };
    private static TranslationManager _instance;
    private static readonly object LockInstance = new object();
    public static TranslationManager Instance
    {
        get
        {
            lock (LockInstance)
            {
                return _instance = _instance ?? new TranslationManager();
            }
        }
    }
    
    private CultureInfo _currentCulture;
    public CultureInfo CurrentCulture
    {
        get { return _currentCulture ?? (CurrentCulture = Thread.CurrentThread.CurrentUICulture); }
        set
        {
            _currentCulture = value;
            OnLanguageChanged(CurrentCulture);
        }
    }
    
    protected void OnLanguageChanged(CultureInfo culture)
    {
        LanguageChanged(culture);
    }
    
    private TranslationManager()
    {
    }
    
    public string Translate(string key)
    {
        return Localization.ResourceManager.GetString(key, CurrentCulture);
    }
}

public class TranslationManager

{

public event Action<CultureInfo> LanguageChanged = val => { };

private static TranslationManager _instance;

private static readonly object LockInstance = new object();

public static TranslationManager Instance

{

get

{

lock (LockInstance)

{

return _instance = _instance ?? new TranslationManager();

}

private CultureInfo _currentCulture;

public CultureInfo CurrentCulture

{

get { return _currentCulture ?? (CurrentCulture = Thread.CurrentThread.CurrentUICulture); }

set

{

_currentCulture = value;

OnLanguageChanged(CurrentCulture);

}

protected void OnLanguageChanged(CultureInfo culture)

{

LanguageChanged(culture);

}

private TranslationManager()

{

}

public string Translate(string key)

{

return Localization.ResourceManager.GetString(key, CurrentCulture);

}

która będzie zarządzała tłumaczeniami. Najważniejszą metodą tej klasy jest oczywiście funkcja

public string Translate(string key)

1	public string Translate(string key)

która to zwraca tekst w odpowiednim języku – w zależności od kultury, która zostanie ustawiona w TranslationManagerze. Ponadto TranslationManager posiada jedno zdarzenie

public event Action<CultureInfo> LanguageChanged

1	public event Action<CultureInfo> LanguageChanged

które ma za zadanie poinformować UI o potrzebie odświeżenia zbindowanych elementów. W jaki sposób się to odbywa ? Wszystko zawdzięczamy interfejsowi INotifyPropertyChanged oraz bindingom. Funkcja ProvideValue została zmodyfikowana w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding("Value") { Source = new TranslationItem(Key), Mode = BindingMode.OneWay };
    return binding.ProvideValue(serviceProvider);
}

public override object ProvideValue(IServiceProvider serviceProvider)

{

Binding binding = new Binding("Value") { Source = new TranslationItem(Key), Mode = BindingMode.OneWay };

return binding.ProvideValue(serviceProvider);

}

W funkcji tej tworze binding, który binduje się do właściwości Value obiektu TranslationItem. TranslationItem jest to prosty obiekt który udostępnia właściwość Value zwracającą przetłumaczony tekst. Dodatkowo obiekt ten podpina się do zdarzenia LanguageChanged z klasy TranslationManager. W przypadku gdy ktoś zmieni język aplikacji, odpalone zostanie zdarzenie NotifyPropertyChanged, które poinformuje widok o potrzebie odświeżenia odpowiednich elementów. Klasa TranslationItem wygląda zatem w następujący sposób

public sealed class TranslationItem : INotifyPropertyChanged, IDisposable
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };
    private readonly string _key;
    public TranslationItem(string key)
    {
        _key = key;
        TranslationManager.Instance.LanguageChanged += Instance_LanguageChanged;
    }

    ~TranslationItem()
    {
        Dispose();
    }

    void Instance_LanguageChanged(System.Globalization.CultureInfo obj)
    {
        PropertyChanged(this, new PropertyChangedEventArgs("Value"));
    }

    public string Value
    {
        get { return TranslationManager.Instance.Translate(_key); }
    }

    public  void Dispose()
    {
        TranslationManager.Instance.LanguageChanged -= Instance_LanguageChanged;
    }
}

public sealed class TranslationItem : INotifyPropertyChanged, IDisposable

{

public event PropertyChangedEventHandler PropertyChanged = delegate { };

private readonly string _key;

public TranslationItem(string key)

{

_key = key;

TranslationManager.Instance.LanguageChanged += Instance_LanguageChanged;

}

~TranslationItem()

{

Dispose();

}

void Instance_LanguageChanged(System.Globalization.CultureInfo obj)

{

PropertyChanged(this, new PropertyChangedEventArgs("Value"));

}

public string Value

{

get { return TranslationManager.Instance.Translate(_key); }

}

public void Dispose()

{

TranslationManager.Instance.LanguageChanged -= Instance_LanguageChanged;

}

Mając gotowy mechanizm tłumaczący możemy wykorzystać go w następujący sposób w XAML-u

<Label Content="{WPFMarkupExtension:Translator Key=Title}"/>

1	<Label Content="{WPFMarkupExtension:Translator Key=Title}"/>

Zauważmy, że tekst do labelki jest przypisywany z wykorzystywaniem naszego customoweog MarkupExtension – WPFMarkupExtension:Translator (WPFMarkupExtension – jest to alias na namespace, w którym znajduje się nasza klasa Translator). W składni przekazujemy do właściwości Key klucz do tekstu (znajdującego się w resourcach), który chcemy tłumaczyć. W celu zmiany języka wystarczy, że ustawimy interesującą nas kulturę w klasie TranslationManager

TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US")

1	TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US")

Przykładowy widok wykorzystujący napisany translator, oraz pokazujący dynamiczną zmianę języka może wyglądać w następujący sposób (dorzucamy następujące linijki do MainWindow.xaml)

<StackPanel>
    <Label Content="{WPFMarkupExtension:Translator Key=Key}"/>
    <Button Command="{Binding PolishCommand}">Polski</Button>
    <Button Command="{Binding EnglishCommand}">English</Button>
</StackPanel>

<Button Command="{Binding PolishCommand}">Polski</Button>

<Button Command="{Binding EnglishCommand}">English</Button>

</StackPanel>

Następnie tworzymy ViewModel do naszego okna

public class MainPageViewModel
{
        public DelegateCommand PolishCommand { get; set; }
        public DelegateCommand EnglishCommand { get; set; }
        
        public MainPageViewModel()
        {
            PolishCommand = new DelegateCommand(()=> TranslationManager.Instance.CurrentCulture = new CultureInfo("pl-PL"));
            EnglishCommand = new DelegateCommand(()=>TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US"));
        }
}

public class MainPageViewModel

{

public DelegateCommand PolishCommand { get; set; }

public DelegateCommand EnglishCommand { get; set; }

public MainPageViewModel()

{

PolishCommand = new DelegateCommand(()=> TranslationManager.Instance.CurrentCulture = new CultureInfo("pl-PL"));

EnglishCommand = new DelegateCommand(()=>TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US"));

}

Ostatecznie przypisujemy obiekt klasy MainPageViewModel do DataContextu MainWindow.xaml

public MainWindow()
{
    InitializeComponent();
    DataContext = new MainPageViewModel();
}

public MainWindow()

{

InitializeComponent();

DataContext = new MainPageViewModel();

}

Kod do projektu można znaleźć pod tym linkiem
http://www.4shared.com/rar/SwDXay7V/WPFMarkupExtension.html

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.2

2011-12-252016-01-31 TPodolakAuthentication, Authorization, Silverlight, WPF

W poprzednim wpisie przedstawiłem w jaki sposób zaimplementować mechanizm logowania po stronie serwera. Wykorzystałem do tego celu WCF RIA oraz znane z ASP MembershipProvidery. Tym razem przedstawię jak wymusić logowanie po stronie klienta, oraz w jaki sposób można dynamicznie zmieniać providerów, którzy walidują usera.
Poprzednim razem stworzyliśmy już szkielet aplikacji, zatem mamy projekt klienta oraz projekt serwera. Zacznijmy od “włączenia” FormsAuthentication po stronie klienta. W pliku App.xaml.cs , w konstruktorze dorzućmy następujące linijki

WebContext context = new WebContext {Authentication = new FormsAuthentication()};
ApplicationLifetimeObjects.Add(context);

1 2	WebContext context = new WebContext {Authentication = new FormsAuthentication()}; ApplicationLifetimeObjects.Add(context);

Następnie zanim pokażemy treść naszej strony, musimy sprawdzić czy użytkownik jest zalogowany.Jeżeli nie, należy pokazać okno logowania. Możemy to zrobić w następujący sposób.

if (!WebContext.Current.User.IsAuthenticated)
{
    ModalDialogService.ShowDialog(_unityContainer.Resolve<IModalView<LoginViewModel>>(),
                                  val => { InitializeView();GetSecureData(); });
}
else
{
    InitializeView();
    GetSecureData();
}

if (!WebContext.Current.User.IsAuthenticated)

{

ModalDialogService.ShowDialog(_unityContainer.Resolve<IModalView<LoginViewModel>>(),

val => { InitializeView();GetSecureData(); });

}

else

{

InitializeView();

GetSecureData();

}

WebContext jest to klasa generowana automatycznie przy buildowaniu solucji.Jej kod powinniśmy odnaleźć w katalogu Generated_Code po stronie klienta. Klasa ta posiada właściwość Current, która zwraca obecny context zarejestrowany w kolekcji ApplicationLifetimeObjects.
Okno logowania zostało zaimplementowane jako ChildWindow. Jego kod może wyglądać w następujący sposób

<Grid x:Name="LayoutRoot" Margin="2">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        <StackPanel VerticalAlignment="Center">
            <sdk:Label Content="Login"></sdk:Label>
            <TextBox Text="{Binding Login,NotifyOnValidationError=True,Mode=TwoWay}" >
               
            </TextBox>
            <sdk:Label Content="Hasło"</sdk:Label>
            <PasswordBox  Password="{Binding Password,NotifyOnValidationError=True,Mode=TwoWay}" >
            </PasswordBox>
        </StackPanel>
        <Button x:Name="CancelButton" Content="Cancel" Click="CancelButton_Click"  Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
        <Button x:Name="OKButton" Content="OK" Command="{Binding OkCommand}" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />
</Grid>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<sdk:Label Content="Login"></sdk:Label>

</TextBox>

<sdk:Label Content="Hasło"</sdk:Label>

</PasswordBox>

</StackPanel>

</Grid>

Kontrolka logowania jest bardzo prosta, składa się ona z dwóch labelek, textboxa oraz passwordBoxa. Powyższy kod powinien wygenerować mniej więcej takie oto okno

Mechanizm wywoływania operacji logowania znajduje się natomiast w ViewModelu kontrolki logowania. Po naciśnięciu przycisku OK, dzięki zastosowaniu DelegateCommand uruchamiany następującą funkcję

private void OkCommandExecuted()
{
    if (Validate())
    {
        PerfomrLoginOperation();
    }
}

private void OkCommandExecuted()

{

if (Validate())

{

PerfomrLoginOperation();

}

W funkcji tej najpierw sprawdzamy, czy użytkownik podał dane do logowania, a następnie wywołujemy kolejną funkcję PerfomrLoginOperation. Przedstawia się w następujący sposób

private void PerfomrLoginOperation()
{      
    WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,string.Empty, CompleteLoginOperation, Guid);
}

private void PerfomrLoginOperation()

{

WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,string.Empty, CompleteLoginOperation, Guid);

}

Widzimy zatem, że wywołujemy funkcję logowania z serwisu WCF, w parametrach natomiast podajemy login oraz hasło przechwycone z okna. Dodatkowo w parametrze podajemy delegata do funkcji, która zostanie wykonana po zakończeniu operacji logowania.

private void CompleteLoginOperation(LoginOperation loginOperation)
{
    if (loginOperation.Error == null)
        OnOperationCompleted();
    else
    {
        if (loginOperation.Error is FormsAuthenticationLogonException)
            MessageBoxService.ShowMessageBox("Nieprawidłowy login lub hasło", MessageBoxButton.OK);
        else
            MessageBoxService.ShowMessageBox("Wystąpił problem podczas operacji logowania",
                                             MessageBoxButton.OK);
    }
}

private void CompleteLoginOperation(LoginOperation loginOperation)

{

if (loginOperation.Error == null)

OnOperationCompleted();

else

{

if (loginOperation.Error is FormsAuthenticationLogonException)

MessageBoxService.ShowMessageBox("Nieprawidłowy login lub hasło", MessageBoxButton.OK);

else

MessageBoxService.ShowMessageBox("Wystąpił problem podczas operacji logowania",

MessageBoxButton.OK);

}

Jeżeli odpowiedź z serwisu WCF zawiera błędy to wiemy, że operacja logowania się nie powiodła. Wyświetlamy zatem stosowny komunikat. Jeżeli natomiast wszystko jest Ok, pole loginOperation.Error będzie miało wartość null. Możemy wtedy pokazać naszą wiadomość dostępną jedynie dla zalogowanych użytkowników.
Mamy zatem ochronę przeciwko nieautoryzowanemu dostępowi do klienta. Jednak co w przypadku gdy nasz klient musi w calach np. zassania danych pobrać je przy wykorzystaniu jakiegoś WebServicu. Na ogól wystawiany jest wtedy drugi WebService do pobierania danych z jakiejś bazy. Do takiego WebServicu w teorii może dostać się każdy – my natomiast chcemy żeby dane można było pobierać jedynie po zalogowaniu się do aplikacji. Na szczęście nasz dodatkowy WebServise można w prosty sposób zabezpieczyć przed dostępem osób trzecich. Stwórzmy zatem sobie nowy WebService służący do pobierania danych. Do projektu Webowego dodajmy nową klasę typu “Domain Service” oraz dopiszmy do nie jedną metodę symulującą pobieranie danych.

[EnableClientAccess()]
public class DataAccesService : DomainService
{
    public string GetSecureData()
    {
        return "very secure data";
    }
}

[EnableClientAccess()]

public class DataAccesService : DomainService

{

public string GetSecureData()

{

return "very secure data";

}

Do takiego Servicu może dostać się każdy. Jeżeli natomiast naszą klasę udekorujemy atrybutem [RequiresAuthentication()] tylko użytkownicy, którzy pomyślnie przeszli autentykację przez nasz CustomAuthenticationService będą w stanie pobrać dane. W przeciwnym wypadku zostanie rzucony wyjątek.

Zastanówmy się teraz w jaki sposób można byłoby logować się do naszej aplikacji np. przy pomocy konta Google. Zacznijmy od tego, że musimy stworzyć własny MembershipProvider. W tym celu dodajmy do projektu Webowego nową klasę “GoogleMembershipProvider“, która będzie rozszerzać klasę MembershipProvider. Klasa MembershipProvider jest klasą abstrakcyjną zatem musimy zoverridować wszystkie jej funkcje (nie musimy wrzucać tam logiki, narazie po prostu wpiszmy tam cokolwiek aby przeszła kompilacja). Mając stworzony szkielet providera musimy go dorzucić do listy wszystkich providerów (tak jak to zrobiliśmy z SqlMembershipProvider-em). Modyfikujemy zatem sekcję podsekcję providers z sekcji membership na następującą.

<membership
            defaultProvider="PremiumHandsMembershipProvider"
            userIsOnlineTimeWindow="20">
      <providers>
        <clear/>
        <add name="PremiumHandsMembershipProvider"
             connectionStringName="aspnetdbConnectionString"
            type="System.Web.Security.SqlMembershipProvider"
            enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/" />
        <add name="GoogleMembershipProvider"
             type="MainModule.Web.Providers.GoogleMembershipProvider"
             enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/"
             />
      </providers>
</membership>

<membership

defaultProvider="PremiumHandsMembershipProvider"

userIsOnlineTimeWindow="20">

<add name="PremiumHandsMembershipProvider"

connectionStringName="aspnetdbConnectionString"

type="System.Web.Security.SqlMembershipProvider"

enablePasswordRetrieval="false"

enablePasswordReset="false"

requiresQuestionAndAnswer="true"

passwordFormat="Hashed"

applicationName="/" />

<add name="GoogleMembershipProvider"

type="MainModule.Web.Providers.GoogleMembershipProvider"

enablePasswordRetrieval="false"

enablePasswordReset="false"

requiresQuestionAndAnswer="true"

passwordFormat="Hashed"

applicationName="/"

</providers>

</membership>

Mając w kolekcji wszystkie nasze providery pozostaje nam się zastanowić, w jaki sposób raz używać GoogleMembershpProvidera, a innym razem SqlMembershipProvidera. Ja zrobiłem to w następujący sposób. Najpierw utworzyłem enuma, w którym przechowuje “nazwy” moich providerów

public enum AccountType
{
    PremiumHandsMembershipProvider,
    GoogleMembershipProvider,
    Facebook
}

public enum AccountType

{

PremiumHandsMembershipProvider,

GoogleMembershipProvider,

Facebook

}

Następnie wykorzystałem parametr customData interfejsu IAuthentication. Po stronie klienta w funkcji logowania po prostu przesyłam typ konta do którego się loguję. Wygląda to w ten sposób:

 WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,AccountType.GoogleMembershipProvider.ToString("g")), CompleteLoginOperation, Guid);

1	WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,AccountType.GoogleMembershipProvider.ToString("g")), CompleteLoginOperation, Guid);

Następnie po stronie serwera wybieram tego providera, przez którego loguje się użytkownik.

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
{
    UserDTO user = null;
    userData = null;
    if (Membership.Providers[customData].ValidateUser(name, password))
    //if (Membership.Provider.ValidateUser(name, password))
    {
        userData = name;
        user = new UserDTO { DisplayName = name, Name = name, Email = name};
    }
    if (user != null) userData = name;
    return user;
}

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)

{

UserDTO user = null;

userData = null;

if (Membership.Providers[customData].ValidateUser(name, password))

//if (Membership.Provider.ValidateUser(name, password))

{

userData = name;

user = new UserDTO { DisplayName = name, Name = name, Email = name};

}

if (user != null) userData = name;

return user;

}

Zauważmy, że linijka

if (Membership.Provider.ValidateUser(name, password))

1	if (Membership.Provider.ValidateUser(name, password))

została zastąpiona przez

if (Membership.Providers[customData].ValidateUser(name, password))

1	if (Membership.Providers[customData].ValidateUser(name, password))

zatem teraz mamy wpływ na to, którego MembershipProvidera użyjemy. Jeżeli chodzi o samo sprawdzenie czy dany użytkownik podał poprawne dane do konta google, to sprawa jest trochę kłopotliwa(tak mi się wydaje :D). Nie udało mi się użyć biblioteki dotNetOpenAuth, gdyż z tego co widzę logowanie poprzez tą bibliotekę wymaga przekierowania na stronę Googla. Niestety taka operacja nie jest dozwolona w Silverlighcie (Silverlight nie wspiera cross-domain policy). Ponadto wykorzystanie tej biblioteki po stronie serwera również nie przyniosło oczekiwanych rezultatów. Ostatecznie zatem skorzystałem z opisu znajdującego się na stronie Googla http://code.google.com/intl/pl-PL/apis/accounts/docs/AuthForInstalledApps.html#Using. Czyli po prostu spreparowałem odpowiedni HTTPS Post Request. Funkcja ValidateUser z GoogleMembershipProvidera wygląda zatem następująco

public override bool ValidateUser(string username, string password)
{
    string requestUrl = string.Format("https://www.google.com/accounts/ClientLogin?service=mail&Email={0}&Passwd={1}", username, password);
    byte[] data = Encoding.ASCII.GetBytes(requestUrl);
    HttpWebRequest req = (HttpWebRequest)WebRequest.Create(requestUrl);
    req.ProtocolVersion = HttpVersion.Version10;
    req.ContentLength = data.Length;
    req.ContentType = "application/x-www-form-urlencoded";
    req.Method = "POST";
    var stream = req.GetRequestStream();
    stream.Write(data,0,data.Length);
    stream.Close();
    
    try
    {
        HttpWebResponse response = (HttpWebResponse)req.GetResponse();
        return response.StatusCode == HttpStatusCode.OK;
    }
    catch (WebException e)
    {
        return false;
    }
}

public override bool ValidateUser(string username, string password)

{

string requestUrl = string.Format("https://www.google.com/accounts/ClientLogin?service=mail&Email={0}&Passwd={1}", username, password);

byte[] data = Encoding.ASCII.GetBytes(requestUrl);

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(requestUrl);

req.ProtocolVersion = HttpVersion.Version10;

req.ContentLength = data.Length;

req.ContentType = "application/x-www-form-urlencoded";

req.Method = "POST";

var stream = req.GetRequestStream();

stream.Write(data,0,data.Length);

stream.Close();

try

{

HttpWebResponse response = (HttpWebResponse)req.GetResponse();

return response.StatusCode == HttpStatusCode.OK;

}

catch (WebException e)

{

return false;

}

Ciężko mi jednak stwierdzić czy takie logowanie jest bezpieczne. Co prawda nie udało mi się wyłapać nic konkretnego poprzez Wiresharka lub Fiddlera, jednakże ekspertem od zabezpieczeń niestety nie jestem.
W następnym wpisie postaram się króciutko przedstawić bibliotekę Microsoft Enterprise Library, a właściwie jeden z jej bloków – Security Block.Wykorzystam go do zezwalania użytkownikom do dostępu do funkcji serwisu, w zależności od ich roli w systemie.

Interactivity oraz Interaction

2011-11-292016-01-31 TPodolakBehavior, Interaction, Interactivity, Prism, Silverlight, WPF

Interactions oraz Interactivity są to dwie dll-ki, które poszerzają sposób komunikacji pomiędzy widokiem oraz ViewModelem. Wprowadzają one nowy typ EventTriggerów(w Silverlighcie nie ma triggerów, natomiast w WPF-ie event triggery można praktycznie używać jedynie do animacji) oraz dodatkowo wprowadzają ciekawe sposoby(funkcje) na interakcję widoku z ViewModelem. Pierwszym z tych sposobów jest użycie właściwości InvokeCommandAction.Jak sama nazwa wskazuje można wywołać komendę z ViewModelu. Jaka jest różnica między wywołaniem komendy poprzez InvokeCommandAction, a Command=”{Binding CommandName}” ? InvokeCommandAction ma tą przewagę nad normalnm bindowaniem do property Command,że pozwala wywołać daną komendę w odpowiedzi na zajście jakiegoś zdarzenia na widoku. Przykładowe użycie może wyglądać następująco:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
      <i:Interaction.Triggers>
        <i:EventTrigger EventName="MouseMove">
           <i:InvokeCommandAction Command="{Binding SubmitCommand}"/>
        </i:EventTrigger>
      </i:Interaction.Triggers>
</Button>

<i:Interaction.Triggers>

<i:EventTrigger EventName="MouseMove">

<i:InvokeCommandAction Command="{Binding SubmitCommand}"/>

</i:EventTrigger>

</i:Interaction.Triggers>

</Button>

Powyższy przykład działa w następujący sposób. Za każdym razem gdy zostanie wywołane zdarzenie MouseMove na przycisku, odpalona zostanie komenda SubmitCommand. Wadą używania InvokeCommandAction jest to, że sami musimy się martwić o wygaszenie kontrolki w przypadku gdy dana komenda nie może być wykonana. Dlatego też w pierwszej linii mamy bindowanie właściwości IsEnabled przycisku do właściwości CanSubmit z ViewModelu. Alias i: jest aliasen na namespace interactivity z dll-ki

System.Windows.Interactivity.xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity".

1	System.Windows.Interactivity.xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity".

Drugim sposobem powiadomiania ViewModelu o jakimś zdarzeniu w widoku jest użycie InvokeMethodAction. Dzięki tej właściwości możemy bezpośrednio z widoku (z XAML-a) wywołać funkcję w ViewModelu. Składnia przedstawia się w następujący sposób:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
     <i:Interaction.Triggers>
       <i:EventTrigger EventName="Click">
        <i:CallMethodAction TargetObject="{Binding}"      Method="Submit"/>
      </i:EventTrigger>
     </i:Interaction.Triggers>
</Button>

<i:Interaction.Triggers>

<i:EventTrigger EventName="Click">

<i:CallMethodAction TargetObject="{Binding}" Method="Submit"/>

</i:EventTrigger>

</i:Interaction.Triggers>

</Button>

TargetObject jest zbindowany do DataContextu, to właśnie tam będzie szukana funkcja Submit. Należy pamiętać, że właściwość CallMethodAction nie wspiera parametrów funkcji. Zatem jeżeli musimy wywołać jakąś funkcję z parametrami, należy opakować ją w funkcję bezparametrową, natomiast wszystkie parametry przekazać z właściwości ViewModelu.

Kolejnym ciekawym featurem Interactivity jest klasa Behavior. Jest niezastąpiona jeżeli potrzebujemy ingerować w działanie widoku po jakimś zdarzeniu. Nie musimy wówczas tworzyć obsługi eventów w code behind. Możemy wyłuskać daną funkcjonalność i zamknąć ją w klasie Behavior a następnie doczepić do wszystkich widoków danego typu. Załóżmy, że sterujemy ListBoxem z poziomu ViewModelu (przełączamy SelectedItem). Możemy zaznaczyć jakiś Item, co jednak jeżeli nasza lista jest bardzo długa,a zaznaczamy ostatni element. Na widoku element rzeczywiście się zaznaczył jednak lista się nie przewinęła. Przez co cały czas wiszą elementy z początku i nie widać czy któryś element jest zaznaczony. Dopiero gdy przeskrolujemy ręcznie ListBoxa widzimy, że rzeczywiście prawidłowo zareagował na zmianę property w ViewModelu. Jest to idealna sytuacja, aby stworzyć własny Behavior, który będziemy mogli podczepić do wszystkich listboxów w każdym widoku.

public class Behavior<ListBox>
{

protected override void OnAttached()
{
 AssociatedObject.SelectionChanged += ListBoxSelectionChanged;
}

protected override void OnDetaching()
{
  AssociatedObject.SelectionChanged -= ListBoxSelectionChanged;
}

private void ListBoxSelectionChanged(object sender, SelectionChangedEventArgs e)
{
         if (sender is ListBox && ((ListBox)sender).SelectedItem != null)
         {
             var listBox = sender as ListBox;
             listBox.ScrollIntoView(listBox.SelectedItem);
         }
  }
}

public class Behavior<ListBox>

{

protected override void OnAttached()

{

AssociatedObject.SelectionChanged += ListBoxSelectionChanged;

}

protected override void OnDetaching()

{

AssociatedObject.SelectionChanged -= ListBoxSelectionChanged;

}

private void ListBoxSelectionChanged(object sender, SelectionChangedEventArgs e)

{

if (sender is ListBox && ((ListBox)sender).SelectedItem != null)

{

var listBox = sender as ListBox;

listBox.ScrollIntoView(listBox.SelectedItem);

}

Metoda OnAttached odpala się w momencie, gdy behavior jest podpinany do kontrolki. W metodzie tej powinniśmy podpiąć się pod wszystkie eventy, które są dla nas istotne. W momencie, gdy widok jest niszczony wywołuje się metoda OnDetaching, w której powinniśmy odpiąć wszystkie metody od eventów.

.NET BLOG

.NET, C# blog

WPF

INotifyPropertyChange – notifying about change of all properties at once

Tworzenie bootstrappera aplikacji przy użyciu CaliburnMicro

1. Wstęp

2. Bootstrapper – Silverlight

2.2 Własna konwencja wyszukiwania widoków

3. Bootstrapper – Windows Phone

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.2

Interactivity oraz Interaction