Robot should not be restarted in onStart()

[Windwoes]

Currently onStart() in FtcRobotControllerActivity contains the following, which restarts the robot:

    // If we're start()ing after a stop(), then shut the old robot down so
    // we can refresh it with new state (e.g., with new hw configurations)
    shutdownRobot();
    updateUIAndRequestRobotSetup();
    cfgFileMgr.getActiveConfigAndUpdateUI();

The comment indicates that this is intended to restart the robot if the user edited the hw config. However, by putting this in onStart(), the robot is restarted in many other cases. For instance, simply opening the About activity and returning to the main activity triggers a restart robot. Also, I frequently run with the screen of the RC off during testing to save battery, and whenever the screen is turned back on a restart robot is triggered.

If the intent really is to restart if the hw config has been changed, then this code should be moved to the if (request == RequestCode.CONFIGURE_ROBOT_CONTROLLER.ordinal() block inside onActivityResult(). However, this will still restart robot even if the config hasn't been changed. To fix this, the result code returned by the configure activity should have a value to indicate whether save was ever clicked during the course of user interactions.

[gearsincorg]

Also, I frequently run with the screen of the RC off during testing to save battery, and whenever the screen is turned back on a restart robot is triggered.

Funny, I had often wondered why this was the case.

For the longest time I assumed that if the screen was blanked, the opmodes would not run, but clearly this is not the case. It does seem that the robot restart is performed as a default cleanup under a lot of situations. Possibly a few too many.

[Windwoes]

For the longest time I assumed that if the screen was blanked, the opmodes would not run, but clearly this is not the case.

Yeah it goes against what might seem logical. The reason that the OpModes, networking, etc. continue to work even when the app is not in the foreground is because all of those core routines are run inside of a Service, rather than in the context of an Activity.

[TimVargo]

To fix this, the result code returned by the configure activity should have a value to indicate whether save was ever clicked during the course of user interactions.

This would be good, but an even better solution would be to evaluate if the CRC of the HW config file has changed during the course of user interactions. This way, no restart will occur even if the user enters edit mode, makes no changes, and clicks save.