Hello guys
Hello guys,
Some days ago I started a project aiming decrease the gap in the integration between Delphi and Objective-C, it is the first time I own an iPhone device (it was a gift, I am a poor guy :P) and my first contact with Delphi wrapping Objective-C APIs, it is pretty good however the integration between the two languages is not pleasant, using TOCGenericImport and TOCLocal is not much beautiful.
The idea here is consume Objective-C APIs in a more friendly way, using the max of Delphi code possible :D It is hosted here (https://github.com/fofoflylandia/Raco) in very very early phase, at this time it is just an experiment.
If you are interested on it, please let me know :D
Thanks in advance and thanks for Chris Rolliston and David Nottage for answering my question here :D
Some days ago I started a project aiming decrease the gap in the integration between Delphi and Objective-C, it is the first time I own an iPhone device (it was a gift, I am a poor guy :P) and my first contact with Delphi wrapping Objective-C APIs, it is pretty good however the integration between the two languages is not pleasant, using TOCGenericImport and TOCLocal is not much beautiful.
The idea here is consume Objective-C APIs in a more friendly way, using the max of Delphi code possible :D It is hosted here (https://github.com/fofoflylandia/Raco) in very very early phase, at this time it is just an experiment.
If you are interested on it, please let me know :D
Thanks in advance and thanks for Chris Rolliston and David Nottage for answering my question here :D
"stringWithCharacters"... o.O
ReplyDeleteHave al look at D.P.F Delphi iOS Native Components - that is a good starting point for things already available (sourceforge.net - D.P.F Delphi iOS Native Components)
ReplyDeleteI used them in the past and got an app into the app store
For what it's worth: I don't find using TOCGenericImport and TOCLocal "not much beautiful"; it's still all Delphi code. What I most object to, is the omission of some very key declarations in interfaces for ObjectiveC equivalents (even after they've been available for several iOS versions), and that the Delphi iOS compilers are still incapable of providing compatible ObjectiveC "blocks" consistently. Anyone who has attempted to use ObjectiveC classes that require these will know exactly what I mean. Anecdotal evidence indicates that FPC has been able to do this for some time now.
ReplyDeleteDavid Nottage My idea is to provide better bindings in therms of method naming, parameters more tighted to Delphi, instead of using NSString you will use UnicodeString, instead of wrapping pointers you will be able to create the objects in the same way you do every day using the proper constructor, expose protocols as abstract classes in the same way as Xamarin and RoboVM does, convert @selectors to anonymous methods, TOCGenericImport and TOCLocal are great but you can end up mixing Objective-C native types with Delphi types all the time.
ReplyDeleteMy 2p is that the existing Delphi to Objective C bridge is pretty good for calling Cocoa APIs, albeit with blocks being a not insignificant gap. That said, I can just about get away with doing blocks manually on OS X, assuming it's only the odd usage case involved.
ReplyDeleteHowever, using the bridge for Objective-C subclassing is horrible for a variety of reasons, independent from the fact the bridge is implemented at the library level with no special compiler support (which is itself a big limitation). My main bugbear is having two independent reference counts, one controlling the Objective-C part of the object and one controlling the Delphi part, especially given the two counts do not share the same basis - Objective-C objects begin with a reference count of 1, Delphi ones with a reference count of 0 that only become 1 on the first assignment.
All in all, over time, I've come to realise that the FPC approach - implement the Objective Pascal dialect - is fundamentally superior, even if Objective Pascal code looks weird from Delphi (or indeed normal FPC) eyes. If you're doing anything serious with direct calls to OS X or iOS APIs, you're just going to have to learn and follow the conventions, otherwise you end up continually having to mentally translate between idioms. And yes, that means I now even prefer typing TNSString.stringWithCharacters over StrToNSStr ;-)