I got the same question too. Usually i will just add a condition to check if the feature I want has been turned on or not yet, in this case, condition wifi state.
But looking from the logcat, if the wifi is on, it seems android simply ignore the request. This is the logcat if my wifi is on and I turn it on again using action Set wifi state. It query 4 lines and the wifi stay on, no other events triggered.
Code: Select all
I AM_fz : [App tester] Action 'Set WiFi State: On' enable = true
D WifiService: setWifiEnabled: true pid=2730, uid=10196, package=ch.gridvision.ppam.androidautomagic
I WifiService: setWifiEnabled package=ch.gridvision.ppam.androidautomagic uid=10196 enable=true
I WifiService: acquireWifiLock uid=10196 lockMode=1
I WifiService: releaseWifiLock uid=10196
I AM_e : [App tester] End executing action 'Set WiFi State: On'
If the wifi is off, the logcat is much longer, because it includes much more events that happen when the wifi is on. (a lot of broadcast)
How ever this is the action done when you check the state, much shorter. It only query one line of code to the system, instead of 4 lines when we just use the set wifi state without checking
Code: Select all
2730 I AM_e : [App tester] Start executing condition 'WiFi State: Enabled'
4042 I WifiService: getWifiEnabledState uid=10196
2730 I AM_e : [App tester] End executing condition 'WiFi State: Enabled' with return value true
So yeah, I would say
it is better add condition to check the state first. It require less CPU cycle (assuming each line consume one cycle) if the wifi is on already. If the wifi is still off, we only add one cpu cycle to query the state anyway.
However this my conclusion from the test above. Under the hood, probably it can be different. Let's wait for Martin confirmation about this.