Before Writing Code

5 ways to set yourself up for a successful app-device integration

1. Start with the desired app user experience (UX) in mind
   
   It is important to answer questions like:
   - Will this be an app that only connects to the device when it is open?
   - Do I need to capture data from the device while the user is not using the app?
   - How much data comes from the device and how often?
   
   Defining the UX provides guide rails for the rest of the integration
   
2. Understand the device capabilities - and change them if possible
   
   For example, does the user need to see real-time readings from a Pulse Oximeter?
   
   Perhaps the device requires you to read (or write commands) to get live data. This could cause problems with getting data in the background. Switching the firmware to send notifications would support the app UX (Step 1).
   
   Obviously, this kind of change isn't possible for commercial, off-the-shelf (COTS) devices - but perhaps there is an alternative device that can be substituted.
   
3. Make sure your app architecture is compatible with BLE
   
   Remember, BLE communication is asynchronous. The architecture should be responsive to data changes at any time.
   
   Because the device is external to the software, the architecture should be prepared to handle failures (disconnects, timeouts, unexpected data).
   
4. Keep the device integration SOLID
   
   SOLID principles apply to all software development but are especially important when writing an integration layer.  This could be a series of posts, but a few highlights:
   
   - It is important to not expose low-level Bluetooth details to the rest of the app
   - Bluetooth code should be contained in its own module
   
   In other words - the Bluetooth module should provide an API that could be powered by Bluetooth devices - or simulated devices - or code mocks for testing.
   
5. Log like crazy
   
   Once you begin writing code, be generous with logging the current state of the Bluetooth module and how the app is using it.
   
   While NSLog/LogCat/prints are good for local development, consider using remote logging tools like Datadog, Bugfender, or Logz.io to capture information from other apps+devices.