Pokazywanie postów oznaczonych etykietą WPF. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą WPF. Pokaż wszystkie posty

poniedziałek, 7 maja 2012

Tworzenie bootstrappera aplikacji przy użyciu CaliburnMicro

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();
        }
    }
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>
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>
    {
      
    }
}
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>
Kompilując, a następnie uruchamiając nasz projekt naszym oczom powinien ukazać się następujący widok


2.1 Własny kontener IOC

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>();
        } 
    }
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>();
        }
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);
        }
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>
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);
                                                 };
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);
(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);
        }
    }
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"/>
i zamieniamy go na
<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 ;
                                                     };
W ostatnim kroku musimy jeszcze tylko dodać nasz bootstrapper do zasobów aplikacji
<Application.Resources>
        <Bootstrapper:WindowsPhoneBootstrapper x:Key="Bootstrapper"></Bootstrapper:WindowsPhoneBootstrapper>
    </Application.Resources>
odpalając teraz program naszym oczom powinien ukazać się taki oto widok

niedziela, 5 lutego 2012

Multiplatforomowe aplikacje w .NET, Silverlight i Windows Phone Cz.3 - Konfiguracja komunikacji socketami

Wstęp

W poprzednich dwóch wpisach, przedstawiłem ogólne zasady tworzenia aplikacji multiplatformowych, pokazałem jak można zapisywać i odczytywać dane z socketów. Oparłem się przy tym mocno na przykładzie Johna Papa. W tym przykładzie pójdę dalej tym tropem i pokażę jak można uruchomić komunikację klient serwer. Jak sprawić, żeby sockety zaczęły nasłuchiwać i ze sobą rozmawiać.

Odczyt/zapis socketa

W poprzednim wpisie przedstawiłem dwie klasy do odczytywania poleceń przesyłanych przez sockety (kody źródłowe dostępne są tutaj), Ponieważ nasze sockety będą miały komunikować się dwustronnie dla uproszczenia sprawy wprowadźmy jeszcze dodatkową klasę opakowującą CommandReaderWriter.

public class CommandReaderWriter
{
    public Socket Socket { get; protected set; }
    public delegate void OnConnectedDelegate(object sender, SocketAsyncEventArgs e);

    public event OnConnectedDelegate OnConnectedEvent = delegate { };

    public CommandReader Reader { get; protected set; }
    public CommandWriter Writer { get; protected set; }

    public CommandReaderWriter()
    {

    }

    public CommandReaderWriter(Socket socket)
    {
        InitializeConnection(socket);
    }

    /// <summary>
    /// Metoda inicjująca połączenie z konkretnym socketem
    /// </summary>
    /// <param name="socket"></param>
    public void InitializeConnection(Socket socket)
    {
        Reader = new CommandReader(socket);
        Writer = new CommandWriter(socket);
    }

    /// <summary>
    /// Metoda inicjująca połączenie z socketem
    /// znajdującym się pod wskazany adresem i portem
    /// </summary>
    /// <param name="serverName">adres serwera</param>
    /// <param name="port">port</param>
    public void InitializeConnection(string serverName, int port)
    {
        var s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        var e = new SocketAsyncEventArgs
                {
                    RemoteEndPoint = new DnsEndPoint(serverName, port)
                };
        e.Completed += OnConnected;
        s.ConnectAsync(e);
    }

    /// <summary>
    /// Metoda obsługująca zdarzenie połączenia się z socketem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnConnected(object sender, SocketAsyncEventArgs e)
    {
        Socket s = (Socket)sender;
        if (e.SocketError != SocketError.Success)
        {
            throw new Exception("Nie udało się połączyć!");
        }

        InitializeConnection(s);

        OnConnectedEvent(this, e);
    }

    /// <summary>
    /// Metoda zakańczająca nasłuchiwanie socketu
    /// </summary>
    public void StopReading()
    {
        Reader.StopReading();
    }

    /// <summary>
    /// Metoda rozpoczynająca nasłuchiwanie socketu
    /// </summary>
    /// <param name="h"></param>
    public void StartListening(ICommandHandler h)
    {
        Reader.StartListening(h);
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez socket
    /// przekazany w konstruktorze
    /// </summary>
    /// <param name="command">polecenie</param>
    public void Write(Command command)
    {
        Writer.Write(command);
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj dodana zostanie obsługi polecenia
    }
}

Klasa ta oprócz opakowania metod CommandReader i CommandWriter posiada też metody odpowiedzialne za jego inicjalizację. Ta z adresem i numerem portu powinna być używana przez aplikację kliencką, ta z Socketem w aplikacji serwerowej.
Mamy już tak naprawdę komplet klas, które pozwolą nam na odczytywanie i zapisywanie z socketów. Musimy teraz utworzyć klasy, które je nam wywołają.


Konfiguracja klienta


Zacznijmy od sprawy prostszej - konfiguracji klienta. Otwórzmy definicję głównego okna aplikacji Multiplatform.Client.Silverlight - MainPage.xaml.cs i zmodyfikujmy je następująco:

public partial class MainPage : UserControl, ICommandHandler
{
    private CommandReaderWriter _commandReaderWriter;

    public MainPage()
    {
        InitializeComponent();

        InitializeNetworkConnection();
    }

    /// <summary>
    /// Metoda inicjująca połączenie z serwerem
    /// </summary>
    private void InitializeNetworkConnection()
    {
        _commandReaderWriter = new CommandReaderWriter();
        _commandReaderWriter.InitializeConnection("localhost", 4529);
        _commandReaderWriter.OnConnectedEvent += CommandReaderWriter_OnConnectedEvent;
    }

    /// <summary>
    /// Metoda przechwytująca zdarzenie połączenia z serwerem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void CommandReaderWriter_OnConnectedEvent(object sender, SocketAsyncEventArgs e)
    {
        //skoro udało się połączyć, to rozpocznij nasłuchiwanie
        _commandReaderWriter.StartListening(this);
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj będzie obsługa poleceń
    }
}

Dodaliśmy do niego zainicjowanie połączenia z serwerem poprzez podanie adresu oraz numeru portu, na którym będziemy nasłuchiwać. Klasa ta implementuje również interfejs ICommandHandler, dzięki czemu może obsługiwać polecenia wysłane przez serwer.
Dokładnie to samo moglibyśmy zrobić w przypadku MainWindow aplikacji WPF oraz MainPage w aplikacji na Phone'a, z małym wyjątkiem w przypadku tego ostatniego. Nie możemy podać jako adres serwera "localhost", gdyż emulator telefonu potraktuje to jako odwołanie się do siebie, a nie do naszego komputera. Możemy to łatwo obejść wpisując zamiast "localhost" nazwę sieciową naszego komputera. Należy uważać też na numer portu, ale o tym szerzej w kolejnym punkcie.


Konfiguracja serwera


Serwer w swoim zachowaniu będzie zbliżony do klienta, poza tym, że będzie musiał rozpocząć nasłuchiwanie na połączenie z klientem, a nie łączyć się bezpośrednio z nim. Utwórzmy nowy katalog solucji "Server" oraz nowy projekt "Multiplatform.Server" typu "Class Library". Dodajmy klasę ServerProgram - będzie ona odpowiadała za rozpoczęcie nasłuchiwania oraz obsługę poleceń od klienta. Powinna ona wyglądać następująco:


public class ServerProgram : ICommandHandler
{
    readonly TcpListener _server = new TcpListener(IPAddress.Any, 4529);

    private CommandReaderWriter _commandReaderWriter;

    void Run()
    {
        _server.Start();
        while (true)
        {
            Socket s = _server.AcceptSocket();

            _commandReaderWriter = new CommandReaderWriter(s);
            _commandReaderWriter.StartListening(this);
        }
    }

    /// <summary>
    /// Statyczna metoda tworząca nową instancję serwera
    /// </summary>
    public static void Start()
    {
        Console.WriteLine("Starting PictureHunt Server on port 4529");
        var p = new ServerProgram();
        p.Run();
    }

    /// <summary>
    /// Metoda obsługująca polecenie od klienta
    /// </summary>
    /// <param name="r"></param>
    /// <param name="cmd"></param>
    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj będziemy obsługiwać polecenie
    }
}

Utwórzmy jeszcze projekt Multiplatform.Server.Host w katalogu solucji Server, który będzie uruchamiał metodę Start naszego Servera w swojej metodzie Main (oszczędzę sobie trudu wklejania, a Wam czytania tej jakże zawiłej klasy).


Wprawiamy to wszystko w ruch


Mamy już zatem 3 rodzaje klientów - WPF, Silverlight, Phone oraz serwer. Co prawda jest to póki co dosyć oszukany serwer bo może obsłużyć, ale zawsze... 
Wypadało by teraz zrobić jakąś własną komendę, dzięki której będziemy mogli przetestować czy nasz szkielet, ma już mięśnie, czy dalej odmawia uczynienia choćby małego ruchu. Zróbmy klasę we współdzielonym projekcie TextCommand, będzie ona pozwalała na przesłanie tekstu.


public class TextCommand : Command
{
    public string Text { get; set; }

    public TextCommand()
    {
        CommandType = 1;
    }

    public TextCommand(string text) : this()
    {
        Text = text;

        // tutaj powinna być serializacja binarna
        // obiektu Text i przypisanie do tablicy Data
    }
}

Jak widzimy jest to bardzo prosta klasa. Dziedziczy po klasie Command, ma konstruktor domyślny oraz przyjmujący parametr z tekstem, który chcemy przesłać. Na pewno was zastanawia dlaczego nie zrobiłem tutaj standardowej serializacji przy pomocy BinaryFormattera. Otóż nie mogłem tego zrobić, bo z nieznanych mi powodów w Silverlight tej klasy nie ma. Można kombinować i robić hacki stosując serializację WCFową, ja jednak polecam użycie Open Source'owej biblioteki SharpSerializer. Pozwala ona na całkiem sprawną i szybką serializację zarówno w zwykłych projektach .NETowych jak i Silverlight, Windows Phone.
Po pobraniu i dołączeniu plików dll do projektów dodajmy klasę opakowującą do dla tej biblioteki.


public static class BinaryUtils
{
    private static readonly SharpSerializer SharpSerializer = new SharpSerializer(true);

    public static byte[] Serialize(object obj)
    {
        using (var memoryStream = new MemoryStream())
        {
            SharpSerializer.Serialize(obj, memoryStream);

            return memoryStream.GetBuffer();
        }
    }

    public static object Deserialize(byte[] bytes)
    {
        using (var memoryStream = new MemoryStream(bytes))
        {
            return SharpSerializer.Deserialize(memoryStream);
        }
    }
}


Jak widać, użycie biblioteki jest banalnie proste, nie wymaga specjalnego tłumaczenia. Mając to już gotowe, możemy dodać serializację tekstu w konstruktorze naszej klasy TextCommand. Ostatecznie wygląda on:

public TextCommand(string text) : this()
{
    Text = text;

    Data = BinaryUtils.Serialize(Text);
}
Dodajmy więc prostą funkcjonalność przesyłania tej komendy pomiędzy klientem a serwerem i odwrotnie. Klient po nawiązaniu połączenia wyśle wiadomość "Ping", serwer mu odpowie wiadomością "Pong". Musimy dokonać zmian w obsłudze Poleceń zarówno po stronie klienckiej ja i stronie serwerowej.
Klasa okna klienta wyglądało będzie po zmianach:
public partial class MainWindow : Window, ICommandHandler
{
    private CommandReaderWriter _commandReaderWriter;

    public MainWindow()
    {
        InitializeComponent();

        InitializeNetworkConnection();
    }

    /// <summary>
    /// Metoda inicjująca połączenie z serwerem
    /// </summary>
    private void InitializeNetworkConnection()
    {
        _commandReaderWriter = new CommandReaderWriter();
        _commandReaderWriter.InitializeConnection("localhost", 4529);
        _commandReaderWriter.OnConnectedEvent += CommandReaderWriter_OnConnectedEvent;
    }

    /// <summary>
    /// Metoda przechwytująca zdarzenie połączenia z serwerem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void CommandReaderWriter_OnConnectedEvent(object sender, SocketAsyncEventArgs e)
    {
        //skoro udało się połączyć, to rozpocznij nasłuchiwanie
        _commandReaderWriter.StartListening(this);
        _commandReaderWriter.Write(new TextCommand("Ping!")); // 1.
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        switch (cmd.CommandType)
        {
            case 1:
                string text = (string)BinaryUtils.Deserialize(cmd.Data); //2
                Debug.WriteLine(text);
                break;
        }
    }
}


Dodałem przesłanie polecenia z tekstem po nawiązaniu połączenia z serwerem (oznaczone numerem 1) oraz przechwycenie polecenia z serwera i obsłużenie go (oznaczone numerem 2). Analogicznie klasa serwera po zmianach będzie wyglądała:


public class ServerProgram : ICommandHandler
{
    readonly TcpListener _server = new TcpListener(IPAddress.Any, 4529);

    private CommandReaderWriter _commandReaderWriter;

    void Run()
    {
        _server.Start();
        while (true)
        {
            Socket s = _server.AcceptSocket();

            _commandReaderWriter = new CommandReaderWriter(s);
            _commandReaderWriter.StartListening(this);
        }
    }

    /// <summary>
    /// Statyczna metoda tworząca nową instancję serwera
    /// </summary>
    public static void Start()
    {
        Console.WriteLine("Starting PictureHunt Server on port 4529");
        var p = new ServerProgram();
        p.Run();
    }

    /// <summary>
    /// Metoda obsługująca polecenie od klienta
    /// </summary>
    /// <param name="r"></param>
    /// <param name="cmd"></param>
    public void DoCommand(CommandReader r, Command cmd)
    {
        switch (cmd.CommandType)
        {
            case 1:
                string text = (string)BinaryUtils.Deserialize(cmd.Data);
                Console.WriteLine(text);
                //odpowiedz klientowi "Pong!"
                _commandReaderWriter.Write(new TextCommand("Pong!"));
                break;
        }
    }
}
Pozostało nam tylko dodać jeszcze obsługę naszego polecenia w CommandReaderze w metodzie TransformData
private void TransformData(SocketAsyncEventArgs e)
{
    [...]
    while (data.Length >= 12)
    {
        [...]

        //zainicjuj obiekt polecenia
        Command cmd = null;
        switch (opcode)
        {
            case 1:
                cmd = new TextCommand {Data = newData};
                break;
            default:
                cmd = new Command{Data = newData};
                break;
        }

        [...]
    }
}
Możecie śmiało odpalić serwer, i jedną z aplikacji klienckich, wszędzie zadziała dobrze oprócz Silverlighta. Dlaczego? Wytłumaczenie znajdziecie w kolejnym punkcie...

Silverlight i Sockety

Silverlight jako chyba najbardziej irytująca technologia Microsoftu i tutaj musi utrudniać programistom życie. Oczywiście celem jest dobro i bezpieczeństwo użytkowników końcowych. Ja jednak nie do końca ufam i nie do końca wierzę tym tłumaczeniom, skoro w Windows Phone nie ma już takich utrudnień związanych z socketami.
Szczegółowo można przeczytać na ten temat w artykule Network Security Access Restrictions in Silverlight na MSDN - ja postaram się to skrócić w kilku zdaniach. Aby zachować bezpieczeństwo i wygodę użytkowników w Silverlight można łączyć się z Socketami tylko z zakresu 4502-4534. Dodatkowo aplikacja Silverlightowa łącząca się z serwerem na zadanym adresie i zadanym porcie najpierw próbuje połączyć się z tym adresem z portem 943. Oczekuje, że na tym porcie będzie wystawiona usługa, która mu dostarczy plik xml z informacjami o zasadach bezpieczeństwa (tzw. "policy file").
Jeżeli nie odnajdzie tej usługi i nie pobierze tego pliku, to automatycznie ignoruje połączenie uznając, że jest ono niebezpieczne. Wszystko dla naszego dobra, oczywiście.
Nie będę tutaj wklejał tego kodu, jest on dostępny w przedstawionym wcześniej artykule, oraz w kodach źródłowych na końcu artykułu. Należy pamiętać, żeby usługa ta była zawsze uruchomiona na tym samym adresie co nasz serwer.

Podsumowanie

W tym artykule pokazałem już jak wprawić w ruch machinę komunikacji socketami pomiędzy klientem a serwerem i serwerem a klientem. W kolejnych artykułach przedstawię jak zrobić serwer obsługujący wielu użytkowników oraz jak ukryć za fasadą tą niezbyt elegancką obsługę komend.

Kody źródłowe możecie pobrać stąd.

Multiplatforomowe aplikacje w .NET, Silverlight i Windows Phone Cz.2 - Wstęp do komunikacji socketami

Wstęp

W poprzednim wpisie przedstawiłem wstęp oraz kilka problemów, które napotykamy przy rozpoczęciu zabawy z aplikacji wieloplatformowych. Tak jak zapowiedziałem, w tym wpisie przedstawię kolejny krok do utworzenia gry multiplayer w Kuku. Tym razem na warsztat wzięte zostają metody komunikacji klient-serwer, serwer-klient przy pomocy socketów. Dlaczego przy pomocy socketów, a nie WCF? Szczegóły później. Najpierw się zastanówmy czego tak naprawdę potrzebujemy.
Naszą wersję Kuku można opisać następująco:
- zbierają się gracze,
- każdemu z nich rozdajemy karty, pierwszy gracz dostaje 4, resta 3,
- jeżeli któryś z graczy ma 3 karty w jednym kolorze lub z tymi samymi figurami, to może krzyknąć "kuku!". Jeżeli nikt tego nie zrobił, to
- zaczyna się tura pierwszego gracza,
- wybiera on jedną kartę i przekazuje ją kolejnemu graczowi,
- zaczyna się jego tura,
- jeśli karta do niego wróci, może ją wymienić,
- kto pierwszy skompletuje kuku ten wygrywa.

Zatem nasza gra powinna:
- umożliwić dołączanie graczy,
- reagować na wybory gracza,
- powiadamiać graczy o zmianie stanu gry. 

Potrzebujemy zatem komunikacji pomiędzy graczami. Niektórym z Was od razu może się to skojarzyć z grami/programami typu P2P (Peer To Peer). Będzie to bardzo dobre skojarzenie. Implementując nasz system można by było w teorii pokusić się o to, żeby gracz, wysyłał kolejnemu graczowi informację: "Stary teraz twoja kolej!". A pozostałym o tym, że to zrobił. Niestety takie systemy są trudne do utrzymania, kontroli i rozwoju. Dodatkowo cała logika biznesowa jest przechowywana w aplikacji klienckiej, co powoduje ich nadmierny rozrost, tworząc je za dużymi do zastosowania na stronach internetowych oraz telefonach komórkowych. Według mnie lepsze jest rozwiązanie pośrednie:
- gracz przesyła informację do serwera o swoim wyborze,
- serwer decyduje o tym jaka akcja powinna być wykonana - to on mówi kolejnemu graczowi o jego turze, on rozsyła informacje do pozostałych graczy.
Komunikacja musi być zatem dwustronna:
- klient - serwer
- serwer - klient



Podejrzewam, że większość z Was miała już do czynienia z web service'ami pisanymi przy pomocy WCF. Są one dobre dla standardowych rozwiązań biznesowych, w których wysyłamy zapytanie, dostajemy odpowiedź - typowa komunikacja jednostronna. Niestety ten model komunikacji nie sprawdzi się w przypadku naszego problemu. U nas żądania wysyłane są w dwie strony, nie wiemy również kiedy dokładnie one wystąpią. Niektórzy z Was zapewne natrafili na Duplex Channel, pozwalający oprogramować w WCF komunikację dwustronną. Niestety w Silverlight dostępna jest tylko jego uboższa wersja, mając dużo ograniczeń, nie nadająca się do rozwiązań komercyjnych (więcej szczegółów na blogu Tomasza Janczuka tutaj i tutaj). Z pomocą przyjdą nam stare jak świat sockety.

Sockety 

Jest to rozwiązanie znane od dawien dawna, istnieje ono zarówno w C++ jak i w Javie. Nie będę się nad tym przesadnie rozpisywał, raczej przedstawię ich ogólną zasadę.
Sockety pozwalają na bezpośrednią komunikację pomiędzy dwoma komputerami. Aby nawiązać połączenie musimy znać adres internetowy komputera oraz port, na którym on nasłuchuje. Klient znając te dane serwera łączy się z nim. Tworzone jest połączenie TCP. Połączenie jest utrzymywane cały czas, dlatego też możliwa jest komunikacja w dwie strony. Odbywa się ona przy pomocy strumienia bajtów. Zalety tego rozwiązania to szybkość i wydajność, minusem jest to, że musimy oprogramować cały mechanizm "odszyfrowywania" strumienia. Musimy sami określać, które bajty odpowiadają za co, gdzie kończy się jedno rozwiązanie, a zaczyna kolejne.
W moich rozważaniach punktem wyjściowym będzie świetny przykład Johna Papa zaprezentowany na Silverlight TV. Przedstawił on tam podstawowy mechanizm przetwarzania socketów, zachęcam do przyjrzenia się mu i porównania ze zmianami, które do niego wprowadziłem.
Zaproponował on bardzo sprytny i prosty zarazem sposób przetwarzania danych przesyłanych w socketach, wykorzystał on przy tym wzorzec projektowy Polecenie (Command).
Chcąc przesłać żądanie do serwera musimy utworzyć obiekt klasy Command. Następnie serializujemy go do postaci binarnej i przesyłamy go poprzez socket do serwera. Serwer odbiera bajty i deserializuje je. Tak utworzony obiekt polecenia przetwarzamy przy pomocy klasy pomocniczej CommandHandler. Dla każdego rodzaju operacji konieczne jest utworzenie implementacji klasy Command, dzięki temu klasa pomocnicza wie w jaki sposób ma wykonać polecenie (na podstawie jej typu).
Wspominałem wcześniej, że największym problemem przy Socketach jest określenie, w jaki sposób rozdzielić jedno żądanie od innego. Tak jak już napisałem pomiędzy klientem a serwerem utworzony jest strumień TCP. Zwykle  każde żądanie jest wysyłane osobno, lecz może dość do sytuacji gdy w jednym pakiecie wysłane zostanie kilka żądań (np. gdy są opóźnienia w sieci a klient wykonał szybko kilka akcji), lub jedno żądanie zostanie podzielone na kilka pakietów (np. gdy wysyłamy sporą liczbę danych). Nie będziemy wiedzieli więc od razu po odczytaniu danych ze strumienia, czy możemy już deserializować i wykonać Polecenie. Jak zatem sobie z tym poradzić? 
John Papa zaproponował, żeby komenda posiadała nagłówek. Nagłówek ten posiadał będzie podstawowe informacje o niej (takie jak jej rozmiar). Najważniejszą jego cechą jest to, że będzie on miał stałą wielkość. Dzięki czemu będzie można go zserializować od razu gdy zorientujemy się, że mamy do czynienia z nowym żądaniem. Po jego odczytaniu będziemy wiedzieć ile jeszcze bajtów zostało nam do odczytania, wiedząc tym samym, w którym miejscu kończy się żądanie. 



Konkrety


Klasa polecenia napisana zgodnie z tymi wytycznymi wygląda następująco:
/// <summary>
/// Klasa wzorowana na rozwiązaniu przedstawionym
/// przez Johna Papa w Silverlight TV
/// http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-70-Sockets-Unplugged
/// </summary>
public class Command
{
    /// <summary>
    /// Typ polecenia
    /// 
    public int CommandType;
    /// <summary>
    /// Rozmiar nagłówka
    /// </summary>
    public int HeaderLen;
    /// <summary>
    /// Dane nagłówka
    /// </summary>
    public byte[] Header;

    /// <summary>
    /// Dane polecenia
    /// </summary>
    public byte[] Data;

    public Command()
    {
        HeaderLen = 12;
        Header = null;
        Data = null;
    }
        
    /// <summary>
    /// Metoda inicjująca nagłówek
    /// </summary>
    /// <returns></returns>
    public virtual BinaryWriter InitHeader()
    {
        Debug.Assert(CommandType != 0);
        Debug.Assert(HeaderLen >= 12);
        Header = new byte[HeaderLen];
        var bw = new BinaryWriter(new MemoryStream(Header));
        bw.Write(Htonl(HeaderLen));
        bw.Write(Htonl(Data == null ? 0 : Data.Length));
        bw.Write(Htonl(CommandType));
        return bw;
    }

    /// <summary>
    /// Metoda formatująca liczby do formatu
    /// odpowiedzniego dla socketów
    /// </summary>
    /// <param name="value"></param>
    /// <returns></returns>
    public Int32 Htonl(Int32 value)
    {
        return IPAddress.HostToNetworkOrder(value);
    }
}

Do zapisywania wysłania polecenia przez Socket służy klasa CommandWriter
/// <summary>
/// Klasa służąca do wysyłania danych poprzez socket
/// </summary>
public class CommandWriter
{
    public Socket Socket;

    public CommandWriter()
    {
    }

    public CommandWriter(Socket socket)
    {
        Socket = socket;
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez socket
    /// przekazany w konstruktorze
    /// </summary>
    /// <param name="command">polecenie</param>
    public void Write(Command command)
    {
        Write(Socket, command);
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez
    /// zadany socket
    /// </summary>
    /// <param name="socket">socket</param>
    /// <param name="command">polecenie</param>
    public void Write(Socket socket, Command command)
    {
        //utwórz nagłówek
        command.InitHeader();
        var senddata = new List<ArraySegment<byte>> { new ArraySegment<byte>(command.Header) };
        //wrzuć dane polecenia
        if (command.Data != null)
        {
            senddata.Add(new ArraySegment<byte>(command.Data));
        }
        var writeEventArgs = new SocketAsyncEventArgs();
        writeEventArgs.Completed += WriteCompleted;
        writeEventArgs.BufferList = senddata;
        //wyślij socketem bajty
        socket.SendAsync(writeEventArgs);
    }
}
Klasa odczytująca polecenie z socketa będzie wyglądała następująco:
/// <summary>
/// Klasa służaca do odczytywania danych z socketa
/// wzorowana na rozwiązaniu przedstawionym
/// przez Johna Papa w Silverlight TV
/// http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-70-Sockets-Unplugged
/// </summary>
public class CommandReader
{
    public Socket Socket;

    byte[] data = new byte[0];

    public CommandReader(Socket socket)
    {
        this.Socket = socket;
    }
    /// <summary>
    /// Metoda zamieniająca liczbę z formatu socketa
    /// na format standardowy
    /// </summary>
    /// <param name="value"></param>
    /// <returns></returns>
    public static Int32 Ntohl(Int32 value)
    {
        return System.Net.IPAddress.NetworkToHostOrder(value);
    }

    /// <summary>
    /// Metoda rozpoczynająca nasłuchiwanie socketu
    /// </summary>
    /// <param name="h"></param>
    public void StartListening(ICommandHandler h)
    {
        Console.WriteLine("CR: Go  : Socket {0} CR {1}", Socket, this);

        //określ parametry nasłuchiwania
        const int size = 10000;
        var e = new SocketAsyncEventArgs();
        e.Completed += OnRead;
        e.UserToken = h;
        e.SetBuffer(new byte[size], 0, size);

        //rozpocznij nasłuchiwanie
        while (Socket.ReceiveAsync(e) == false)
        {
            TransformData(e);
        }
    }

    /// <summary>
    /// Metoda wywołana po zaczytaniu paczki danych z socketa
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnRead(object sender, SocketAsyncEventArgs e)
    {
        //przetwarzaj dane
        TransformData(e);
        //nasłuchuj czy nie przychodzą kolejne porcje danych
        while (Socket != null && Socket.ReceiveAsync(e) == false)
        {
            TransformData(e);
            if (e.BytesTransferred == 0)
            {
                break;
            }
        }

    }
    /// <summary>
    /// Metoda przetwarzająca dane otrzymane z socketa
    /// </summary>
    /// <param name="e"></param>
    private void TransformData(SocketAsyncEventArgs e)
    {
        var oldLen = data.Length;
        var newLen = oldLen + e.BytesTransferred;
        Array.Resize<byte>(ref data, newLen);
        Array.Copy(e.Buffer, 0, data, oldLen, e.BytesTransferred);
        while (data.Length >= 12)
        {
            //pobrano już co najmniej nagłówek
            var reader = new BinaryReader(new MemoryStream(data));
            var headerLen = Ntohl(reader.ReadInt32());
            var dataLen = Ntohl(reader.ReadInt32());
            var opcode = Ntohl(reader.ReadInt32());
            var totLen = headerLen + dataLen;
            var extra = data.Length - totLen;

            //jeżeli nie pobrano jeszcze całości danych
            //zakończ przetwarzanie i czekaj na kolejną
            //paczkę z danymi
            if (extra < 0)
                break;
                
            //Pobrano już co najmniej tyle danych ile ma polecenie
            //utwórz nową tablicę do przechowywania danych polecenia
            byte[] newData = new Byte[dataLen];
            Array.Copy(data, headerLen, newData, 0, dataLen);

            //zainicjuj obiekt polecenia
            Command cmd = null;
            switch (opcode)
            {
                //tutaj wstawiamy tworzenie poszczególnych poleceń
                //w zależności od typu
                default:
                    cmd = new Command{Data = newData};
                    break;
            }

            //jeżeli pobrano więcej bajtów niż miało mieć polecenie
            //przenieś je do nowej tablicy
            if (extra > 0)
            {
                Array.Copy(data, totLen, data, 0, extra);
            }
            Array.Resize<byte>(ref data, extra);

            //wykonaj polecenie
            ICommandHandler h = (ICommandHandler)e.UserToken;
            h.DoCommand(this, cmd);
        }
    }
}

Podsumowanie

W tym poście przedstawiłem ogólny zarys sposobu komunikacji dla aplikacji multiplatformowych w środowisku .NET. Pokazane zostało po co nam komunikacja dwustronna, klient - serwer, serwer - klient. Jak można zaimplementować ją przy pomocy socketów.
Popisałem się również umiejętnością czytania ze zrozumieniem i pokazałem klasy do obsługi czytania i zapisu do socketów zaprezentowane przez Johna Papa. W kolejnych postach przedstawię jak w ogóle uruchomić sockety, jak skonfigurować serwer i klienta i pokażę trochę własnej inwencji przedstawiając swoje ulepszenia do dotychczas opisanych rozwiązań.

Multiplatforomowe aplikacje w .NET, Silverlight i Windows Phone Cz.1 - Współdzielenie klas

Wstęp

W kilku najbliższych wpisach postaram się przybliżyć tematykę tworzenia aplikacji multiplatformowych. Środowisko .NET dostarcza nam rozwiązań, które pozwalają tworzyć zarówno aplikacje okienkowe (WinForms, WPF), strony internetowe (ASP.NET, Siverlight) jak i programy na telefony komórkowe (Windows Phone). W dzisiejszych czasach rozpowszechniło się tworzenie aplikacji w architekturze trójwarstwowej. Dzięki niej zostaje rozdzielony dostęp do danych, logika biznesowa oraz warstwa kliencka. Ułatwia to bardzo stworzenie systemów, które będą mogły "wystawiać" środowiska klienckie na różne platformy technologiczne. Brzmi prosto, ale w praktyce okazuje się trudniejsze. Programiści muszą cały czas się pilnować i mieć świadomość tego co się robi.Według mnie najważniejsze rzeczy, które powinniśmy mieć cały czas "w głowie" przy tworzeniu systemów wieloplatformowych są:
- możliwość wielokrotnego używania tych samych klas w różnych rodzajach projektów,
- tak jak tort, cebula i ogry, nasza aplikacja powinna posiadać warstwy. Warstwy te powinny komunikować się z sąsiednimi, nie burząc łańcucha zależności
- łatwość refaktoryzacji. Twórzmy rozwiązania w ten sposób, żeby np. zmiana typu bazy danych nie pociągała za sobą zmian w aplikacji klienckiej

Oczywiście jak we wszystkim, tutaj również trzeba kierować się rozsądkiem. Nie należy tworzyć rozwiązań, które pozwolą nam oprogramować działanie świata i rozpracować teorię wielkiego wybuchu, gdy chcemy napisać prosty kalkulator. Tak samo nie ma sensu generować kilkudziesięciu warstw, do których spamiętania będziemy potrzebowali schematu na dwie kartki A0.


.NET umożliwia nam tworzenie aplikacji w różnych platformach klienckich, ale żeby nie było tak prosto do każdego z nich ma pewne obwarowania. Silverlight, WPF i Windows Phone wywodzą się z jednego pnia, ale są osobnymi gałęziami. Z różnych powodów, głównie związanych ze specyfiką technologiczną środowiska klienckiego, oraz zaszłościami historycznymi są to tak naprawdę 3 różne frameworki .NET. Współdzielą niektóre klasy, część mają innych. W dużym uogólnieniu można by było powiedzieć:
- Silverlight jest podzbiorem WPF,
- Windows Phone jest podzbiorem Silverlight.
Oczywiście nie jest to do końca prawdą, ale całkiem dobrze oddaje rzeczywistość bez wchodzenia w większe szczegóły. No ale przejdźmy wreszcie do przykładów przykładu. Na nim powinno być łatwiej przedstawić te problemy. Graliście kiedyś w Kuku? Nie? To proszę oto i zasady (znalezione na "ABC Gier Karcianych"):


"Kuku jest bardzo prostą grą karcianą trwającą zazwyczaj około 10 - 15 minut. Celem gry Kuku jest skompletowanie trzech takich samych kolorów albo trzech takich samych figur. W Kuku grać może nawet do kilkunastu osób. W Kuku można grać całą talią kart albo gdy w grze bierze udział mała liczba graczy można grać kartami od 9. Rozdający daje każdemu z graczy po trzy karty, zaś graczowi siedzącemu po swojej lewej stronie cztery. Gracz który ma cztery karty oddaje jedną kartę z nie pasujących mu kart graczowi który siedzi z lewej strony. Karty oddaje się zgodnie z ruchem wskazówek zegara. W przypadku powrotu do tej samej osoby i grające osoby potwierdzą taką możliwość wówczas gracz może zamienić kartę na jedną kartę z tali. Jeśli osoba która zbierze trzy jednakowe kolory lub figury nie krzyknie "kuku", a reszta graczy krzyknie wówczas osoba ta przegrywa. W sytuacji gdy wszyscy gracze poza jednym mają zebrane „kuku” wówczas gra się kończy a przegrany gracz musi odgadnąć „kuku” innych graczy może pomóc sobie jedynie własnymi kartami."

Spróbujemy zrobić system, który pozwoli nam na zagranie w nią zarówno w "okienkach", stronie internetowej jak i telefonie komórkowym. Jest to na tyle prosta gra, że nie będzie trzeba za dużo męczyć się z oprogramowaniem jej logiki a na tyle trudna, że będę mógł traktować nasze rozważania jako punkt wyjściowy dla kolejnych artykułów (dodatkowo uprościmy sprawę i darujemy sobie zgadywanie na koniec gry, po prostu pierwszy gracz, który skompletuje kuku wygrywa).

Przykład

Przed uruchomieniem Visual Studio polecam zainstalowanie sobie:
- Visual Studio 2010 Service Pack 1
- Silverlight 4 SDK (może być też 5)
- Windows Phone SDK 1
Gdy wszystko będzie już poinstalowane, skonfigurowane i dopięte na ostatni guziczek zapraszam do uruchomienia Visual Studio i utworzenia pustej solucji.




Następnie w nowej solucji utwórzmy dwa katalogi:
- Shared - na projekty ze wspólnymi klasami
- Client - na projekty klienckie




Do katalogu Client dodajmy projekty klienckie:
- WPF



- Silverlight




  wraz z projektem hostującym na stronie www





- Windows Phone




Do katalogu dodajmy projekt biblioteki klas




W tym projekcie będą znajdowały się klasy odpowiadające za logikę gry, które będą wspólne dla projektów klienckich. Dodajemy zatem referencję do tego niego w projekcie WPF, następnie w Silverlight i Phone. 
Udało Wam się? Mnie nie. Przy próbie dodania referencji w projekcie Silverlightowym wyskakuje komunikat:




Podobny dostaniemy przy próbie dodania referencji do projektu Phone'owego. Zatem w jaki sposób można współdzielić pliki skoro nie możemy podpiąć projektu do wszystkich typów aplikacji klienckich?
Rozwiązanie tego problemu nie jest ani eleganckie, ani najwygodniejsze, ale póki co jedyne rozsądne. Musimy utworzyć analogiczne projekty z klasami wspólnymi dla każdej z docelowych platform klienckich:
- Silverlighta




- Phone'a




Po tym wszystkim struktura projektów powinna wyglądać następująco:





Będą one tak jakby kopiami tego co mamy w głównym projekcie ze wspólnymi klasami. Aby kopia była wierna musimy skopiować właściwości projektu i generowanej dllki. Otwórzmy informacje projektu wzorcowego:




Musimy przenieść informacje:
- Assembly Name
- Default Namespace
- Assembly Information
Robimy to poprzez otworzenie właściwości projektów dla Silverlight oraz Phone i zmianę odpowiednich pól a na koniec zapisanie plików projektów.
Dzięki temu uzyskamy, to że generowane pliki będą miały ten sam namespace oraz takie same właściwości asemblatu. Będziemy mogli dzielić bez problemu klasy poprzez serwisy wcf, serializować je itd.


Domyślam się, że teraz po Waszej głowie chodzi myśl: "Wszystko pięknie, ładnie, ale czy teraz będziemy musieli dodawać te same klasy do 3 różnych projektów i przy każdej zmianie uaktualniać w 3 miejscach?". Odpowiedzią jest: "I tak, I nie". 
Tak, będziemy musieli dodawać plik do każdego projektu osobno. Nie, wystarczy że będziemy zmieniać je w jednym miejscu. Jak to możliwe? Visual Studio umożliwia dodawanie plików do projektu jako linków. Dzięki tym linkom VS nie tworzy nowego pliku tylko odwołuje się do lokacji w innym miejscu. Do projektu wzorcowego dodawać będziemy pliki w normalny sposób, do pozostałych linki do nich.
Aby pokazać jak to się robi utwórzmy interfejs IKukuGame w projekcie Multiplatform.Shared. Chcąc dodać plik jako link naciskamy na projekcie Multiplatform.Shared.Silverlight "Add Existing Item". Przechodzimy do lokalizacji gdzie znajduje się świeżo dodany interfejs. Zaznaczamy go i naciskamy małą strzałkę przy przycisku "Add". Pojawi nam się wtedy opcja "Add As Link". Naciskamy ją i et voilà!




Kody źródłowe można pobrać tutaj.


Podsumowanie


Po tym artykule powinniście już wiedzieć, że:
- zwykły .NET, Silverlight i Phone to nie to samo, 
- nie da się w prosty sposób połączyć ze sobą projektów,
- ale da się w nieco trudniejszy,
- powinniście znać zasady gry w Kuku.

W kolejnym wpisie podążymy tropem tego ostatniego punktu i zrobimy kolejny krok w stronę utworzenia gry multiplayer w Kuku.

sobota, 21 stycznia 2012

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

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

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

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

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

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

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

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

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

}

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}"/>

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

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>

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

Ostatecznie przypisujemy obiekt klasy MainPageViewModel do DataContextu MainWindow.xaml

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


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

sobota, 7 stycznia 2012

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

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

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

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>

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

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

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

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

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>

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
}

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

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


Zauważmy, że linijka

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

została zastąpiona przez

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

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.

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Online Project management