Share
In deze zelfstudie introduceren we een serie waarmee twee mobiele apparaten informatie kunnen overdragen met een 'bump'-gebaar. Deze app vereist een combinatie van client-side en server-side programmering, en we zullen alle stappen bespreken om beide aspecten te coderen. Vanaf nu wordt deze app liefkozend 'Thump' genoemd.
De belangrijkste functie van onze "Thump" -app is de gegevensoverdracht via verschillende apparaten via een intermediaire webserver. De handeling waarbij twee mobiele apparaten samen worden gebombardeerd, zal voor de eindgebruiker verschijnen als lokale communicatie tussen apparaat en apparaat, terwijl de webserver de gegevensuitwisseling feitelijk heeft verwerkt. Hoewel het idee van lokale apparaatcommunicatie in eerste instantie de meest praktische benadering lijkt, is het in de praktijk gevuld met platformoverschrijdende problemen en nachtmerries over beveiliging! In plaats daarvan gebruiken we een Rails-app die wordt gehost op het Heroku-platform om berichten van onze apparaten te ontvangen en het bericht af te leveren aan de beoogde ontvanger.
De manier waarop dit werkt is best interessant. De server maakt in essentie een schatting van wie de meest waarschijnlijke ontvanger van een bericht zal zijn op basis van een combinatie van GPS-coördinaten en een servertijdstempel. Door tegelijkertijd (of bijna tegelijkertijd) onze twee apparaten samen te slaan, sturen we informatie over de breedte- en lengtegraad naar de server, zodat deze kan vaststellen dat onze twee lokaal vergelijkbare apparaten met elkaar probeerden te communiceren in iets bijna in de buurt. Eenvoudig, toch?
Hoewel deze methode niet precies perfect is, biedt deze wel een statistische waarschijnlijkheid dat onze twee apparaten bedoeld waren om met elkaar te communiceren. Een van de grote problemen met een dergelijke service (en onze app is geen uitzondering) zou een evenement zijn zoals een beurs of ergens waar veel mensen tegelijkertijd allemaal proberen te 'bonzen'. Hoewel het onwaarschijnlijk is, kan het mogelijk de overdracht van een bericht aan een onbedoelde ontvanger mogelijk maken.
We beginnen met het maken van enkele basisfunctionaliteit voor onze mobiele app. In ons main.lua-bestand zullen we enkele essentiële coderegels toevoegen om ons op weg te helpen.
Accentsconagua
local ui = require ('ui') system.setLocationAccuracy (10) local isSimulator = "simulator" == system.getInfo ("environment") local deviceId = system.getInfo ("deviceID") De eerste regel vereist dat we de UI-bibliotheek opnemen die de creatie van native componenten in Corona enorm ondersteunt. Deze code wordt opgenomen in een broncode-zipbestand dat is gekoppeld aan deze Mobiletuts + tutorial. Vervolgens stellen we een locatienauwkeurigheidsdrempel in voor onze apparaten. We hebben het apparaat nodig om zijn best te doen om ons een locatie binnen een fouttolerantie van niet meer dan 10 meter te krijgen. Als de afstand groter is dan dit, lopen we het risico van het opvangen van onbedoelde dreuningen van apparaten die niet in de buurt zijn. Om dingen gemakkelijker te maken terwijl we ons ontwikkelen, zullen we detecteren of onze app wordt uitgevoerd in de Corona-simulator of op het apparaat. Dit zal in de eerste plaats voorkomen dat oneven gedrag optreedt van functies die momenteel niet door de simulator worden ondersteund. Ten slotte moeten we een apparaat identificeren met een unieke waarde. Een apparaat-id als deze zal voorkomen dat de server probeert een bericht terug te sturen naar het apparaat dat het heeft verzonden in plaats van de bedoelde ontvanger.
local bg = display.newRect (0, 0, display.contentWidth, display.contentHeight) local logo = display.newImageRect ("logo.png", 172, 107) logo.x = display.contentWidth / 2 logo.y = ( display.contentHeight / 2) - 150 Vervolgens maken we een achtergrondrechthoek die onze app een mooie, witte achtergrond geeft. De volgende 3 regels geven een logo weer in het midden bovenaan het scherm.
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
De bovenstaande code gebruikt de toegang van de UI-bibliotheek tot de oorspronkelijke weergavecomponenten voor het apparaat. In dit geval tonen we eenvoudig het woord "Message" in een donkerblauwe tint. De reikwijdte van dit artikel omvat niet alle ingewikkeldheden van de native weergavebibliotheek, dus ik raad aan om een kijkje te nemen op de Corona-site als u nog niet bekend bent met de SDK. De Y-coördinaten worden ingesteld op 60 pixels groter dan de positie van het logo dat we net hebben weergegeven.
if is Simulator dan - Simulator (simuleer het gebied textField) textField = display.newRect (20, titleLabel.y + 60, 280, 30) textField: setFillColor (200, 200, 200) else local function fieldHandler (event) if (" "== event.phase) ingediend en vervolgens native.setKeyboardFocus (nul) -eindgedeelte 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 Een van de beperkingen van de simulator is dat het niet alle native componenten van mobiele apparaten correct kan weergeven. Om te voorkomen dat er fouten worden gegenereerd, zullen we detecteren of we de app in de simulator gebruiken en een grijs vak weergeven in plaats van een invoerveld. Dit zal ons helpen bij het positioneren van de elementen. Als de app niet in de simulator wordt uitgevoerd, zullen we een native "textField" -onderdeel weergeven waarmee de eindgebruiker een bericht kan typen. De terugroepactie fieldHandler is nodig om een fase van "ingediend" te detecteren, of met andere woorden de gebruiker die op de "return" -knop drukt. Door deze gebeurtenis te vangen, kunnen we het toetsenbord verbergen nadat de gebruiker zijn bericht heeft getypt.
local removeKeyboard = function (event) - Verberg toetsenbord native.setKeyboardFocus (nihil) einde bg: addEventListener ("tap", removeKeyboard) Als toegevoegde bonus voor de gebruikersinterface kunnen we een gebeurtenislistener toevoegen aan onze witte achtergrond die wacht op een "tik" -gebeurtenis. Op deze manier, als de gebruiker op het scherm tikt buiten het toetsenbordgebied, zal het de focus ervan verwijderen en ervoor zorgen dat het verdwijnt.
local latitudeText = "" local longitudeText = "" if isSimulator dan local alert = native.showAlert ("Error", "GPS niet beschikbaar in Simulator") else local locationHandler = function (event) latitudeText = string.format ('% .8f ', event.latitude) longitudeText = string.format ('% .8f ', event.longitude) einde Runtime: addEventListener ("location", locationHandler) einde Nu verder met de goede dingen! Eerst zullen we detecteren of we in de simulator actief zijn en gewoon een foutmelding weergeven dat de GPS niet beschikbaar is. Wanneer we op het apparaat werken, maken we een runtime-luisteraar die continu onze locatie pakt van de locatieservice van het apparaat en onze locationHandler-methode met deze gegevens aanroept. We zetten dit om naar acht decimalen van nauwkeurigheid, die voor onze doeleinden meer dan juist zouden moeten zijn.
lokale getThump = function (event) als event.isShake == true dan local alert = native.showAlert ("Thump!", "Location:"? latitudeText? ","? longitudeText? "\ r \ nMessage:"? textField. text, "OK") system.vibrate () end-end Runtime: addEventListener ("accelerometer", getThump) Ten slotte zullen we een andere runtime-gebeurtenislistener maken die gegevens van de accelerometer van het apparaat haalt en doorgeeft aan onze methode getThump. Binnen deze methode zullen we detecteren of het evenement een "schud" -gebeurtenis was. Een shake-evenement is een andere naam voor wat er zal gebeuren wanneer we twee apparaten samen "dumpen" in de hoop een bericht te kunnen verzenden. Aangezien we onze servercomponent nog niet hebben geschreven, zullen we deze gegevens eenvoudig weergeven in een waarschuwingsvenster om aan te geven dat onze app tot nu toe werkt. Om dit uit te testen, kunt u eenvoudig een bericht typen en het apparaat waarop de app wordt uitgevoerd een shake geven.
Houd deze week in de gaten voor deel II van deze serie, waar we de serverfunctionaliteit in Rails on Heroku zullen aanpakken!
