When we call 'dataClient.getDataItem(xyz).await()'...

# compose-wear

[Arjun Achatz]

When we call 'dataClient.getDataItem(xyz).await()' do we need to call release on the 'DataItemBuffer' item that gets returned once we're done using it ?

[Hardik Khandelwal]

Based on the API documentation: https://developers.google.com/android/reference/com/google/android/gms/wearable/DataClient#public-abstract-taskdataitembuffer-getdataitems-uri-uri

Callers must call AbstractDataBuffer.release() on the returned buffer when finished processing results.

Hence you should release the items.

[amoledwatchfaces]

I don't know why but DataLayer / WearableListenerService is so unreliable for me with the latest Play Services. Works good only with Bluetooth turned on. (Galaxy Watch4)

[yschimke]

BT is usually on when available, so you will have a persistent connection. You should assume when BT is not available and you are on Wifi/LTE that you only occasionally have a network. I'm not sure it's what you are seeing, but expect more delays when not on BT.

[amoledwatchfaces]

I'm using it for simple communication, send request to phone, phone sends phone battery back to watch. I'm using setUrgent and also sending system.currentTimeinMillis to ensure every data sending task is different (I assume this is needed for listener to receive event)

[yschimke]

Is it just delay/unpredictable behaviour, or does it never arrive?

[amoledwatchfaces]

Arrives when I enable BT. With Wifi / Data it acts unpredictable. Sometimes works, sometimes not at all. I thought that this was an issue of the previous Play Store Services (23.07.14) but this behavior seems to appear back with every other Play Services update

[amoledwatchfaces]

I'm on latest 23.12.13 (both phone / watch)

[amoledwatchfaces]

What's even more interesting, same build works fine when I use signed apps installed via adb (sending and receiving messages instantly) but when I upload it to the internal test, it only works via BT

[amoledwatchfaces]

Discard. Must be an issue with my watch. It works instantly on emulator / Fossil Gen 6 with same Play Services version. So the issue must be on Samsungs end. Anyway, should I use AbstractDataBuffer.release() in my code?

[louiscad]

@amoledwatchfaces Yes you should

[amoledwatchfaces]

@louiscad I'm asking because in the link above, it's only mentioned under DataItemBuffer and in my code, I'm only using DataEventBuffer

[louiscad]

Oh, then it shouldn't be needed unless you are using the objects beyond the callback (in which case you should also call freeze() first and foremost) @amoledwatchfaces

[amoledwatchfaces]

@louiscad So using it like here, only inside onDataChange, should be fine, yes?

[amoledwatchfaces]

IMG_20230408_140558_195.png

[louiscad]

Should be fine

[amoledwatchfaces]

Thanks 🙂

[amoledwatchfaces]

@yschimke now experiencing the same also on emulator / Fossil Gen 6. Interestingly, everything works instantly fast with signed apk. When I upload same build (aab) to the internal test, apps cannot communicate via WiFi or mobile data. Maybe it's something which needs to be excluded in the build.gradle?

[amoledwatchfaces]

Based on logcat, wearable service datalayer send task finishes correctly but mobile WearableListenerService is not responding

[Arjun Achatz]

Yeah I find this happens as well; can you try wiping the emulator, starting it back up, install your app fresh, and then see what happens?

[amoledwatchfaces]

@Arjun Achatz I'm using wear os emulator and it is connected to my phone. I think the mobile part is the problem because I'm pretty sure watch app is sending data task successfully. I'll try two emulators then. Any Idea why everything works fine when I install signed apks but not work when I upload aabs to the internal / public release?

[Arjun Achatz]

I also use a wear emulator paired with a physical device. The same thing happens to me every now and then and it drives me bonkers.

What I meant was could you wipe your wear emulator and install the app fresh, and then see what happens

[amoledwatchfaces]

Ok, going to try that

[amoledwatchfaces]

But should I install release from play store? Because when I install both apps with adb install, they will communicate just fine.

[amoledwatchfaces]

@Arjun Achatz So, it works now. So the wearable is completing sending task but actually does not send any request?

[amoledwatchfaces]

Isn't this some bug / error within Wear OS or Play Services?

[Arjun Achatz]

It's definitely something 😅 @louiscad ^

[amoledwatchfaces]

@Arjun Achatz @louiscad wiped also Galaxy Watch4 and communication works fine too. We can't expect from users to do this. When this error occurs it's basically impossible for user to use our apps when their device are not connected with BT. I'll try to wipe cache / force stop play services on my Gen 6. If it helps, then it's definitely some issue between Play Services Updates (Wear OS)

[Arjun Achatz]

Not sure who the right person is but we definitely need to escalate it. Maybe you can report it as an issue ?

[yschimke]

Definitely report an issue, even if you found a workaround, it should obviously work without such effort.

[amoledwatchfaces]

@yschimke I'm new to this. Should I use Google Issue tracker page?

[yschimke]

This isn't exactly the right link, but this is probably the best place to start. https://developer.android.com/jetpack/androidx/releases/wear#feedback

[amoledwatchfaces]

Thanks 🙂

[Yingding Wang]

I always check the available node from CapacityClient, before i send any data between the wear and android apps. I will inform user to reconnect BT. Sometime, the connection just lost.

[amoledwatchfaces]

Problem is that the node is actually connected. Not nearby, but definitely connected because I even can remotely open play store app on it. (remote activity helper). Also, we're talking about devices connected with WiFi/ mobile data. Via BT, everything works fine