Before I ask the next one, please inform me if thi...
# compose-wear
b
Before I ask the next one, please inform me if this is not the right place for these questions. I am trying to add a complication and glance tile for my app. Each of those would have the same logic: 1. get the location 2. do a network request with the result 3. update the complication/tile My main concern is that the get location from FusedLocationProviderClient is not synchronous, so 2 and 3 are in addOnSuccessListener. I am looking for some directions in how this is supposed to work. Currently I am trying to start a Worker to get the location and do the network request and then somehow this one should request an update on the UI. Is this the right way?
j
Yeah this isn't really the right place to ask as this channel is dedicated to Compose for Wear OS. But that said we can probably get you some answers anyhow. For complications you could look at the new placeholder support that they have added to return a placeholder while you wait for your async requests to complete - then return the data on the next
onComplicationRequest
call
1
For Glance given this is a new and evolving API I am not sure - but @Jamie Garside [G] might know
There isn't another slack channel that I know of - @Kseniia Shumelchyk where is the best place for these types of questions?
k
Right, this channel is only for Compose for Wear OS. @Bogdan C If you’re in Android Study Group Slack than there are two channels - one #android-wear-tv-auto where you can post any Wear OS related question and another #glance-wtf for Glance API (both for widgets and tiles). Alternatively, good old Stack Overflow. Googlers sometimes answering questions on both, but that’s based on available people’s bandwidth, and as usual you may also get help from community experts.
b
@Kseniia Shumelchyk Sadly, I am not in that group. I will try SO, but since these WearOS features are so new, I doubt there are many there who can help
k
Let me check with few folks if ASG will accept new members. Meanwhile can you please DM your email used for Slack (for invite)?
y
Isn't there #glance?
When I've tackled this I did as you suggested. A worker to request data, update it a local store (room, prefs data store?)
👍 1
Then send update signals for both tiles and complications. It works well. You definitely don't want tiles or complication updates timing out waiting for variable delay of slow async operations.
👍 1
j
Yeah, there's #glance for Glance related quiestions 🙂
👍 1
k
@Jamie Garside [G] apparently there are two Glance channels - are you in ASG as well?
j
I'm not in ASG, sadly
t
I am starting to make an app for watch and would be nice to have a place to follow discussions and make questions about wear. How can I join ASG?
y
If you have some Wear questions, you do have the right audience here, particularly if compose related. Which surfaces are you building for (app/overlay, tile, watchface, complication etc)?
t
It's an app, but my question is more about architecture in general, what's the best approach to share stuff between my app and the watch as they basically do the same. I'm trying to migrate to a common module at the moment, but as it's not really related with compose I guess it's not the right place to post questions
y
No that is very on point.
You should be able to share a common domain model, remote API (Retrofit?) and local repositories (Room?).
But with a different implementation of your UI layer, even if you have Views on mobile, with the clean architecture you can reuse those common layers across multiple targets.
The extreme of this is probably sample projects by @John O'Reilly which are Kotlin Multiplatform, like https://github.com/joreilly/StarWars/ and https://github.com/joreilly/PeopleInSpace/
t
That should be exactly my case, so I guess it can work. Thanks for sharing all these resources!
y
In StarWars, a common Apollo GraphQL API layer with local caching is used across wear, mobile and other platforms. Not saying you should dive into KMP, but it shows what is possible.
❤️ 1