Where a feature is iOS 9 exclusively, checks are (or rather should be) included that forbid the use of the feature. With Apple’s iOS 9 having widely spread, I see no use in supporting iOS 7 anymore. Where this is finished, you find the class in a finished folder inside its framework folder, together with a note on its implementation and documentation status.
Recently I have started to update the documentation. When you read Apple’s documentation, you should be able to check if an implementation exists. I have tried to put every control into its respective framework folder. In that case, the internal iOSLib object’s events do not fire anymore! Frameworks & status When you use those classes as a custom control, the event is forwarded to the wrapper customControl object, mimicking Xojo Event names and reporting with Xojo parameters if any. Where an iOSLib class has certain events implemented into its custom ClassPtr, they are usually forwarded to the iOSLib object itself, mostly under the name Apple uses in its documentation and with iOSLib properties if they use any. Which means an iOSLibScrollView has an ID As AppleScrollView property. ID As AppleObject (subclass) that gives you access to the iOSLib implementation behind. Again, if you want maximum performance, they each own an The custom controls have, wherever possible, Xojo properties built around them so you can integrate them into you Xojo iOS workflow, the computed properties doing the conversion. An AppleLabel control that doesn’t need special events and is therefore a subclass of iOSLabel is called iOSLabeliOSLibEnhanced instead.
Therefore, a custom AppleView/UIView class, basically the full implementation of a Xojo iOSCanvas, is called iOSLibCanvas. IOSLibXojoname, iOSLibAppleName or Xojoname iOSLibEnhanced, depending on if a Xojo control of that class exists or if the control is a subclass of the Xojo control. You find custom controls in the folder Custom Controls where they follow the naming scheme Exceptions are controls that don’t use special events (or where it’s very doubtful these will ever be needed) where I could just subclass the Xojo control. These controls are almost ever built on the iOLib native class.
Minus they will only appear as a cutomControl rectangle during layout phase.
Plus you can address many of their properties in inspector. Where it made sense, custom controls exist which are built on iOSCustomControl subclasses and mostly feature the events of the class too. I had to rename it to AppleView to resolve conflicts with iOSKit. Please note that this property was named View for some time, and some parts of the documentation may still say so. For a iOSTextfield, AppleView is a UITextField/AppleTetField property. Keep in mind that while this property may be called AppleView, it is the respective subclass of AppleView always. If you want to maximize performance without using custom controls, work on this AppleView property directly with the native iOSLib classes. Which means all method and property calls in their convenience modules work on this property.
No matter what they do, they all have a property You find them in the folder Class Extensions.
Where possible (because it is basically a native control and has a Handle), convenience modules contain the conversion and install "virtual" properties on the Xojo controls. So for example Color.toAppleColor converts a Xojo color to an iOSLib color and AppleColor.toiOSColor does the reversed conversion. Where a Xojo class is a subclass of a native iOS class, you will usually find methods to convert between both: Thus, a NSArray in iOSLib is an AppleArray and a CFArray is an AppleCFArray.Įvery such native class has its ID As Ptr which is the ptr to the object itself, very much like the Handle property of Xojo iOS classes. The Core Foundation derivatives of different classes that Apple has not built into classes (you usually handle the pointer only and use it for different framework methods) have been built into classes too with their framework identifier added to the classname. Here’s a small legend for first explorations: iOS classesĮvery native iOS class in iOSLib begins with an " Apple" instead of " NS" or " UI". Until we are able to build Xojo plugins with Xojo, I am afraid it will even grow. Yes, I know, iOSLib tends more and more to overwhelm the curious coder by its size.