[GENERAL] Wishes/ideas for Connect IQ future

Hello Connect IQ team!

as I started to take Connect IQ development more seriously about year ago, spent lots of time with it and had to explore lots of dark corners of CIQ for my more complex projects, I feel to share some topics and ideas which I find quite important or limiting to take the apps on Connect IQ platform to next level. I didn’t want to create separate threads for them so there they are all together.

First of all, great job guys for creating such platform in what I assume not easy environment. You made the Garmin products A LOT smarter. There are lots of things on development on Connect IQ platform which I really like and why I decided to invest lots of my time and effort to it recently. On another hand during this immediately popped up lots of topics which in my opinion prevents developers to transform lots of ideas into real app solutions on the platform. So, I hope you will take it constructively as wider feedback from one of your CIQ developer for whom the development to CIQ is not just another hobby.

CIQ Features:

Datafields can’t share data with each other or connect to same ANT sensor. 
Newly developed ANT sensors usually don’t provide only one interesting value. I find very limiting to not be able to read data from one ANT sensor (with one ANT channel) by more CIQ datafields. So in order to show users relevant values, we have to try to squeeze more values to one datafield which have big impact on UI experience and usability.

DF communication only every 5 minutes
I fully understand requirements for sustain good battery consumption, but this limitation take away huge amount of ideas as it applies also for communication with gyro sensor. And custom DFs which gyro data processing is something which can bring lots of added value for whole Garmin ecosystem in my opinion. I know that CIQ dedicated apps do not suffer from this limitation, but they on another hand brings lots of other limitations preventing them to be widely used during sport activities, especially on recent generations of CIQ devices. One of them is..

CIQ app is unable to do Resume later
In case it records the activity. This is one of the key reasons why we can’t substitute limitation of DFs by dedicated apps. Sure, we can pause recording within the app, but that don’t allow us to use other Connect IQ widget or watchfaces during activity break.

CIQ app can be automatically started only with user input to confirm dialog
I understand the idea behind this, but this again in my opinion take away some great scenarios and do more harm in development freedom than brings benefits. If some app will abuse this feature, it will be easy to identify it by user and do uninstall if necessary. Also, app reviews in Connect IQ store would be great control mechanism for possible abuse of this feature. I find this important as for Garmin watch to be powerful smartwatch, moving task from smartphone to watch and back must be seamless as possible just like on rival platforms in this respect. I believe allowing developers to launch app without confirm dialog but with some vibration alert and timeout for user-input would be great compromise.

CIQ app ability to run native or even other CIQ datafields
This is rather wilder idea to make CIQ apps more powerful. Ability to load available datafields from within the apps can remove lots of mentioned platform limitations in my view.

CIQ apps / activities main device menu
Recent Garmin watches can be in some way capable smartwatches with many installed applications doing various jobs, including native/custom activity recording or for example managing lights in your home. For that I find that current logic of main device menu, with native activities and CIQ apps in one list, insufficient mainly in contrast with other smartwatches on market.


CIQ platform development:

Slowdown of CIQ advancement?
This might be only subjective feeling, but I see noticeable decrease in activity around whole platform which relates also to following bullets. CIQ Summit didn't really help to change this opinion. And this doesn’t show the platform in “healthy” condition, which is rather disturbing.

CIQ 3.0 status 
CIQ 3.0 was introduced year ago and in my opinion some of its key features are less polished than they already should be. For example, MapTrackView and MapView still seems like alpha version, because lots of their features are useless if you don't want to jeopardise user experience of your app. Of course, you will not find out this from documentation, so every developer have to multiply development time with those modules several time to learn their real limitations and to prepare workarounds for the rest. There are lots of posts regarding this topic on the forum.

CIQ 3 Messaging for selected developers
I miss information about who can be granted to use CIQ 3 Messaging, under what conditions and what are the actual capabilities.

Unknow future strategy
I find quite non-standard for developers on platform like this to know that little about future plan for platform development and upcoming possibilities. CIQ 3.1 is out and seems like even CIQ team don't know what should be in 3.2... 

Long-term not resolved bug tickets
On the forum there are many topics about issues for which were reportedly opened internal tickets months or even years ago, but without any further status updates or with same status again and again that team is looking at them. One example: https://forums.garmin.com/developer/connect-iq/f/legacy-bug-reports/5144/failure_during_transfer-issue-again-now-using-comm-sample 
Honestly in this environment I am not motivated to report all issues to which I step into during development. I simply don’t feel required feedback here.

Other Garmin pieces related to Connect IQ

Garmin Forum
New forum is vast improvement, but look here how messy it can still get: https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access
Updating thread rendering for sorting by new messages will help a lot. 


Garmin development blogs
Which Garmin blog should I follow to not miss anything important? I followed https://developer.garmin.com/blog/ to find out that I missing lots of interesting articles from here https://www.garmin.com/en-US/blog/category/developer/ . I bet I am not the only one confused there. It will be great to simplify communication to community.

Closer integration with rest of Garmin – as viewed from outside
I am aware that the teams responsible for Garmin Connect, CIQ Store etc. are different and some even located in another country, but from what I see, I believe that communication/prioritization with those teams don’t work too well. And that drags down whole CIQ potential in the eyes of somebody who is considering to invest bigger effort/money to bring something new to the platform. What else explains that nobody is still able to fix issue like (https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access). I whish CIQ topics have bigger priority in other Garmin teams…


I think it’s all about potential of platform for Garmin itself which can be in my opinion higher not having the issues mentioned above. But you can’t rely on gaining another level of CIQ importance with help of 3rd party developers if they can’t rely that their service will work here. Typical egg or chicken paradox.

I will love to know what others thinks about these topics, hope that my summarized experience might help at least a little for making CIQ better, wish to keep the pace on further platform development and having enough contributors to CIQ Store. I am working on another one. :)

Jan

REFRESHED ON 30.7.2019 (but not that much...)
Actual view on current ciq situation here: forums.garmin.com/.../912867

  • capinoha great post! I agree with all of the above, and I also wish the documentation were improved. Personally, I have many items on my own wishlist, some of which have to do with more efficient usage of memory, especially for data fields on older devices. One example is that adding strings used only for app settings will consume memory at run time, especially if resources are loaded at run time. I wish we could add strings to a separate section that is only used for app settings, since it’s unlikely that many apps will use any of those strings at run time. It seems like a huge waste to me.

    The funny thing about Resume Later is that CIQ data fields are terminated and restarted, and most of them don’t handle this properly (save and restore state), not even Garmin”s own Running Power app. I wish CIQ data fields would be automatically suspended and resumed, just like the rest of the native activity.

    Anyway, just wanted to point out that you can view the widgets / watchface during an activity / CIQ app on some newer watches, through the use of a hotkey. E.g. For Fenix 5, the default hotkey for viewing the widgets is to Hold Down. On the 935, there is no default hotkey for this, but you can assign one in the settings. The downside is not all watches support this feature and you can’t view CIQ widgets while running a CIQ app.
  • As far as the mapping API, the main issue I see with that is the sim doesn't always reflect how things work on a device, but that said, it is being used in apps in the store. I know of a number that use MapView and MapTrackView, including 3 of my own. (for fenix, edge, and outdoor handheld with maps - but there are a few differences between the families)

    Mapping is complex to use, and there things like on a watch, if you have track log=show set, your app doesn't need to draw a polyline for your track - it's handled for you - but that's something you won't see in the sim.

    I'm actually been a bit surprised there haven't been more threads about mapping here, as yes, it is more complex than most interfaces in CIQ (music apps may be more so), especially with the things in the sim not being the best, but mapping is a nice addition!

    Because it's complex, if you have a question, post it here, or if you run into something, a bug report, because as I said, others are using it, and can help point out some of the things.
  • The funny thing about Resume Later is that CIQ data fields are terminated and restarted, and most of them don’t handle this properly (save and restore state), not even Garmin”s own Running Power app. I wish CIQ data fields would be automatically suspended and resumed, just like the rest of the native activity.

    I don't consider this as big problem, as devs have ways how to handle this on their own, although not as simple. But of course, if Garmin's own CIQ datafield doesn't have this solved properly, who should expect this from other devs.. I am aware of possible hotkey to go back to watch and widgets, but as you mentioned - no CIQ widget will be running this way if CIQ app was launched.

    jim_m_58 Well I remember to implement track polyline on my own in the end and I don't think it was only because lacking support on sim. BTW how we should know that sim doesn't have that functionality implemented if it is not mentioned in documentation? Or did I miss it elsewhere? Anyway in next few weeks I will make another attempt with this part of CIQ3, so I hope it will be more straight forward this time. And as for bug reports, I would like to, but as mentioned above, it also require to have feeling that I am not missing anything important here, my bug report will be relevant for somebody and don't end up on some internal ticketing software for months..


  • capinoha

    Thanks for investing effort in CIQ platform. This is a great post, although a few of the item that you have mentioned are in the CIQ team's wish list as well, but in a complex multi-team organization not all the wish-listed items get high priority for implementation and pushed back. All the bug reports for CIQ goes through the team every week, feel free to report any thing you find during your CIQ development. As for the road map and future of CIQ platform, the summit is a good place to get all your questions answered and get more insight into where the platform is headed.
  • Access to ascent/descent course information. The distanceToDestination info is already available—it would be great to have access to ascentToDestination and descentToDestination, too. It isn't always available in the loaded course but, when it is, that information would allow for data fields to show the climbing remaining. Something all cyclists (and some runners) are interested to know.
  • Yes, these are really good suggestions. Few more changes what I would like:

    Better handling of errors / logs
    Many times you reach the limits of the device (memory limits etc.). Usually the watch app or the watchface just closes and displays the CIQ logo. The most infamous case is the "Code executed too long" that can happen sometimes on Fenix 3 or Forerunner 235. These errors are really hard to replicate, and you cannot easily prevent them. I think we need more information in the log, why it happened, which activity was running, how much memory was left…

    Usually you cannot get much more information, even if you compile the app as a debug app and send it to user to replicate. In the log it will be just this one line. Not sure how this can be handled… But these types of errors are making the apps very unreliable. Maybe if the developer knows that this piece of the code can cause problems (in very rare occasions), he should be able to wrap it in some "try catch" block, that will just skip this method when the limit is exceeded and the app will still keep running… Or there may be some event, that the memory is low / the execution takes a lot of time…

    Ability to install apps / data fields together
    User should be able to install "the bundle" from the Garmin app store. For example I would like to publish a device app, also with a datafield (the app would download the list of routes from the internet, then you would start the running activity with a custom data field). I would also like to see some additional statistics on the watchface, or have a related custom music provider installed :)

    But right now you need to search for each separate app in the store, and install (and configure) every data field extra. It would be very useful and more easier for users to be able to install all components of the app at once.
  • Tomas - "Code executed too long" - You mean the watchdog timer? It is shorter on older devices like the 23x/f3 than on newer devices, and a common cause is a long loop in the code, where you've not returned to the VM, so that's a place to look. Somethinging like doing calculations with a large array. And if that array keeps growing, things take longer and longer.
  • Yes, the watchdog timer. You have no control on that, you cannot see if you are near the limit, or you cannot catch it as an exception. For example it can happen when you parse the values from the SensorHistory, or when you draw a lot of polygons in one draw. The problem is that it may "mostly work", but it can crash just once per day (when the reference counting / garbage collection of the CIQ is started? or who knows). I just wish we have more control over this, and just do not hope that it will work. Or this problem should not crash the watchface, just the remaining code of the onUpdate method should be ignored (and logged in the log).

    Documentation
    Also I wish the documentation would be more up to date :) From the last observations:
    • It is not mentioned that the PersistentContent module does not work on the Vivoactive 3
    • The same case is for the Training Effect. It also does not work on some devices. It would be nice to have a device compatibility matrix for these features.
    Missing features
    Why we cannot access the time of the alarm from the watchface? The weather information? The stress value or other parameters? :)
  • Anshul.ConnectIQ If all bug reports are going through the team every week, why we doesn't know state of some critical ones for years?
  • We triage issues every week. Triaged issues may be transferred to other teams to be fixed, or may be backlogged to be fixed when it is appropriate.