SMS INFRAESTRUCTURA como su nombre indica, crea una infraestructura para env\u00edo de mensajes de texto SMS , est\u00e1 pensando para construirla de manera econ\u00f3mica con terminales Android razonablemente baratas, mientras m\u00e1s terminales de Android tenga en su pool m\u00e1s r\u00e1pido podr\u00e1n despacharse cientos o miles de mensajes. El uso m\u00e1s com\u00fan para este tipo de aplicaciones es env\u00edo de mensajes de falla de servidores. En programaci\u00f3n puede ser usado en el c\u00f3digo try catch para excepciones importantes como falla en la conexi\u00f3n de una base de datos, lectura de disco, error de red, ETC. En grupos sociales se puede usar como env\u00edo masivo de mensajes SMS por ejemplo el gobierno avisando de una alerta climatol\u00f3gica a sus ciudadanos. <\/p>\n
SMS INFRAESTRUCUTURA<\/a> ( Ver articulo<\/a> )<\/p>\n En el 2012 hab\u00eda escrito un App llamada SMS INFRAESTRUCTURA, no quede muy satisfecho ya que esta versi\u00f3n pronto dejo claro que amarra al programador a usar exclusivamente la base de datos MySQL, el APK del app al incluir drivers de conexi\u00f3n para la base de datos se vuelve a\u00fan m\u00e1s pesado por lo que quiere m\u00e1s CPU del celular, m\u00e1s RAM para ejecutarse y m\u00e1s espacio para almacenar el APK. Sin contar que la conexi\u00f3n a la DB no va cifrada.<\/p>\n SMS INFRAESTRUCTURA 2<\/strong><\/p>\n Para solventar este problema la versi\u00f3n 2 hace uso de webservice SOAP, Esto consigui\u00f3 liberar el uso exclusivo de MySQL como DB pero involucra que cada lenguaje en el que se quiera trabajar deber\u00e1 escribir el webservice apropiado lo cual se complica un poco si se trata de SOAP. Por esta raz\u00f3n nunca se public\u00f3 esta versi\u00f3n en la Google Play Store<\/p>\n SMS INFRAESTRUCTURA 3<\/strong><\/p>\n Para solventar los problemas que involucran los webservice con SOAP escrib\u00ed la nueva app para usar un sencillo API REST WebService que b\u00e1sicamente es recibir un bloque en JSON con GET y lo obtiene consultando una \u00fanica URL, este tipo de webservice es f\u00e1cilmente soportado por cualquier lenguaje de programaci\u00f3n. En algunos lenguajes como PHP construir el bloque JSON es cosa de 2 l\u00edneas de c\u00f3digo, las dem\u00e1s l\u00edneas de c\u00f3digo son para la consulta en la DB que podr\u00eda ser cualquiera soportado por PHP,Python,Ruby,ETC en el caso de escribir el webservice con C# o Java este podr\u00eda consultar DB como Oracle o SQL Server o incluso NoSQL sin mayor problema pues al final lo que vale para esta versi\u00f3n es el JSON <\/p>\n JSON para controlar el APP<\/strong><\/p>\n En cada consulta que hace el APP al url espera recibir un JSON y es con este que sabe si debe enviar un SMS o no hacer nada cuando no hay SMS que enviar.<\/p>\n Bloque JSON para no hacer nada.<\/strong><\/p>\n Cuando \u201cnum\u201d vale NO y debe ser NO<\/strong> con may\u00fasculas, el APP descarta este bloque, aunque PAYLOAD tenga un valor de texto para enviar no hay n\u00famero a donde enviarlo, la aplicaci\u00f3n se mantiene quieta hasta la pr\u00f3xima consulta GET para obtener un nuevo bloque JSON. Como la aplicaci\u00f3n tiene que estar consultando por nuevos mensajes para enviar se debe controlar con num valor NO cuando no tenga mensajes nuevos o en cola por enviar.<\/p>\n Bloque JSON para enviar un mensaje a un numero de celular<\/strong><\/p>\n Ejemplo en c\u00f3digo PHP para construir el bloque JSON<\/strong><\/p>\n \/\/ Codigo para darle valor a num y payload<\/p>\n header('Content-Type', 'application\/json'); $resultado = array('num' => \"NO\", 'payload' => \"MENSAJE\"); ?>{\"num\":\"NO\",\"payload\":\"MENSAJE\"}<\/code><\/p>\n{\"num\":\"5544332211\",\"payload\":\"AQUI VA EL MENSAJE DE TEXTO\"}<\/code><\/p>\n<?php<\/p>\n
\nheader('Content-Type: text\/html; charset=UTF-8');<\/p>\n
\necho (json_encode($resultado));<\/p>\n
<\/code><\/p>\n