|
LISNR Radius Android SDK 2.0.0
|
The following example demonstrates a basic application integrated with the LISNR Radius Android SDK. The application uses a Transmitter to either send once or repeatedly beacon the string "Hello World" to a listening Receiver upon pressing a button in the app.
The transmitting and receiving functionality should be performed on two separate devices although they are contained in the same application in this example for simplicity. Trying to transmit and receive on the same device using this application will not work. If you would like to see a bidirectional example see the Hello World - Bidirectional Two Transceivers examples.
In this example, you will learn to:
Estimated time to complete and run the example is between 5-15 minutes depending on level of Android development experience.
This example is meant for developers who are new to LISNR Radius and want to see a simple example of an application running the Radius SDK for Android. If you are not a developer, do not have access to the requirements, or want to observe all of the tone profiles, bidirectional, unidirectional, and major features of the Radius SDK, see the Radius Sample Application. If you have a Radius development question that is not addressed by these examples, please contact our Customer Success team (cs@lisnr.com).
Before writing any code using the Radius SDK, you will first need to set up your basic Android application and UI/UX. Follow these instructions:
SDK_TOKEN with an SDK Token from the LISNR Portal. The SDK token must be created with the same Android Application ID as this application (ex. com.example.helloworld). Your Android Application ID is located in the app level build.gradle file.
The following sections show in detail the particular lines of code that are responsible for each aspect of the example application that you created in the setup steps.
Before any transmitting or receiving functionality can happen, a Radius object must be created. A Radius object manages all instances of Transmitter and Receiver objects in your application. There should only be one Radius object in your application.
In the code snippet below, SDK_TOKEN will need to be replaced with a valid Radius SDK Token from the LISNR Portal. When creating your SDK token in the LISNR Portal, be sure to input the Android Application ID (found in app level build.gradle file) of the Hello World project (ex. com.example.helloworld).
Notice that the Radius constructor we utilize in this example takes a Lifecycle object in the constructor. (To learn more about the Android lifecycle, read the documentation: https://developer.android.com/guide/components/activities/activity-lifecycle) Passing in a lifecycle parameter when creating your Radius object will tie it's usability/lifecycle directly to the Android Lifecycle object. Therefore, whenever an ON_STOP event occurs in the provided lifecycle, the Radius object will be rendered unusable, shutdown, any transceiving/transmitting/receiving functionality will cease, and a new Radius object will need to be created when returning to the app. This can be useful if you want your application to automatically stop transmitting/receiving when a user backgrounds the app. To see an example of not using the lifecycle Radius constructor and manually shutting down the Radius object, see the Create a Radius Object and Shutdown Radius sections.
In order to have transmitting functionality in the Hello World app, we will need to create a Transmitter with its required parameters. The Transmitter constructor requires a Transmitter Callback and a tone profile (see Tone Profiles to compare the other types). In this example, we will be using the Standard2_wideband tone profile, optimized for movement and longer distances.
The Transmitter callback determines what happens when a tone finishes playing (onTransmitComplete) and when a repeating beacon has stopped (onTransmitterEmpty). In this example, we are just adding logs in these callbacks but often times this is where a counter can be implemented to track how many times a beacon has transmitted or to update the UI/UX when broadcasting is complete.
Now that the Transmitter object has been created, it must be registered to the Radius object that was created earlier in order for the Transmitter to be authenticated and used.
The Tone object constructor requires a byte array. Use the getBytes() method to convert any String to a byte array.
In order to have receiving functionality in the Hello World app, we will need to create a Receiver with its required parameters. The Receiver constructor requires a Receiver Callback and a tone profile (see Tone Profiles to compare the other types). In order to detect the Tones from a Transmitter, the Receiver must be created with the same tone profile as the Transmitter.
The Receiver callback determines what happens when a tone is detected (onToneReceived). This is usually where the received tone payload is validated or processed by a backend and the UI/UX is updated to stop listening depending on the use case. In this example, we are adding a log in this callback and calling payloadBytesToString on the received Tone's data contents to convert it from byte array to ASCII string. See the Byte Array to ASCII section to see the payloadBytesToString method contents.
You may notice there is no separate section in this example for how to start listening with a Receiver. When a Receiver is registered to the Radius object, listening begins. To stop listening for incoming Tones, the Receiver must be unregistered from the Radius object.
Microphone permissions are required in order to use a Receiver in the Radius SDK. This example shows how to perform the steps of checking for microphone permissions, providing context to the user, and then asking the user to grant permissions, before trying to listen/receive Tones with the Radius SDK. It is important that in a real Android application using Radius, to disable any UI/UX that is intended for receiving Tones if the user denies microphone permissions. In this example, the UI remains enabled when permissions are denied for simplicity sake. See Audio Permissions for more details on requesting runtime permissions.