2009-07-31

Como hacer que nant funcione con mono en OS X

En el sitio de Monobjc, dice que para compilar y armar el paquete de aplicación para un programa hecho con una interfaz Cocoa y Monobjc se debe utilizar un script de nant que ellos proveen.

El problema es que al intentar ejecutarlo nant se queja diciendo que le faltan ciertas librerías.


Para poder solucionarlo hay que hacer dos cosas:
  • Crear un SymLink de /Library/Frameworks/Mono.framework/Versions/Current/bin/pkg-config a /usr/bin/pkg-config
  • Editar el archivo /Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/mono.pc y comentar la linea que comienza con "Requires"
Con esto hecho, podrán utilizar sin problemas el script de nant para armar los .app de mono!

Saludos!
Z


2009-07-23

.NET Tip: Validación de requests con SSL usando System.Net.WebClient

¿Cuantas veces han querido hacer un request a una página por HTTPS y su certificado no era válido? Posiblemente nunca, pero en caso de querer hacerlo se encontrarán con que, por default, System.Net.WebClient rechazará el pedido por motivos de seguridad. Para poder pasar esta validación por arriba hay que hacer el pequeño triquiñuelo de agregar un callback a ServicePointManager.ServerCertificateValidationCallback antes de hacer el request utilizando el WebClient:

public void RequestSSL(string url)
{
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
using (WebClient client = new WebClient())
{
client.DownloadString(url);
}
}
private static bool ValidateRemoteCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors policyErrors)
{
return true;
}

Espero que a alguien le sirva!
Z


2009-07-18

Probando Blogo desde la Mac

Mr. Kus me pasó el link a este programa de blogging para Mac, frente a mi pedido de algún soft que pudiese reemplazar a mi querido Live Writer.

Por ahora parece bastante bueno. Cuando tenga un post mas largo para escribir, espero poder confirmarlo.


2009-07-14

Monos y Manzanas: Key Value Coding y Configuración

Hacia el final de la entrega anterior de Monos y Manzanas estuve contando sobre como utilizar los bindings de Cocoa con Monobjc. En el capítulo final de esta serie de posts veremos como es posible agilizar la implementación de clases que utilicen Key Value Coding (KVC de ahora en mas) desde .NET y como agregar un panel de preferencias para modificar la configuración de la aplicación y que la misma sea persistida de forma automática.

Ante todo, fe de erratas: una persona del equipo de MonobjC con la cual me contacté, me acalró que no es necesario crear una instancia que nadie usa de NSAutoReleasePool en el bootstrapping de la aplicación, ya que eso se hace automáticamente.

En el último ejemplo mostrado, cada vez que se quería implementar una propiedad que pudiese ser utilizada para los bindings con KVC era necesario crear los setters y getters, indicarles que iban a ser llamados como mensajes de ObjectiveC y llamar a las notificaciones de cambios de propiedad.
Para no tener que hacer esto por cada propiedad que queramos exponer al runtime de ObjectiveC, crearemos un nuevo atributo el cual indique que esa propiedad podrá ser utilizada con KVC:

using System;

namespace zPod.Objc
{
public class KeyValueCodingAttribute : Attribute
{
public KeyValueCodingAttribute (string propertyName)
{
PropertyName = propertyName;
}

public string PropertyName
{
get;
set;
}
}
}

Teniendo esto, las propiedades que querramos exponer se verán así:


[KeyValueCoding("modelo")]
public BrowserModel Modelo
{
get;
set;
}

Muy lindo hasta ahora pero... ¿Como le indicamos al runtime de ObjectiveC que deberá tomar la propiedad "modelo" al intentar llamar al mensaje "modelo" o "setModelo:"? Simple, sobreescribiendo el llamado a los mensajes "setValue:forUndefinedKey:" y "valueForUndefinedKey"


[ObjectiveCMessage("setValue:forUndefinedKey:")]
public override void SetValueForUndefinedKey (Id val, NSString key)
{
this.ResolveSetValueForUndefinedKey(val, key);
}

[ObjectiveCMessage("valueForUndefinedKey:")]
public override Id ValueForUndefinedKey (NSString key)
{
return this.ResolveValueForUndefinedKey(key);
}

Al no encontrar una clave definida, Cocoa avisa a la clase que se intento leer o dar valor a la clave utilizando estos mensajes.


En estas implementaciones se está llamando a los métodos ResolveSetValueForUndefinedKey y ResolveValueForUndefinedKey. Los mismos son extension methods creados para la clase NSObject que resuelven cual es la propiedad que deberá ser devuelta o modificada utilizando reflection para saber si tienen el atributo definido anteriormente. El código de estos métodos se incluye dentro de los fuentes de este ejemplo.




Hacia el final de la entrega anterior de Monos y Manzanas comenté que Cocoa proveía un controller especial llamado NSUserDefaultsController que permite guardar automáticamente las preferencias del usuario.
Ahora vamos a ver como crear un nuevo panel de preferencias donde configurar la URL Home de nuestro browser.


Volviendo al Interface Builder, agregamos un nuevo NSPanel y le agregamos un TextField para ingresar la URL Home


Picture 1


Para poder abrir el panel desde el menu de preferencias, conectamos la opción Preferences... del menú con el panel creado, asociándolo a la acción makeKeyAndOrderFront:.


Picture 3


Dado que se necesita únicamente una instancia de este panel, lo configuramos como se muestra en la siguiente imagen. Lo mas importante es desmascar las opciones Released When Closed y Visible at launch para que no se muestre al incio, pero que al cerrar la ventana solamente se oculte y no se destruya el objeto.


Picture 2


Creamos el binding para el value del TextField, conectándolo con la instancia de SharedUserDefaultsController, utilizando la clave values y el model key path homePage.
Al utilizar este controller, los valores conectados serán persistidos automáticamente.


Picture 4


Como último paso dentro del Interface Builder, agregamos un nuevo boton para ir a la home, agregamos una nueva acción llamada goHome: al BrowserController y los asociamos de la misma manera que el boton Go.


Picture 5


Volviendo a C#, Dentro del código del BrowserController, modificamos el método AwakeFromNib y agregamos el método que responda al mensaje goHome:, para que al iniciar la aplicación vaya a la URL definida como home y, en caso de no haber nada, definirle un valor default (recuenden que en _userDefaults tenemos guardada una instancia de SharedUserDefaultsController):


[ObjectiveCMessage("goHome:")]
public void GoHome(Id sender)
{
NSString home = _userDefaults.ValueForKeyPath("values.homePage");
this.Modelo.WillChangeValueForKey("url");
this.Modelo.Url = home;
this.Modelo.DidChangeValueForKey("url");
Browse(sender);
}

[ObjectiveCMessage("browse:")]
public void Browse(Id sender)
{
NSString url = this.Modelo.Url;
browser.MainFrameURL = url;
_userDefaults.SetValueForKeyPath("CocoaBrowser - " + url, "values.title");
}

[ObjectiveCMessage("awakeFromNib")]
public void AwakeFromNib ()
{
NSString home = _userDefaults.ValueForKeyPath("values.homePage");
if (home == null)
{
_userDefaults.SetValueForKeyPath(new NSString("http://zPod.com.ar"), "values.homePage");
}

GoHome(null);
}

Listo! Ahora a compilar y a disfrutar de su nuevo browser con botón de Home para Mac hecho en .NET!


Picture 6


Con esto queda finalizada la serie de posts: Monos y Manzanas. El código completo lo pueden bajar de aca.



Hasta la próxima!
Zaiden

2009-07-12

Monos y Manzanas: Binding entre la UI y el Modelo

En el último post expliqué como hacer una aplicación sencilla para Mac cuya UI estaba hecha con Interface Builder, y el resto de la plomería de fondo utilizaba C#, gracias a Mono y el bridge Monobjc.

Dada la extrema simplicidad de nuestro CocoaBrowser, hubieron algunos conceptos que escaparon al ejemplo inicial.

En esta nueva entrega de Monos y Manzanas veremos como hacer uso del binding provisto por Cocoa y el Interface Builder para conectar nuestra interfaz gráfica al Modelo de nuestra aplicación.

Por ahora, definiremos una nueva clase BrowserModel, la cual representará el “modelo” de nuestra apliación de juguete.

public class BrowserModel
{
private string _url;
public string GetUrl()
{
return _url;
}

public void SetUrl(string newUrl)
{
_url = newUrl;
}
}


Posiblemente se pregunten: Por qué la propiedad esta definida con metodos Get y Set, en vez se ser una propiedad “normal” de C#, al estilo “public string Url { get; set'; }”?

Es por un requerimiento del bridge con Objective-C y el binding con la UI, pero vamos a verlo bien mas adelante.


La idea es que lo que usuario tipee dentro del TextField utilizado para ingresar la URL de nuestro browser actualice automáticamente nuestro modelo y, en caso de actualizar el modelo desde otro lugar, se actualice automáticamente el TextField.


Para poder hacer esto, agregaremos un nuevo campo a la clase BrowserController que nos de acceso al modelo, y lo haremos visible para el bridge, con los siguientes getter y setter:


[ObjectiveCClass]
public class BrowserController : NSObject
{
//
// Mucho codigo antes...
//

private BrowserModel _modelo = new BrowserModel();

[ObjectiveCMessage("modelo")]
public BrowserModel getModelo()
{
return _modelo;
}

[ObjectiveCMessage("setModelo:")]
public void setModelo(BrowserModel nuevoModelo)
{
WillChangeValueForKey("modelo");
_modelo = nuevoModelo;
DidChangeValueForKey("modelo");
}

//
// Mucho codigo despues...
//

}

Esta forma de crear los campos permite a ObjectiveC utilizar la clase con algo conocido como Key Value Coding, accediendo a ciertas propiedades de nuestra clase como si fuesen pares Clave - Valor, tanto para leer como para escribir.

Los métodos WillChangeValueForKey y DidChangeValueForKey permiten avisarle a la UI que hubo un cambio en el valor la propiedad.


Para que las propiedades de la clase BrowserModel sean accesibles de la misma manera, las decoramos de forma similar, quedando como resultado:


[ObjectiveCClass]
public class BrowserModel : NSObject
{
// Constructores requeridos por NSObject
public BrowserModel()
{
}

public BrowserModel (IntPtr nativePointer) : base(nativePointer)
{
}

private string _url;

[ObjectiveCMessage("url")]
public string GetUrl()
{
return _url;
}

[ObjectiveCMessage("setUrl:")]
public void SetUrl(string newUrl)
{
WillChangeValueForKey("url");
_url = newUrl;
DidChangeValueForKey("url");
}
}

Como pueden ver, es requisito agregar el atributo [ObjectiveCClass] y hacer heredar la clase de NSObject (o algún hijo) para que la misma sea visible desde ObjectiveC. Al hacer esto, deberán agregar los dos constructores indicados en el código.


Dado que ahora el URL a navegar será indicado por las propiedades del modelo, podemos sacar la referencia al TextField del BrowserController y modificar el metodo Browse de la siguiente manera:


[ObjectiveCClass]
public class BrowserController : NSObject
{
//
// Mucho codigo antes...
//

[ObjectiveCMessage("browse:")]
public void Browse(Id sender)
{
string url = this.fModelo.getUrl();
browser.MainFrameURL = url;
}

//
// Mucho codigo despues...
//

}

Con esto listo, solo resta hacer los bindings propiamente dichos en el Interface Builder.


El primer paso será agregar un ObjectController desde la Library. Este tipo de controller nos permite hacer binding facilmente a un objeto concreto del modelo. En caso de querer hacer binding contra Arrays, Diccionarios y otros tipos de datos, existen controllers mas apropiados.


Picture 1


Dentro de los atributos del ObjectController, agregar una nueva clave llamada “url”, la cual usaremos como nexo entre el modelo y la UI.


Picture 2


Dentro de los bindings del ObjectController, indicamos que el Controller Content debe hacer binding con el BrowserController, utilizando como Model Key Path “modelo”. Esto hará referencia a la propiedad modelo que creamos – e hicimos visible con setter y getter para ObjectiveC – dentro de la clase creada en C#.


Picture 3


Finalmente, seleccionamos el TextField de la URL y dentro de la solapa de bindings indicamos que se deberá hacer el binding con el ObjectController, utilizando “selection” como Controller Key y “url” como Model Key Path. Para que el modelo se actualice cada vez que se modifica el TextField y no únicamente al terminar de editarlo cambiando el foco, deberemos marcar el check de “Continuosly Update Value”.


Picture 4


Como yapa, en esta versión de los fuentes, podrán ver como hacer binding contra una clase especial llamada NSUserDefaultsController, la cual nos permite mantener guardadas las preferencias del usuario haciendo binding contra las mismas. En este ejemplo se utiliza para guardar el titulo de la ventana de la aplicación, aunque su utilidad mas común es dentro de los paneles de preferencias.


El código lo pueden bajar de aca.


Hasta la próxima!
Zaiden

2009-07-08

Monos y Manzanas: Como hacer aplicaciones Cocoa con .NET

Desde que soy usuario de OS X he intentado varias veces desarrollar alguna aplicación que pueda aprovechar todo el poder de la plataforma .NET y las delicias gráficas de las interfaces gráficas creadas con Cocoa y sus frameworks para Mac.

La necesidad de utilizar .NET sobre el sistema operativo impulsado por Steve Jobs está cubierta desde hace un buen tiempo por la gente de Mono y su implementación multiplataforma del CLR y gran mayoría de las librerías incluidas en el .NET Framework.
El problema radicaba en como poder interactuar de forma simple y comoda con una UI hecha en Cocoa y no con el - bastante sovietico - port de Windows.Forms que incluye Mono, o con librerías graficas como GTK que se ven bastante alienigenas dentro de la Mac.

Investigando un poco, encontré que existen varios proyectos que hacen de bridge entre el mundo de Mono y .NET y los frameworks provistos por Cocoa.
Inicialmente, utilicé la librería publicada en el mismo sitio de Mono: Cocoa#. El problema fue que, pese a su simplicidad, tenía demasiados problemas de performance y estabilidad, por lo que quedó descartada.

Hace no mucho leí de otro bridge que, apartentemente, tiene bastante aceptación: Monobjc. Estas librerías permiten utilizar tanto una interfaz creada en Cocoa y sus frameworks desde una aplicación .NET como exponer - con ciertas restricciones - clases hechas en .NET dentro de una aplicación nativa hecha en Cocoa y ObjectiveC.

En este caso voy a explicar, paso a paso, como crear una nueva aplicación que nos permita navegar por la web cuya (única) View esté desarrollada con Cocoa utilizando el Interface Builder y el Controller y (ausente) Model estén hechos en C#

Requerimientos

Para empezar vamos a crear una nueva View utilizando Interface Builder (se recomienda tener al menos conocimientos básicos sobre como utilizar Interface Builder).

Al abrir Interface Builder seleccionamos el template de Cocoa Application

1. NuevaApp

Una vez creado el proyecto, podremos ver la ventana principal creada para la aplicación, su menú, el listado de objetos existentes, el inspector donde podrémos modificar propiedades de los controles y la librería de controles disponibles desde Cocoa

2. Empezar

En la librería de controles buscamos los controles de WebView, TextField y Button y los agregamos a la ventana, como se ve en la imagen. Pueden modificar las propiedades de estos controles en el inspector para permitirles ajustar su tamaño de acuerdo al resizing de la ventana.

5. VentanaLista

Con la ventana lista, agregamos un nuevo Object a la ventana que contiene la lista de objetos disponibles, y cambiamos el nombre de su clase por ObjectController. Este será el objeto que represente al Controller que crearemos desde C# mas adelante.

6. NuevoObject

Dentro de las actions disponibles para el controller deberemos agregar "browse:" que corresponderá a la acción de iniciar la navegación del URL escrito en el TextField anterior.
De la misma manera, deberémos exponer los Outlets "address", "window" y "browser" como se muestra en la imagen, los cuales asociaremos al TextField, la ventana y el WebView.

7. PropiedadesController

El último paso de esta parte será hacer el link entre las acciones y outlets definidos en el BrowserController y los controles creados dentro de la UI. Para hacer esto mantenemos apretada la tecla control y dibujamos una linea hacia cada uno de los controles. De esta manera aparecerá un menú para vincularlos hacia los outlets disponibles en el Controller.
De forma análoga se debe dibujar una linea desde el botón hacia el BrowserController, para asociar el click a la action "browse:"

Para asegurarse de haber vinculado todo de forma correcta, al hacer click derecho sobre el BrowserController se deberá ver un panel similar a este:

8. BindingController

Con la interfaz lista, guardamos la ventana como un nuevo archivo NIB (ojo! guardar como NIB y NO como XIB!).

Ahora, a programar el controller y el bootstrap de la aplicación en C#
Para hacerlo, pueden utilizar cualquier IDE de su agrado. En particular, yo uso MonoDevelop.

Deberémos crear un proyecto el cual referencie a las assemblies de Monobjc, Monobjc.Cocoa y Monobjc.WebKit ya que son las que utilizamos dentro de la interfaz.
Dentro del proyecto crearemos dos clases: la primera será el bootstrap de la aplicación y la segunda sera el BrowserController

Para hacer el bootstrap deberémos crear una clase muy similar al siguiente ejemplo:

using Monobjc;
using Monobjc.Cocoa;
using System;

namespace zPod.CocoaBrowser
{
public class Program
{
public Program ()
{
}

public static void Main (String[] args)
{
ObjectiveCRuntime.LoadFramework ("Cocoa");
ObjectiveCRuntime.LoadFramework ("WebKit");

ObjectiveCRuntime.Initialize ();
NSApplication.Bootstrap ();

NSAutoreleasePool pool = new NSAutoreleasePool();

NSApplication.LoadNib ("MainWindow.nib");
NSApplication.RunApplication ();
}
}
}


Las primeras lineas del método Main cargan los frameworks de ObjectiveC que utilizaremos. En este caso "Cocoa" y "WebKit".


Luego de cargar los frameworks se inicializa el bridge con el runtime de ObjectiveC y se dispara la aplicación.


Como verán, antes de cargar el NIB se crea un nuevo NSAutoreleasePool. Esto sirve para evitar leaking por parte de ObjectiveC.



Finalmente llamamos al metodo LoadNib, el cual cargará la interfaz grafica creada anteriormente y lanzamos la aplicacion con el método RunApplication.



La creación del BrowserController es muy sencilla: en la misma hay que crear propiedades que corresponderán a los outlets definidos en la interfaz y metodos para atrapar las actions disparadas desde la misma.



Las clases marcadas con el atributo [ObjectiveCClass] serán expuestas al runtime de ObjectiveC. Las propiedades decoradas con el atributo [ObjectiveCField] representan los outlets y los métodos decorados con [ObjectiveCMessage] sirven para atrapar las actions disparadas por la View.



using System;
using Monobjc;
using Monobjc.Cocoa;
using Monobjc.WebKit;

namespace zPod.CocoaBrowser
{
[ObjectiveCClass]
public class BrowserController : NSObject
{
[ObjectiveCField]
public NSTextField address;

[ObjectiveCField]
public WebView browser;

[ObjectiveCField]
public NSWindow window;

public BrowserController ()
{
}

public BrowserController (IntPtr nativePointer) : base(nativePointer)
{
}

[ObjectiveCMessage("browse:")]
public void Browse (Id sender)
{
string url = address.Cell.Title;

browser.MainFrameURL = url;
}

[ObjectiveCMessage("awakeFromNib")]
public void AwakeFromNib ()
{
window.Title = "CocoaBrowser - zPod";
}
}
}


En este ejemplo, se ve el método AwakeFromNib, el cual se ejecutará al finalizar de cargar la vista. En el mismo, seteamos el título de la ventana.

Para atrapar la accion "browse", creamos un metodo con su correspondiente atributo y dentro del mismo cambiamos la URL del MainFrame del WebView.



Una vez listo esto, solo queda probar la aplicación.

Según la documentación de Monobjc, se tendría que poder ejecutar un script de NAnt que proveen ellos y crear una estructura de directorios específica. Dado que eso no me está funcionando (por algún motivo NAnt no encuentra a mono) armé un pequeño script de bash que arma todo lo necesario para tener nuestra App empaquetada y lista para ejecutar.



Aca dejo para bajar esta aplicación de ejemplo como proyecto de MonoDevelop, el cual al compilarse dejará en el directorio bin/Debug todos los archivos necesarios para armar el paquete. Lo único que hay que hacer es, desde la consola, ir al directorio /bin/Debug del proyecto y ejecutar:



./MakePackage CocoaBrowser


Con esto se generará un nuevo paquete de aplicación ejecutable, cuyo resultado es:



9. App



Ahora, a divertirse!



Saludos!

Zaiden