Ticket Created
over 5 years ago

WERETECH-7119, WERETECH-7120, WERETECH-8181

Split issues in this thread into multiple issues.

MapView and MapTrackView classes are broken - even more on CIQ3.1

Hi, 

not only that CIQ 3.0 implementation of MapView and MapTrackView still have more issues than actual working features, CIQ 3.1 even made them worse. 

Newly, UI rendered by both classes can not be refreshed on CIQ 3.1 devices by calls from code after first initialisation - for example by setMapVisibleArea method as it is described here:

https://forums.garmin.com/developer/connect-iq/f/discussion/191378/fenix-6-ciq-maps-implementation/932413#932413

I can summary also the older issues if it will help somebody to take care of them in one run. But some of them are already mentioned on various places of the forum without any positive reaction from CIQ team, so I don't want to waste time if nobody ask for them.   

Will there be please finally time to fix those important parts of CIQ after settling down dust from CIQ 3.1 public release? This is kind of things why Connect IQ is extremely hard to use for any more complex apps which should be perfectly doable according to documentation.  In my case I have to disable maps on all CIQ 3.1 devices until the problems will be solved leaving my users confused again. Disappointed

Jan Čapek
Parents
  • over 5 years ago in reply to Jan Čapek

    Looks like it is at least partially fixed.  I'm able to use setMapView to change the zoom on the fly.  The tracks are updating for the most part although on this morning walk I did see a case where the map went blank for multiple minutes before continuing.  So this seems to be back to the 3.0 functionality after very brief testing.

Comment
  • over 5 years ago in reply to Jan Čapek

    Looks like it is at least partially fixed.  I'm able to use setMapView to change the zoom on the fly.  The tracks are updating for the most part although on this morning walk I did see a case where the map went blank for multiple minutes before continuing.  So this seems to be back to the 3.0 functionality after very brief testing.

Children
  • over 5 years ago in reply to Jan Čapek

    Hi Jan, this was documented in the SDK Readme > v3.1.0.beta1 > Allow native UI pages to be set as the initial view.

  • over 5 years ago in reply to ekutter-dnu

    Yep, thanks for confirmation.. Dummy page was part of my workaround - I just forgot for all its initial reasons and thought that I can remove it finally.

     Is change of this restriction in CIQ 3.1 somewhere described for public devs please? As usual, can't find anything related in documentation...

  • over 5 years ago in reply to Jan Čapek

    On 3.0, you couldn't have the MapView as your first view.  This has been changed in 3.1.  So in 3.0, if you wanted your main view to be a MapView, you first had to have a dummy view that would just push a MapView.  It's nice that they removed this restriction, but could cause issues on 3.0 devices if you don't deal with it properly.  I've chosen to leave in the dummy view that just pushes the MapView.

  • over 5 years ago in reply to ekutter-dnu

    I wanted to finalise maps implementation for new app version finally and decided to remove my old map screen transition workaround completely even for CIQ3.0 devices. But oh boy, now I am getting 

    Error: System Error
    Details: Native base view is not supported.

    when I am trying to do switchToView to my class which extends MapView on CIQ 3.0.  Oh boy, I forgot to such limitation.. 

    1) I know that switchToView is limited to push only user-defined views, but I am confused here - is this correct behaviour with child class of MapView? :-/

    2) Error is not triggered on CIQ 3.1 and the map is pushed correctly there. Is this new change on switchToView behaviour (so docs is obsolete in this) - can I rely that this will stay to work? 

    Thanks

  • over 5 years ago in reply to Jan Čapek

    I would agree with all the you said. CQI maps clearly were not designed with creating an app that mimicks the user experience of a native app, but rather with displaying a static map in preparation for running a native app.  Hopefully this will be changed with time, although we are going on over 18 months since they were released.

    - Pushing Map Views have definitely become a bit more consistent on 3.1.  That's a good thing. 
    - The flicker almost every time you update the poly line / markers is quite annoying.  In my case, I want real time track, location, and status of the dogs, but have had to add an option for the user to set the update interval if the flashing every few seconds is too annoying.  I already had to have that for 3.0.  I usually set the interval to 15 seconds.  A dog can cover a lot of ground in 15 seconds.
    - The screen going blank for multiple minutes is a bigger issue, and far far worse than it ever was on 3.0.
    - Having no control over the displayed map is a huge issue for a decent user experience.  Relying on how settings were left from the previous user really is unacceptable.  The golf course map being used is a perfect example.  At least with my apps, a user likely won't even notice what the settings are until they've started recording the activity.  So they would have to stop the activity, load an activity they know has the settings they want, and then restart the dog tracker app.  I can't think of any system where that would be considered acceptable.

    When I was adding maps, I considered having maps be either the old bread crumb mode, or use the new MapView version.  Instead I still always have the bread crumb view, but add as an additional page the MapVIew.  Given the current state of maps, I suspect most users would just stay on the bread crumb page.