Share
En la parte I de esta serie, vio cómo creamos una aplicación móvil simple en el marco de Corona que responde a una acción similar a "bump" (llamada "thump") para enviar un mensaje a otro dispositivo móvil. La comunicación entre los dos dispositivos móviles se produce entre un proceso de servidor intermediario que coincide con dos dispositivos "golpeados" por marca de tiempo y distancia. En este tutorial, configuraremos el proceso del servidor intermediario con Ruby on Rails.
Empecemos por crear nuestro proyecto. Ya que usaremos el complemento geokit para ayudarnos con nuestros cálculos geoespaciales, tenemos que crear este proyecto en Rails 2.3.5 ya que el complemento no es compatible con 3.0.
Después de iniciar sesión en su servidor / cuenta de alojamiento (en nuestro caso, estamos usando Heroku), escriba lo siguiente:
mkdir thump-server cd thump-server / rails. eliminar public / index.html
Las declaraciones anteriores crearán un directorio y comenzarán un nuevo proyecto de rieles dentro de él. Si tiene 3.0 instalado en su máquina de desarrollo, es posible que necesite instalar RVM y crear un conjunto de gemas separado para este proyecto. Sin embargo, hacer esto está fuera del alcance del tutorial. Ahora instalemos el plugin geokit.
script / plugin install git: //github.com/andre/geokit-rails.git
Una vez que esto se complete, debemos agregar nuestra gema al proyecto dentro de Rails :: Initializer.run do | config | bloque de nuestro archivo environment.rb:
config.gem "geokit"
Ahora que este complemento se ha agregado al proyecto, debemos ejecutar un comando rake para asegurarnos de que todas las gemas necesarias estén instaladas en nuestro sistema..
rastrillar gemas: instalar
Geokit se basa en la base de datos para realizar cálculos de distancia bastante sofisticados. Debido a esto, la base de datos SQLite predeterminada con la que viene un proyecto de rieles no funcionará. Geokit requiere que utilicemos un ds mysql o postgres para almacenar nuestros datos. A pesar de que heroku utiliza postgres de forma predeterminada, es más común que las máquinas de desarrollo tengan instalado mysql. La belleza de usar Rails y ActiveRecord es que no importa. Podemos desarrollar nuestra aplicación con MySQL y funcionará a la perfección con postgres.
mysql -u root crea el servidor de la base de datos;
Ahora actualizaremos nuestro archivo database.yml para que apunte a nuestra nueva base de datos de desarrollo "thumpserver".
desarrollo: adaptador: base de datos mysql: usuario de thumpserver: socket raíz: /tmp/mysql.sock pool: 5 timeout: 5000
Finalmente nuestro proceso de creación de proyectos está completo. Podemos comenzar a codificar la lógica dentro de nuestro thumpserver..
Rails tiene un método generador simple que crea un recurso basado en REST para CRUD de datos. Si la última frase no tuvo ningún sentido, le sugiero que busque en Google "recursos relajantes" para obtener más información. Esencialmente, con un solo comando podemos crear una tabla de base de datos, modelo, controlador y rutas dentro del proyecto.
./ script / generar recurso thump deviceid: cadena lat: decimal lng: mensaje decimal: cadena recibida: booleano
Nuestro recurso se llama thump, por lo tanto, al generarlo de esta manera, estará disponible en url / thump una vez que nuestro servidor esté funcionando. Especificamos 5 campos a crear para nuestra tabla de base de datos:
deviceid: el UID del dispositivo móvil
lat: latitud proporcionada por el servicio de localización
lng: longitud
mensaje: el mensaje que se transmitirá a los usuarios que han golpeado
recibido: este es un booleano para marcar una vez que se ha recibido un mensaje, por lo que no se puede volver a enviar
Rails creará "automágicamente" campos de marca de tiempo llamados created_at y updated_at. Usaremos created_at más adelante en nuestro ejemplo..
Cuando generamos nuestro recurso, se creó un archivo de migración de la base de datos de Rails en la carpeta "db" del proyecto. El nombre del archivo debe parecer algo como esto: TIMESTAMP_create_thumps.rb
Necesitamos modificar este archivo para garantizar que nuestra ubicación pueda almacenarse con suficientes decimales. Para hacer esto simplemente reemplaza estas dos líneas:
t.decimal: lat t.decimal: lng
Con las siguientes líneas:
t.decimal: lat,: precision => 8,: scale => 8 t.decimal: lng,: precision => 8,: scale => 8
Esto asegurará que nuestros campos de latitud y longitud puedan contener como máximo 8 decimales.
Además, para evitar que el campo "recibido" en nuestra base de datos sea NULO, debemos agregar una configuración para que su valor sea falso de manera predeterminada. Nuevamente podemos hacer esto reemplazando esta línea:
booleano: recibido
Con esta línea:
t.boolean: recibido,: predeterminado => falso
Ahora que nuestra migración está configurada, podemos ejecutar el comando rake que realmente creará la tabla dentro de la base de datos:
rastrillo db: migrar
Para tomar entradas para nuestros datos, usaremos la acción "crear" en nuestro controlador de golpe. Además de esto, necesitamos una acción de "búsqueda" que tome algunos parámetros y busque a través de la base de datos para que coincida con los dos dispositivos golpeados. Necesitamos modificar nuestras rutas.rb en el directorio de configuración para responder a la URL / thump / search en una solicitud GET. Podemos hacer esto reemplazando esta línea:
map.resources: golpes
Con esta linea
map.resources: thumps,: collection => : search =>: get
A continuación, agreguemos las siguientes líneas a nuestro archivo thump.rb dentro de app / models.
act_as_mappable validates_presence_of: lat,: lng,: deviceid
La primera línea hace que nuestro modelo sea "mapable". Esto nos da algunos métodos de consulta adicionales para ayudar a calcular la distancia entre dos conjuntos de coordenadas. La siguiente línea agrega algunas validaciones simples a nuestro modelo de datos de thump para asegurarnos de que cuando recibamos un mensaje de thump contenga los campos adecuados..
Finalmente, podemos crear nuestras acciones para crear y buscar datos en nuestro controlador. Gracias a la belleza y simplicidad de ActiveRecord, nuestra acción "crear" es bastante simple:
def cree Thump.create! (params [: thump]) render (: json => : success => true) rescue render (: json => : success => false) end
En el caso de que nuestras validaciones fallen, devolveremos un objeto json con: success => false. En la parte III del tutorial ampliaremos nuestra aplicación móvil para tener en cuenta esto..
Nuestra búsqueda "acción" es un poco más compleja, ya que utiliza algunos de los asistentes de consulta de geokit:
def search thump = Thump.find (: first,: origin => [params [: thump] [: lat], params [: thump] [: lng]],: conditions => ["deviceid! =? AND recibido = ? ", params [: thump] [: deviceid], false],: order => 'distance asc, created_at desc') aumentar a menos que (thump) thump.update_attribute (: recibido, true) render (: json => : success => true,: message => thump.message) rescue render (: json => : success => false) end
Vamos a desglosar esto:
thump = Thump.find (: first,: origin => [params [: thump] [: lat], params [: thump] [: lng]],: conditions => ["deviceid! =? AND recibida =?" , params [: thump] [: deviceid], false],: order => 'distance asc, created_at desc')
Esencialmente estamos consultando nuestra coincidencia "thump" en la base de datos. Un dispositivo enviará a lo largo de su propia latitud y longitud, que será nuestro punto de origen. Nuestras condiciones garantizan que no encontremos accidentalmente nuestro propio dispositivo al excluir nuestro deviceid propio del conjunto de resultados. También solo queremos buscar golpes donde el campo "recibido" es falso. Para encontrar la coincidencia más cercana tanto en la distancia como en el tiempo, ordenaremos nuestros resultados por distancia entre los 2 puntos en orden ascendente (es decir, la más cercana) y el tiempo creado o creado en orden descendente para encontrar la más reciente. Obviamente, es un evento improbable que exista algún "golpe" conflictivo para nuestra aplicación de prueba, pero este tipo de consulta podría sostener una aplicación multiusuario si quisiéramos.
aumentar a menos que (thump) thump.update_attribute (: recibido, verdadero) render (: json => : success => true,: message => thump.message)
El comando raise hará que nuestra progresión de código entre en el bloque de rescate que devolverá: success => false si no podemos encontrar un golpe que coincida. Esto asegurará que nuestra aplicación móvil recibirá al menos algo en caso de error. Si el objeto existe, estableceremos el campo "recibido" en verdadero para garantizar que este mensaje no coincidirá en una solicitud de datos posterior. Nuestra declaración de renderización devolverá un objeto JSON que el dispositivo que recibe el "golpe" interpretará.
Para probar esto, podemos ejecutar un comando en la consola de Rails para crear un registro de muestra con un punto de origen de la ciudad de Nueva York:
Thump.create (: deviceid => "B",: lat => 40.7141667,: lng => - 74.0063889,: message => "B")
Para obtener una coincidencia de "golpe", o una devolución exitosa, primero podemos iniciar nuestro servidor en el puerto predeterminado 3000:
./ script / server
Y luego pulse la siguiente URL:
http: // localhost: 3000 / thumps / search? thump [deviceid] = A & thump [lat] = 40.7141667 & thump [lng] = -74.0063889
Si todo va bien, el navegador debería mostrar lo siguiente:
"mensaje": "B", "éxito": verdadero
Esto simula un dispositivo llamado "A" que recibe un mensaje de "golpe" desde el dispositivo B. Y ahí lo tenemos!
Estuve atento a la parte III de esta serie, donde enviaremos la aplicación del servidor a Heroku y actualizaremos nuestra aplicación móvil para comunicarnos con el servidor..
Accentsconagua