Actuar quan entra una trucada a les aplicacions amb Windows Phone

Aquí teniu un gràfic del model d’execució de Windows Phone.

Com podeu veure les aplicacions passen a estat Dormant quan no estan en primer pla. Posteriorment si el sistema determina que necessita més memòria els passa a un estat Tombstoned.

Aquests dos estats són completament recuperables. La diferencia entre un i l’altre és que el primer tot està a memòria i el segon no.

Una aplicació passa a segon pla quan premem el botó de Windows o quan l’aplicació crida un altra aplicació. O bé quan el sistema ho necessita. En tots els casos tal com veieu a la gràfica es crida OnNavigatedFrom.

En una trucada entrant no és així. En aquest cas no es considera que la App passi a segon pla. Mentre tu parles l’aplicació continua la seva execució. Això significa que no es crida el OnNaviogatedFrom i per tant no ens dóna cap tipus de pista que hi ha una trucada entrant.

Per sort, si tenim els events Obscured i Unobscured. Aquí teniu un link que us dóna molta información : How to handle phone calls and other interruptions in Windows Phone, tot i que he detectat un petit error en el codi font. Aquí poso corretgit:

App<span style="font-family: Consolas; font-size: small;"><span style="font-family: Consolas; font-size: small;">.RootFrame.Obscured += RootFrame_Obscured;</span></span>

App.RootFrame.Unobscured += RootFrame_Unobscured;

void RootFrame_Obscured(object sender, ObscuredEventArgs e)
{
oTimer.Stop();
txtStatus.Text = "Obscured event occurred";
}

void RootFrame_Unobscured(object sender, EventArgs e)
{

oTimer.Start();
txtStatus.Text = "Unobscured event occurred";
}

Aspectos fundamentales de la programación ASP.NET (3era parte)

Tercera parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte y la segunda.

Cookies

Una de las formas que tienes de poder conservar el estado en tus peticiones Http es utilizando Cookies. Ya he hablado de que el protocolo Http no tiene estado, significa que cada petición es independiente de la anterior, e implica que para cada petición necesitas enviar toda la información necesaria para que el servidor pueda recordar quien eres y que habías hecho para saber que quieres hacer. Eso es lo que denominamos mantener el estado.

Las cookies son ficheros de texto simples que se guardan en el ordenador del cliente y se adjuntan a las peticiones Http. Se habla mucho de las cookies y del peligro de seguridad que suponen. Al ser una información que viaja por la red y que se queda guarda en el cliente no la puedes utilizar para almacenar información importante o susceptible para el buen comportamiento de tus aplicación web.

Normalmente se utilizan las cookies para ayudar a la aplicación web saber que páginas has estado visitando antes.

Internet Information Server (IIS)

Toda aplicación web ya sea estática o dinámica necesita de un servidor web para poder entregar las páginas. En Microsoft tenemos el IIS. El IIS es el responsable de entregar las páginas que se solicitan mediante una petición Http. En el caso de ASP.NET necesita la instalación del Framework para que el IIS sepa interpretar los archivos con extensión .aspx.

Microsoft Windows Server 2003 trabaja con IIS 6, Microsoft Windows Server 2008 con IIS 7. Existe un cambio importante entre las dos versiones.

La aplicación web se guarda en una carpeta del servidor que por defecto es wwwroot en la unidad de instalación del sistema operativo.

 

Directorios virtuales

Configura una carpeta para que funcione como una aplicación web. Una aplicación web funciona mediante un pool de aplicaciones que puede ser distinto para cada web permitiendo aislar la web de todas las demás.

Procesado ASP.NET

Como se comporta el IIS ante una petición a una página ASPX sirve para entender un poco más como funciona la lógica de proceso ASP.NET.

Ya he hablado que existen dos versiones actualmente del IIS y que habían cambios importantes, con la siguiente explicación espero poder aclarar en que se basan.

Procesado en IIS6 / IIS7 Modo clásico

El IIS tiene la responsabilidad para cada solicitud de comprobar restricciones IP, permisos de lectura y ejecución de la página solicitada y si es de acceso anónimo o necesita una autenticación. En IIS 6 solo puedes gestionar la autenticación por Windows.

Después la solicitud es recogida por el proceso de trabajo ASP.NET donde se evalúa la autorización de acceso al recurso solicitado, si es necesario una autenticación por formularios, sobreescritura de la URL, recuperación de la sesión, gestión de la caché, servicios personalizados, creación de los objetos ASP.NET. Todo esto es lo que se hace en la Pipeline.

En la primera solicitud se carga el ensamblado en el dominio de la aplicación y se crea una instancia del objeto. Recuerda que ya he comentado que en .Net todo es un objeto incluso las páginas en ASP.NET.

Con la instancia del objeto creado se procesa y se genera una respuesta.

El ensamblado se queda guardado en el dominio de la aplicación para posteriores peticiones. De esta forma las peticiones siguientes serán más rápidas.

Procesado en IIS7 Modo integrado

En la nueva versión del IIS hay módulos ASP.NET integrados que permite coger más responsabilidad en el procesado de las páginas ASP.NET. Ahora el Pipeline está en el IIS, de esta forma la autorización, autenticación o caché de salida sirve para páginas estáticas, páginas php, etc.

También IIS7 permite la autenticación por formularios.

ASP.NET 4 Versión IIS 7.5

Con el Microsoft Windows Server 2008 R2 aparece una versión mejorada del 7. El IIS 7.5 tiene la novedad que junto a ASP.NET versión 4 del .Net Framework puedes programar el auto arranque de las aplicaciones web hospedadas en el IIS. Tal y como he hablado antes las primeras peticiones cargan el ensamblado en el dominio de la aplicación, esto supone claro una perdida de tiempo. Para evitarlo tienes el auto arranque.

Para ello debe indicar qué pool de aplicaciones son arrancados automáticamente. Tienes que editar el fichero de configuración applicationhost.config

<applicationPools>

<add name=”MyApplicationPool” startMode=”AlwaysRunning” />

</applicationPools>

o puedes indicar individualmente aplicaciones para que se auto carguen al inicializar el IIS.

<sites>

<site name=”MySite” id=”1″>

<application path=”/” serviceAutoStartEnabled=”true” serviceAutoStartProvider=”PrewarmMyCache” >

<!– Additional content –>

</application>

</site>

</sites>

<!– Additional content –>

<serviceAutoStartProviders>

<add name=”PrewarmMyCache” type=”MyNamespace.CustomInitialization, MyLibrary” />

</serviceAutoStartProviders>

El funcionamiento es muy simple: En el momento que IIS arranca por primera vez o se reinicia un pool de aplicaciones IIS 7.5 envía una solicitud al objeto CustomInitialization para que ejecute el método PreLoad. En este momento las solicitudes quedan bloqueadas.

Después se carga el ensamblado en el dominio de la aplicación y se libera el bloqueo.

public class CustomInitialization :

System.Web.Hosting.IProcessHostPreloadClient

{

public void Preload(string[] parameters)

{

// Perform initialization.

}

}

La interfaz IProcessHostPreloadClient permite la implementación del método PreLoad utilizada en IIS 7.5 como punto de entrada en la pre carga de una aplicación web.

Más cosas en la cuarta parte de este post.

Gracias

Windows Phone : TextBlock justify doesn’t work

TextBlock is the control to used for writing text on the screen. It is really simple and easy. But, I don’t know why, justify the text using the TextAlignment attribute doesn’t work.

Luckily we have the RichTextBox control.

 

<RichTextBox TextAlignment=”Justify” IsReadOnly=”True”>
<Paragraph>
Put your text here
</Paragraph>
</RichTextBox>

 

Happy coding.

Transicions animades entre pàgines de Windows Phone

Amb el Windows Phone Toolkit tenim la possibilitat de poder assignar animacions (no moltes) entre les transicions de les pàgines.
Un cop instal·lar el toolkit que ho hem de fer amb el NuGet, que realment va molt i molt bé, i assignat una animació a la transició a la pàgina amb el següent codi XAML:

<phone:PhoneApplicationPage
x:Class=”PhoneApp1.Page1″
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation&#8221;
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml&#8221;
xmlns:phone=”clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone”
xmlns:shell=”clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone”
xmlns:toolkit=”clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls.Toolkit”
FontFamily=”{StaticResource PhoneFontFamilyNormal}”
FontSize=”{StaticResource PhoneFontSizeNormal}”
Foreground=”{StaticResource PhoneForegroundBrush}”
SupportedOrientations=”Portrait” Orientation=”Portrait”
shell:SystemTray.IsVisible=”True”>

<toolkit:TransitionService.NavigationInTransition>
<toolkit:NavigationInTransition>
<toolkit:NavigationInTransition.Backward>
<toolkit:TurnstileTransition Mode=”BackwardIn”/>
</toolkit:NavigationInTransition.Backward>
<toolkit:NavigationInTransition.Forward>
<toolkit:TurnstileTransition Mode=”ForwardIn”/>
</toolkit:NavigationInTransition.Forward>
</toolkit:NavigationInTransition>
</toolkit:TransitionService.NavigationInTransition>
<toolkit:TransitionService.NavigationOutTransition>
<toolkit:NavigationOutTransition>
<toolkit:NavigationOutTransition.Backward>
<toolkit:TurnstileTransition Mode=”BackwardOut”/>
</toolkit:NavigationOutTransition.Backward>
<toolkit:NavigationOutTransition.Forward>
<toolkit:TurnstileTransition Mode=”ForwardOut”/>
</toolkit:NavigationOutTransition.Forward>
</toolkit:NavigationOutTransition>
</toolkit:TransitionService.NavigationOutTransition>

<Grid x:Name=”LayoutRoot” Background=”Transparent”>
<Grid.RowDefinitions>
<RowDefinition Height=”Auto”/>
<RowDefinition Height=”*”/>
</Grid.RowDefinitions>

<StackPanel Grid.Row=”0″ Margin=”12,17,0,28″>
<TextBlock Text=”MY APPLICATION” Style=”{StaticResource PhoneTextNormalStyle}”/>
<TextBlock Text=”page name” Margin=”9,-7,0,0″ Style=”{StaticResource PhoneTextTitle1Style}”/>
</StackPanel>

<Grid x:Name=”ContentPanel” Grid.Row=”1″ Margin=”12,0,12,0″>
<Button x:Name=”ClickMe” HorizontalAlignment=”Center” Click=”ClickMe_OnClick”>Click Me</Button>
</Grid>
</Grid>

</phone:PhoneApplicationPage>
L’única cosa que ens queda llavors és canviar aquesta línia del App.xaml.cs per tal de que en lloc d’utilitzar el Frame que hi ha per defecte s’utilitzi el que porta el Toolkit

//RootFrame = new PhoneApplicationFrame();
RootFrame = new TransitionFrame();

Més informació:

How to create Transition animation in Windows Phone Toolkit?

 

Aspectos fundamentales de la programación ASP.NET (2na parte)

Segunda parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte.

HTML, páginas estáticas

Es el escenario más simple que puedes tener en una web. Ahora prácticamente son todas dinámicas, hay ya pocas webs que utilicen páginas estáticas Html.

Una página Html contiene etiquetas que indican a los navegadores como tienen que renderizar el contenido.

Al final, todas las páginas dinámicas terminan enviando Html estático al navegador ya que es esto lo que interpreta y no los controles ASP.NET que verás más adelante.

<div>

<html>

<head>

<title>This is a static page</title>

</head>

<body>

<h1>Hello world</h1>

<table border="1" width="50%">

<tr> <th>Name</th>   <th>Age</th> </tr>

<tr> <td>Emily</td>  <td>4</td>   </tr>

<tr> <td>Thomas</td> <td>4</td>   </tr>

</table>

</body>

</html>

Añadir código de cliente

Esta técnica es la utilizada por las aplicaciones web para poder realizar tareas dinámicas en el cliente, es el navegador quien realiza el trabajo liberando así al servidor. El lenguaje por excelencia utilizado para el código de cliente es el Javascript. En ASP.NET verás que muchas de las funcionalidades que nos prestan los controles se convierten en acciones Javascript que se ejecutan al cliente.

<div>

<html>

<head>

<script language="javascript">

function displayValue()

{

alert("You entered: " + document.form1.text1.value);

}

</script>

</head>

<body>

<form name="form1">

<input type="text" size="10" name="text1" />

<input type="button" value="Click Me!" onclick="displayValue();" />

</form>

</body>

</html>

</div>

Se suele utilizar Javascript para validar datos en el cliente antes de ser enviadas al servidor, para realizar efectos en la interfaz gráfica y para realizar Ajax. Ha evolucionado mucho el concepto del código en cliente hasta al punto de existir Frameworks galardonados por la comunidad como son JQuery, MooTools, Dojo y muchos más. JQuery ha sido introducido por Microsoft en las aplicaciones web del .Net 4.

Proceso en el servidor

El proceso en el servidor te permite crear páginas dinámicamente, lo que son ASPX por ASP.NET. Son páginas que necesitan del Framework para poder ejecutarse y generar el contenido Html necesario para que el navegador pueda renderizar el contenido.

Las páginas estáticas anteriormente comentadas solo necesitan un servidor de páginas web como es el IIS de Microsoft que se encuentra en sus sistemas operativos para poder ser entregada al cliente. Las páginas dinámicas como son las .aspx de ASP.NET, .php de PHP, .jsp de Java, necesitan aparte del IIS el Framework que permita la compilación si es necesaria y la posterior ejecución del código asociado a la página dinámica.

Este código asociado es el que te permite si es necesario poderte conectar con servidores de bases de datos, servicios web para poder recuperar la información en tiempo real que te está pidiendo el cliente.

Formularios y proceso en el servidor

 

Formularios

Los formularios te permiten enviar información al servidor para que esta la pueda procesar. Un formulario es el cuerpo principal de todas las páginas aspx de ASP.NET, las denominadas Web Forms.

La etiqueta Html del formulario es el Form. Esta etiqueta tiene unos atributos que vale la pena comentar:

• Action : Define la página que recibirá el contenido del formulario. En Web Forms este atributo es por defecto la misma página que tiene el formulario.
• Method : Define el método Http que vas a utilizar para enviar el contenido. Existen dos que son los más utilizados en la web: GET y POST. Este atributo en los Web Forms es por defecto el POST.

En los formularios se puede enviar elementos de entrada como campos de texto, checkboxes, radio-buttons, botones, listas y otros.

 

Métodos

Tal y como he comentado existen dos métodos principales en el momento de enviar el formulario al servidor: Get y Post.

Para los dos el formato con el que se envía la información es la misma: campo=valor separando cada campo con el símbolo ‘&’.

Las diferencias básicas las encuentras en:

• Get: Utiliza la Url para enviar la información. Por tanto puede  ser guardado en los favoritos de los navegadores pero tiene una longitud limitada. El estándar HTTP 1.1 que puedes leer en http://www.w3.org no indica ningún tipo de limitación, son los navegadores que lo imponen, en el caso del IE8 está en 2083 caracteres.
• Post: La información se envía adjunto a la petición como si se tratara de un fichero. No existe ninguna limitación en la longitud y queda oculto al usuario, por tanto, no se puede guardar en favoritos.

Proceso en el servidor

Procesar en el servidor te permite dar contenido dinámico al usuario. Contenido dinámico significa que puedes determinar cual es la información que quiere ver el usuario en función a las entradas que te ha indicado en los formularios.

La primera solución que había para poder generar código en el servidor era CGI (Common Gateway Interface), era ejecutar un programa externo que leía las peticiones y su cabecera y generaba una respuesta.

Después apareció lo que llamamos el ‘scripting’, código anidado en las páginas Html que el servidor era capaz de ejecutar antes de enviar la página de respuesta. Aquí es donde encuentras ASP. Tecnología anterior a ASP.NET.

 

 

Más cosas en la tercera parte de este post.

Gracias

Blend 2012 and weird error

Last week, using Blend 2012 in a Windows Phone 8 Project caused a weird error. An error hard to know why it is happening and which sentence is the guilty.

The error says:

“Unable to cast object of type ‘System.Reflection.CustomAttributeData’ to type ‘System.ComponentModel.TypeConverterAttribute’

If you search on the Internet about this error you can find some webs talking about Update 2 of Visual Studio 2012 in WP8 projects but in my case the problema came from another spot.

I was working with DataTrigger and ChangePropertyAction in Windows Phone 8 using Blend 2012. From properties tab I put the Binding, the Value to compare, the property to modify and finally the value to assign.

In this case the property was Source from Image Control and Blend 2012 write in XAML this piece of code as follows:

<ec:DataTrigger Binding=”{Binding Path=Level}” Value=”Level1″>
<ec:ChangePropertyAction PropertyName=”Source”>
<ec:ChangePropertyAction.Value>
<Source>/Assets/Levels/logoGraduacio1stars.png”</Source>
</ec:ChangePropertyAction.Value>
</ec:ChangePropertyAction>
</ec:DataTrigger>

The famous error is below this line:

<Source>/Assets/Levels/logoGraduacio1stars.png”</Source>

 

The correct piece of code has to be:

<ec:DataTrigger Binding=”{Binding Path=Level}” Value=”Level1″>
<ec:ChangePropertyAction PropertyName=”Source”>
<ec:ChangePropertyAction.Value>
<BitmapImage UriSource=”/Assets/Levels/logoGraduacio1stars.png”></BitmapImage>
</ec:ChangePropertyAction.Value>
</ec:ChangePropertyAction>
</ec:DataTrigger>

Enjoy programming.

 

internal member

En orientació objectes tenim la capacitat de marcar la visibilitat de les propietats, camps o mètodes.

Els més coneguts: public, protected i private

Potser no tant conegut és internal. Internal significa que un membre és només public dins del seu enssamblat. Fora d’ell és completament privat. És molt útil quan construïm llibreries de classes que son suport d’altres projectes i volem protegir propietats per tal de que no ens facin un mal ús fora del nostre projecte.

El problema, el podem tenir quan necessitem serialitzar una classe que té una propietat d’aquest tipus. L’error que ens pot sortir és semblant a aquest:

The data contract type ‘Secondary.Project.MVVM.ViewModel.ViewModelBase’ cannot be deserialized because the property ‘DisplayName’ does not have a public setter. Adding a public setter will fix this error. Alternatively, you can make it internal, and use the InternalsVisibleToAttribute attribute on your assembly in order to enable serialization of internal members – see documentation for more details. Be aware that doing so has certain security implications.

Tal com diu, l’internal port ser la causa de l’error i per resoldre’l ens demana de posar un atribut dins assembly.cs que ens permet marcar enssamblats de confiança per tal de que l’internal passi a ser una propietat publica per ell.

Personalment pensó que es una mica arriscart però pot ser útil quan no hi ha més possiblitats.

[assembly: InternalsVisibleTo("Main.Project")]

D’aquesta manera estic marcant que el projecte Main.Project és de confiança i per tant tindrà aquest membre com a public.

Pot ser interessant saber-ho, pot ser útil usar-lo.

Aspectos fundamentales de la programación ASP.NET (1era parte)

Por que es tan popular la Web?

La web es fácil de utilizar. Todos hemos utilizado un navegador para conectarnos a páginas web sin problemas y hemos interactuado con ellas. Al poco rato somos capaces de pedir al navegador que queremos ver más páginas, que podemos enviar datos o incluso subir ficheros. Después nos damos cuenta que la información que estábamos mirando en un ordenador de la biblioteca también es accesible des de casa con otro ordenador e incluso con otro navegador. La web hace posible que sus páginas puedan ser vistas por cualquier navegador que interprete el HTML.

El HTML es el lenguaje de la web, el lenguaje que interpretan los navegadores y que hace que puedas visualizar texto, imágenes, videos, enlaces y formularios.

Al principio se nos enseña que existen unos buscadores capaces de buscar las páginas que tienen información de lo que queremos, después nos damos cuenta de que las páginas están asociadas a una dirección web, una dirección URL. No se nos muestra que en realidad estamos accediendo a un ordenador que tiene una IP asociada, la verdad, los servidores DNS son los olvidados de la web, nadie se acuerda de ellos, nadie sabe de ellos, solo son protagonistas cuando cae uno y de forma misteriosa no podemos acceder a la web. Poca gente sabe que podríamos acceder también mediante su dirección IP.

Es cuando vemos por primera vez una URL que nos damos cuenta que tiene un prefijo igual para todas las URL’s; el HTTP, este protocolo de comunicación que ha dado muy buenos resultados precisamente por no querer hacer demasiadas cosas, es decir, el HTTP es una comunicación simple, sin estado. Sin estado significa que la web no tiene memoria, somos nosotros en cada clic que hacemos en las páginas que estamos refrescando la memoria a la web. Este aspecto que lo verás en el capítulo 11 de este libro es muy importante para entender muchas de las cosas que hace ASP.NET para nosotros.

Al principio la web era texto, después se añadieron las imágenes y ahora los videos. Como puedes ver se ha convertido en un protocolo potente de comunicación mundial donde no importa donde estás y que ordenador tienes, solo necesitas un navegador web y una buena conexión ADSL.

HyperText Transfer Protocol

Entender el protocolo es el primer paso para entender la tecnología web y a su vez las aplicaciones web.

El protocolo es:

• Simple: Tiene una petición y una respuesta
• Sin estado: Cada petición es independiente de las otras

Una forma de entender el protocolo es mediante la siguiente imagen donde vemos como un cliente realiza una petición al servidor. La petición es una Request y la clase que representa  una petición en .Net es la HttpRequest. La respuesta es una Response y la clase que representa una respuesta en .Net es la HttpResponse.

Como ya puedes ver la petición entre otras cosas indica cual es el recurso que quieres del servidor. En el caso del ejemplo es una petición a la página page.aspx que se encuentra en la carpeta folder.

La respuesta es siempre un código y el contenido de la petición. Los códigos de las respuestas siguen la tabla siguiente:

Status Code	Tipo	Descripción
1xx	Información	Petición recibida
2xx	Éxito	La acción se ha recibido   con éxito y aceptada
3xx	Redirección	Otra acción se debe   realizar para completar la petición
4xx	Error de cliente	La petición   contiene errores o no puede ser entendida
5xx	Error de servidor	El servidor ha   producido un error en la petición de cliente

Más cosas en la segunda parte de este post.

Gracias