Results 1 to 7 of 7
  1. #1

    Question Importing Lightstreamer with Swift Package Manager

    As you might heard Xcode 11 now allows us to use Swift Package Manager for iOS projects. This allows us move away from CocoaPods or Carthage. I am already converted our Lightstreamer internal wrapper into Swift Package but I was unable to build it. I am getting errors when trying to import the framework:

    error: no such module 'Lightstreamer_iOS_Client'
    import Lightstreamer_iOS_Client

    I have also tried to wrap lightstreamer into its own SPM project and I am able to build it, but even if my package depends on it, it produces same error.

    Quick research showed me that Swift packages do not support binary frameworks, however I think it is worked in Xcode beta 5, now I am using Xcode beta 6 and it doesn't work any more.

    Ideally we would have Swift.package file into Lightstreamer client and this would allow us to import it, the code has to be open. Thank you.

  2. #2
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    93
    Hello,

    we are investigating the problem. If it will be possible to wrap our client library in a Swift Package, we will surely do. Anyway, consider that we will wait for Xcode 11 to be GM before finalizing such wrapper. Don't hold your breath.

  3. #3
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    93
    Hello again,

    we investigated the matter, and I’m afraid we have bad news. As reported even at the very beginning of the official documentation, a Swift package can't contain binaries.

    We could publish our source code (in fact, our client SDKs are just reference implementations of our TLCP public protocol, there’s nothing to hide), but our build is currently based on a Java to Obj-C transpilation process (discussed in this blog post) that requires multiple libraries from an external project (Google’s J2ObjC). Those libraries could not be included, since they are binaries, and they are not available in turn as a Swift package.

    This rules out the possibility to wrap our iOS client SDK, as is, in a Swift package, at least for now. The day J2ObjC should release their libraries as a Swift package, or if we should ever embark on a full rewrite of the client in Swift, we will re-evaluate the opportunity. Until then, you will have to continue with more traditional ways to add our client to your projects.

    Thanks anyway for bringing this matter to our attention.

  4. #4
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    2
    Yes, indeed SPM doesn't yet support precompiled binaries. It seems they are on the pitching stage for this feature. For more information check:
    - Pitch: https://forums.swift.org/t/pitch-sup...ndencies/27620
    - SPM support for binary distribution discussion: https://forums.swift.org/t/spm-suppo...ribution/25549
    - SPM bundles & resources support discussion: https://forums.swift.org/t/swift-pm-...esources/13981

    It is quite interesting to realize you are transpiling Java to Obj-C. It seem to work well for my usage, which is mainly desktop bounded (https://github.com/dehesa/IG). I do wonder however how well does it play with URLSession including this year's changes (low data mode, etc). I had to do a MQTT library wrapping for Apple systems some years ago and using C and Posix implied not using URLSession, which work as intended on WiFi, but on Cell stop working altogether.

  5. #5
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    93
    Our client library uses only native components for networking: NSURLSession on HTTPS transport, and CFStream on WebSocket transport.

    The mechanism we use is a simple dependency injection pattern:
    • The Java engine wraps all the services it needs for connecting, receiving messages, sending messages etc., behind a Java interface.
    • The Java desktop and Android clients implement this interface with Java classes that use Netty as networking component.
    • The transpilation process scraps the interface implementations, leaving just the bare interface, which then becomes an Obj-C protocol on the iOS client.
    • Finally, the protocol is then implemented with a Obj-C classes that provide the same services using NSURLSession or CFStream as required.


    So, our client is actually well aligned with the latest features of NSURLSession. We don't circumvent them using BSD sockets or similar expedients. Our client is, and has always been, a good iOS citizen regarding networking.

  6. #6
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    2
    Thanks for the details, Gianluca! and congratulations on achieving a multi-platform working architecture (I know it is not easy).

  7. #7
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    93
    Thank you very much. It's a team effort of course, I'll forward your words to the other people of the team.

 

 

Similar Threads

  1. Java import - package does not exist
    By UweF in forum General
    Replies: 4
    Last Post: March 2nd, 2016, 06:58 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 02:10 PM.