Mobile SDK and Companion Apps Informal Survey

Hi, so I'll start with my experience:

1. How has your overall experience been developing companion apps with our mobile SDKs?
I was doing and Android companion app. The overall experience is fine, but there are some crucial things missing in the SDK, please see below.

2. Are there any documentation improvements you would recommend?
No, docs are alright .)

3. Is the sample app included with the SDK a useful sample?

Since I needed to rework it into a service instead of activity, it was only partly useful. I suggest to add another example that would be a service - a completely different approach is then needed. But maybe this is a niche need.

4. Are there specific issues you encountered while attempting to develop a companion app?

a) Starting app from watch via connectIQ.openApplication is uncontrollable. Mainly because you don't get feedback about the chosen user action. You should get a callback if user chooses Yes or No.
Often the prompt on the watch does not appear at all.
To make sure the prompt appears, I have to resend it numerous times, which is annoying for the user if he wants to choose No.

b) To start the app on phone from watch, a hack is needed. I have to intercept the ConnectIQ.INCOMING_MESSAGE intent w which is being sent for the GCM app and examine its extras to see if the message is from my app, and in reaction start my app.

c) Communication between phone and watch is unstable. Often it drops into a broken state and I start getting FAILURE_DURING_TRANSFER when trying to send a message from phone to watch with no possibility of finding out the root cause.
Interestingly, at the same moment, communication from watch to phone works fine.

5. Of those issues, are there any you were unable to address or work around?

I haven't been able to workaround the 4c) issue. When the FAILURE_DURING_TRANSFER starts to appear, a phone restart is needed.

6. Do you have any feature recommendations or improvements to the mobile SDK you suggest?

a) Starting watch app from phone: either drop the prompt at all, or at least make the callback more useful with specific information about the user action.
b) Implement starting phone app from watch app into CIQ
c) Ideally enable easily sending logs to the phone. It is very painful to debug CIQ apps with real users, especially since the txt logfiles are so limited in size.



Hopefully I don't sound too negative. I really appreciate the work you've put and are putting into this since the platform is really good and a pleasure to develop for. It is only natural that some evolution has to take place :)

Thank you!
Jiri

Hi,
I spent some time with mobile SDK: already have an app with mobile companion, which does optional complex configuration (interval constructor, way-point storage organizer), currently I'm actively testing yet unreleased widget to be used in "daily smartwatch" scenario, thus, presumably, I know the drill. So, here are my thoughts on the subject.

1. How has your overall experience been developing companion apps with our mobile SDKs?
Apart from unpleasant situation, when all of the mobile companions were crashing due to the changes in parcel structure (lasted for a couple of months during middle of 2016), I have a rather stable experience. In comparison to Android Wear watches I find reaction times to disconnect/reconnect events very fluent, e.g. in AW environment watch can consider it's connected for a couple of minutes after connection is actually lost, while with GCM on Android I receive callback almost immediately, which helps to control data flow more efficiently.

2. Are there any documentation improvements you would recommend?
I agree with ArtaudAntonin that it would be nice to at least have extensive explanations about ConnectIQ.INCOMING_MESSAGE broadcast as currently it looks semi-hacky reflection-like sort of behavior which we cannot guarantee to last. Also, registerForPhoneAppMessages needs it's dedicated section in API Docs.

3. Is the sample app included with the SDK a useful sample?
It's useful by being the only working sample of this kind, although I would like to see "best practices" sample for Android services implementation, as currently message about GCM not being installed is given even if I query ConnectIQ from non-activity context thus there's a necessity for some kind of workaround by checking if GCM installed via package manager as this message crashes service otherwise.

4. Are there specific issues you encountered while attempting to develop a companion app?
Apart from still being unable to create a stable test ADB environment using simulator, everything is working fine.

5. Of those issues, are there any you were unable to address or work around?
For now it just BLE debug feature.

6. Do you have any feature recommendations or improvements to the mobile SDK you suggest?
6.1. Obvious suggestion for a smartwatch scenario: it would be nice to have (at least optional) feature for a watch to give some kind of signal when it looses/regains connection to paired phone.
6.2. Another good thing to have would be an ability to discover watch in bluetooth device list on phone (e.g. to use it along with smart unlock functionality). I've read some posts about how people are able to see their Fenix3 in BT device list, but unfortunately it's not an option at least for my FR230, therefore I consider this feature absent.
6.3. I understand the consideration behind severing communications for watchfaces, but it would be nice to at least have some kind of interface to send settings from a companion app to watch programmatically. This, although still being battery friendly, will allow for developers to deliver additional useful information via the most visible and popular application type.

Thanks for the thoughtful feedback! I'll gather what's here and get things sorted into actionable reports. A couple of the things mentioned above are being addressed (I'm withholding which ones because they're related to some fun, new upcoming CIQ features), and the rest we'll try to get prioritized. Most everything mentioned so far sounds entirely reasonable and possible. The only one I'm a little unsure about is device discoverability in the Bluetooth list on a phone because of the way our GCM pairing process works.

If anyone else has any other ideas or suggestions, please post here any time. Thanks again!

Hi again and many thanks for the feedback Brandon!
I don't really qualify as anyone else currently :) but I just realized one more thing.

A lot of trouble with maintaning the comm link between my companion app and the watch app results from Android's battery saving features. All of the involved apps (GCM and companion app usually) have to be whitelisted from those battery saving features, otherwise it is probable that Android will sever the link. It is not the 100% cause, but it sure plays its part.

6.1. Obvious suggestion for a smartwatch scenario: it would be nice to have (at least optional) feature for a watch to give some kind of signal when it looses/regains connection to paired phone.

I'd like to get some clarification on this one. The CIQ API already has System.DeviceSettings.phoneConnected() to tell you whether the device has a phone connected over Bluetooth. I'm assuming your suggestion is for something other than this.

I'd like to get some clarification on this one. The CIQ API already has System.DeviceSettings.phoneConnected() to tell you whether the device has a phone connected over Bluetooth. I'm assuming your suggestion is for something other than this.

Hi Brian, the basic idea is to have a system feature, which gives you vibe/sound notification on watch when you unintentionally leave your phone behind. I meant this to be a system feature, as there's already must be listener on watch, which runs watchface update when phone disconnects (in watchface I receive onUpdate callback almost immediately when phone disconnects). I'd gladly develop this notification on phone disconnect myself but IQ application is unable to run in the background and there's no something BroadcastReceiver-like available in MonkeyC, thus I can't listen for this event, also watchface cannot give feedback using Attention module (or have I missed when this feature became available?).

Well, "live and learn" they say, seems that I didn't dig that deep inside settings yet... Thank you Jim, I'll test if this option triggers the behavior I was trying to describe.

You get a toast and vibration on disconnect, but in your code, you still want to check phoneConnected before you do any comm. (I actually keep it off as just walking around the house it can keep disconnecting/reconnecting)

Hello and thank you for giving us the opportunity to have a say. Hopefully someone will listen :-)

I've developed apps for Sony SmartWatch and various other Sony smart accessories, as well as for Pebble, Tizen (Samsung Gear) and Android Wear.

I've published 3 apps for Garmin Connect IQ, all of them include companion apps for both Android and iOS devices (with the exception of the Log app which only has an Android companion app, because it cannot have an iPhone companion, due to iOS system limitations).

1. How has your overall experience been developing companion apps with our mobile SDKs?

Not the best.

2. Are there any documentation improvements you would recommend?

Yes. Please ensure that the documentation is relevant to the actual API. Describe each method parameter and whether it is necessary or not.

3. Is the sample app included with the SDK a useful sample?

Yes. It shows much more than what the documentation says.

4. Are there specific issues you encountered while attempting to develop a companion app?

Yes, quite a few. What is important is mentioned in the next point.

5. Of those issues, are there any you were unable to address or work around?

Unfortunately, yes. The speed of communication between the watch-app and the companion app. It's very slow, it ruins the user experience seriously. I understand that the current standard is quite OK for notifications. But, not for much more. I have only a few bytes in each transmission and still it takes a long time. That is something I didn't anticipate at all. The simulator (and BT via ADB) leaves a false impression that this communication is smooth, while the reality is much, much different.
6. Do you have any feature recommendations or improvements to the mobile SDK you suggest?

I suggested somewhere on this forum that the addition of image transmission would be a great benefit. But, that was when I was testing without an actual device. At the current comm speed, it makes no sense to transmit image data, although I still claim it adds great potential for companion apps.


Lastly, if anyone has any companion apps they have built they'd like to show off, please include a link.

My three apps:
1. https://apps.garmin.com/en-US/apps/ebb8b616-52cb-4a32-aee3-aaa95eeffb8d
2. https://apps.garmin.com/en-US/apps/4187fab3-36d2-4fe0-ab60-4858424c5cbf
3. https://apps.garmin.com/en-US/apps/b6f1ee3e-7663-4177-b1ae-8ce641631684

Feel free to include any other feedback about the mobile SDK that isn't addressed by the question above.

Other smart wear platforms have detailed and accurate information in regards to the companion app development. They even provide resources (such as Photoshop templates to use to submit screenshots to the respective app store.

Generally, I guess that offering a way for developers to monetize could bring more dev attention to the platform. Also providing actual devices to devs for development and testing tends to be motivating. I've asked and I was refused.