Draft: TV Casting APIs to recall previously connected TVs/Content Apps and target user/client selected ones #40
Conversation
…arget user/client selected ones
examples/tv-casting-app/android/App/app/src/main/jni/com/chip/casting/TvCastingApp.java
Outdated
Show resolved
Hide resolved
examples/tv-casting-app/android/App/app/src/main/jni/com/chip/casting/TargetContentApp.java
Outdated
Show resolved
Hide resolved
examples/tv-casting-app/android/App/app/src/main/jni/com/chip/casting/TargetVideoPlayer.java
Outdated
Show resolved
Hide resolved
| * @return Read all VideoPlayers the TvCastingApp knows about, from previous connections (may not | ||
| * be actively connected to some/any of them) | ||
| */ | ||
| public native List<VideoPlayer> readAllVideoPlayers(); |
There was a problem hiding this comment.
could we follow same verb for the method above and this one. So either get for both or read for both?
There was a problem hiding this comment.
I used the verb "read" here deliberately to tell the client that we are reading from the app's cache in this API, rather than "getting" the list of video players over the network.
| * @param discoveryFailureCallback | ||
| * @return true, if the discovery request was sent successfully, false otherwise | ||
| */ | ||
| public boolean discoverCommissioners( |
There was a problem hiding this comment.
Will this discover any commissioner or only video players? If only video players does it make sense to rename this to discoverVideoPlayers?
There was a problem hiding this comment.
Sure, I'll update the name to discoverVideoPlayers
| @@ -0,0 +1,13 @@ | |||
| /** a.k.a content app like the PV app on a TV */ | |||
| public class ContentApp { | |||
There was a problem hiding this comment.
For reference : https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-app/android/App/platform-app/src/main/java/com/matter/tv/server/model/ContentApp.java
Looks like all the properties are present. Maybe have a Set for cluster IDs to make clear that they cant be duplicate.
There was a problem hiding this comment.
I am actually using the other option we discussed: that of letting the PV app fetch the attributes from the ApplicationBasic cluster directly, rather than packaging them in to this one class. That seems to be a simpler option, and the PV app can decide what information it needs to fetch. This ContentApp class will just contain the endpointId and the list of clusterIds. See project-chip#23181
| private byte fabricIndex; | ||
|
|
||
| private boolean isConnected; | ||
| // Empty if we don't have a connection to the TargetVideoPlayer yet (for e.g. when the casting app |
There was a problem hiding this comment.
Or if this is not a casting video player.
There was a problem hiding this comment.
Currently, provided we're connected to the video player, we do return a list of all the endpointIds with all their clusterIds. How is a "casting video player" defined anyway - are we supposed to check for specific clusters on the endpoints it hosts?
There was a problem hiding this comment.
device type of the video player will be different.
These APIs address the following issues:
Note: This is a draft PR to get feedback on the shape of the APIs themselves. The APIs are going to be very similar for iOS, except for mapping Java types to Objective C ones. There will an updated PR later with the actual implementation and this draft PR will NOT be merged in project-chip/master as such.