App: Speed Dial

I recommend caching your numbers in the object store on the device. This will prevent start-up delay.

Also, the transmit API from the phone to the device can be used when the WatchApp is not running, messages will be saved in the device mailbox, and can be retrieved on the next run. If you cache the values in the ConnectIQ app, and send updates to the entries immediately when they are changed from the phone, you can bring in updates from the mailbox on app startup, and will only require direct communication when initiating a call.

I recommend caching your numbers in the object store on the device. This will prevent start-up delay.

Also, the transmit API from the phone to the device can be used when the WatchApp is not running, messages will be saved in the device mailbox, and can be retrieved on the next run. If you cache the values in the ConnectIQ app, and send updates to the entries immediately when they are changed from the phone, you can bring in updates from the mailbox on app startup, and will only require direct communication when initiating a call.

Hello Brian,

thanks a lot for the reply and the advices. I was not aware that the caching exists in some form. What I noticed when developing my apps was that the state was often preserved, and I even think some messages were resent, but all that behaviour only made my work more difficult. Is this all documented somewhere?

I have made such an app (speed dialing) with the same functionality, for other smart watches (for example Pebble and various Sony devices) and I took the BLE communication speed for granted, I never even imagined that simple message transmission of a few bytes could take up to several seconds.

There is some information in the API documentation in the SDK, but after taking a quick look at it, it isn't especially thorough. In the documentation, you can see the functions: getMailbox(), setMailboxListener(), and emptyMailbox(). There is an example that uses these in the SDK called "Comm" there is a partner app for this sample in the Android SDK.

When a partner app sends a message to the device and the app is not running (or a listener is not set in the running app), then that message is saved to the apps mailbox on disk. If there is data in the mailbox, the listener will be triggered immediately when it is set. After calling getMailbox, and reading all the messages from it, you should call emptyMailbox() to clear out the messages or you will receive them again the next time you run the app.

I believe we have an improved version of this API planned for a future SDK because there is an asynchronous timing issue that could cause you to lose a message if you delete the mailbox at the same it is received with the current implementation.

I have been told that most existing platforms use Bluetooth 3.0 (classic), and not Bluetooth 4.0 (BLE), which has much higher bandwidth. This may contribute to the speeds you are experiencing. I know our max speed peaks out somewhere around 0.5KB/second, and latency can be extremely slow, especially on iOS, if the partner app is not running in the foreground.

There is some information in the API documentation in the SDK, but after taking a quick look at it, it isn't especially thorough. In the documentation, you can see the functions: getMailbox(), setMailboxListener(), and emptyMailbox(). There is an example that uses these in the SDK called "Comm" there is a partner app for this sample in the Android SDK.

When a partner app sends a message to the device and the app is not running (or a listener is not set in the running app), then that message is saved to the apps mailbox on disk. If there is data in the mailbox, the listener will be triggered immediately when it is set. After calling getMailbox, and reading all the messages from it, you should call emptyMailbox() to clear out the messages or you will receive them again the next time you run the app.

Of course, I've seen that example, and I do invoke emptyMailbox() after each received message.

I believe we have an improved version of this API planned for a future SDK because there is an asynchronous timing issue that could cause you to lose a message if you delete the mailbox at the same it is received with the current implementation.

I have been told that most existing platforms use Bluetooth 3.0 (classic), and not Bluetooth 4.0 (BLE), which has much higher bandwidth. This may contribute to the speeds you are experiencing. I know our max speed peaks out somewhere around 0.5KB/second, and latency can be extremely slow, especially on iOS, if the partner app is not running in the foreground.

Well, there certainly are BT 3 devices, but for example Sony's SmartWatch 3 and Pebble watches are BT 4, and they still don't have that kind of lag, so it seems the reason lies elsewhere. I understand that Garmin focuses on other aspects of these devices, but I'd say having a faster BT communication with the watch is not too much to ask from a device of this price range.

I will continue this discussion in the Developers forum.