I have implemented the UISearchBar class so that a native search bar can be added to your iOS applications. My implementation provides access to every method and property except for inputAccessoryView which cannot be implemented in Xojo at this time since an arbitrary UIView cannot be created independent of an iOSView. The class has the following events:
TextChanged(newText as Text)
BookmarkButtonPressed
CancelButtonPressed
SearchButtonPressed
ResultListButtonPressed
ScopeButtonChanged(newIndex as Integer)
The class can be easily configured in the IDE inspector since all of the properties have been made available. https://xojo.io/c1d7563ea5e2
If you have any questions on how to use it let me know.
[quote=156464:@Jason King]I have implemented the UISearchBar class so that a native search bar can be added to your iOS applications. My implementation provides access to every method and property except for inputAccessoryView which cannot be implemented in Xojo at this time since an arbitrary UIView cannot be created independent of an iOSView. The class has the following events:
TextChanged(newText as Text)
BookmarkButtonPressed
CancelButtonPressed
SearchButtonPressed
ResultListButtonPressed
ScopeButtonChanged(newIndex as Integer)
The class can be easily configured in the IDE inspector since all of the properties have been made available. https://xojo.io/c1d7563ea5e2
If you have any questions on how to use it let me know.
[/quote]
If you had worked at Xojo 2 years ago, iOS may not have taken that long to get here
Now with all the work you are doing, they should have their new year resolutions together : implement in 2015 R1 what you and a handful others have been able to come up in just a couple months
Congratulations, and thank you for making all these treasures available.
Thank you for your kind words, but we both know that is not true
What else have you got on the list, if I may ask? I’ve been implementing stuff as I find I need it or others ask about it, but I don’t have enough knowledge of what is available in iOS to really know what is missing/what I can use and implement in declares.
Well, since you asked ;), you’ve already implemented the UIImagePicker as well so I don’t have a whole lot more left on my list. The iOSTable obviously needs additional customisations - I’d love a multi-column version (and I know I’m not alone) plus the ability to add/draw whatever I like in the full height and width of the cell but I believe I read somewhere on this forum that this is tricky in Xojo right now. After that my biggest needs are for scrollable views, a UICollection view and access to the iOS Keychain.
[quote=156500:@Jason King]Thank you for your kind words, but we both know that is not true
What else have you got on the list, if I may ask? I’ve been implementing stuff as I find I need it or others ask about it, but I don’t have enough knowledge of what is available in iOS to really know what is missing/what I can use and implement in declares.[/quote]
iCloud storage integration would be very cool, but I suspect this is a larger project. Likewise with Game Center.
This actually wouldn’t be very hard to do with declares… if Xojo revealed the handle to the underlying UITableViewCell object. Until then your are correct; all of these are tricky or even impossible to do.
Indeed, adding scrollable views is very important, I’ve tried to do so in declares but autolayout seems to mess them up. Getting access to the iOS Keychain shouldn’t be very hard, its a fairly straightforward reference. But the UICollectionView looks like a pretty daunting task to have anything beyond basic support, and it would be terribly hard to implement in declares.
Quickly peeking at the iCloud docs its definitely a decent sized project since many things which happen automagically on OSX have to be done manually on iOS, and there are MANY classes which would have to be implemented. I’m not sure it’s even possible to implement Game Center at this time since it appears that a static link to GameKit is required at compile time and it is currently not possible to pick which frameworks the compiler links to at compile time.
It sounds as though we need to wait for Xojo to implement a better iOSTable, scrollable views (<https://xojo.com/issue/37340>) and the UICollectionView (<https://xojo.com/issue/36805>). Another thing that would be very useful for me is the UIPageViewController. It was in there at one stage but was pulled.
Ulruch and JasonK both have made a lot of great contributions for IOS declares. We all appreciate there efforts big times !
The real difficulty is to use them in one project In most cases the compiler gets lost in double/triple assigned stuff making it very hard to get it going.
Therefore it would be awesome if it could be put into one library. Michel already has done a great job with the iOSWrapper but adding some declares does introduce the same issues.
Some uniform source as MacOSlib is a good way to make sure everything will work in one project.
I did add a few classes in the wrapper, but that is not as easy as it seems. Often enough, the classes have been made for a single project and not really thought out as part of a bigger project. But it is feasible.
Since I mainly add to the wrapper for my own use, I did not try to add everything that has been published, and there was quite a bit lately.
Ulrich Bogun’s iOSLib seems on its way to that as well. It would be great if he made it a Github repository as well.
Stephen J. Beardslee just did, and that is very neat.
If Jason could pack all he has done in a Github, that would be wonderful as well, but he has so many projects…
All in all, I was pretty nicely surprised by the number of declare projects introduced since the advent of 2014R3. I do not recall such a creative trend ever happening before. That is very impressive for a platform that some professed as being of no interest…
Now I sincerely hope all that work will inspire the Xojo team in making 2015R1 able to use most of these assets within the language. Plus, if I had a wish for the coming year, in app purchase, which is a definite must for iOS apps marketing.
Don’t think this will happen for 2015r1 - Xojo Inc will only focus on getting it 64bit ready (I think) with some minor additions. But you never know. Proof me wrong.
Ill gladly do, but I have to watch the Github webinars first. I have not even succeeded in setting up a private repository yet ;(
I go on a week’s vacation on Sunday without Computer! but Ill post the current version before. If you like to take it for a repository, please feel free to do so.
What would be great - if possible - would be to design a iOSLib having classes not so dependent/nested like MacOSLib. So one could delete the stuff not needed. I believe the overhead would be worth it?
I think so too, and I will try to do so step by step for Mac OS X, but I believe some core modules are important to have so things will not get too big. It would be a massive overhead implementing the NSObject/UIVIew features to each class separately.
I try to set up something with like this with the iOSLib project: I put as many things as possible in extension modules on Xojo base classes and only use optional(!) subclasses where I need to add delegates or event definitions. Instead of using UIKit objects as parameters, I convert them to Xojo data types and objects before passing them. This way, there are only a few interdependencies that cannot be avoided and only a handful of core items need to be installed for a base iOS system. Whenever Xojo adds a feature, we can eliminate it from the extension modules and won’t have to refine zillions of subclasses too.
BTW: Michel, I think it would be easy to fuse our projects if you are interested. I have created a lot of conversions in new framework style (like Color.toText) but as good as no legacy methods yet.
[quote=156561:@Ulrich Bogun]Ill gladly do, but I have to watch the Github webinars first. I have not even succeeded in setting up a private repository yet ;(
I go on a week’s vacation on Sunday without Computer! but Ill post the current version before. If you like to take it for a repository, please feel free to do so.[/quote]
One thing I just figured is that Github is able to keep binary projects and zip files in a folder, pretty much like it does for pictures, for instance. So I created a folder called “Other projects”, and put into it the iOSLib.zip file.
Excellent idea. I can give you access to the repository as well.
I’ve been implementing stuff as I find I need it or others ask about it, but I don’t have enough knowledge of what is available in iOS to really know what is missing/what I can use and implement in declares.