Add "Find my phone" app.

[vchigrin]

This change set adds implementation of client for BLE "Immediate alert service", allowing companion apps get notifications from PineTime watch when requested by user.

Fixes: #343

[vchigrin]

This pull request is result of joint work of @jmlich and @vchigrin, most of the code is written by Jozef (personal contributions can be found by commit history).

[vchigrin]

That is how that app looks like

After user presses "Mild" or "High" button phone starts ringing and vibrating. User can stop this either by pressing "None" button on the PineTime, or by pressing button in GadgetBridge companion app on the phone.

To make this work some changes in GadgetBridge application were required, I suppose to upstream this after ensuring that this functionality will be accepted in InfiniTime.

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	374400B	1584B
data	948B	0B
bss	22584B	48B

[vchigrin]

Corresponding PR to GadgetBridge
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3746

[NitroNils]

And reverse? Find my watch? Make PineTime blink display and vibrate?
Don't know what this would take. Just a logical follow up 😁

[jmlich]

Find my watch already works. It is Alert Notification Service. In Amazfish -> Settings -> Debug page -> Phone Call.
Also Immediate Alert Service is implemented and shows None/Mild/High levels, but this is not right to find watch.

[crazycrystals]

Sorry if its offtopic, but is it also possible to have something like a signal strength indicator so you can see how close the device is and triangulate it?
Doing a ring with an app could be broken by do not disturb.

[jmlich]

The signal strength or more precisely RSSI (Received Signal Strength Indication) is specified/measured in BLE and Nimble can provide the value. I am not sure if it is reasonable reachable in the code.

[devnoname120]

Previous attempt: #1193

[devnoname120]

FYI here are some notes about the limitations of the Immediate alert service standard: #1193 (comment)

[vchigrin]

Well, you have a point. Indeed, using ImmediateAlertService has some drawbacks. Problems you mentioned are not solved here - in this app button returns to original state after timeout in few seconds, there are no any complex communications.

So having this PR and your work maintainers have a choice - either use standard BLE service, having some drawbacks, or develop custom solution, which may give better user experience. I'll be happy with any of these choices.

Or may be this functionality is out of "product vision" of the InfiniTime and it will not be merged - I don't know...

If I can help in any way to bringing this functionality to main branch, let me know, please.

[devnoname120]

@vchigrin As far as I see your approach matches better what they were looking for! And no matter what the UI code will be useful. We will have to wait for @JF002 to chime on this 😊

[vchigrin]

Just noted that corresponding issue at present is the leader by "thumb-up" reactions :)
https://github.com/InfiniTimeOrg/InfiniTime/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@JF002 @mark9064 I'll be very happy to assist with merging this PR. Is there anything I can do to help with review?

[mark9064]

I agree that the BLE spec sucks completely here. Both the IAS and FMP have annoying limitations that makes them kind of useless :(

I think implementing just the IAS is probably our best bet, but we should probably bend the rules a bit and expect the central to keep ringing even on disconnection etc. I honestly have no clue who the IAS is designed for TBH.

As for this PR, I think the UI needs some work. The "None-Mild-High" buttons aren't immediately clear in functionality to the user. Though the specification leaves it vague, I think we could assign more precise meaning to the levels- whether the companion app chooses to do something else doesn't really matter as we don't get to control the meaning of levels anyway. Maybe Stop, Vibrate and Ring? Or maybe we should simplify it to just Stop and Ring (and skip ever sending the mild level)?

(as an aside, I also wanted to remove all client roles from InfiniTime as they're kind of silly but the spec doesn't allow notify either- sending a notification to the central makes sooooo much more sense to me. So that puts a hole in that plan which I'm a little sad about. Oh well)

[vchigrin]

Updated. I've removed "mild" alert since "Vibrate" label is too long for this button size. If you think 3 buttons will be better, I think we should consider emojis/icons...

At present UI looks like this.

PS: There "build-simulator" check fails since simulator repo does not have ImmediateAlertClient class. What is correct way handle situations like this? Should I open PR with necessary changes to simulator repo beforehand?

[mark9064]

I think the two button design looks quite good, what about you?
Not sure if anything should be done with the space above, I'm pretty bad at visual design 😅
Now this PR is feature complete it is a good time to do the InfiniSim PR 👍

I'll try to review soon but things are looking busy- I'll get to it when I can

[vchigrin]

Made InfiniTimeOrg/InfiniSim#165

[mark9064]

I think this app could be improved by some UI rework:

• The app should be aware of whether BLE is connected and whether the connected device supports the IAS. If not, it should show an appropriate message and disable the buttons, otherwise they can be enabled. It should also respond to connection changes, so it'll need a Refresh() method to check the bluetooth conditions continuously and change the UI as needed
• It should maintain state (only while the app is open) - so it should show a message like "Device alerting" after a successful IAS write, and "Alert stopped" after setting the no alert level. On app load since the IAS state is unknown, it would probably be best to display a simple "Ready"/"Disconnected"/"Alert service unavailable" message and replace this message after sending an alert
• Since signal may be bad when using this service, it should explicitly handle message send failures, and report back a different message to when the service isn't present or BLE is unavailable

Other than those points the rest looks good 👍

[mark9064]

Thank you for all the changes, I will try to review them properly soon! Apologies in advance if it takes me a while to get round to it