richk / projectbeacon Goto Github PK

Monitoring is needed to support sending notification when a user's smartphone enters or exits beacon region

User should be able to tap on a recipe from the list of recipes in "My Recipe" activity and look the details of the recipe. User should then be able to make changes to the recipe by changing the beacon or the action on the beacon.

Use Parse to create login/registration flow for users of the app to sign in.

/cc @nesquena , @vibhorB and @thecodepath
Please review the sprint 2 week milestones for our project.

Please review their first sprint /cc @vibhorB

\cc @nesquena and @thecodepath
Please review the first week milestones for our project.

1. The good news is that the SDK is able to detect beacons from all manufacturers - I tried KS technologies, Qualcomm, TI

2. The bad news is that BLE technology itself does NOT specify a protocol for advert data transmitted by beacons. This means that there is no standard way of getting UUID, MajorId, MinorId across all manufacturers. Each manufacturer sends this data in a byte array and the order of bytes is not the same.

3. The only reason we really need UUID, MajorId, MinorId is so that we can uniquely identify a beacon and implement our application logic based on that. I tried using the MAC address of the beacon as unique key but that doesn't work because Qualcomm (and maybe others) rotate the advertised MAC address several times in a second because of which it's not unique.

4. This is where Apple's "iBeacon" spec comes in handy. If the device is compatible with iBeacon spec, it must advertise its data per iBeacon spec. If that is the case, then parsing beacon attributes like UUID, MajorId, MinorId is simple.

5. If we do not enforce the "iBeacon" requirement then we will need to investigate and find out the way of getting UUID and other advert data individually per manufacturer which won't result in a good user experience since they might use a beacon from a manufacturer which is not supported by us.

In the light of above findings, I think we should support only "iBeacon" compatible devices. Most beacon manufacturers allow you to configure the device to be iBeacon compatible using some sort of app provided by them. I looked at Qualcomm and TI and both have provided some documentation for that.

Let me know if you guys have any additional thoughts on this. All the code written so far for this investigation is checked into our Git repo and the app is in working state. After you signup and login, it shows you a list of nearby beacons.

We now have the first cut of our app working end to end. As a quick refresher - the main use case of the app is to be able to create "beacon" based recipes such that user can configure certain actions when they approach or leave a beacon region.

We have the basic flows in place with notifications functionality working. Here are the main components that we have worked on so far:

1. BLE service for scanning / monitoring beacons: The service is built from scratch using standard Bluetooth API's available in Android. We could have picked one of the enhanced BLE SDKs such as RadiusNetwork or Estimote but chose to implement from scratch so that we could learn concepts such as services, loopers, handlers, IPC.

2. All the required screens for creating recipe, selecting beacon, configuring actions and sending notifications. Implemented using standard Android concepts such as activities, fragments, intents, push notifications etc.

3. Used Parse SDK for login, syncing user data in the cloud.

Here is a quick demo:
https://www.youtube.com/watch?v=PWfxCbwYyJ4

@nesquena and @timothy1ee, @vibhorB take a look