Failed app crash log

Dreuw over 2 years ago

I am getting an app crash with a datafield.

The field attempts to handle the partially implemented workout step API.

It works with my structured workouts.

It works with suggested structured workouts when accessed via the options at the start of an activity.

It fails with the CIQ error when the same workout is started from the race widget.

Annoyingly, it does not generate a .YAML file as promised:

App Crashes

App crashes typically result in an app quitting unexpectedly or displaying an ‘IQ!’ icon, but does not cause the entire device to crash or reboot. This kind of crash is most commonly due to a bug in an app, though it can also be due to a bug in Connect IQ itself. Whenever an app crash occurs, a CIQ_LOG.YAML file is written or updated to /GARMIN/APPS/LOGS on the device, and contains information related to the crash that app developers may use to address the problem.

This is annoying as this is almost certainly a CIQ crash.

P.S.

These devices have great potential but are continually spoiled by poor software.

We have a font debacle with absurdly tiny fonts when displaying a two data field view.

We have a problem with the editing of structured repeats where the changes do not occur until one leaves the activity then returns.

To Garmin Scrum Masters. AGILE is not an excuse to dispense with software quality assurance. It is just sloppy practice.

jim_m_58 over 2 years ago

If this is happening on a device and not the sim, add some System.println() calls and creat a log file for your app to narrow down what's happening.

See https://forums.garmin.com/developer/connect-iq/w/wiki/4/new-developer-faq#debugging

Dreuw over 2 years ago

Sure, I could do that as if I were tracking down a semantic error.

It isn't very helpful not to provide the crash log as promised though.

I am not asking for help Jim, merely complaining.

Dreuw over 2 years ago in reply to jim_m_58

In the end I went to the trouble expecting little.

These are the outputs of sys.println at the start of each function called by CIQ during the data field's life cycle.

It is broken as expected.

// de nada when run from race app

// run from activity rather than the race app

initialize
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
layout
layout
onUpdate
onUpdate
onUpdate
Compute
onUpdate
Compute
onUpdate
onUpdate
onUpdate
onUpdate
Compute
Compute
Compute
Compute
layout
onUpdate
onUpdate
Compute
onUpdate
Compute
onUpdate
onUpdate
onUpdate
Compute
onUpdate
layout
onUpdate
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute

jim_m_58 over 2 years ago in reply to Dreuw

if it's on the first data screen, try moving it to the 2nd. I seem to recall an issue with CIQ not having a ciq_log on the first. screen. I'm guessing it may involve not null checking something that needs to be null checked.

flocsy🤠 over 2 years ago in reply to Dreuw

I thought that both comoute and onUpdate are called every second, so shouldn't the log look like: compute;onUpdate;compute;onUpdate...?

jim_m_58 over 2 years ago in reply to flocsy🤠

compute is always called every second. onUpdate is only called every second if it's visible on the current data screen.

_psx_ over 2 years ago in reply to flocsy🤠

Note:

The system will call the onUpdate() method inherited from View when a Data Field is displayed by the system. Because compute() and onUpdate() are asynchronous, there is no guarantee that compute() will be called before onUpdate(). For this reason, variables should never be initialized in compute()

flocsy🤠 over 2 years ago in reply to jim_m_58

that still doesn't explan: onUpdate;onUpdate;onUpdate (without compute between them) unless this was in simulator and there were multiple fields on 1 screen

Dreuw over 2 years ago in reply to jim_m_58

OK. I created a new complex data field using the ** default code **, exported the field to my 255 and configured a data screen with this field, but not the first screen. Again it merely shows the IQ app crash icon when launched from the race widget, but runs OK when launched from the run activity. Again, no log file is created.

So this is definitely an IQ bug. No doubt.

Perhaps the sandbox environment for the app is not being set up properly by Garmin when launching from this route? Enough memory??

There is clearly nothing I can do other than not launch a workout from the race app or just not use a custom data field.

So the Garmin bugs so far:

The bug discussed above, failure of custom data fields in activities for structured workouts launched from the race app.

Tiny fonts on 2 data field layout.

Structured repeats does not immediately update if edited on the watch. You have to go back then re-enter an activity for the changes to take effect. (annoying if making changes on the fly just before a track session)

I have also noted that when I export RUN workouts to the 255 from the mobile app it says "NOT SUPPORTED". Despite this, the activity does seem to download to the device (& Interestingly other activities are supported including pilates & yes, I do have a run activity as that is my main sport, and no I do not have too many downloaded)

In my opinion, this number of problems in non-beta software indicates a systemic software quality control problem at Garmin.

flocsy🤠 over 2 years ago in reply to Dreuw

I'm not 100% sure it's CIQ bug. It is possible that the order of the first calls to your functions is different in the 2 cases and the bug is in your code, because you don't initialize something in one of the cases. If you try to use another CIQ datafield the same way, then what happens?