| ... | ... | @@ -12,17 +12,17 @@ After installation via Gradle/.AAR files or Eclipse/.JAR files, continue with th |
|
|
|
The B4S SDK requirs initialization of the library with the unique application ID (provided by Ezeeworld). It is strongly recommended to do so in the application object. If no `Application` is yet defined, add it in your `AndroidManifest.xml`, for example:
|
|
|
|
|
|
|
|
```xml
|
|
|
|
<application
|
|
|
|
android:name="com.ezeeworld.b4s.android.sdk.sample.SampleApp"
|
|
|
|
android:label="@string/app_name" >
|
|
|
|
<application
|
|
|
|
android:name="com.ezeeworld.b4s.android.sdk.sample.SampleApp"
|
|
|
|
android:label="@string/app_name" >
|
|
|
|
```
|
|
|
|
|
|
|
|
and in the `Application` instance (here `SampleApp`) `onCreate` method call `init` and make sure the monitoring service runs upon the first app start. Replace `MY-APP-ID` with your unique application ID.
|
|
|
|
|
|
|
|
```java
|
|
|
|
B4SSettings settings = B4SSettings.init(this, "MY-APP-ID");
|
|
|
|
settings.setShouldEnforceBluetooth(false); // When set to true, Bluetooth is automatically turned ON on application launch
|
|
|
|
MonitoringManager.ensureMonitoringService(this);
|
|
|
|
B4SSettings settings = B4SSettings.init(this, "MY-APP-ID");
|
|
|
|
settings.setShouldEnforceBluetooth(false); // When set to true, Bluetooth is automatically turned ON on application launch
|
|
|
|
MonitoringManager.ensureMonitoringService(this);
|
|
|
|
```
|
|
|
|
|
|
|
|
Logging is turned off by default; use the `B4SSettings` object returned on initialization to enable debugging (using `setShouldLogScanning` and `setShouldLogMatching`).
|
| ... | ... | @@ -74,7 +74,35 @@ B4S can relate beacon interactions to individual customers. Supplying the custom |
|
|
|
|
|
|
|
### Deep linking
|
|
|
|
|
|
|
|
By default the SDK will generate interaction notifications directly, such as web links. Deep links are send to the main activity of your application. The following Intent extras are available:
|
|
|
|
Notifications such as web links or simple messages are handled directly by the SDK. For deep linking, there are three options, which can be set using `NotificationService.registerDeepLinkStyle(NotificationService.DeepLinkStyle)`:
|
|
|
|
|
|
|
|
- `DeepLinkStyle.LaunchActivityClearTask` - (Default) Deep links are delivered to your launch Activity, and always in a new task (with an Activity restart)
|
|
|
|
- `DeepLinkStyle.LaunchActivityDirect` - Deep links are delivered to your launch Activity; if this is already running the Intent is delivered directly to your `onNewIntent` lifecycle method
|
|
|
|
- `DeepLinkStyle.BroadcastReceiver` - Deep links are broadcasted with a `com.ezeeworld.b4s.android.sdk.notifications.DEEP_LINK` Intent action type
|
|
|
|
|
|
|
|
When you configure to use `DeepLinkStyle.BroadcastReceiver` deep links, the application can and must register a `BroadcastReceiver` that handles the deep links, such as opening a specific Activity or starting a Service. In your `AndroidManifest.xml` you declare:
|
|
|
|
|
|
|
|
```xml
|
|
|
|
<receiver android:name=".DeepLinkReceiver">
|
|
|
|
<intent-filter>
|
|
|
|
<action android:name="com.ezeeworld.b4s.android.sdk.notifications.DEEP_LINK" />
|
|
|
|
</intent-filter>
|
|
|
|
</receiver>
|
|
|
|
```
|
|
|
|
|
|
|
|
The `DeepLinkReceiver` can, in its simplest form, simply relay the broadcasts to some other Activity:
|
|
|
|
|
|
|
|
```java
|
|
|
|
public class DeepLinkReceiver extends BroadcastReceiver {
|
|
|
|
@Override
|
|
|
|
public void onReceive(Context context, Intent intent) {
|
|
|
|
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); // Required as no Activity context is available
|
|
|
|
context.startActivity(intent);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
Deep link `Intent`s contain a bundle of extras to respond appropriately:
|
|
|
|
|
|
|
|
- `NotificationService.INTENT_SHOW` - (int) Hash code of the interaction that was matched
|
|
|
|
- `NotificationService.INTENT_INTERACTION` - (String) Unique ID of the interaction that was matched
|
| ... | ... | @@ -104,4 +132,4 @@ It is recommended to call these from the `Application`'s 'onCreate` method, but |
|
|
|
|
|
|
|
With Android 6.0 (API level 23) a new permission system was introduced by Google. On Android 6 devices, users can manually manage permissions on a per-application basis. If an app targets Android 6 (using targetSdkVersion 23 and compileSdkVersion 23), an app also needs to deal with runtime permissions. This means that permissions such as location access (which is now a so-called 'dangerous' permission) needs to be explicitly requested with a permission request pop-up. Until SDK version 1.4.2, the B4S SDK does not handle this automatically and therefor the integrator needs to [handle permission request dialogs manually](https://developer.android.com/training/permissions/requesting.html).
|
|
|
|
|
|
|
|
From version 1.5.0 onwards this will be handled for you by the SDK. A request to access the user location will automatically be shown when access was not yet granted. It is important to note that this does not affect any applications, even when running on an Android 6 device, that still target API level 22 or lower. |
|
|
|
From version 1.5.0 onwards this will be handled for you by the SDK. A request to access the user location will automatically be shown when access was not yet granted. It is important to note that this affects any application when running on an Android 6 device, even those that still target API level 22 or lower. |
