MapTrackView issues - just the simulator or is it the design

Hi there,

Honestly - I was so far so much disappointed that decided to wait till further implementation - hoping - Garmin will implement most important features.

I have to fully agree with you - the major problem I can recognize at the moment is - no way to check from the software point of view - what area is visible, which makes extremely difficult to play with the map... also - including orientation of the map!

At least (as mentioned not only by my in the other threads) method to map screen coordinate to map coordinate would be helpful...

With the current API - it can be used only for classic things like marking something on the map :( - that's not enough.

For the polyline - I was voting to make possibility of adding more than one polyline to the map - what would resolve some other issues. Haven't seen issue with MapTrackView - as difference between simulator and device was even bigger (like - no possibility to change center of visible map).

There was a new beta for device - not yet tested, maybe something was improved there?

I ended up installing the Edge 1030 beta (against my better judgment given the reported issues) to see just how this stuff works on an actual device. There are quite a few bugs in the 1030 beta, like no way to actually bring up the menu or any user input other than the back button. I'm guessing it is known that the 1030 beta has these limitations.

It would be really helpful to have more full documentation on the intended functionality. A simple sample app just isn't enough especially if you don't have any (or more than 1) device to play with. Having the zoom levels per device would be really helpful. Also, are there limits to the number of data points and markers. If I have 400 data points that I set on every OnUpdate, what is that going to do to performance. The tools are too limited to be keeping a track without resetting the polyline regularly, not to mention the polyline interface being too limited to manage the list without recreating it.

After playing with the Edge1030, in MapTrackView it looks like the orientation is heading up vs the MapView that is North up. Doesn't look like this is in anyway configurable, as well as not documented.

I have my own very efficient (speed and memory usage) map path drawing code that I'd like to use. But no way to do that with the current implementation.

With the current implementation (yes I know it's all just Beta at this point), it is extremely difficult to develop an app that takes advantage of the mapping feature with any confidence it will work. Trying to debug it long distance with a user becomes nearly impossible. And I'm not about to go buy a $700 device that I actually don't want (Id be happy to pay $700 for a 935Plus) to develop an app that doesn't make any money.

I've got users requesting support but it will likely be CIQ 4.0 before it really becomes useful. I guess the good news is I could have said the same thing a couple years ago about CIQ in general waiting for CIQ 2.0 to ship. So kudos are still in order for how far we've come.

Since, MapViews are something new, we were speculating on very basic feature to display native map on a view and add some basic usability through CIQ apps. Although we would like more feedback from the usability/new features standpoint to improve the Map api, this is a start.

There have been some discussion on the team to add more functionality to the Map api, I will create a ticket to track this as well.

Thanks Anshul. I'll take that as Garmin being open to input for future developments here. I would actually have rather seen maps added at a lower level where you have a map object that you can draw to the current screen (sort of like bitmaps). The object would have methods that would give you all the info you need for doing your own drawing of tracks and way points and options such as North up vs track up. That would actually have made it pretty easy to extend such an object to the current MapView and MapTrackView with scrolling, panning, etc. By tieing it to the derived view objects, it makes the reverse customization impossible.

One draw back of tieing it to the View objects is that many of us create multi-page apps with a single view object. We manually keep track of which page you are on and have a switch statement for which page to draw. This often ends up simplifying the app rather than a whole bunch of separate view and delegate classes that you have to navigate through. With the current MapView implementation, this doesn't work, as all pages would be based on the same MapView, even those that don't want to display maps. Throwing a single MapView in the page sequence is possible but definitely complicates things.

Nothing necessarily wrong with the route that Garmin took here as it makes it much more trivial to add a basic map page with markers and a polyline and you get the zoomin/pan features for free. But it is limiting if the goal is to unleash the creativity of the CIQ developer community.

Lastly, I just posted my "Dog Tracker Plus" app to the CIQ store that does use the MapView on devices that supports it. I've heard there are some definite flicker issues probably because I'm constantly resetting the polyline, markers, and bounds as the current position and dog positions are constantly changing. I don't have a F5 Plus device but have been able to play with it on my Edge 1030 with the latest beta, although the implementation there seems very limited without the ability to set the polyline and markers.

Regardless, having maps in CIQ apps is a big step forward.

I'm pleased with the possibilities we have for now. I understand the limitations and I'm fine with the decisions that Garmin took (e.g. making MapView an extension of View). Of course we devs would prefer to have more control on what is being displayed, but I also see advantages of this "higher level" approach. For example, having the options such as North up and track up defined by the user in the general settings avoids that each app has its own implementation of the choice. It's clearer for the users and less work for us ;-)


What I have learned so far:
- "refreshing" the map is a costly operation (i.e. clear, setMapVisibleArea, (re)set polyline and markers). It takes a few seconds until everything is redraw, so this shouldn't be performed too often. The simulator gives the feeling that everything is smooth, but in reality it is very slow. (@ekutter : I downloaded your "Dog Tracker Plus" on my F5S+. This is probably why it flickers. I think the right approach is to always ask yourself 'do I really need to refresh the map?'. You can create thresholds for the locations that you want to plot, and only redraw the map if the thresholds are reached).

Bugs and problems I experienced:
- Pushing a menu while a MapView or a MapTrackView was open made my F5S+ to 'freeze'. Actually the menu opened, but when I selected an item, it got stuck. My app is relatively 'heavy' and I didn't test it in a 'simpler' setting (this is why I didn't file a bug report). But it worked pretty fine in the simulator, so I'm sure there's a bug.
- Sometimes the maps do not render at all on a real device. When it happens, it lasts the whole session of the app. No maps can be seen anymore, not even after a "refresh" (i.e. calling setMapVisibleArea, MapView.clear or creating a completely new MapView object). I was running the same code and performing the same steps, but having different results (sometimes it rendered, sometimes it didn't). It seems that having a GPS fix and/or opening the native Map app before opening my app helped.
- The MapTrackView stops tracking my location. I saw the arrow (i.e. me) moving out of the screen (in theory it should always remain at the same position, right?). This happened when the maps stopped rendering.

What I don't understand yet:
- The rendering of MapTrackView. I first thought that the region around the current location would be automatically loaded and rendered. setMapVisibleArea would basically define the zoom level. But after having problems with rendering (mentioned above), I wonder if we need to call setMapVisibleArea periodically in order to load and display the right portion of the map. Or what is the right approach?

--
My suggestions for Garmin:
- Give devs the possibility to read the location chosen by the user in MAP_MODE_BROWSE
- Add an option to let the zoom level of the MapTrackView be automatically set according to the moving speed

(@ekutter : I downloaded your "Dog Tracker Plus" on my F5S+. This is probably why it flickers. I think the right approach is to always ask yourself 'do I really need to refresh the map?'. You can create thresholds for the locations that you want to plot, and only redraw the map if the thresholds are reached).

Thanks for giving the app a shot on a real device. Definitely a hard one to fully develop until I have a fully functioning device. Holding my breath for the 935plus. I had a request from users for adding the mapping support but since I couldn't fully debug it and was having the issues, added the bread crumb versions as well which are probably going to be more useful in the short term (I already had the breadcrumbs code for a private app). The insights into the difference between simulator and real device are helpful. Thanks.

I could easily use a threshold for updating the map bounds (or using the MapTrackView - in the simulator and Edge1030 it wasn't showing tracks or markers), as well as for updating the polyline, but the markers do need to be updated in near real time (every few seconds) as the whole purpose of the app is to see in real time the location and status of the dogs relative to your position. The zoom level usually only shows under 100 meters total so it doesn't take much movement to hit any reasonable threshold. If you have the Garmin Alpha dog tracker, the location and moving status for up to 20 dogs will be shown on the map. My bread crumb view makes it clear what you can get when there is every second real time updates. If the MapView doesn't match, I suspect I'll have some disappointed users.

In the test app I'm using, in onUpdate() for the MapView, I only update things like the polyline and markers at most every 15 seconds (based on time). With GPS, the direction/current location thingy changing means onUpdate can get a bit hammered, so a flicker. That may have been fixed, but I've not tried in a bit.

In the sim, there can be a flicker, as when you change zoom/pan, it doesn't have the map data locally, and pulls it from the web. (a real pain for a few days when my ISP was having problems!)

I've mainly been doing things with a test app I wrote, but do have the mapping in Hike2 for my own testing...

I will say this. Right now, I'm still trying to understand a few things based on what I see on real devices, (and how they may differ right now) that I'm not ready to publish an app. It's getting close!

I've been waiting for this for over 2 years, so I'm glad to see things are getting there!

Jim, thanks for the further insights. I created a brand new version of my app and clearly labeled it Beta. I wanted to get some real world feedback, although it probably is jumping the gun a bit. It's a pretty low volume app since it also requires the Garmin Alpha ($800) to truly be useful. Plus adding the bread crumb page added enough benefit that as long as the app doesn't crash, it'll still adds benefit to people. Hopefully once the Edge 1030 gets better support, that'll be enough to do real world testing. Unfortunately for me, I don't think updating every 15 seconds will be an adequate experience for this app. But maybe between the two pages, MapView for details vs breadcrumb map for real time feedback, that would be adequate.

I currently limit the number of points to 300, trimming it in half when full, and then doubling the minimum distance to add additional points. Have you noticed a point where performance starts to suffer with the number of points?

Like I said, I'm very much in testing mode, but I do limit the points displayed for both breadcrumbs and the polyline. I think I'm at 150 points right now. If I have more than 150, I do every 2nd one, every 3rd, etc. In today's test, I'm keeping the map static (only do the polyline/markers in initialize), and the way to update is to switch to another screen and come back, just to see what I can see.

Jim, have you (or anybody else) experienced the problem that the map stops redendering after you have travelled some distance? (On a real device)

For me it looks like a map tile is loaded to the memory when you start the MapView, but if the user moves out of it, the next tile isn't automatically loaded (not even after a setMapVisibleArea). When I close my app, open the native Map app and then reopen my app, the problem is temporarily fixed.

(* Sometimes the MapView/MapTrackView don't load at all on my F5S+. The native Map app always works, though)