Posts

Post not yet marked as solved
2 Replies
2.0k Views
I've been working on a live broadcasting app for a bit now and have run across a few stumbling points.I thought I'd mention a few things that have helped, and hope for more suggestions and accumulated experience from others.If nothing else, just knowing what can be expected to *not* work may be useful to others just starting to aim their head for the wall.In no particular order, here are some observations and my workarounds, if any. I'd love to hear what I've got wrong, or how others have handled the situations.You will not see console (in debugger or console app) prints or NSLogs from an extension. I'd love to know a way to get them to happen.That said, if you open the Console app before you run your app and search for your extension name, replaykit, and RPBroadcast you can get a fair chunk of logging for startup issues, etc.If you debug a broadcast setup UI or the broadcast extension, it will not auto-attach in the debugger, at least not usually - can't recall if it ever did so. If your extension is alive long enough, you can manually attach to it (Debug->Attach to Process), but obviously that won't help with startup issues, early breakpoints, or crashes that happen before you can attach.The default stub/template code that XCode provides for the setup UI extension have an NSExtensionPrincipalClass type setup, but you can switch it to a NSExtensionMainStoryboard version instead, same as other extensions if you want to.I found creating my own little replaykit enabled app to test my replaykit extensions to be worth the time, vs. solely using other games, etc. to test the extensions. I found using other games, etc. to test *in addition* to still be useful, to confirm behavior and see differences in presentation.In loadBroadcastingApplicationInfo's completion handler, I'm not sure if it gets called back on the main UI thread, so I use DispatchQueue.main.async to get back on it for any UI touching bits (setting labels, etc.). Not sure it is needed, but think it's safe - anyone confirm?State transitions for broadcast starting, stopping, etc., can take surprising lengths of times sometimes. Not clear if there's anything that can be done to make them snappier. I'm referring to time spent inside internal replaykit code between the time you return from a callback, delegate method, etc., and the time the original app gets it's notification. Sometimes it seems like the messages don't get sent, as described in other posts in this forum. It's not clear to me though if that is a replaykit issue, or just a bug in my code I haven't traced yet. More docs and debugging ability would help.I have found as issue with the appIcon arg of the completion handler that surprised me. It is declared an optional, which I assumed was because sometimes their may not be an app icon... fair enough. I use a `if let icon = appIcon` statement before setting my setup UI's UIImageView image property to the icon UIImage, but I was getting an exception about an unrecognized selector, size. When I debugged it a bit, it seemed that it wasn't the property set that was causing it, but rather looking at the non-nil app icon the handler gave me. After taking out the image set, I'd still get the exception if I just tried to print icon.size, for instance, but not if I tried to print icon itself (not that one could see the prints, anyway). Really not sure what's going on with that, and it's somewhat slow going without being able to attach to the extension and debug, or see diagnostic prints. I guess I'll defer the triggering code to a button press or something in order to be able to manually attach to the process before it can die.If anyone has pointers, links, or other hints to share on the basics, gotcha's, best practice examples, etc. they'd be deeply appreciated.
Posted
by Tokotsi.
Last updated
.