-
-
Notifications
You must be signed in to change notification settings - Fork 959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Airplane mode feature (redesigned) #888
Conversation
Implements 'Airplane mode' feature to disable and enable bluetooth/ble Adds airplaneMode as a non-persisted setting Adds a setting menu for switching airplane mode on and off Displays an airplane symbol on the Digital watch face and the PineTimeStyle watch face when airplane mode is enabled Always enables bluetooth/ble on boot (disable airplane mode) Alphabetizes the settings menu options Style cleanups Closes InfiniTimeOrg#632
hi , i have tested the pr and it work great ! the setting order is pretty disturbing at first but become intuitive after two day or so . great redesign @evergreen22 ! i wish that it would be merged by @JF002 for 1.8.0 too ! |
Code looks clean, |
for what i see in the pr action @geekbozu , compared to last dev action github , i'ts around 1k more (maybe related to the new icon ) |
While I think the settings order isn't the best, alphabetizing it is worse. That is my opinion as a mostly regular user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good and seems to work as expected. I can't test if the watch leaks any signals, but it disconnects and can't be found when scanning.
It would be much better to have this option in the quick settings, though that's obviously not possible yet. We should look into reworking that so it can hold more functionalities as they come.
void UpdateSelected(lv_obj_t* object, lv_event_t event); | ||
|
||
private: | ||
static constexpr std::array<const char*, 2> options = {" No", " Yes"}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the "Yes" option should be above "No"
EDIT: Perhaps call it Enabled and Disabled instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree.
I did a HCI/UX paper prototype study to test the following options before selecting this option (n=16):
- Yes/No 56% of respondents performed correctly
- On/Off 25% of respondents performed correctly
- Enable/Disable 19% of respondents performed correctly
Regarding the order, the existing UX displays the default choice first and "No airplane mode" is the default mode. Therefore the order should be "No" then "Yes" for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand what you mean. Do you mean that if a person goes to enable the airplane mode, only 19% would be able to press the correct button to enable it? I highly doubt that is the case. "Airplane mode. Yes/No" doesn't really make sense in a literal sense either.
Having the default option first sounds reasonable, but somehow having "No" above "Yes" doesn't feel right. Unfortunately I'm not able to explain why.
This could also just be a switch widget.
void NimbleController::SwitchAirplaneMode(bool enabled) { | ||
if (enabled) { | ||
if (bleController.IsConnected()) { | ||
bleController.SetConnectState(Ble::ConnectStates::Airplane); | ||
ble_gap_terminate(connectionHandle, BLE_ERR_REM_USER_CONN_TERM); | ||
} else { | ||
bleController.SetConnectState(Ble::ConnectStates::Airplane); | ||
ble_gap_adv_stop(); | ||
} | ||
} else { | ||
bleController.SetConnectState(Ble::ConnectStates::Disconnected); | ||
fastAdvCount = 0; | ||
StartAdvertising(); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather have this be two functions without a boolean parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree. I see no reason to make the code larger.
{Symbols::sun, "Display", Apps::SettingDisplay}, | ||
{Symbols::eye, "Wake Up", Apps::SettingWakeUp}, | ||
{Symbols::clock, "Time format", Apps::SettingTimeFormat}, | ||
{Symbols::home, "Watch face", Apps::SettingWatchFace}, | ||
{Symbols::list, "About", Apps::SysInfo}, | ||
{Symbols::airplane, "Airplane mode", Apps::SettingAirplaneMode}, | ||
{Symbols::batteryHalf, "Battery", Apps::BatteryInfo}, | ||
{Symbols::sun, "Display", Apps::SettingDisplay} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order shouldn't be alphabetized and shouldn't be changed in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @Riksu9000, I'm not sure the alphabetized order is the best one, and I would rather like to see this change in a dedicated PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree. While I concede this may not be an ordering that makes 100% of people happy (does that even exist?), I feel strongly that the aribtrary order is wrong from a UX standpoint because it creates an unecessary cognitive burden on the user.
If we order the options alphabetically now I expect it will kick off a serious, evidence based discussion on how this is best resolved. Folks posting about which option they use the most (FWIW I use "About" the most) is not moving the ball forward and just adding new options in random spots is procrastination.
At the very least, alphabetical ordering is a common, accepted UX pattern for options that is widely understood.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that alphabetical ordering has its benefits. However when changing languages, should the order change according to the used language? Alphabetical ordering isn't common for settings on other platforms either. At the very least this will not be changed in a PR about airplane mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this nice and complete PR (new feature + settings + icon, perfect!).
Could you have a look at the @Riksu9000's and mine reviews?
@@ -2,12 +2,12 @@ | |||
|
|||
using namespace Pinetime::Controllers; | |||
|
|||
void Ble::Connect() { | |||
isConnected = true; | |||
void Ble::SetConnectState(Ble::ConnectStates newState) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should mix "connection state" (connected and disconnected are implemented, and other future states could be "error", "failed", "refused",...) with an "operating mode" (normal and airplane mode).
I think they are 2 distinct concept that should be kept separate :
- ConnectionMode : What is the status of the BLE connectivity : are we connected or not ?
- OperatingMode (or ConnectionAllowed, or something similar?) : Do we accept new BLE connections ?
What do you think?
void Init(); | ||
void StartAdvertising(); | ||
int OnGAPEvent(ble_gap_event* event); | ||
|
||
/* these are not implemented yet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can safely remove those declarations of the methods are not implemented in NimbleController.cpp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't remove them because I wasn't sure if they had any value from a documentation standpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I forgot to remove them a long time ago. They are not needed since these functionalities are implemented is services.
@evergreen22 I have one question regarding this PR : If I understand correctly the changes, the radio is not "physically" switched off. Do you know if there's any chance the radio is still emitting signal when the airplane mode is enabled? Also, what prevents a bonded device from re-connecting to the watch, as a bonded device does not need an advertising packet to be able to connect to the device ? |
I applied the changes I asked for and merged the PR. Thanks @evergreen22 and everyone who contributed to this PR! |
Why is this called "airplane mode"? The watch only has bluetooth, which is nowadays allowed in flights and also actively used. The watch has no cellular antenna either, which does need to be disabled in planes. I relate deactivating bluetooth more with privacy and battery saving, TBH. Anyway, I wanted to bring up #1060, I think there's an overlap in functionality between this PR and that feature request. Mostly, I'd like bluetooth to be turned on after the device boots from an out-of-battery situation. The use case is: I've let it run out of battery and put it in the charging case. When it wakes up, I want it to auto-sync the time with my laptop ASAP, and then turn bluetooth off again. I think this PR is a |
@WhyNotHugo Nobody had thought of that. Renaming it might be a good idea. |
Add airplane mode feature (redesigned)
You turn on airplane mode by swiping and selecting settings, selecting Airplane mode, then choosing Yes. This will disconnect the watch if it is currently connected or cancel advertising if it is not connected. When airplane mode is on you cannot connect to the watch (i.e. bluetooth communications are disabled).
To turn airplane mode off, swipe and select settings, select Airplane mode, and choose No. If your companion app is set to automatically reconnect then your watch will automatically connect.
Note that in both cases, turning airplane mode on and off, the change happens when you close the Airplane mode setting menu (swipe down).
The airplane mode setting is not saved. Rebooting the watch will turn off airplane mode.
In addition, the following style and organizational changes are included in PR:
Resolves #632