iOSLib is dead …

Targets iOS
1

… and if you should be using it: Don’t worry, it’s not as bad as it sounds.

I realized I ran into too many restrictions and complexities with iOSLib, and after the r2 update many things were not working anymore. Its structure made it necessary to add a lot of redundant code – pragmas for 32 and 64 bit and so on. And I know many didn’t like it because it forced you to install the whole beast or nothing.

After I started OSXLib, I felt the urge to bring iOSLib to the same, easier structure which allows you to use only the (admittedly more than a handful) core classes and remove everything else. On the other hand, I did not want to do everything again. That’s why I combined both libraries now into one repository that uses a lot of shared code. There are, of course, two different projects included: One for macOS, the other for iOS. But basically, it makes it possible to add declares for both systems at once where the frameworks are identical, while individual differences are still possible.

Currently, the iOSLib part does not offer any useful classes or controls at all. I still have to import and update a lot of things.

But this will follow soon, and in case you are developing for Mac, you already can use the features that were included in OSXLib. You find all stuff under

https://github.com/UBogun/Xojo-AppleLib/

To finish the title: …, long live AppleLib! :wink:

2

Super kudos to you! I feel like sending you something fun for all the work you’ve put into this.

Do you happen to be a runner? I’ve got an iOS app I’ve been working on I could send you if you’d like to try it. If not you might have to wait a bit for a playable version of the game I’ve got stashed away for rainy day work.

3

Thanks a lot, Kevin – and all the others who gave me positive feedback too!
Sadly, no: I don’t run, I mostly do sit :wink: – and I even don’t have an iPhone. My old iPad 3 (the first Retina) will wait patiently for your game – rainy days sound perfect for that purpose.

4

If you should have downloaded the first version: Aplogies – I incidentally put both libraries on the main level, so you might have had wrong app objects appearing after opening one. That’s fixed now, and a first addition to iOSLib allows you to use the almost full feature set of CGContext – like here in macOS:

Big question: Can you figure out how the Layoutconstraints on macOS do work? I did not intend to change the window’s frame, but I left it as an eye candy. Anyway: I wanted to keep the logo centered, not vice versa :wink:

5

Small update:
AppleView Block animations working again in iOSLib. Created an iOSLibView and an iOSLib Canvas custom control, the latter one being a subclass of the first plus the Paint event which gives you access to the native AppleCGContext with all its features directly. Fixes to LayoutAnchors. Added layoutAnchors in iOSLib too.
The View control is meant to enable layer access and therefore layer-backed graphics, where a paint event would ruin everything because you are painting over the layers. You find both controls in OSXLib too (where I have to rebuild their structure a bit yet).

View animations behave a bit differently on macOS and iOS:
On macOS, you have an animator property which is an AppleView/NSView in itself. Simply change one of the animatable properties of the view and changes will be animated with a standard duration. If you want to change the latter one, simply create a new instance of AppleAnimationContext and change its property:

dim ac as new AppleAnimationContext (me.AppleObject) ac.Duration = 8
(code from the Shown event of the Selection demo window of OSXLib – the Shown event being the “better” open event. It represents the HasMovedToWindow method, which means frame sizes are defined at this time.)

Then, simply change one or several of the Animator object properties:

 me.AppleObject.animator.Frame  = FoundationFrameWork.NSMakeRect (0, 50, me.width , me.height)

The required BeginGrouping method call is automatically done by creating an AnimationContext, and it fires its EndGrouping method during destruction time.

On iOS, animations are done in a block method. I have installed several convenience methods – from AnimateAlpha to AnimateTransform – that change one property. But you are not restricted to them. You can add more of those methods for every animatable property you find in the UIView (sub)classs(es).

Each must finally call

Public Sub Animate(duration as Double,  animationBlock as appleblock, delay as double = 0, options as AppleViewAnimationOption = Nil, Curve as UIVIewAnimationCurve = uiviewanimationcurve.EaseInEaseOut, transition as UIVIewAnimationTransition = UIVIewAnimationTransition.None, completionBlock as AppleBlock = nil)

where the enumerations and the AppleViewAnimation custom class should allow some kind of convenience when changing the animation parameters.

6

Apologies once again for all those who encountered problems when Xojo prompted for a lot of allegedly missing files and folders. While the external links worked perfectly here, they were linked into Nirvana when you tried to download them from the repository. I fixed the project files now manually. Would be great if someone could give me feedback if everything is fine now.
And, if you should encounter any problems: Please send me a short message or use the issues tab on the repository.

So far, both libraries are now quite on par for the majority of features. New is the better native Scrollview in macLib (The control needs to get a few more convenience properties yet). Both have their layoutConstraints and layoutAnchors classes, but the latter are still giving me a hard time because they usually resize the wrong view …

7

Short update notice:
Added a lot of CiFilter classes and demo views to both libraries. iOSLib’s CIFIlters are in beta. They work ok, but the method of converting an endless CIImage to an UIImage does not work correctly yet. It does so on macOS.

Changed the custom controls’ structure in macLib and started to implement an optional Boolean to the constructor to allow creation of native view subclasses without Xojo wrapper and event handling which prevents focus being stolen by views taking the focus hostage.