“Resisten la bomba atómica, pero no sobreviven a un simple zapato!”
Esta frase la escuché el otro día en la calle y la mujer hablaba de las cucarachas. Me quedó dando vueltas y hoy le encontré el real sentido.
El escenario es una aplicación (no pensaban que iba a hablar de cucarachas, la lección es sobre bugs) con años de desarrollo, varias versiones en producción y una funcionalidad que el folklore de users+team la había declarado como TO DO.
Sin embargo la funcionalidad existía en el código y lo único que ocurría era que ciertos bugs (a partir de ahora los puedo llamar cucarachas) nunca se habían corregido. En relación, el desarrollo original de la funcionalidad había sido como resistir a la bomba atómica, y por culpa de un simple zapato el valor nunca llegó al cliente.
Cada cual que genere su propia moraleja.
Al parecer un gran mercado se está moviendo en éste sentido. Y a pesar de todas las posibilidades que brindan los dispositivos actualmente para acceder a internet, que tal si queremos realizar una aplicación para los dispositivos?
Voy a fijarme un poco en lo que son los principales SO para dispositivos móviles (por favor, favoritismos aparte, pude olvidarme de algunos, por ejemplo Symbian o Blackberry, sólo quiero hacer una enumeración general).
Windows mobile
Windows mobile es una plataforma conocida (al menos para mi), casi cualquier programador .Net (a mi juego me han llamado) a jugado alguna vez con el .Net Compact Framework. El desarrollo desde el Visual Studio es muy sencillo, en la parte 2 del post voy a incluir un ejemplo sencillo.
Android
El SO Android, un proyecto de la Open Handset Alliance, es un desarrollo Open Source de Google. Aunque actualmente sólo existe un teléfono, HTC G1, es probable que el 2009 veamos una explosión (a al menos varios modelos).
Para desarrollar una simple aplicación (el ejemplo provisto con el SDK de Android es HelloAndroid) me tuve que meter en un mundo poco conocido por mí, y debo decir que quedé gratamente sorprendido.
Bajé el Eclipse, el SDK de Android, instalé el Eclipse, que anduvo sin problemas desde el primer momento, instalé el plugin para el desarrollo de Android en el Eclipse. Y voilá, ya estamos funcionando. Debo decir que además de que en 15 minutos estaba funcionando no tuve que regsitrarme en ningún sitio!
En el segundo post de la serie voy a mostrar el ejemplo desarrollado, pero mientras tanto les dejo una imagen del emulador con mi aplicación (HelloAndroid) funcionando.
Apple IPhone
El desarrollo para el IPhone, es otro tema. Para este caso tenemos que registrarnos, debemos utilizar las herramientas provistas por Apple (esto es similar en todos los casos), utilizar ObjetiveC como lenguaje (a leer!) y si queremos participar del mundo de las aplicaciones para IPhone (aunque no querramos lucrar) tenemos que participar del IPhone Developer Program que tiene costo.
Tal vez pueda hacer algo en éste terreno también.
Primera conclusión
Hay un mercado muy interesante para aplicaciones para dispositivos móviles, y además resulta muy interesante ver como la interacción con otras cosa que nos resultaban inimaginables en el desarrollo para desktop o para web, como por ejemplo la interacción con GPS, acelerómetros, voz, cámáras, etc. generan un montón de posibilidades para los que nos gusta jugar!. Como ejemplo se pueden ver miles de aplicaciones locas e interesantes para el IPhone en el repositorio de ITunes o los resultados del Android Development Challenge de Google.
Se está charlando mucho de (la asunción de Obama, la guerra en Medio Oriente, la crisis de la economía?) no, del artículo “2009 CWE/SANS Top 25 Most Dangerous Programming Errors”, como su nombre lo indica intenta sumarizar los 25 errores más peligrosos a la hora de programar. Hay una síntesis muy interesante en éste post realizada por Jeff Atwood en su muy buen blog Coding Horror.
Lo que me interesa es, dado que estoy viendo las distintas tecnologías de presentación, como se puede implementar en WPF el primero de los puntos. Improper Input Validation.
Existe en WPF una clase base abstracta llamada ValidationRule. Verifiquemos si el título del post tiene sentido. ValidationRule, Rules?
Un ejemplo de implementación de los miembros de la clase (MandatoryValidationRule es una clase que verifica que el valor no sea nulo o un string vacío)
public class MandatoryValidationRule : ValidationRule
{
public override ValidationResult
Validate(object value, System.Globalization.CultureInfo cultureInfo)
{
return
String.IsNullOrEmpty((string)value) ?
new ValidationResult(false, "Value is Mandatory") : new ValidationResult(true, null);
}
}
Un ejemplo de uso de la clase en el XAML (simlpemente bindeamos (neologismo ampliamente aceptado) la ValidationRule)
<TextBox Name="textBox1"Width="50"FontSize="15"
Validation.ErrorTemplate="{StaticResource validationTemplate}"
Style="{StaticResource textBoxInError}"
Grid.Row="1"Grid.Column="1"Margin="2">
<TextBox.Text>
<Binding Path="Name"
UpdateSourceTrigger="PropertyChanged" >
<Binding.ValidationRules>
<c:MandatoryValidationRule/>
</Binding.ValidationRules>
</Binding>
</TextBox.Text>
</TextBox>
Por lo visto no es tan complejo y al estar utilizado directamente en el lenguaje declarativo podemos tener muchas posibilidades de manejo de estilos, recusos, templates, etc.
No se si concluir que es una buena forma o no de validar, sin embargo podemos ver un buen post de Josh Smith que nos puede dar un poco más de elementos para juzgar.
Esto se puede ver en miles de blogs. 
Que novedad! Lo único diferente en éste caso es que lo estoy haciendo en el micro (a lo platense) volviendo del trabajo hacia La Plata. (Commute?)
Al parecer un viaje Buenos Aires-Villa Elisa alcanza.
Update: alcanza el tiempo, pero no la batería.
Entradas
