Share
Dans ce didacticiel, nous allons lancer une série qui permettra à deux appareils mobiles de transférer des informations avec un geste "Bump". Cette application nécessitera une combinaison de programmation côté client et côté serveur, et nous couvrirons toutes les étapes pour coder les deux aspects. A partir de là, cette application sera affectueusement appelée "Thump".
La fonction principale de notre application "Thump" sera la communication inter-appareils de données via un serveur Web intermédiaire. Le fait de cogner deux appareils mobiles ensemble apparaîtra à l'utilisateur final comme une communication de périphérique à périphérique, alors qu'en fait le serveur Web a traité l'échange de données. Bien que l’idée de la communication avec un périphérique local puisse sembler être l’approche la plus pratique au début, elle est en pratique pleine de blocages inter-plateformes et de cauchemars de sécurité! Nous allons donc utiliser une application Rails hébergée sur la plate-forme Heroku pour gérer la réception des messages de nos appareils et la remise du message à son destinataire..
La façon dont cela fonctionne est assez intéressante. Le serveur déterminera essentiellement le destinataire du message le plus probable en fonction d'une combinaison de coordonnées GPS et d'un horodatage du serveur. En frappant simultanément (ou presque simultanément) nos deux périphériques, nous enverrons des informations de latitude et de longitude au serveur afin qu'il puisse déterminer que nos deux périphériques de même emplacement tentaient de communiquer l'un avec l'autre en temps quasi réel. Simple, droit?
Bien que cette méthode ne soit pas tout à fait parfaite, elle fournit une probabilité statistique que nos deux appareils aient l'intention de communiquer l'un avec l'autre. L'un des gros problèmes avec un service comme celui-ci (et notre application ne fait pas exception à la règle) serait un événement comme un salon professionnel ou un endroit où de nombreuses personnes pourraient essayer de "frapper" en même temps. Bien que cela puisse sembler peu probable, cela pourrait éventuellement permettre la transmission d’un message à un destinataire non souhaité..
Nous allons commencer par créer des fonctionnalités de base pour notre application mobile. Dans notre fichier main.lua, nous ajouterons quelques lignes de code essentielles pour bien démarrer..
Accentsconagua
local ui = require ('ui') system.setLocationAccuracy (10) local isSimulator = "simulator" == system.getInfo ("environment") local deviceId = system.getInfo ("deviceID") La première ligne nécessite l’inclusion de la bibliothèque d’interface utilisateur, qui facilite grandement la création de composants natifs dans Corona. Ce code sera inclus dans un fichier zip de code source joint à ce didacticiel Mobiletuts +. Ensuite, nous définirons un seuil de précision de localisation pour nos appareils. Nous avons besoin que l'appareil fasse de son mieux pour nous localiser dans une tolérance d'erreur maximale de 10 mètres. Si la distance est plus grande que cela, nous risquons de capter des coups accidentels provenant d'appareils qui ne se trouvent pas à proximité. Pour faciliter les choses pendant le développement, nous déterminerons si notre application est exécutée dans le simulateur Corona ou sur l'appareil. Cela visera principalement à empêcher tout comportement étrange de fonctionnalités non prises en charge par le simulateur. Enfin, nous devons identifier un appareil avec une valeur unique. Un ID de périphérique comme celui-ci empêchera le serveur d'essayer de renvoyer un message au périphérique qui l'a envoyé à la place du destinataire souhaité..
local bg = display.newRect (0, 0, display.contentWidth, display.contentHeight) logo local = display.newImageRect ("logo.png", 172, 107) logo.x = display.contentWidth / 2 logo.y = ( display.contentHeight / 2) - 150 Ensuite, nous créons un rectangle d’arrière-plan qui donne à notre application un joli fond blanc. Les 3 lignes suivantes afficheront un logo dans la partie centrale supérieure de l'écran.
titleLabel local = ui.newLabel bounds = 15, 5, 290, 55, text = "Message", font = native.systemFontBold, textColor = 12, 12, 100, 255, taille = 24, aligner " center " titleLabel: setReferencePoint (display.TopCenterReferencePoint) titleLabel.y = logo.y + 60
Le code ci-dessus utilise l'accès de la bibliothèque de l'interface utilisateur aux composants d'affichage natifs du périphérique. Dans ce cas, nous affichons simplement le mot "Message" dans une teinte bleu foncé. La portée de cet article n'inclut pas toutes les subtilités de la bibliothèque d'affichage native. Je vous suggère donc de jeter un coup d'œil sur le site Corona si vous êtes nouveau dans le SDK. Les coordonnées Y sont définies à 60 pixels au-dessus de la position du logo que nous venons d'afficher..
if isSimulator then - Simulator (simule la zone textField) textField = display.newRect (20, titleLabel.y + 60, 280, 30) textField: setFillColor (200, 200, 200) sinon fonction locale fieldHandler (event) if (" "== event.phase)", puis 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 L'une des limites du simulateur est qu'il ne peut pas afficher correctement tous les composants natifs des périphériques mobiles. Pour l'empêcher de générer des erreurs, nous allons détecter si nous exécutons l'application dans le simulateur et afficher une case grise au lieu d'un champ de saisie. Cela nous aidera avec notre positionnement des éléments. Si l'application ne s'exécute pas dans le simulateur, nous allons afficher un composant natif "textField" qui permettra à l'utilisateur final de saisir un message. Le rappel fieldHandler est nécessaire pour détecter une phase de "soumission" ou, en d'autres termes, l'utilisateur qui appuie sur le bouton "retour". En interceptant cet événement, nous pouvons masquer le clavier une fois que l'utilisateur a fini de taper son message..
local removeKeyboard = function (event) - Masque le clavier native.setKeyboardFocus (nil) fin bg: addEventListener ("tap", removeKeyboard) En tant que bonus d'interface utilisateur supplémentaire, nous pouvons ajouter un écouteur d'événement à notre fond blanc qui attend un événement "tap". De cette façon, si l'utilisateur appuie sur l'écran en dehors de la zone du clavier, le focus disparaîtra et sera supprimé..
local latitudeText = "" local longitudeText = "" si isSimulator alors local alert = native.showAlert ("Erreur", "GPS non disponible dans le simulateur") sinon local locationHandler = fonction (événement) latitudeText = string.format ('% .8f ', event.latitude) longitudeText = string.format ('% .8f ', event.longitude) end Durée d'exécution: addEventListener ("location", locationHandler) end Passons maintenant aux bonnes choses! Premièrement, nous allons détecter si nous courons dans le simulateur et simplement afficher un message d'erreur indiquant que le GPS n'est pas disponible. Lorsque nous exécutons sur le périphérique, nous créons un écouteur d'exécution qui saisit en permanence notre position à partir du service de localisation du périphérique et appelle notre méthode locationHandler avec ces données. Nous convertissons cette précision en 8 décimales, ce qui devrait être plus que précis pour nos besoins..
getThump local = fonction (événement) si event.isShake == true, puis alerte locale = native.showAlert ("Thump!", "Emplacement:"? latitudeText? ","? longitudeText? "\ \\ Message:"? textField. text, "OK") system.vibrate () end end Runtime: addEventListener ("accelerometer", getThump) Enfin, nous allons créer un autre écouteur d'événements d'exécution qui prend des données de l'accéléromètre du périphérique et les transmet à notre méthode getThump. À l’intérieur de cette méthode, nous déterminerons s’il s’agissait d’un événement «secoué». Un événement shake est un autre nom pour ce qui va se passer lorsque nous "assommons" deux appareils ensemble dans l’espoir de transmettre un message. Comme nous n'avons pas encore écrit notre composant serveur, nous afficherons simplement ces données dans une boîte d'alerte pour indiquer que notre application fonctionne jusqu'à présent. Pour tester cela, vous pouvez simplement taper un message et secouer l'appareil qui exécute l'application.
Restez à l'écoute pour la deuxième partie de cette série la semaine prochaine, où nous aborderons la fonctionnalité côté serveur de Rails sur Heroku.!
