Luke 40079 Posted January 4, 2014 Posted January 4, 2014 These two endpoints will allow you to do that [Route("/Sessions/{Id}/Users/{UserId}", "POST")] [Route("/Sessions/{Id}/Users/{UserId}", "DELETE")] This way when something is watched for that session, the playstate goes to every user. Eventually I'll have the web client do some neat tricks with it so that you can see what's possible for mobile. But living room clients can use it to mimic the new netflix functionality where you can indicate who else is present in the room.
ebr 15667 Posted January 4, 2014 Posted January 4, 2014 Perfect. Now I can add the "also here" stuff to MBC. Thx. 1
CBers 7114 Posted January 4, 2014 Posted January 4, 2014 How does this work from a user point of view? Do we have to tell MB3 who is viewing somehow? TIA.
gcw07 347 Posted January 4, 2014 Posted January 4, 2014 How does this work from a user point of view? Do we have to tell MB3 who is viewing somehow? TIA. At the moment there is no user point of view. It is just an API end point at the moment. I would assume eventually you would be able to sign in a person and then sign in another as just "viewing". It would just then mark things. This would all depend upon the client. Hopefully one day we can also have a feature built into the server where "X" user can always be attached to the view state of "Y" user. 1
Redshirt 1487 Posted January 4, 2014 Posted January 4, 2014 It's going to be a little while before this gets to Android. Unless other client dev's force my hand CBers. Client devs will need to provide a sign-in UI indicating to the end user that they are 'also signing in, or out' user x. There will also need to be indicators in the client to remind the user that more than one user is signed in. As it will have an impact on things like Trakt that actually do stuff with the watch status. 1
Redshirt 1487 Posted January 4, 2014 Posted January 4, 2014 It's too early for me to say but the I may go the route gcw07 suggested on the client side where we have a user-group entitiy and add various users to it so that it's a simple fact of selecting the group rather than manually signing in each user. 1
Luke 40079 Posted January 4, 2014 Author Posted January 4, 2014 It's going to be a little while before this gets to Android. Unless other client dev's force my hand CBers. Client devs will need to provide a sign-in UI indicating to the end user that they are 'also signing in, or out' user x. There will also need to be indicators in the client to remind the user that more than one user is signed in. As it will have an impact on things like Trakt that actually do stuff with the watch status. and that is good you have bigger and better things to do right now. it's initially for mbc.
ebr 15667 Posted January 6, 2014 Posted January 6, 2014 How do I obtain my session ID? I'm not using that anywhere else.
ebr 15667 Posted January 6, 2014 Posted January 6, 2014 How about adding it to the system info call? I don't currently have a result on the authentication post.
Luke 40079 Posted January 7, 2014 Author Posted January 7, 2014 That doesn't really have anything to do with system info. i can add filters to the sessions endpoint so that you can get it based device info, but i'll also add it to the auth result because there is an object that comes back on that call.
Luke 40079 Posted January 7, 2014 Author Posted January 7, 2014 I will add it to the authentication result
chef 3808 Posted January 7, 2014 Posted January 7, 2014 @@chef can probably use this This sounds like another step, filling in the blanks, towards programmatic user switching. Plus, kinect will enumerate faces and can automatically load the user names who are watching. This could be very cool, if I can make it work that way.
ebr 15667 Posted January 20, 2014 Posted January 20, 2014 Is the session ID being returned from the authentication result in the latest server now?
Redshirt 1487 Posted January 21, 2014 Posted January 21, 2014 I'll get a release build out in the next few days. Clearly ebr is sitting on a cool feature he wants to release.
Luke 40079 Posted January 21, 2014 Author Posted January 21, 2014 well we would also have to test iOS and Roku. If it works with them then we're good to go.
Luke 40079 Posted January 21, 2014 Author Posted January 21, 2014 not yet because it will break the android login, and possibly ios
gcw07 347 Posted January 21, 2014 Posted January 21, 2014 Are there any changes to login that we would need to make? Assuming we aren't wanting to implement the multiple user stuff yet, is there anything that would break existing login?
Luke 40079 Posted January 21, 2014 Author Posted January 21, 2014 you just need to make sure you're always sending the identification header, even when you don't yet have a user id. just omit that value from the string. if you're already doing that then you're fine.
gcw07 347 Posted January 21, 2014 Posted January 21, 2014 I know i don't when I get all the user profiles. I think that is the only area is doesn't.
Luke 40079 Posted January 21, 2014 Author Posted January 21, 2014 ok, that's fine. this can wait then.
ScottIsAFool 517 Posted January 22, 2014 Posted January 22, 2014 I assume I'm ok for this with the apiclient?
Redshirt 1487 Posted February 6, 2014 Posted February 6, 2014 The client changes needed to send the author header for everything have been made in the current android public release.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now