<< This is not the relevant forum for OceanaWebRTC SDK queries, however, I will post my response in here for this query >>
Hi Jim,
Apologies for the delay, just getting around to this now as I was out of office for the last few days.
Firstly, can you confirm what version of Oceana the customer is using? This would aid us in making the changes to the correct version to the queries below.
RE: 1) oceanacustomerwebvoicevideo.aar has a dependency to netty.jar version 4.1.10, this netty.jar is conflict to their existing netty version 4.1.16 and they cannot exclude our jar.
We are bundling the Netty dependency in our oceanacustomerwebvoicevideo.aar project, which is causing the conflict.
We will take the steps to extract this dependency from the .aar project, which would allow it to be included in the application, removing this conflict.
RE: 2) They usually compile the third party SDK into their own app but our SDK uses embed framework. They want to know why are we choose this way (What is the logic behind it? Is it better or out of some consideration? -Jim).
The reason we decided to use the embedded framework structure initially was to hide away the ability to implement the frameworks that the OceanaCustomerWebVoiceVideo is dependant on, (AvayaClientServices and AvayaClientMedia). We felt this could cause confusion and potential issues when a customer was implementing the OceanaCustomerWebVoiceVideo framework if the other frameworks headers (AvayaClientServices and AvayaClientMedia) were available.
Apple do ‘discourage’ the use of embedded frameworks, but I have not uncovered any suggestion that it would cause the application to be rejected for App Store submission for example.
However, in saying that, Apple may decide to prohibit this entirely in future, so it would be safer to remove the embedded frameworks from our SDK bundle and package them separately.
RE: 3) Current SDK separates x86_64 and arm architecture, how to make one project configuration work for both simulator and real phone? (The current project configuration will cause other developers cannot use either simulator or phone? -Jim) Or can we provide a SDK that includes both x86 and arm architecture?
This is done because Apple forbids submitting a binary to the App Store that includes simulator architectures. If we provided a binary with both device and simulator architectures the developer would have to strip out the simulator slices before submission. Unfortunately Xcode does not provide a good way to handle separate binaries for device and simulator, but it is possible to work around:
- Copy one of the architectures to a common directory name
- Add the libraries to the Xcode project from this common directory
- Delete the common directory
- Add a Run Script build phase that creates a symbolic link to the directory with the libraries for the platform being built at the path of the previous common directory. For example:
ln -s ${PLATFORM_NAME} current
We will need to update our DevConnect bundles with the updated iOS and Android changes required for query 1 & 2 outlined above once we know the version the customer is using.
Regards,
Pat
|