I have been working with a customer to test merging OceanaWebRTCSDK with their application and they can run our demo apps on Android and iOS already, but here are some issues were identified.

For Android:

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(because we've put them inside of the /lib folder).
They suggested that we use “compile” scope when build the oceanacustomerwebvoicevideo.aar, so they can use their own version of netty and avoid the conflict.

For iOS (I don’t familiar with iOS development and am trying my best to describe it accurately):

They usually compile the third party SDK into their own app but this SDK uses embeded framework. Customer wants to know why is the SDK choose this way (What is the logic behind it? Is it better or out of some consideration? ).

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? Update: in the meeting yesterday, customer states that they can accept that the SDK *compiles* for everyone but may not *run* for Simulator or Phone in the same time.) Or can Avaya provide a SDK that includes both x86 and arm architecture?

Hello,

This forum helps answer questions about Avaya Breeze Client SDK. Is that the product you are using? What version are you using?

Thanks,
Artem.

Hello,

Sorry the SDK was renamed from OceanaWebRTCSDK on version 3.5 to OceanaWebVoiceVideo on 3.5.1. And customer is using 3.5.1.

This SDK can be downloaded from Dev Connect Featured Downloads. And I felt it belongs to the Client SDK family.

<< 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