Estoy seguro que en más de una ocasión han visto algo así:
Los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar.
Tecnología, innovación y responsabilidad social
Estoy seguro que en más de una ocasión han visto algo así:
Los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar.
Para todas estas situaciones es importante tener en claro el Principio de Sustitución de Liskov, el cual sostiene lo siguiente:
Los subtipos deben ser sustituibles por sus tipos base.
Acá definimos un Factory para leer/escribir valores o cadenas JSON para las estructuras de datos.
Luego, “instalamos” el módulo ionic.utils que acabamos de crear hace un instante.
Agregamos las referencias necesarias a la raíz de nuestro SPA.
¡Y listo! No olvidemos que la persistencia de la información dependerá de las limitaciones de espacio en disco y el SO.
Esta simple implementación es útil, sin embargo hay otras alternativas en GitHub e inclusive en Ionic 2 que también nos pueden ayudar en este asunto.
Más adelante espero tener la oportunidad de compartir hacerca de SQLite en un proyecto Ionic, pero antes tendré que hablar un poco sobre ngCordova.
En esta ocasión quiero compartir como hago para poder usar las fuentes Segoe MDL2 en un proyecto Xamarin.Android.
Agregamos la fuente y establecemos su Build Action como AndroidAsset.
Hecho esto, ya puedes continuar presionando F5 y ser feliz.
Hace poco tuve que aprender a progamar para subir vídeos en Windows Phone. Al parecer habían un par de formas de hacerlo, así que a continuación compartiré la que me funcionó y la que creo que fue la mejor alternativa. Se aceptan sugerencias :)!
Para mi caso en especial todo gira alrededor de la siguiente clase:
En el proyecto Windows Phone, empezamos actualizando el WMAppManifest.xml para poder usar la cámara y el micrófono.
Luego de ello ya podemos definir nuestra pantalla como mejor creamos.
En mi caso quedo así:
Luego de definir la pantalla, viene el .cs en el cual hay que lidear con el estado de la cámara, no vayamos a usar recursos que ya estan en uso y con la orientación de nuestra aplicación. Para mi fue todo un lío llegar a terminar esta parte, es más, actualmente tiene un bug. Una estrella para quien lo encuentra.
En fin, luego de haber capturado correctamente la información y dando aceptar, nos ayudamos de una variable estática en el App.xaml.cs llamada PendingVideo y navegamos hacia atrás. Ya del otro lado, la usamos y limpiamos referencias innecesarias.
Es importante conocer el estado de conexión de nuestra aplicación para no hacer consultas que pueden resultar en fallas, así como para tener la oportunidad de mostrar al usuario el mensaje adecuado para que no crea que hay una falla en la aplicación cuando el verdadero problema es uno de conectividad.
En caso de Xamarin.Android, lo primero que debemos hacer es agregar los permisos adecuados al AndroidManifest.xml.
Seguido de ello podemos hacer lo siguiente para validar si tenemos algun tipo de conexión:
O lo siguiente para saber si tenemos conexión con algún host en específico.
Si son instrucciones recurrentes en nuestra aplicación, deberíamos encapsularlas y ponerlas en una clase llamada ConnectivityService.cs por ejemplo.
Para mayor info acerca de ConnectivityManager, véase la documentación oficial: https://developer.xamarin.com/api/type/Android.Net.ConnectivityManager/
Los gists usados para este post puedes ubicarlos aquí: https://gist.github.com/MAlexanderSalazar/62bdf1ac153078817b26