The plight and suffering of Xojo iOS users with missing features...

[Michel_Bujardet]

45577 - iOS Please add LostFocus to iOSTextField

Michel Bujardet Yesterday at 11:59 PM
I file this feature request with the sinking feeling that for iOS it is completely futile, and we are on our own to live in declare and workaround misery.

A related request to expose becameFirstResponder to do gotFocus has been in dungeon jails of oblivion since 2014

Well, at any rate :

Please add LostFocus to iOSTextField.

The other FR is Case 36429

<https://xojo.com/issue/45577>

[DaveS]

Michel… is about time to come over to the “Dark side”… you pain and suffering will be mostly alliviated

[Jason_King]

What do you need to use lost focus for? If the user closes the app (home button x2, swipe) I don’t believe you’ll get an event anyway. Can you not use TextChanged?

[DaveS]

• User enters data into a textfield
• taps return/swipes … something the causes it to move to another view or field
• but hey I want to validate that that textfield has good stuff in it first, if not reassign FirstReponder

[Michel_Bujardet]

@294030:@Dave S

Michel… is about time to come over to the “Dark side”… you pain and suffering will be mostly alliviated

I know the dark side. I want to use my existing code and frankly would hate rewriting everything. That also would be a lot of pain and suffering onto itself…

That said, I am not in that of a pain. my wrapper contains isFirstResponder, all I have to do is use that in a custom class to have my own gotFocus and LostFocus. Which is my intention.

But I think of the numerous users who are not as fluent as me, and who indeed will live in pain. Pretty please, Xojo, have pity of the basic user.

@294031:@Jason King

What do you need to use lost focus for? If the user closes the app (home button x2, swipe) I don’t believe you’ll get an event anyway. Can you not use TextChanged?

LostFocus makes a lot of sense to format the TextField, or save its content.

[Michel_Bujardet]

BTW, since indeed there is not way to know when the app ends, I am regularly using lostFocus to save the content of the TextFields, and TextAreas.

That is a challenge in iOS apps, since there is no such thing as CancelClose for housecleaning upon shutdown.

[Sam_Rowlands]

@294055:@Michel Bujardet

That is a challenge in iOS apps, since there is no such thing as CancelClose for housecleaning upon shutdown.

What?! Is there a deactivate event for the view?

[Tim_Parnell]

@294059:@Sam Rowlands

What?! Is there a deactivate event for the view?

Yes. You get a notification when your app is about to go into the background. You can use this very brief period to save the state of your app so it can restore properly - but it is not for save on quit type actions.

And there is no CancelClose, because iOS does not give your app that much power.

[DaveS]

I don’t know if “Xojo for iOS” exposes or provides any access to these events, but iOS does supply these

• didFinishLaunchingWithOptions : similiar to App.Open
• applicationWillResignActive : the app is about to surrender to something like a phonecall
• applicationWillEnterForeground : the app is about to return to active status
• applicationDidBecomeActive :
• applicationWillTerminate : Called when the application is about to terminate. Save data if appropriate.

NOTE : THESE ARE NOT NECESSARILY XOJO AVAILABLE FUNCTIONS, JUST AN ILLUSTRATION OF WHAT IOS OFFERS

Fyi… these are all defined in the AppDelegate of ObjC/Swift

[Ulrich_Bogun]

No need to use a delegate for these events. They exist as notifications too and can be caught by a UserNotificationCenter. Which is not part of Xojo iOS but many implementations exist.

[Eli_Ott]

Notifications are such a vital part of iOS, that they should be a part of the Xojo framework.

[Michel_Bujardet]

@294079:@Ulrich Bogun

No need to use a delegate for these events. They exist as notifications too and can be caught by a UserNotificationCenter. Which is not part of Xojo iOS but many implementations exist.

Is it part of iOSLib ?

[Sascha_S]

@294085:@Eli Ott

Notifications are such a vital part of iOS, that it should be a part of the Xojo framework.

+1

[Michel_Bujardet]

@294085:@Eli Ott

Notifications are such a vital part of iOS, that they should be a part of the Xojo framework.

+1
You should file a feature request, so we put points on it.

[Ulrich_Bogun]

@294086:@Michel Bujardet

Is it part of iOSLib ?

Yes, it’s in iOSLib and OSXLib, working with the same code. You can pull an iosLibNotificationCenter (or OSXLib…) on your layout which is a custom subclass of NSNotificationCenter that does the handling of the Notification objects for you, which means it will deregister them automatically when it is closed. In its open event handler you can register all the notifications you would like to watch, like

 me.RegisterNotification "UIKeyboardWillShowNotification"

(or whatever strings you find as Notification constants in Apple’s documentation.) Optionally you can pass the object to watch too, but I have not included a convenience wrapper for that yet.

It will then fire its Notification event when it receives a registered notification, forwarding this as an AppleNotification (NSNotification) object where you can read the name and userInfoDictionary from it. You could subclass this as well and build a AppNotificationCenter that fires different events like the ones listed by Dave. Or if you don’t like the structure, take the main class AppleNotificationCenter and override the callback block that usually triggers the events.

Both libraries have demo windows/views with a NotificationCenter.