The Sim does not report the location of the error

This is a case where you might want to post some code. Like maybe lines around where the error occurred.

On this occasion it occurred on the line:
userId = Application.getApp().getProperty("userId").toNumber();

when the property was null, but, it occurs whenever a "Failed invoking <symbol> error" occurs.

I noticed this while working on a related feature before Christmas break. I think we can definitely do better here.

I don't know if this is all that similar, but I have also noticed that if you "Reset all App Data", the app will terminate and restart, but it will "disconnect" from the console. So now if your app calls System.println() or crashes, you won't see the normal logs on the console. Not a big deal if you were expecting it, but I was surprised the first time.

On a related note, can we get a way to terminate and restart an app in one step without resetting all app data? This is actually a pretty useful feature. (Unless of course it already exists and I missed it.) I guess if your app is a datafield, you can just discard the activity, but it's not quite the same thing.

I think we can definitely do better here.

I do too.

can we get a way to terminate and restart an app in one step without resetting all app data?

Isn't this what happens if you run the app and it is already running? I've never noticed that it resets app data. Does it?

Isn't this what happens if you run the app and it is already running? I've never noticed that it resets app data. Does it?

I meant in the sim, when you select "File > Reset all App Data".

Sorry I should've clarified that I wish the option was there in the simulator, since the sim can clearly do it when you "Reset all app data".

Yes, running the app from the plugin works, but, as I mentioned elsewhere:
- It's a few clicks to select and run a target with the default run configuration, especially since the previous target is not remembered.
- If you define your own one-click run configurations. they work great, but then you lose the ability to choose any other target on the fly. I don't really want to define 24 separate run configurations for each project. (Realistically I'd usually never test more than 6 "families", but there would be some oddball exceptions to that, especially for touchscreen vs not.)

You also have to wait for the plugin and the sim to work together to convince the app to die, which takes a few seconds and sometimes doesn't work. (Based on my own experience and many anecdotal reports, although it works much better now.)

Selecting File > Reset All App Data is much faster.

Yeah, I'm lazy.

(Then again, until literally today, I was maintaining five separate versions of the same compute() function in one app. >_<.)

I'm confused.

You are asking for a way to terminate and start the app without resetting all app data. You do this by clicking the green/white arrow in the toolbar or pressing Ctrl+F11 in Eclipse. I count that as a single click if you want to run using the same device. This won't restart the app instantaneously because Eclipse has to communicate with the simulator to stop/start the app, but it definitely takes less than 3 seconds. It isn't as fast it would be if we were to just restart the app in the simulator, but that seems plenty fast.

Travis.ConnectIQ I understand what you're saying.

What I'm saying is that currently devs have the choice of:
A) Zero run configurations and they can choose the run target on the fly
B) One or more run configs and they can't choose the run target on the fly. (So you have to create a run config for every single target you want to test, whether or not you test all targets regularly.). I filed a bug report / enhancement request on this, but I'm not sure if anyone looked at it.

In the case of A), if I press CTRL-F11 or click the green arrow (1st click):
- I have to choose between Connect IQ app / Run No evil (2nd click)
- I have to select a target, which is not remembered (3rd click, scroll to desired target, 4th click)
- Press OK (5th click)

Total clicks = 5 clicks + 1 scroll

In the case of B), yes it is one click, but then I have to create a run config for every single target I want to test (regularly or not), for every single project. I tried this and it wasn't worth it, because whenever I wanted to test an oddball device, it was annoying to go create a new run config. Also, your run config list gets pretty cluttered once you have 24 run configs for every single project.

So obviously I've been doing it all this time so it's not the end of the world, I'm just saying I wish there was a faster way.

Please correct me if I'm missing an easier way to do things.

As I suggested before, it would be nice to be able to combine A) and B).
- Let devs create custom one-click run configs, but also have a "default" run config where the device is left unspecified and you can choose it on the fly. If there exists a way to do this already, I'm sorry I missed it
- And in the default run config, please remember the last target chosen!

Maybe it's not a big deal if your app is the same for all targets, but I've made apps that have 6 different "families" or more. It gets worse when you have to test different input methods and screen shapes. My stopwatch app has the following families:
- VA
- 920XT
- VAHR
- 230, 235, 735
- 630
- Fenix 5S
- 645/935/Fenix5/Fenix5+/etc.
- Vivoactive 3/3m
- Approach S60

Each of those "families" is slightly different in either screen size/shape/resolution, fonts, CIQ2/3 support, available memory (Approach S60 is not the same as other CIQ2 devices for whatever reason) or input methods. Even if I wrote code with zero annotations or device-specific logic that somehow supported all of those targets (*), I would still need to test on each family to honestly say I tested properly.

(*) Which is impossible if you want to support CIQ3, or support touchscreens properly, etc.

I don't want to create a different run config for each family. I maybe want to have a couple of frequently used run configs (i.e. not Approach S60) and have a "on the fly" run config where I can just select on the fly. But I can't do that, unless I'm missing something.

I realize another alternative would be to just cut down the list of targets in the app config while I test, so it's easier to select from the list, but I find that to be an undesirable workaround.

For B), I have a single run config for each of my apps. When I want to switch targets, I just select the config for that app, and change the target.It's a couple of extra mouse clicks, but that's it - and easier than having a bunch of different run configs for a single app.

I have a generic run config called "new app" for something I'm just writing, and there I just set the app and the target, and I'm off and running. Again, just a few clicks.