Differences in iOS projects?
Shagans982 opened this issue · 11 comments
Whats the difference between this project and the other Twilio has hosted here on Github?
this one: https://github.com/twilio/video-quickstart-ios
aside from the different implementations. Is this project included as one of the implementations in the other?
Hi @Shagans982, the purpose of this repo is to provide a more complete example of a typical multi-party video app implementation that is closer to production code than the quickstarts. We still have some work to do with Swift conversion and architecture but that is the vision for this repo.
As we encounter overlap with quickstarts we will probably remove some of the quickstart examples and refer people to this repo.
There is no code shared between this repo and quickstart repo.
Let me know if you have any other questions!
Seems like there is quite a bit more going on here vs the quick start app. No notion of a passcode in the quick start, however I can connect to a room (quick start app to web) if the token is valid. Regardless of passcode the web used. Is a passcode needed? We have a POC in place using the quick start so trying to see which approach is the one recommended by Twilio.
The app in this repo gets access tokens from an access token server that must be deployed (instructions in the readme). We added a passcode so that there is at least some simple authentication the user must do to get an access token from the server. The passcode solution is intended to get POCs up and running quickly but not for production. For production something more secure like Google sign in or your own auth implementation is recommended.
The quickstart requires that developer go to Twilio Console and manually generate an access token and copy and past into the quickstart code. So no server to deploy but a lot of copy and pasting for each device and the tokens expire after 1 hour.
For POC if you want to try on a number of devices and not deal with access tokens that expire after an hour I would recommend to use the app in this repo.
Thank you for the information. We would only require authentication on one side of a peer to peer video conf. That being on the native iOS side. The web portion (for us) is just serving as a connection point for an unknowing participant. So in that case we just want to authenticate the other end and generate a link for the unknowing web participant to join.
As far as rooms, I assume we can generate that in code using something like a phone number and generate a new room with the 2 participants for each session. Or does the room id need to be more unique?
As long as the room is unique you should be good and it sounds like your multi phone number solution would do the trick. Generating a random identifier may be a little more robust depending on how you are getting the user's phone number and how reliable it is. But yeah I think you get the idea.
When you generate an access token for a user you can optionally specify a room so that they are only able to connect to that room which provides additional security. Just something to be aware of.
Hey @Shagans982 I received the message below in an email but don't see a comment for it on this ticket. In case you still need an answer I will answer here. I don't think the SDK provides this information prior to connecting to a room but I'm pretty sure the REST API would provide this.
Quick question regarding the notion of a "waiting room". Does Twilio offer the ability to display who is currently in a call prior to joining that call to the incoming participant?
Is TVIError not exposed? Seems like everything is coming from as an Error. Why not pass back a TVIError?
Are you referring to the SDK interface? I think accessing it via Swift it is just a Swift.Error. I know you can get localizedDescription from that. I suspect it is possible to cast to NSError and look at domain and code but not certain. I will get back to you with more info.
I think the challenge is that the SDK is Objective-C and when the NSError is bridged to Swift it is just a Swift.Error due to bridging limitations. Glad you have the cast working and I'll pass the feedback onto the SDK developers. Thanks!