Auto migration and jungles

I would expect it to, as it's just taking what's built for the va3 and using that for the va3m. It doesn't rebuild the app.

That sounds good.

And where can we find information about which device will serve as base for the new device?

Before Garmin launched the Vivoactive 3, they gave us the hint to port our apps to the Approach S60, implicitly saying that a similar device was on the way. Then the auto-migration made the apps for the Approach S60 compatible with the Vivoactive 3. But the Approach S60 has more buttons, what might potentially change the user interaction. An app for the Approach S60 could become useless for the Vivoactive 3. That was an unsafe migration, in my point of view.

I really like the idea of auto-migration, but for reasons like the one above I do not trust it so much now. And I think it should be better documented and communicated. (e.g. let developers know which rules will be applied for resources override by the "XYZ 6S Plus" when auto-migration takes place).

Cheers!

There are other differences between the va3 and S60, including the S60 doesn't have a baro, sensor history, etc, and for apps where there is a difference for things like that, I turn off auto-migration. Same for apps with the semi-rounds, because 3 are CIQ1 and 1 is CIQ2, which was a problem for a couple of mine. The migrations seem to be based on screen layout (round/semiround,etc)/resolution and common fonts.

will auto-migration include resource-touch for the vivoactive3m?

Auto-migration doesn't re-build your application for the new device. It simply re-packages the existing .IQ file, associating the .PRG file for the base device with the new device.

The auto-migration should always be done in a way that ensures compatibility. The screen shape, screen dimensions, and font sizes are big concerns, but input availability is a concern as well. It would not make sense to auto-migrate from a device with 5 buttons to one with 3; chances are good that applications would expect all 5 buttons and that would break. But going the other way would be allowed.

Travis

This is what I expect, but Garmin migrated apps from the Approach S60 to the Vivoactive 3, which goes against that principle.

But ok, this is in the past and doesn't bother me now.

Another issue that happened a couple of times, and I find more important: I often get reports from users of newer devices saying that the migrated app doesn't work. Example:

https://apps.garmin.com/en-US/apps/4d598437-2092-4d76-b058-f9e4df8d567d

(Read the review from a Fenix 5X Plus user. I had received an email from another Fenix 5 Plus user as well).

I have not uploaded a version to support the F5 Plus series; it was auto-migrated.

The app works fine in the sim (even when I added support to the new devices), on my Fenix 5S, on my Vivoactive HR and (I believe) on all older devices.

It is a relatively simple app. The code is the same for all devices. No jungle or annotations. Just in-line checks on the screen size and shape. I'm 99.9% sure that the issue experienced by the user is not due to a problem in my program.

Maybe an important information: it makes image requests. I think it was also the case when I received similar reports in the past. In most cases, the request results in response code 0 ("unknown error").

I'm sorry, but I really feel there's something wrong with app migration. Or maybe a recurring problem with the firmware of all new devices when they are launched. I honestly think Garmin should take a look at it. It's pretty annoying to receive those reviews.

PS: I will not update the app to "fix" the problem. I hope Garmin uses it as a "case study" ;-)

Could it be that the firmware on the plus device has a bug and that the auto migration went fine? Something with image requests?

I can't see which app, as the url in your post has dots in it, and is missing digits. (it starts with 4...8 for me)

Maybe send the user a sideload built for that device and see if the problem still occurs...

Sorry for the broken link. Here it is:

https://apps.garmin.com/en-US/apps/4d598437-2092-4d76-b058-f9e4df8d567d

Could it be that the firmware on the plus device has a bug and that the auto migration went fine? Something with image requests?

This is what I said:

...Or maybe a recurring problem with the firmware of all new devices when they are launched. I honestly think Garmin should take a look at it. It's pretty annoying to receive those reviews.

A bug was recently discovered that causes a device to be in an odd state causing any makeWebRequests to retrun -2 and no data. A reboot fixes this.
could it be that the plus device is coincidentally in this state and the makeImageRequest fails in similar fashion?
I’ll test it on my plus device.

EDIT
=====
As per this thread, I have managed to reproduce the odd state on couple of my devices.
I tested a modified version of the test app (from this thread) that uses makeImageRequest, and I can confirm that it is also affected by this bug.
I do not want to restart my plus device in order to test your app, as it takes a long time (24 hours) to reproduce the state, and I still need this state for testing a couple of my own apps.
I'll ask someone to verify your app on a plus device that has been freshly restarted.

Friend confirmed your app on a plus device gives a different error from what I have reported in my previous post, so you can disregard that post.

I believe there is a bug affecting makeImageRequest on Fenix 5 Plus models at this time. A fix is being worked on. I think this will be corrected via a Garmin Connect Mobile update.