Share
In questo tutorial, introdurremo una serie che consentirà a due dispositivi mobili di trasferire informazioni con un gesto "Bump". Questa applicazione richiederà una combinazione di programmazione lato client e lato server e tratteremo tutti i passaggi per codificare entrambi gli aspetti. Da qui in poi, questa app verrà chiamata affettuosamente "Thump".
La funzione principale della nostra app "Thump" sarà la comunicazione cross-device dei dati attraverso un server web intermedio. L'atto di battere insieme due dispositivi mobili apparirà all'utente finale come dispositivo locale alla comunicazione del dispositivo, quando in realtà il server Web ha elaborato lo scambio di dati. Mentre l'idea della comunicazione periferica locale può sembrare l'approccio più pratico all'inizio, in pratica è pieno di rotture cross-platform e incubi di sicurezza! Quindi, utilizzeremo un'app Rails ospitata sulla piattaforma Heroku per gestire i messaggi ricevuti dai nostri dispositivi e consegnare il messaggio al destinatario previsto.
Il modo in cui funziona è piuttosto interessante. Il server effettuerà essenzialmente una stima di chi il destinatario più probabile di un messaggio sarà basato su una combinazione di coordinate GPS e un timestamp del server. Con simultaneamente (o quasi simultaneamente) i nostri due dispositivi insieme, invieremo le informazioni di latitudine e longitudine al server in modo che possa determinare che i nostri due dispositivi simili localmente stessero cercando di comunicare tra loro in qualcosa di quasi in tempo reale. Semplice, giusto?
Sebbene questo metodo non sia esattamente perfetto, fornisce una probabilità statistica che i nostri due dispositivi intendano comunicare tra loro. Uno dei grossi problemi con un servizio come questo (e la nostra app non fa eccezione) sarebbe un evento come una fiera o un posto dove molte persone potrebbero provare a "battere" tutte allo stesso tempo. Sebbene possa essere improbabile, potrebbe potenzialmente consentire la trasmissione di un messaggio a un destinatario involontario.
Inizieremo creando alcune funzionalità di base per la nostra app mobile. Nel nostro file main.lua, aggiungeremo alcune linee essenziali di codice per iniziare.
Accentsconagua
local ui = require ('ui') system.setLocationAccuracy (10) local isSimulator = "simulator" == system.getInfo ("environment") local deviceId = system.getInfo ("deviceID") La prima riga richiede che includiamo la libreria dell'interfaccia utente che assiste notevolmente la creazione di componenti nativi in Corona. Questo codice sarà incluso in un file zip del codice sorgente allegato a questo tutorial Mobiletuts +. Successivamente, imposteremo una soglia di accuratezza della posizione per i nostri dispositivi. Abbiamo bisogno che il dispositivo faccia del suo meglio per ottenere una posizione entro una tolleranza di errore di non più di 10 metri. Se la distanza è maggiore, corriamo il rischio di raccogliere colpi accidentali da dispositivi che non si trovano nelle nostre vicinanze. Per semplificare le cose durante lo sviluppo, rileveremo se la nostra app è in esecuzione nel simulatore Corona o sul dispositivo. Ciò consentirà principalmente di prevenire comportamenti strani da funzionalità non attualmente supportate dal simulatore. Infine, dobbiamo identificare un dispositivo con un valore unico. Un deviceID come questo impedirà al server di cercare di restituire un messaggio al dispositivo che lo ha inviato al posto del destinatario previsto.
local bg = display.newRect (0, 0, display.contentWidth, display.contentHeight) logo locale = display.newImageRect ("logo.png", 172, 107) logo.x = display.contentWidth / 2 logo.y = ( display.contentHeight / 2) - 150 Successivamente, creiamo un rettangolo di sfondo che dona alla nostra app uno sfondo bianco e gradevole. Le 3 linee successive mostreranno un logo nella parte in alto al centro dello schermo.
local titleLabel = ui.newLabel bounds = 15, 5, 290, 55, text = "Message", font = native.systemFontBold, textColor = 12, 12, 100, 255, size = 24, align = " center " titleLabel: setReferencePoint (display.TopCenterReferencePoint) titleLabel.y = logo.y + 60
Il codice sopra riportato utilizza l'accesso della libreria UI ai componenti di visualizzazione nativi per il dispositivo. In questo caso, stiamo semplicemente visualizzando la parola "Messaggio" in una tonalità blu scuro. Lo scopo di questo articolo non include tutte le complessità della libreria di visualizzazione nativa, quindi ti suggerisco di dare un'occhiata al sito Corona se sei nuovo nell'SDK. Le coordinate Y sono impostate su 60 pixel più grandi della posizione del logo che abbiamo appena mostrato.
if isSimulator then - Simulator (simula l'area textField) textField = display.newRect (20, titleLabel.y + 60, 280, 30) textField: setFillColor (200, 200, 200) altro campo funzione localeHandler (evento) if (" inviato "== event.phase) then native.setKeyboardFocus (nil) end end textField = native.newTextField (20, titleLabel.y + 60, 280, 30, fieldHandler) end textField: setReferencePoint (display.TopCenterReferencePoint) textField.x = display.contentWidth / 2 textField.y = titleLabel.y + 60 Uno dei limiti del simulatore è che non può visualizzare correttamente tutti i componenti nativi dei dispositivi mobili. Per evitare di generare errori, rileveremo se stiamo eseguendo l'app nel simulatore e visualizziamo una casella grigia invece di un campo di input. Questo ci aiuterà con il nostro posizionamento degli elementi. Se l'app non è in esecuzione nel simulatore, verrà visualizzato un componente "textField" nativo che consentirà all'utente finale di digitare un messaggio. Il callback fieldHandler è necessario per rilevare una fase di "submit", o, in altre parole, l'utente che preme il pulsante "return". Catturando questo evento possiamo nascondere la tastiera dopo che l'utente ha finito di digitare il suo messaggio.
local removeKeyboard = function (event) - Nascondi tastiera native.setKeyboardFocus (nil) end bg: addEventListener ("tap", removeKeyboard) Come bonus aggiuntivo per l'interfaccia utente, possiamo aggiungere un listener di eventi al nostro sfondo bianco che aspetta un evento "tap". In questo modo, se l'utente tocca lo schermo al di fuori dell'area della tastiera, rimuoverà la messa a fuoco da esso e causerà la sua scomparsa.
local latitudeText = "" local longitudeText = "" se isSimulator then alert locale = native.showAlert ("Errore", "GPS non disponibile in Simulator") else local locationHandler = function (evento) latitudeText = string.format ('% .8f ', event.latitude) longitudeText = string.format ('% .8f ', event.longitude) end Runtime: addEventListener ("location", locationHandler) end E ora le buone notizie! Per prima cosa, rileveremo se stiamo eseguendo il simulatore e semplicemente mostreremo un messaggio di errore che il GPS non è disponibile. Quando siamo in esecuzione sul dispositivo, creiamo un listener di runtime che acquisisce continuamente la nostra posizione dal servizio di localizzazione del dispositivo e chiama il nostro metodo locationHandler con questi dati. Lo convertiamo in basso con 8 posizioni decimali di accuratezza che dovrebbero essere più che accurate per i nostri scopi.
locale getThump = function (event) if event.isShake == true then alert locale = native.showAlert ("Thump!", "Location:"? latitudeText? ","? longitudeText? "\ r \ nMessage:"? textField. text, "OK") system.vibrate () end-end Runtime: addEventListener ("accelerometro", getThump) Infine, creeremo un altro listener di eventi di runtime che preleva i dati dall'accelerometro del dispositivo e li passa al nostro metodo getThump. All'interno di questo metodo, rileveremo se l'evento è stato un evento di "scossa". Un evento shake è un altro nome per ciò che accadrà quando "battermo" due dispositivi insieme nella speranza di trasmettere un messaggio. Poiché non abbiamo ancora scritto il nostro componente server, mostreremo semplicemente questi dati in una finestra di avviso per mostrare che la nostra app funziona fino a questo momento. Per verificarlo, puoi semplicemente digitare un messaggio e dare una scossa al dispositivo su cui è in esecuzione l'app.
Restate sintonizzati per la seconda parte di questa serie la prossima settimana, in cui affronteremo la funzionalità lato server in Rails su Heroku!
