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
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.
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…
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=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
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
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.