Complication Update

[Philoul]

Test to improve consumption

[sonarqubecloud]

Quality Gate failed

Failed conditions
16.5% Duplication on New Code (required ≤ 4%)

See analysis details on SonarQube Cloud

[Philoul]

@TebbeUbben can you please review this PR ? (I tried to implement your proposal to fix #3821 for Complication management, but I never use complication on my side and never worked before on complication (so not sure I correctly implemented your proposal...)

@olorinmaia Can you please test this PR and check if it works correctly or if there are issues compare to previous implementation.

On my side I made quick verification (but don't know if it's regression or not...)

• Update of complication is done every 5 minutes (but can be late compare to real update of data). As example for BG Value, time ago is updated every 5 minutes and not every minutes (so you can see BG value with 1' when value has been received 2 or 3 min ago), same for IOB
• If watch is always on, complication is not updated in Ambient mode (update is only done when watch is again in Interactive mode)
• Not sure if code works correctly for Uploader battery and Graphical complication (it seems good but didn't check for long duration...)

[olorinmaia]

I've tested PR one day and compared to another day with latest dev, and I can't see any difference in battery consumption either for watch or phone. I don't have good tools to monitor this, except for what comes with android OS. Complications works like before.

[MilosKozak]

any update on this?

[Philoul]

I tried to implement Tebbe's proposal (not a specialist of complication 😉) but didn't found noticeable improvements concerning watch autonomy...

I didn't made any new version or update since this PR.

[njmo]

my sons battery also drains very fast. Android AAPS used since morning about 47% ( phone working for 7hours), we are struggling to have phone charged whole day, we are using 3.3.2. I don't recall having those problem earlier. And it is not everyday, some days it works whole day and we have 40% late evening, but sometimes in the middle of the day it is dead. Always AAPS have 50%+ drain in battery info app

[Philoul]

@njmo
This PR is dedicated for users with complication (so not using AAPS Watchfaces).
Can you test this PR and check if watch autonomy is improved?

Note that can build and install only the wear apk and keep 3.3.2.0 running in your phone during your tests.

[njmo]

we are not using any wearable application for aaps. samsung watch is connected to the phone but only for notification purposes

[Philoul]

Will update soon this PR with the 4 additional complications for Ext data...
It seems there is an autonomy improvement with it (one user tested it in discord...)

[TebbeUbben]

Will update soon this PR with the 4 additional complications for Ext data... It seems there is an autonomy improvement with it (one user tested it in discord...)

Hi @Philoul! I appreciate your work on this. Sorry for not being of further assistance as I'm currently a little busy with my degree and private life. I just wanted to add that since updating my Pixel Watch 2 to WearOS 6 / Android 16, the watchface doesn't format the complication correctly anymore (hh:mm instead of x min). It might be required to use dynamic values here instead.

[Philoul]

@TebbeUbben Strange,
Which complication do you use in your screenshot ? (It seems to be LongStatusComplication but when I look at code behind, it shouldn't be (0:02) but (2')

AndroidAPS/wear/src/main/kotlin/app/aaps/wear/interaction/utils/DisplayFormat.kt

Line 41 in 937e2bc

fun shortTimeSince(refTime: Long): String {

Could you also share me the watchface used (I don't have Watchfaces with TYPE_LONG_TEXT complication available...) to let me test it on my watch ?

I would appreciate a quick review of my implementation of your proposal in this PR (I'm not a specialist of complication, so I tried to understand and adapt your code, but not sure I did it the right way...)

[TebbeUbben]

@TebbeUbben Strange, Which complication do you use in your screenshot ? (It seems to be LongStatusComplication but when I look at code behind, it shouldn't be (0:02) but (2')

AndroidAPS/wear/src/main/kotlin/app/aaps/wear/interaction/utils/DisplayFormat.kt

Line 41 in 937e2bc

fun shortTimeSince(refTime: Long): String {

Could you also share me the watchface used (I don't have Watchfaces with TYPE_LONG_TEXT complication available...) to let me test it on my watch ?
I would appreciate a quick review of my implementation of your proposal in this PR (I'm not a specialist of complication, so I tried to understand and adapt your code, but not sure I did it the right way...)

As far as I can tell, your PR correctly implements the TimeDifferenceComplicationText. And you’re absolutely right: I’m using the LongStatusComplication. The reason you don’t see the faulty formatting in the AndroidAPS code is that I’ve modified it to use a TimeDifferenceComplicationText.

In the standard AndroidAPS setup, the app acquires a WakeLock every 15 seconds to update the complication, which keeps the watch from going to sleep. The idea behind using TimeDifferenceComplicationText was to let the watch face handle the time difference calculation and formatting on demand, rather than forcing constant updates that drain the battery. Please see ##3821.

However, it seems that Wear OS 6 broke the formatting for this complication type. So, we may need to switch to the newer and more flexible “dynamic text” complications instead.

[sonarqubecloud]

Quality Gate failed

Failed conditions
11.8% Duplication on New Code (required ≤ 4%)

See analysis details on SonarQube Cloud

[Philoul]

PR updated with the 4 additional complications for External data.