Is there any way from monkeyc to test if the program is running on the simulator or on real hardware so I can initialize some data differently?
Thanks,
Dave.
I wonder if System.getDeviceSettings().uniqueIdentifier is constant and unique for each installed simulator. Or is there already another solution except conditional compiling?
I like FlowState's ingenuity, but I think the idea of the person asking the question is not a bad idea...
wonder if System.getDeviceSettings().uniqueIdentifier is constant and unique for each installed simulator.
...not a bad idea at all.
I haven't tested it, but the unique id should be constant for the instance that runs in the simulator on the same device (pc/macintosh/unix box) (but it will differ for each app).
So it will be a matter of defining a constant in your app once you know what the uniqueidentifier is for the app while running in the sim. And then compare it in your "isSimulator" function that you create.
Interesting idea. You would still need to add every new device to the constant, but I guess the problem that your app will think it runs on a real device for the first time you run it in the sim is not too big.
The disadvantage is that you also will need to do this for every app, which makes it not scaling well.
Where was this tested? Mac or Windows? From my (very limited) experience with Windows tricks like this sometimes don't work the same way.
Regarding the detection of the TZ/DST bug on the device:
it's not a Windows, Mac or linux-specific "trick", the behaviour in the simulator is correct because the sim uses the OS's time and date functionaity and because a normal operating system is able to apply DST rules correctly (based on the given date, not today's date), while behaviour on a real Garmin device is broken because Garmin's logic (for Gregorian.info(Moment)) is to always apply DST rules based on today's date, even when asking for info about a different date. The fact that Gregorian.info(LocalMoment) works correctly on a real Garmin device should demonstrate that even Garmin realizes this is a bug.
To be clear, the bug is this: on a real Garmin device, if I pass a Moment with UTC time for a calendar date other than today into Gregorian.info(), which gives local time based on the device's location, the device applies DST rules for today instead of the specified date. This does not happen for when passing LocalMoment into Gregorian.info(), which gives local time based on the location specified in the LocalMoment. This also does not happen on any sane operating system or embedded device which has support for TZ rules (I've tested Windows, MacOS, linux, SteamOS, iOS, Android, etc.) The OS doesn't even have to support historical TZ rules - if only one set of rules is available, they'll be applied to past years, which is still more acceptable than always applying the rule for today's calendar date.
Again, I said it was a terrible way of detecting the sim, because it requires that the sim and any potential device you want to check are both located in a jurisdiction which switches between DST and standard time. So it would be no good if you or a potential user lives in China, for example (where it's standard time all year round). It's really only good for your own personal testing if you live in the right place.
Honestly, I shouldn't have bothered to post it.
I think the idea of using isAppInstalled() with a placeholder app is a lot better, but it won't work with CIQ < 3.2.
wonder if System.getDeviceSettings().uniqueIdentifier is constant and unique for each installed simulator....not a bad idea at all.
Yeah, this idea is is the best one since it would be supported for CIQ >= 2.4.1 and doesn't rely on a firmware bug / or sim/device location.
You would still need to add every new device to the constant, but I guess the problem that your app will think it runs on a real device for the first time you run it in the sim is not too big.
You're assuming that Garmin went to the trouble of making the sim look like a unique "device" [*] (for the purposes of uniqueIdentifier) for every distinct device type that can be run in the sim.
But if you build the same app for a different device type, the uniqueIdentifier in the sim doesn't change. I tried it (at least for a few device types) on Windows and Mac. It doesn't change if you change the SDK version, so it's not unique per "installation" either. It's different for the same app ID on different computers though.
My guess is that for the "device" part of uniqueIdentifier, the sim would just use something constant on your computer, like a mac address.
IMHO you contradicted yourself:
it's not a Windows, Mac or linux-specific "trick", the behaviour in the simulator is correct because the sim uses the OS's time and date functionaity
That's exactly what I meant when I asked whether you tested this on Wiondows. I'm not sure how it is these days, but in the far past I know it usually ran the CMOS clock in local time instead of UTC. And even today I often see strange things in the company slack and calendar (they sometimes display strange timezones for people sitting 2 meters from me). So BECAUSE this uses the OS date functions it MIGHT depend on the OS that you use.
First off, I am deeply sorry I even mentioned the tz bug, since it's not a good way to detect the sim vs the device at all, unless you live in the right area and you are only doing personal testing. (Or you can assume that all your users also live in the right area, which is quite frankly a ridiculous assumption)
Just a huge mistake and a waste of everyone's time.
IMHO you contradicted yourself:
Well, in *my* opinion, I didn't contradict myself at all, because I have strong reason to believe that this stuff (calculations related to date/time/tz) works properly on all the widely-used OSs, including Windows, Mac, and Linux (see below). And for the record I tested the bug (or its non-existence) on the sim for both Windows and Mac.
Luckily it was just your "humble/honest opinion". Btw, imo prefacing everything you say with "IMHO" only lessens the impact of using "IMHO" in the first place. imo, the "H" in IMHO is extremely played out, since if you mean "humble", it's disingenuous/meaningless (especially if it's said *every* time), and if you mean "honest", it's implicitly understood.
imo, while IMHO may be appropriate here (it is your opinion), it is not synonymous with afaik (as far as I know), which imo, is far more appropriate in the cases when talking about a fact, not an opinion, that one may be unsure of. e.g. "afaik, properties and storage both persist data when the app exits" (a statement of fact which one is unsure of, and happens to be incorrect.)
imo, "IMHO" is just a really cheap and played out way of saying "no offense" or "I'm not sure" or "don't hold me to this". Then again, tbf "imo" and "afaik" aren't really much better.
Once again, perhaps I did not communicate properly, but my point is that I know that Windows, Mac and Linux all work properly with regards to calculating time zone offset for a date other than today. They use the rules for the calendar date you asked for, not for today's date. Every sane OS/device works properly. Even Garmin works properly when you use a LocalMoment instead of a Moment.
How do I know?
- I tested the general behaviour (not specific to Garmin) - of how UTC is converted to local time, for a different date than today - in Windows, Mac, Linux. This can be tested by writing a simple C app, for example
- I also looked at how iOS, Android, and other embedded devices work with timezones and date/times even more generally (without writing a test app)
- I tested the specific behaviour (Garmin tz bug, when converting UTC to local time, for a date other than today) in the Garmin sim for Windows and Mac, as well as on real devices. The sim in Windows and Mac works correctly (as expected) and the real devices do not.
I have also worked irl with dates, times, and time zones in embedded systems (Linux) and web apps [*] - but who hasn't? I know how this stuff is supposed to work. ime, the most common cause of date/time/timezone issues is mistakes made by app devs (e.g. subtle bug caused by incorrect assumption), not egregious bugs in the big OSs or standard libraries. [Yeah, Garmin is an exception here, but they didn't use a standard, widely used OS, they made their own, as far as we know.]
[* note that when you write front-end code that runs in a web brower and uses standard date/time/TZ functions, it's expected to work consistently across all OSs that the browser supports - e.g. windows, mac, linux, ios, android, steamos, etc. this would be tough if the OSs in question could just make random implementation decisions about handling dates and times in standard library functions]
I am also pretty sure that the Garmin sim clearly uses OS functions for this stuff, as it reflects changes in the system timezone (for example).
Furthermore, I think that intuitively speaking, if I ask you "What was the local time in New York City on December 1st, 2021 0800 UTC?", to perform that calculation, you should apply the DST rules for December 1, 2021 (if available), and failing that (i.e. lack of historical TZ/DST data), apply the rules for December 1 (no year specified). What you should never do is apply the rules for March 21 (today), because the question isn't about March 21, it's about December 1.
Even Garmin agrees with me, as their implemention for Gregorian.info(LocalMoment) works, it's just Gregorian(Moment) that doesn't work.
[1/x]
I'm not sure how it is these days, but in the far past I know it usually ran the CMOS clock in local time instead of UTC.
Irrelevant. If you really care, at some point, Windows gained the ability to work either way (with RTC/CMOS clock set to UTC time or local time). (It's controlled by a registry setting in Windows.)
If you were dual booting between windows and linux, it was recommended to put Windows in the RTC = UTC mode (to match Linux), in order to prevent the RTC clock from being changed every time you booted to a different OS and it synced time with the internet.
Also, in the past DOS and old Windows used local timestamps for files instead of the UTC timestamps but that really doesn't matter either
The standard date/time/tz functions don't need to know anything about how the system clock / RTC is implemented. They just need a source for UTC time and local timezone info that's correct, regardless of implementation.
And even today I often see strange things in the company slack and calendar (they sometimes display strange timezones for people sitting 2 meters from me). So BECAUSE this uses the OS date functions it MIGHT depend on the OS that you use.
Yeah good thing I tested the Garmin sim on Windows and Mac, and I'm fully aware of how it's supposed to work (in general) on linux.
Garmin is the only vendor I have ever seen which supports DST / time zone rules, yet applies them to today's date rather than the date you asked for.
Different OSs and apps can have different quirks, but this behaviour is pretty basic. There's both common sense rules and international standards regarding how you calculate local time from UTC, based on time zone / DST rules.
Also, when you test this stuff using C standard library functions (or js browser functions), for example, the behaviour is supposed to be consistent across different platforms.
After all, the main point of all of this stuff is for geographically-separated computers to talk to each other over a network. That wouldn't work so well if every implementation of this stuff was just randomly determined.
[2/2]
