You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem we are having right now is that we need 3 languages (dart, objective-c, java) to maintain Sounds.
As we move to support more platforms this will only get worse.
As such we are looking to move to FFI (foreign function interface) to do direct calls from Dart into the required native calls.
This will result in only a single language being required (dart) to support Sounds.
Our fall back position is to use 'C' as a bridging language to the platform native calls.
The 'C' bridge will be a very small wrapper for each native call.
The reason for this is that we are still uncertain if we can achieve FFI calls directly to iOS native libraries.
What is the current state of this development?
The ffi work is proving fairly difficult but we are making (slow) progress. We would certainly appreciate any help.
Were we are right now:
We have done a conversion of the objective-c code to dart.
We did this by putting the objective-c code throught swiftify to create swift code.
We then manually modified the swift code (line by line) to change it to dart code.
This process went fairly smoothly but there are still a few spots where we are not certain if we converted the code correctly but we think its mostly close.
We are now looking at how we do the native calls to IOS libraries.
We are using the dart-native package to do the heavy lifting as it provides a reasonable wrapper for calls into ios.
The next step is to provide a dart wrapper library for the set of ios calls we need to make.
We have done some of this work.
The process we have been using:
Try using the dart-native 'generator' to create dart wrappers for the required ios library.
This has been partially successful but the generator often fails as it is still unable to parse some of the objective-c syntax.
When this occurs we try to create a 'cut-down' version of the ios header files that only contain the required entry points.
This often gives us a much better chance of doing the conversion.
As of now we think we have managed to create dart wrappers for each of the ios calls used by Sounds.
We are still uncertain if these dart wrappers are correct.
The next step is to get each of these functions to dynamically load. This requires us to find the ios library for each of these entry points.
We raised an question on stack overflow to get some guidance on this.
The summary answer is: In that case, I suggest searching through the folder /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk. The .tbd files in there contain library paths as well as a list of exported symbols. – Siguza Dec 3 '20 at 23:14
Make a decision on the final structure of the code based.
We are trying to move to a federated model that still allows uses to use pigeon if that is the appropriate solution and given that in the short term we will be using pigeon with the java code.
I've opened this issue to track work on converting the iOS code (and eventually the java code) to FFI calls.
The work is being down in:
https://github.com/bsutton/sounds/tree/sounds_federated
The problem we are having right now is that we need 3 languages (dart, objective-c, java) to maintain Sounds.
As we move to support more platforms this will only get worse.
As such we are looking to move to FFI (foreign function interface) to do direct calls from Dart into the required native calls.
This will result in only a single language being required (dart) to support Sounds.
Our fall back position is to use 'C' as a bridging language to the platform native calls.
The 'C' bridge will be a very small wrapper for each native call.
The reason for this is that we are still uncertain if we can achieve FFI calls directly to iOS native libraries.
What is the current state of this development?
The ffi work is proving fairly difficult but we are making (slow) progress. We would certainly appreciate any help.
Were we are right now:
We have done a conversion of the objective-c code to dart.
We did this by putting the objective-c code throught swiftify to create swift code.
We then manually modified the swift code (line by line) to change it to dart code.
This process went fairly smoothly but there are still a few spots where we are not certain if we converted the code correctly but we think its mostly close.
We are now looking at how we do the native calls to IOS libraries.
We are using the dart-native package to do the heavy lifting as it provides a reasonable wrapper for calls into ios.
The next step is to provide a dart wrapper library for the set of ios calls we need to make.
We have done some of this work.
The process we have been using:
Try using the dart-native 'generator' to create dart wrappers for the required ios library.
This has been partially successful but the generator often fails as it is still unable to parse some of the objective-c syntax.
When this occurs we try to create a 'cut-down' version of the ios header files that only contain the required entry points.
This often gives us a much better chance of doing the conversion.
As of now we think we have managed to create dart wrappers for each of the ios calls used by Sounds.
We are still uncertain if these dart wrappers are correct.
The next step is to get each of these functions to dynamically load. This requires us to find the ios library for each of these entry points.
We raised an question on stack overflow to get some guidance on this.
https://stackoverflow.com/questions/65083514/ios-dylib-entry-points
The summary answer is:
In that case, I suggest searching through the folder /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk. The .tbd files in there contain library paths as well as a list of exported symbols. – Siguza Dec 3 '20 at 23:14
Actions:
finding the list of exports to that we need to call.
You can see the calls we are making in:
https://github.com/bsutton/sounds/tree/sounds_federated/sounds/lib/src/ios
Make a decision on the final structure of the code based.
We are trying to move to a federated model that still allows uses to use pigeon if that is the appropriate solution and given that in the short term we will be using pigeon with the java code.
This stack overflow article has some useful references:
https://stackoverflow.com/questions/64037971/using-dart-pigeon-in-a-federated-model
The text was updated successfully, but these errors were encountered: