Simulator Fidelity

I understand the difficulty in providing good fidelity simulation with such an annoying plethora of devices but whether I can understand the difficulties or not the end result is still painful. I have recently written code to download workouts from a third party site. I re-invoke the original web request method on failure reported in the callback. Fine in the simulator. Not allowed on the device. Hours wasted. I now realise I need to poll a state machine to do achieve what is needed with a timer invoked method. But timers are not what they seem as they are not reliably garbage collected when stopped and no longer referenced. It is a recipe for the too many timers error. When these issues are added to the "error invoking <symbol>" with no stack trace and flaky in-line debugging developing becomes a pain. These issues have been around for years now. Do Garmin ever feel a little embarrassed about this underperformance when compared to the toolchain available for Watch or Wear OSs?

0 flowstate over 4 years ago

I couldn't agree more, but around here you'll get nothing but the standard reply of "the simulator is not an emulator."

Never mind the fact that more than developer has made complaints to the effect of "I can't afford to buy all the devices (*) to test my app properly". (* Yes, I realize that that there are groups of devices that are effectively identical for the purposes of development, but there's still a lot of "device families".)

0 jim_m_58 over 4 years ago

Sound to me you have limited experience with CIQ, and are doing things based on assumptions. There is no GC in Monkey C for example

Also your design doesn't really need a bunch of timers. What you want is a single timer, that controls the other functions. Even advancing your state machine.

You do realize you are posting in a place where folks have developed 100's of other apps, right?

Ask for help with your code. There are many here that will assist!

0 jim_m_58 over 4 years ago in reply to flowstate

"the simulator is not an emulator."

What's kind of sad is you don't understand what that means.

A simple example. Start a widget for say the 935 in the sim, and go to bed. When you wake up it will still be running.

But in the real device, it will time out in 1-2 minutes and close. The sim does not emulate the real device,

0 flowstate over 4 years ago in reply to jim_m_58

jim_m_58 said:
"the simulator is not an emulator."

What's kind of sad is you don't understand what that means.

I actually do understand what it means, but thanks for your concern.

There's a big difference between:

A) Understanding a fact

B) Believing that said fact is the ideal state of affairs

jim_m_58 said:
A simple example. Start a widget for say the 935 in the sim, and go to bed. When you wake up it will still be running.

But in the real device, it will time out in 1-2 minutes and close. The sim does not emulate the real device,

Great example!

What does it have to with the OP's statement?

Dreuw said:
I understand the difficulty in providing good fidelity simulation with such an annoying plethora of devices but whether I can understand the difficulties or not the end result is still painful.

I was simply pointing out that any time a dev complains that the simulator doesn't behave in a way that closely corresponds to reality (especially with respect to behavior that varies across devices), they can't expect to get any sympathy on these boards. And I was right.

0 jim_m_58 over 4 years ago in reply to flowstate

More proof you don't understand.

The widget example proves it.

0 flowstate over 4 years ago in reply to jim_m_58

jim_m_58 said:
More proof you don't understand.

The widget example proves it.

Sure, if you say so. Believe me, I understand the concept that "the simulator is not literally running the same device firmware code that runs on a real device". I know what an emulator is.

I just don't agree that your widget example and the OP's example are the same kind of problem. They may have the same root cause ("the simulator is not an emulator") and they may have the same outcome ("just test on the real device noob"), but they're not the same kind of problem from a practical POV, in my subjective opinion.

Unless you think "widget doesn't automatically close in simulator like it does in device" and "function succeeds in simulator but fails on device" are the same kind of problem, from a practical POV. It's subjective, but I don't think they're the same kind of thing. At least the widget timeout is a system-wide thing that should be noticeable to anyone who's used widgets on their watch for any extended period of time. Having a specific api call succeed in the sim but fail on the device (for whatever reason) is a much more specific and unexpected failure. In my subjective opinion.

As a matter of fact, nothing stops Garmin from simulating the 2 minute widget timeout, if they wanted to. As you have argued, this would make widgets harder to test. I would argue that it would avoid surprises for devs who are unaware of that behavior.

I happen to like the principle of least surprise, but I can't speak for anyone else.

jim_m_58 said:
There is no GC in Monkey C for example

Are you sure you know what garbage collection is?

https://forums.garmin.com/developer/connect-iq/f/discussion/6257/garbage-collection-in-monkey-c

Travis.ConnectIQ wrote (emphasis mine):

MonkeyC uses reference counting. When an object is allocated, it gets an initial reference count of 1. When another reference is made to that object, the reference count is incremented and when a reference goes out of scope the reference count is decremented. When the last reference goes away and the reference count goes to 0, it is deallocated automatically.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Reference counting

Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero. An object's reference count is incremented when a reference to it is created, and decremented when a reference is destroyed. When the count reaches zero, the object's memory is reclaimed.^[7]

0 jim_m_58 over 4 years ago in reply to flowstate

You seem to like dancing! Reference counts are not the same as GC.

0 flowstate over 4 years ago in reply to jim_m_58

jim_m_58 said:
You seem to like dancing! Reference counts are not the same as GC.

It depends on what definition of "garbage collection" you use.

If by "GC" you mean "tracing garbage collection", then no, reference counts are not an example of that.

If you mean garbage collection in general, then reference counting is just another form of garbage collection.

In the context of the OP's post I assumed they meant garbage collection in general, but perhaps I was wrong about that.

0 jim_m_58 over 4 years ago in reply to flowstate

It depends on if you understand Monkey C or you don't.. Have you even worked in the underlayer of anything that does GC? I have.

Where did you get a comp sci degree?

0 Dreuw over 4 years ago in reply to jim_m_58

Twoddle. Years of experience in CIQ and other platforms. Either you don't understand my post or choose to ignore its content.