[C#] - Software Tutorial - Catalogo de juegos hecho por mi

[Juancho]

Bueno este es el primero de unos cuantos ejemplos de software que voy a estar subiendo. En este caso es un catalogo de juegos para windows, hecho en un par de semanas hace como un año, lo he ido mejorando de a poco. Tome la iniciativa de hacerlo porque tengo un storage de red con 1.5 Tb de juegos y estaba manteniendo la lista con una planilla excel... apesta. Me considero un coleccionista cuando se trata de juegos y el hecho de hacer un catalogo me interesaba muchisimo.

Screenshots:

http://i126.photobucket.com/albums/p105/juancho707/cata.png (http://s126.photobucket.com/user/juancho707/media/cata.png.html)
http://i126.photobucket.com/albums/p105/juancho707/direct.png (http://s126.photobucket.com/user/juancho707/media/direct.png.html)


Como veran es bastante feo, pero 100% funcional.

Desde el punto de vista tecnologico, esta hecho en C# 4.0, usando WPF. Tiene varias cositas interesantes para el aficionado a .NET. Todo el sistema de busqueda esta hecho con linq de manera bastante mutable. Consta con extension methods, buenos ejemplos de recursividad, serializacion y una arquitectura que no es la gran cosa pero tiene los elementos bien separados cosa de que mañana puedo separar las funcionalidades principales y crear por ejemplo un web service. Contiene un control wpf customizado que esta mismo en la solucion, se trata de un control de grafica de barras que recibe un Dictionary<string, int> como parametro de criterio para graficar. En cuanto a WPF hay varias cosas interesantes, controles de paneles colapsables, controles de listas, imagen, tabla de datos, etc. Todo es adaptable a cualquier tamaño de ventana.

Caracteristicas:


- Permite crear entradas de manera muy facil con un formulario con secciones colapsables.
- En la pantalla principal muestra los datos del juego asi como imagenes del mismo que rotan cada 10 segundos.
- Contiene la posibilidad de graficar el rendimiento esperado del juego en la pc donde se corre el programa (el programa detecta los specs de hardware).
- Utiliza archivos xml para guardar la informacion de los juegos, la lista de generos y sub generos, quiere decir que hasta cierto punto es bastante configurable.
- Tiene un directorio con filtros de busqueda muy especificos, se puede buscar juegos por rango de años, desarrollador, genero, tags... etc etc.
- Al usar linq como principal metodologia de busqueda, el programa es sumamente rapido.
- Contiene una pantalla con diferentes estadisticas, desde conteo de juegos por genero hasta graficas de mejores juegos por año, etc etc.


Lista de ToDo para la proxima version:


- Informacion sobre capacidades multiplayer, por ejemplo si soporta lan, si tiene coop, etc etc.
- Pantalla de configuracion... demasiado necesario.
- Arreglar un bug que segun el procesador no toma los multicore.
- Arreglar un bug que en algunas PCs no toma el espacio libre en disco
- Implementar un buen sistema de puntaje de VGA, el actual es muy trucho
- Implementar el boton de go to web site, pense que funcionaba pero no :)
- Poder hacer override de la deteccion del hardware asi el usuario puede dar info de otra maquina o la info real de la suya si algo falla.
- Soportar varios lenguajes


Me imagino que este programa me va a ser bastante util en esas lanes que nadie sabe que jugar, simplemente se busca, se asegura que en todas las maquinas se corre y se baja del storage :)

Links:
Source (https://www.dropbox.com/s/w4xnr2ssy9lh7ys/Source%20v0.7.rar)
Binaries (https://www.dropbox.com/s/lu48k8t7c56m76h/Catalog%20v0.7.rar)

Si alguien tiene alguna consulta sobre el codigo postee aca :)

[Master of the Wind]

Yo te iba a preguntar en el otro topic en que lo hiciste, pero veo que fue en C#.


Ta interesante, te chusmeo el codigo de atrevido.

[G4lle]

Hablamos de esto varias veces pero no llegué a verlo en funcionamiento, así que voy a chusmearlo y romper un poco...

[Reizor]

Lo que tiene se estupendo WPF es la forma que podea customizar los controles desde xaml. y los bindings son un golazo.

[Juancho]

Lo que tiene se estupendo WPF es la forma que podea customizar los controles desde xaml. y los bindings son un golazo.

Si, hacer controles custom esta de fiesta, es re facil y se presta para hacer de todo, en el codigo ese el control custom de graficas utiliza un canvas como base para dibujar las graficas.

[Emisand]

Está bien lindo el código, bien ordenado y comentado.
Por lo del multilanguaje creo que lo ideal es usar un resource file .resx por cada idioma que quieras implementar y cargar el idioma segun la configuracion regional y de cultura de windows, permitiendo hacer override en las settings.

Para cambiar el idioma a cargar de los resources programaticamente se reemplaza en
Thread.CurrentThread.CurrentCulture y en
Thread.CurrentThread.CurrentUICulture

Lo he hecho mil veces, en especial en aplicaciones web multilenguaje.

Consulta:
Tenés idea de como es la mejor manera de implementar un patrón MVC o MVVM con WPF?

[Juancho]

Está bien lindo el código, bien ordenado y comentado.
Por lo del multilanguaje creo que lo ideal es usar un resource file .resx por cada idioma que quieras implementar y cargar el idioma segun la configuracion regional y de cultura de windows, permitiendo hacer override en las settings.

Para cambiar el idioma a cargar de los resources programaticamente se reemplaza en
Thread.CurrentThread.CurrentCulture y en
Thread.CurrentThread.CurrentUICulture

Lo he hecho mil veces, en especial en aplicaciones web multilenguaje.

Consulta:
Tenés idea de como es la mejor manera de implementar un patrón MVC o MVVM con WPF?

Lo de usar los archivos de resource lo he hecho y de hecho es como planeo hacer el multilenguaje de esto gracias :D

Trabaje en un proyecto bastante grande en el que usabamos MVVM con WPF. La estructura de la solucion estaba dividida principalmente en 3 carpetas Views, Models, ViewModels. Las views tenian solo de de WPF, lo importante que hay que tener en cuenta con este modelo es que el WPF tiene que tener basicamente cero logica, es tu principal regla con este patron de diseño, la cosa es cuando empezas a manejar conceptos de dependency property y dependency injection, ahi se complica un cacho la cosa. Pero bueno, sin irse mucho por las ramas, en el constructor de cada wpf haces que reciban el view model asociado como parametro y haces un set de propiedades que estan asociadas directamente al view model.

Ejemplo, en el code behind del WPF:


private windowViewModel myVM;

public int value1
{
get { return myVM.value1; }
set { myVM.value1 = value; }
}


Entonces en el xaml bindeas los controles a estas propiedades del code behind y te quedan bindeadas al view model.

Luego el model, bueno eso simplemente van a ser tus entidades principalmente. Los principios a tener en cuenta es que el WPF nunca toque modelos y el view-model actua como mediador entre datos e interfaz.

[Emisand]

Lo de usar los archivos de resource lo he hecho y de hecho es como planeo hacer el multilenguaje de esto gracias :D

Trabaje en un proyecto bastante grande en el que usabamos MVVM con WPF. La estructura de la solucion estaba dividida principalmente en 3 carpetas Views, Models, ViewModels. Las views tenian solo de de WPF, lo importante que hay que tener en cuenta con este modelo es que el WPF tiene que tener basicamente cero logica, es tu principal regla con este patron de diseño, la cosa es cuando empezas a manejar conceptos de dependency property y dependency injection, ahi se complica un cacho la cosa. Pero bueno, sin irse mucho por las ramas, en el constructor de cada wpf haces que reciban el view model asociado como parametro y haces un set de propiedades que estan asociadas directamente al view model.

Ejemplo, en el code behind del WPF:


private windowViewModel myVM;

public int value1
{
get { return myVM.value1; }
set { myVM.value1 = value; }
}


Entonces en el xaml bindeas los controles a estas propiedades del code behind y te quedan bindeadas al view model.

Luego el model, bueno eso simplemente van a ser tus entidades principalmente. Los principios a tener en cuenta es que el WPF nunca toque modelos y el view-model actua como mediador entre datos e interfaz.

Bien, eso lo tengo claro.
Yo he trabajado bastante con ASP.NET MVC.

Lo que veo que estaría faltando, es como mapeo eventos en el xaml a algun controlador o algo que se encargue de ejecutar la operacion y refrescar la vista o cargar otra vista.
Por ejemplo en MVC tenes en el html de la vista (con razor por ejemplo) los forms que linkeas a una acción de un controlador, o tenes links a acciones, o tambien usas ajax para ejecutar de forma async las acciones sin refrescar la página. Ahora en WPF como implementaría esto con el mínimo código posible en los xaml y code behind?

[Reizor]

Para utilizar los viewmodels en WPF se implementa una interfaz INotifyPropertChange que contiene una funcion OnPropertyChange, y en el set de cada property se notifica a la vista del cambio llamando a la funcion OnPropertyChange.
A nivel de la vista se le bindea el model y a cada elemento de la vista se le bindea la property en la cual deberia de escuchar el evento onchange. En el caso de colecciones en vez de utilizar el List utilizas la clase ObservableCollection que internamente implementa INotifyPropertChange.

Este post de codeproject me ayudo a entenderlo cuando empeze a laburar con WPF:
http://www.codeproject.com/Articles/36545/WPF-MVVM-Model-View-View-Model-Simplified

[Juancho]

Podes investigar el uso de Commands, eso lo tengo medio oxidado para ser honesto pero es re mutable, podes definir Commands en el codigo y usarlos en el xaml, pero como dije antes tambien podes bindear eventos en el xaml.

Digamos por ejemplo:

<Button Content="" Height="32" HorizontalAlignment="Left" Name="btnRandom" VerticalAlignment="Top" Width="32" Grid.Row="3" ToolTip="Random Game" Click="btnRandom_Click">

en el code behind te queda el metodo publico con parametro tipico de evento (object sender) y en ese metodo haces el llamado a tu rutina en el view model o controlador.

Para actualizar una vista en WPF hay un truquito, el tema es que las vistas en WPF corren en un thread separado a las operaciones que se levantan desde ellas mismas. Es decir, .NET utiliza un thread especifico para todo lo grafico en WPF y los eventos que se disparan levantan otro thread para hacer la parte de logica. Cual es el problema con esto? que a diferencia de winforms, si tenes logica por fuera del WPF y su code behind que necesita actualizar algo del WPF tenes que usar el famoso Dispatcher.

Digamos que a nivel de la clase de view model tu vista se llama PM y tiene un control ListBox llamado ProxiesListBox, para llamar un metodo de la vista tenes que implementar lo siguiente:



Thread thread = new Thread(new System.Threading.ThreadStart(
delegate()
{
PM.ProxiesListBox.Dispatcher.Invoke(
System.Windows.Threading.DispatcherPriority.Normal,
new Action(delegate()
{
PM.UpdateList();
}
));
}
));

thread.Start();


Espero que sea de ayuda :)

[Juancho]

Para utilizar los viewmodels en WPF se implementa una interfaz INotifyPropertChange que contiene una funcion OnPropertyChange, y en el set de cada property se notifica a la vista del cambio llamando a la funcion OnPropertyChange.
A nivel de la vista se le bindea el model y a cada elemento de la vista se le bindea la property en la cual deberia de escuchar el evento onchange. En el caso de colecciones en vez de utilizar el List utilizas la clase ObservableCollection que internamente implementa INotifyPropertChange.

Este post de codeproject me ayudo a entenderlo cuando empeze a laburar con WPF:
http://www.codeproject.com/Articles/36545/WPF-MVVM-Model-View-View-Model-Simplified

Esto es parte de DependencyProperty no? solo lo use una vez en mi vida para actualizar una lista de checkboxes segun el model que se cargaba de la base de datos, un penal de aquellos.

[Reizor]

Si, exacto.
Yo lo utilice en toda una aplicación, y la verdad simplifico mucho.
El único control que puede romper las bolas son los combobox que tienen unos dramas que no refrescan adecuadamente si no inicializaste la observablecoletion antes de agregar el listener.
Lo que tiene las dependency properties es que te olvidas de codebehind, y te apoyas 100% en el XAML a no ser que quieras switchear viewmodels y view dentro de una view padre que va a ser el unico momento done utilizas el code behind, aparte claro de la declaración de los eventos de los controles.
También se pueden declarar commands en el viewmodel para ejecutar acciones sobre el model y bindiarlas en el XAML.

[Emisand]

Ok, estuve viendo el tema y si, WPF está diseñado para que se pueda trabajar fácilmente con un patrón MVVM. Es decir las interfaces de notify y los commands son la forma más adecuada y limpia de trabajar con WPF.
También vi que hay algunos frameworks para facilitar el desarrollo de WPF + MVVM tales como Catel o MVVM Light Toolkit.

Alguno de ustedes probó alguno de estos frameworks para facilitar el desarrollo de WPF + MVVM y recomienda alguno?

Nunca he necesitado trabajar con WPF o SL porque me dedico más a aplicaciones web que aplicaciones de escritorio, y para las aplicaciones web he trabajado tanto con ASP.NET clásico como con MVC 4, pero siempre puede surgir un proyecto que lo requiera y es bueno estar bien preparado.

[Reizor]

Yo probé solo MVVM Light, simplifica mucho la implementación de commands, después no utilicé mas nada del framework. Me apoye en lo posible 100% en el xmal y mis viewmodels.