ExternalAccessory.framework

I’m trying to get a Xojo iOS project working with an external barcode scanner. In the company’s forum they have a bare bones listing. In step 3 they have this blurb:

3. In Xcode, navigate to Frameworks and add the ExternalAccessory.framework

What does this mean to a Xojo app?

If I recall… “Xojo for iOS” does not yet support external frameworks.

For Swift/ObjC what you indicated above would add that framework into the app, but it is done in the “Build Settings” panel in Xcode

Hm…okay. Had a developer do a conversion for me that took their library and made it into a framework that Xojo could use. Reliable developer who’s offline today. Kind of grasping at straws trying to figure out what my !(*@#% isn’t connecting to the scanner.

iOS is such a different beast…

I am looking forward for the hopefully not too distant time when, at long last, Xojo iOS will support plugins. We do need MBS ASAP.

I believe the upcoming Interop will be helpful for this too.

Sure, but a declare as clever as it may be cannot do as much as a piece of C++. In practice, there are several things that are simply impossible to implement within Xojo, let alone because they need call backs.

This is true IF the C++ code is more than just wrapping a header file & making the API call for you
If thats all it does then a declare is the equivalent without the overhead of having to call into the dylib that then calls the exact same api for you

Indeed a simple wrapper is no better than a declare. But for iOS, where callbacks are necessary, more is required, and as far as I understand from what Jason King has shared, that cannot be done with declares.

I should also say that I grew fatigue of having to mess with declares. If we had access to a plugins collection like MBS, no need for haphazard declares and suffering through Apple documentation which BTW is becoming even more abstruse by the day.

My job is to produce consumer software. Not to become a systems engineer.

Async callbacks that are done off the main thread are problematic and that cannot be solved using declares

[quote=313626:@Michel Bujardet]I should also say that I grew fatigue of having to mess with declares. If we had access to a plugins collection like MBS, no need for haphazard declares and suffering through Apple documentation which BTW is becoming even more abstruse by the day.
[/quote]
I wont argue this one
I filed a bug report about their horrid online reference where they dont even cross link from one api to the types it returns
Apples docs are becoming a great example of what not to do for online documentation
Might as well just say “read the header files” because thats about what they have in pretty HTML layouts
And its not even that useful as you have to navigate into and out of every method call etc
At least in a header file I can just scroll it

[quote=313598:@Dave S]If I recall… “Xojo for iOS” does not yet support external frameworks.

For Swift/ObjC what you indicated above would add that framework into the app, but it is done in the “Build Settings” panel in Xcode[/quote]
Hm. I’ll have to look around because I’m sure I’ve loaded the Reveal framework in the past.

Perhaps you have… I’ll be honest… .“Xojo for iOS” is not a mature enough product to warrant a lot of my attention, too many hoops to do the simplest things…

@Greg O’Lone you are actually saying that one could load the Fabric framework with the current version of xojo for iOS?

I’m saying I’ve done it with another vendors framework, but I’m not near my desk right now and haven’t had a chance to go look at how it was done.

Here’s the code I used for the Reveal framework at one point:

#if DebugBuild Declare Function IBARevealLoggerGetLevelMask Lib "@executable_path/libReveal.dylib" () As Int32 Call IBARevealLoggerGetLevelMask() #endif

and the libReveal.dylib was copied into the bundle before the Sign step with a destination of “App Parent Folder.”

That looks like a simple “declare” to a single function… not access to a “framework”
I would think a “framework” would provide integrated access to a suite of methods and classes without revealing the actual code behind them, like SQLite for example

[quote=314075:@Greg O’Lone]Here’s the code I used for the Reveal framework at one point:

#if DebugBuild Declare Function IBARevealLoggerGetLevelMask Lib "@executable_path/libReveal.dylib" () As Int32 Call IBARevealLoggerGetLevelMask() #endif

and the libReveal.dylib was copied into the bundle before the Sign step with a destination of “App Parent Folder.”[/quote]

Superb, Greg !

It means the current Xojo iOS can use dynamic libraries. This is a major step forward !

[quote=314110:@Michel Bujardet]
It means the current Xojo iOS can use dynamic libraries. This is a major step forward ![/quote]
It always could
You just had to know how to declare into the right things on iOS

[quote=314112:@Norman Palardy]It always could
You just had to know how to declare into the right things on iOS[/quote]

Well, that may have been apparent for you engineers, but it was not exactly common knowledge.

I may be wrong, but on the contrary, I vaguely remember discussions where it was said dylibs were not possible, only static.

It is the very first time I see code to call dynamic libraries.

Thats an odd contention since iosLib and iosKit are all declares and have been around for some time (like almost since we released iOS)

The only difference with Greg’s code is the location of the framework (which BTW can also be used on macOS to include custom frameworks in a built app)
That too however is not new

https://forum.xojo.com/13023-how-to-call-dylib
https://forum.xojo.com/24433-where-should-private-dylib-and-so-files-be-placed-within-an-app

The reference to static libs had to do with how plugins like MBS & that to make that work we would need to use static libraries if we wanted to support iOS 7 and prior

Norman, both links are about macOS. While it is great news that the same technique can be used in iOS, unless I am completely mistaken, this is the first time I see it. Thank you.