Decouple client setting and initialisation

[jgongo]

The ShakaPlayer currently provides a single initializer: init(client: ShakaPlayerClient!) where ShakaPlayerClient is a protocol with all its methods marked as optional.

After inspecting the code:

• The player initialisation may fail. In this case the player client is informed of the failure through the onPlayerError(_ error: ShakaPlayerError!) method. This means that you are forced to create a client if you want to know about the error in case of failure.
• The initialisation requires you to provide the client. But the methods of the client don't include the player in their parameters. That means you have two options:
  • either make the class directly using the player implement the ShakaPlayerClient protocol, keeping a reference to the player in an instance variable that can be later accessed inside the methods (see #94, not good from a responsibility separation point of view)
  • or create a separate object implementing the ShakaPlayerClient. In that case that object may need the player we are creating to extract information from it in several methods, so we must inject it. So we have to: create the client, create the player using the client, inject the player into the client
• All the methods in ShakaPlayerClient are optional, so it does not make sense to require a client to initialise the player: what would be the difference between providing no client or providing a client with no methods? You could think that the code requires a non nil client to be there, but that't not the case: the reference to the client is stored in a NativeClient which later forwards the events to the original client using the DispatchObjcEvent method, which checks if the client is nil before invoking any method. Taking this into account it seems the only reason to require the client in the initializer is to be able to inform of a initialisation error.

Could you please decouple initialisation from client setting? This way:

• Player and client creation could be completely decoupled if #94 is fixed
• Initialisation success could be easily determined if initialisation used a initializer which throws an error as described in the Error Handling guide. In this case we have the error information more clearly provided and related to the initialisation operation with no need for any third object
• You wouldn't be forced to create a client if you aren't interested in receiving player events
• You would be able to use third party libraries which rely on classes adopting the delegate pattern (for example RxCocoa reactive support for classes with delegates)

[TheModMaker]

I'll be fixing #94 to add the ShakaPlayer instance to the callbacks; but note that for initialization errors, the value passed will probably be nil. This is because the object failed to initialize, so the object is unusable.

The client can be nil (though that may not appear in Swift), and I'll add an empty init method for convenience.

I don't think we can use Swift error handling since that wouldn't work well in Objective-C. Exceptions in Objective-C are supposed to be programming errors and fatal errors; most apps won't catch them. An alternative would be to use an NSError** pointer to set the error in init. Then you could do something like:

var err: ShakaPlayerError = nil;
guard let player = ShakaPlayer(client: self, error: &err) else {
  print("Error: \(err.message)")
}

[jgongo]

Hi @TheModMaker Having a parameter of type NSerror** as the last parameter of any Objective-C method (including an initialiser) translates into a Swift method with that last parameter removed and with a throws. That's why in #116 I requested ShakaPlayerError to inherit from NSError

Regarding throwing an exception in this case... you would only throw it in Swift. In Objective-C you would be passing back the error in the NSError** parameter.

[jgongo]

With the modification provided in the #119 PR, the init method from Swift is seen as init() throws, while you can still use the initWithError:(NSError **)error signature when used from Objective C.