I do hope Xojo realises that they need to provide more than a basic no frills framework, and let users contend with haphazard declares.
[quote=453581:@Michel Bujardet]What about that never realised promise of Xojo coded plugins ?
To tell you the truth, I was amazed at the number and quality of libraries for B4A and B4i. Perhaps the fact that they are based on Java explains it.
Fact is, I cannot seriously rely on a bunch of half baked volunteer declares to develop professional apps. Either I had to spend an inordinate amount of time painstakingly developing myself all the declares I needed, or I turned to a richer environment.
Xojo has a formidable asset with MBS, Einhugur, GraffitiSuite and others. That is for a professional almost as important as the language itself. Almost all my apps could not have been created without MBS plugins. They are maintained and Christian’s support is outstanding. This kind of asset was sorely missed for iOS.
I do hope that the upcoming Android will permit plugins, so users won’t have to suffer through breakable declares.[/quote]
There is a confusion in this thread about pligins, most of them in B4, are not system libs. Are classes that are compiled alogside the app. In android are writen in java, but for ios are in objective C. More than that, there are also those created in pure B4X, compatible with android and ios with a sigle source code.
Onother thing is that you can use frameworks and code found in github, either creating a simple wraper or with inline C/Java
Does Xojo support inline C/Swift for ios?
Does Xojo support inline C/Swift for ios?no
I am far from being as competent as Xojo engineers, so please forgive my naivet, but I read that Objective-C iOS programs can call into dylibs. Why would Xojo programs not be able to do so ?
PS:@IvanTellez - I am not confusing anything with BAi here.
a few notes:
- dylibs or frameworks can be used since iOS 8.
- dlopen/dlsym exists
- Xojo Inc. did never port the existing plugin interface from desktop to iOS
- We got a plugin SDK for FileMaker and have a plugin there for years now.
I can’t do anything for iOS via C compilers unless we have a workable way and the best hope currently is the Xojo llvm library stuff (aka plugin in Xojo), which may enable to embed a static library within the library.
Imaging what we could have for iOS if just half of MBS Plugins would have been ported for iOS!
no “inline” anything anywhere
apple may reject apps that use this
https://forums.developer.apple.com/thread/96246
at the time Xojo’s iOS support came to be dlopen etc were forbidden
that meant no plugins would work
that may have changed over the years
As of today, the MBS FileMaker Plugin is shipping in an iOS version.
It is used inside apps who passed to through App Store review.
And it includes dlsym/dlopen to load dylibs.
As of today, I would be happy to see a new revision of the iOS framework including the plugin interface to load plugins at runtime.
Yes, it may be needed to make them frameworks technically and load them via CFBundle APIs.
that would be a welcome addition for iOS
[quote=453777:@Christian Schmitz]As of today, I would be happy to see a new revision of the iOS framework including the plugin interface to load plugins at runtime.
Yes, it may be needed to make them frameworks technically and load them via CFBundle APIs.[/quote]
I believe that without the help of a collection of plugins, API 2 or not, Xojo iOS will remain too limited for most business applications.
Which might all change when they ship a version which supports iOS Interops – currently number 5 on the roadmap .
Interops are an intriguing solution, but yet, they won’t provide the same services as plugins.
As a professional, I don’t want to waste considerable time researching the often abstruse Apple documentation, then experiment, sometimes not being lucky. Until I see them in action, to me interops seem like glorified declares.
With MBS plugins, I have a maintained and reliable service. That’s all I need. That is all that was missing in Xojo iOS which prevented me from porting my apps to iOS. It is a shame that Xojo iOS still to this day expects users to dab in declares when they need more than the incomplete properties and events.
I don’t disagree. I subscribe to many plugins for Xojo desktop because it is vastly more efficient use of my time then developing and maintaining myself.
But at least with InterOps we’ll hopefully be able to create many projects that just are not practical now. There is a big difference between a brick wall you can’t overcome, and hurdle you have to jump over in your path.
I have difficulty understanding all this fuss about iOS plugins not being available.
There are currently two solutions that are already available but one would need a proof of concept to validate it.
[h]Encrypted modules and classes[/h]
Modules and classes enable adding many features from iOS, using declares under the hood. Just like iOSKit (unencrypted) and dtPlugins (encrypted) for iOS.
The person or team creating a plugin already needs to know about the operating system’s functions which are all available here:
https://developer.apple.com/documentation
Writing declares for this might take longer time than creating a plugin with a wrapper around C code but it isn’t impossible to do. iOSKit has hundreds, maybe thousands of declares and works almost perfectly.
[h]Dynamic library[/h]
There are many dynamic libraries available and even Xojo compiles one into the app bundle when running the app in the simulator.
I have successfully used AppLanga, RevealApp and ZipArchive external frameworks (dylib) in the simulator.
However I haven’t done it in a compiled app because I don’t know if the framework/dylib needs to be code-signed before adding it to the Xojo project, or at the same time as code-signing the entire app. This is why a proof of concept needs to be done.
The easiest way to use a dylib is to create a module or set of classes that act as a wrapper for the dylib. This is what I did to use ZipArchive and AppLanga.
iOSKit for all it’s qualities is still a work in progress with close to no documentation. DtPlugins are very close to no documentation either, and in spite of Jean-Paul’s talent, he now went to other horizons and his code is in an abandoned state. An encrypted abandoned state, which makes it extremely fragile.
You may have enough talent and free time to entertain declares, but that is not the case of most professional programmers.
The fuss is, I and many other professional Xojo users don’t have time to deal with finicky declares and waste an afternoon or more chasing a feature after reading pages of Apple documentation often just a clear as dungeons and dragons. I rather pay for a set of plugins, or a dylib, or whatever else, and be done with it. I paid for dtPlugins, and was happy until Jean Paul decided to be done with them.
It is a fact that quite a few Xojo users rely on Christian and his MBS plugins to get more out of the language. NOT declares, NOT MacOSLib. Professional plugins with outstanding support. If instead of half finished sets of declares, a solution from MBS existed, I am convinced quite a few professional Xojo users would gladly try to port their popular applications to iOS with Xojo.
Let alone because the MAS future is not as bright as it once was, and applications new frontier is mobile.