Cuaderno de ingeniería

Mes: diciembre 2012

Desarrollando para iOS desde VisualStudio 2012 con MonoTouch

29 diciembre, 2012 / / Sin comentarios

Hace un tiempo encontré en GitHub una extensión para Visual Studio que si bien no permite ejecutar el emulador de iOS en Visual Studio (básicamente por lo integrado que está Cocoa en OSX), sí que nos permite desarrollar para MonoTouch usando como principal IDE VisualStudio, incluso permite compilar las librerías. Básicamente lo que hace es añadir las referencias de las librerías de MonoTouch por nosotros (podríamos hacerlo manualmente, pero francamente, es un coñazo).
Bien, la extensión en cuestión es esta: https://github.com/ste8/VSMonoTouch. En el enlace tiene las instrucciones para su instalación e información de la misma. Igualmente, aquí hay un enlace con un ejecutable.

 

Imagen

Instrucciones:

Copiar los binarios de MonoTouch desde tu Mac hacia el entorno de Visual Studio. Es decir, lo ficheros de /Developer/MonoTouch/usr/lib/mono/2.1/ de tu Mac a C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv1.0 tu PC. Esto es así porque debemos indicarle a Visual Studio que ahí están los archivos (para que autocomplete, vamos).

Cuando creamos un nuevo proyecto en Visual Studio, este por defecto nos añade una referencia “invisible” a mscorlib.dll, para el correcto funcionamiento de la extensión, debemos sustituir esa referencia por la que utiliza MonoTouch, es decir copiar dicha dll de la solución de MonoTouch y decirle a VisualStudio que debe utiliza la dll de MonoTouch en su lugar.
Según la web del proyecto, con abrir el .csproj y añadir estas líneas debería valer:

<ItemGroup>

<Reference Include="mscorlib" />

<Reference Include="monotouch" />

<Reference Include="System" />

<Reference Include="System.Xml" />

<Reference Include="System.Core" />

</ItemGroup>

A mí particularmente no me funcionó porque me daba un error de duplicidad de referencias (deben ser las instrucciones para VS2010. Lo solucioné incluyendo en el .csproj esta sentencia:

<PropertyGroup Condition=" ‘$(Configuration)|$(Platform)’ == ‘Debug|AnyCPU’ "> <NoStdLib>True</NoStdLib>
</PropertyGroup>

Por último, dado que MonoDevelop aún no soporta proyectos de VS2012, puede que al abrir el proyecto con VS2012 este cambie el .sln y se vuelva incompatible con MonoDevelop. Es tan simple de solucionar como añadir al inicio del proyecto:

Microsoft Visual Studio Solution File, Format Version 11.00
#Visual Studio 2010

Como veis no es demasiado complicado, llevo un mes desarrollando así y os aseguro que vale la pena: la agilidad de VS, resharper, hacer UnitTest con tu runner favorito (el de resharper en mi caso), mantener proyectos con target para WP7&8, W8, Android e iOS desde el mismo IDE con código que sólo cambie la vista… ¿Cómo? Sí, pero de eso ya hablamos otro día.

¡Preprocesador de plantillas Razor!

9 diciembre, 2012 / / 1 comentario

Los chicos de Xamarin no dejan de sorprender, si el otro día Lluis Sanchez presentó la increíble herramienta XWT, hoy es el turno de Michael Hutchinson presentando el preprocesador de plantillas Razor. Lo he probado, y es una auténtica pasada. En su blog podemos ver una entrada (publicada hace un par de horas) de cómo usarla en un proyecto MonoTouch, y asegurando que sirve para prácticamente cualquier tipo de proyecto. Yo os haré una demostración en un proyecto de Consola.

En primer lugar debemos descargarnos los fuentes de MonoDevelop y compilarlos (hay mucha documentación en la red sobre esto). A continuación, creamos un nuevo proyecto de consola al que llamaremos TemplateRazor. Creamos una Clase, Foo, con el siguiente código: 

   1:  namespace TemplateRazor
   2:   
   3:  {
   4:   
   5:  public class Foo
   6:   
   7:  {
   8:   
   9:  public string Salute {
  10:   
  11:  get{return "Hello Razor";}}
  12:   
  13:  }
  14:   
  15:  }
  16:   

Añadimos un nuevo fichero, HelloWorld.cshtml, desde TextTemplating->Preprocessed Razor Template y escribimos:

   1:  @model Foo
   2:   
   3:  <html>
   4:   
   5:  <body>
   6:   
   7:  @Model.Salute;
   8:   
   9:  </body>
  10:   
  11:  </html>



Ya tendríamos nuestra plantilla lista (si os fijáis nos ha creado dos ficheros un .cshtml y .cs). Ahora sólo falta mostrar el contenido en algún navegador, pero por motivos didácticos vamos a ver el código que nos genera en la consola, para ello:

   1:  using System;
   2:   
   3:  namespace TemplateRazor
   4:   
   5:  {
   6:   
   7:  class MainClass
   8:   
   9:  {
  10:   
  11:  public static void Main (string[] args)
  12:   
  13:  {
  14:   
  15:  var template = new HelloWorld(){Model = new Foo()};
  16:   
  17:  Console.WriteLine(template.GenerateString());
  18:   
  19:  }
  20:   
  21:  }
  22:   
  23:  }
  24:   

Y ¡voilá!

PD Podéis encontrar el proyecto de ejemplo en github.

Haciendo un sitio con Orchard multiidioma

6 diciembre, 2012 / / Sin comentarios

Orchard por defecto no soporta multilocalización o multiidioma, lo cual es comprensible porque sigue la máxima de no soportar aquello que no se utilice. Sin embargo, en un país no anglosajón, y más aún en un país dónde el turismo es uno de los principales sectores de nuestra actividad económica, debemos traducir nuestros sitios para intentar llegar a la máxima audiencia.
En realidad no hay ninguna “best practice” para llevar a cabo este proceso con Orchard, no obstante sí que existen unos pasos en común hay que hacer, y esto es instalar una serie de módulos y activar ciertas características:

En Settings>General podemos añadir los idiomas o localizaciones que queremos que estén disponibles.
El módulo Localization : Permite traducir el contenido del sitio. Por defecto, algunos ContentTypes como Page, ya lo implementan, y al instalarlo nos aparece un link que nos permite añadir soporte para las localizaciones a las que hemos dado soporte en las opciones.

Existen más módulos interesantes para ayudarnos con la implementación multiidioma del sitio: CulturePicker, CultureLayer, etc. Aunque como he comentado van en función de lo que queramos hacer.
Si hay algo que no tiene una solución clara, es cómo contemplar los Menús de la página, hay quien opta por crear un menú entero por cada idioma y usar módulos como CultureLayer para mostrar sólo una de esas capas por idioma. En mi caso particular, lo he solucionado convirtiendo el ContentType Custom Link en localizable (añadiendo manualmente el ContentPart Localizable a CustomLink). Y aunque he tenido que introducir los urls a mano, es bajo mi punto de vista, la mejor solución, al menos por ahora.

Coste de las operaciones.

2 diciembre, 2012 / / 1 comentario

Motivado por la excelente entrada de Eduard Tomàs, El orden de los algoritmos… esa gran O. Hoy os traigo una pequeña tabla que he confeccionado, intentando mantener la simplicidad, de los tipos de datos más comunes y el coste asintótico de las operaciones habituales.

tabla

Grosso modo estas son las colecciones más usadas y sus costes de las implementaciones más comunes (hay más), como vemos depende de la situación. Por ejemplo, ante la duda de una lista ordenada o no ordenada, nos decantaremos por una u otra dependiendo si tenemos que buscar o insertar más.

Entradas recientes

Meta

Categorías

Archivos

Comentarios recientes

© 2024 Cuaderno de ingeniería

Tema por Anders Noren — Arriba ↑