Swift / Objective C / IOS

Sync’ing blood glucose data over Bluetooth to HealthKit

Liam

The code for this project is on my GitHub (here).

While newer blood glucose monitors (BGM) have Bluetooth capability (BLE), they are often designed only to sync data to their own clouds. Many applications call for mixing glucose measurements with data like weight, activity, carb consumption from other apps to enable consumers themselves, coaching, or care teams to use the information directly.

This code pulls glucose measurements from a BLE-enabled BGM and stores in:

  • HealthKit. Many apps and EHRs have HealthKit integration and can use HK as a channel to import glucose data.
  • Open format. Developer can integrate into other database systems.
 HealthKit result

The code was developed using a Contour Next One BGM since it was found in a study published by the Diabetes Technology Society to be the most accurate of the set of 18 BGMs tested and one of the few to meet the FDA accuracy standard for glucometers.

The Bluetooth Forum developed a standard “GATT” profile for BGMs. Details can be found here.

Reads from the BGM are performed via its “Record Access Control Point (RACP)” characteristic. The code writes to RACP requesting data from the Bluetooth Glucose Measurement read more

Simplest NSOutlineView Demo

admin

Most NSOutlineView examples I have seen are not that helpful since you spend time trying to figure out how the data model behind the example works rather than seeing how to use the framework itself. Yes, the data model is critical, however if you don’t understand the framework then you won’t be able to write a controller to feed the view or the model…

 So. I have tried instead to get started by boiling this all down to the simplest possible configuration.

Before the Memory Leak Police get on to me, the below is not written for memory management beauty but rather to demonstrate the framework; so, the reader is left to figure out the releases. I know I generate lots of objects…and also that I violate MVC….

But, can you make it simpler than this..?

 

Power up Interface Builder, drop an NSOutlineView into a window, hook up the delegates and outlets like you would for NSTableView. That’s it.

Here is what’s going on in the code.

In Method#1, I hard-wire the code to return that every node has 3 children. You can see that in the output below if you look under the nodes that have been expanded. You could put here any integer or function that returns one.

In Method#2, you have to return a pointer to a unique object for each of the children that you declared in #1. Normally you would ferret around in your data model to find the right object. Here I just generate a new empty object each time and return a pointer to it.

In Method#3 I hard wire-in that every node is expandable.

Finally in Method#4, I demonstrate a point from the last blog entry. You return the data that you want displayed according to with the object you returned from Method#2.

This data can be from within the Method#2 object itself or it can be something completely different, perhaps even completely unrelated to the Method#2 object. For example, you could just return the word “Hello” and have it appear at every node on the view.

I chose to get the address of the Method#2 object (also demonstrating that each object in the tree is unique) and to concat that with some text.

In the next post, a more complicated directory browser. This time with MVC.

NSOutlineView: Part 1 Introduction

admin

Introduction

Outline views are great for displaying hierarchical data because they allow the user to drill down into the parts of the dataset that are the most interesting.

OutlineView Tree

A common place where they show up is in file handling windows. So. My last example in this column will be a directory browser. To build an outline view, all you have to do is create the view in Interface Builder, hook it up to your code and implement 4 specific delegate methods. Simple really.

It turns out that unless you try and understand some of what NSOutlineView does behind the scenes, the chances of actually hooking up your data right are remote… If you have a bug, what tends to happen is that you either get an exception/crash or nothing happens. And since much of the inner workings take place beneath the hood inside runtime, it’s not as if you can put a breakpoint inside the NSOutlineView to see what’s going on. It can take many NSLogs in your code to get some visibility.

Delegate Methods

You can think of delegate methods like the outsourcing of a task. When the outline view needs to know more about the data that you would like to display in the view, it simply calls the relevant “delegate” method and expects an answer.

These methods are the interface between your dataset and the onscreen view. At a minimum, NSOutlineView requires you to implement 4 delegate methods in your code. There are several other delegates that are strictly optional and which add more functionality to your outline view.

It’s easier to call the 4 compulsory delegates Method 1-4 instead of their full names; besides, this is the order in which runtime tends to call them anyway, so it’s a useful frame of reference.

Let’s dig in to how it all works.

Method#1

– (int) outlineView: (NSOutlineView *) outlineView numberOfChildrenOfItem:(id)item

This is the first delegate that runtime will call to populate your outline view. It asks the question: “For the node that you just clicked on to expand, how many children objects should I allow for?”

This method is only called on one of 2 occasions. Either:

  •  When the view is first displayed at start up and runtime needs to know the contents of the Root level of your data
  • When a node is expanded and runtime needs to start building the display of that node’s children.

Since these cases both happen relatively rarely, Method#1 tends to be called the least frequently out of the 4 delegates.

The next delegate methods #2 and #3 will be called the number of  times you specify in the number you return now. So, if you return “3” here, they will get called 3 times.

2 values are passed to this delegate by runtime:

  •  (NSOutlineView *) outlineView (or whatever you choose to name the view). This pointer is passed to you in all 4  delegates so I’m only going to bother to explain it once here. When you build an outline view in Interface Builder, you have the option of making a multi-column display. You could have 2 different outlines displaying in each column. To let you know which outlineview runtime is talking about, it sends you a pointer. For a simple 1 column outlineview, you can ignore this pointer.
  •  (id) item. This is a pointer to the object associated with the node that the user clicked on. For example, in the above diagram, when the user clicked on “Applications”, the pointer to item here would point to the object associated with Applications. There

read more