There is always a delay (2-3seconds) on the first time the keyboard got invoked in application. Is there a method or a trick to improve this experience? I tried to use NSTreading, but it crashes on error "only perform on Main Thread" if I use [textfield becomeFirstResponder]; Any ideas?
As a general rule, do not try to touch UI elements from a background thread unless the documentation specifically states that it is thread-safe.
In your case, attempting to preload the keyboard in the background will not work. Keep in mind that the keyboard isn't created just within your application — it's shared across the system. That means if the system decides it needs to clear up some memory it will most likely "uncache" the keyboard if it's not visible.
If this is occurring in the Simulator, that's most likely because you're quitting the Simulator after every test run. As a result, the keyboard has to be loaded each time you run a test. If this is happening on a device, however, then most likely your device is frequently running low on memory.
That being said, if the instant showing is incredibly important, you could always try to use the old trick of making an invisible UITextField first responder, then immediately resigning first responder in order to force the keyboard to load.
maybe try a different keyboard? or try going into setting and looking at the input options, and go to keyboard. most of the time its because the programming is lagging, or you have more programms running in the background
Related
Apps set to Screen time are strongly constrained by their behavior.
If the screen time starts while the app is running, the nature of the app causes problems in operation.
Normally, the setting screen is called by the following code, but I do not know how to call Screen Time.
UIApplication.sharedApplication().openURL(settingsURL)
Do you know how to do that? Or tell me if there is another way around it.
I have an unreasonable delay (3 seconds) in my iOS application between the time a user taps a control and when the keyboard is shown.
To reproduce this, I give textfield #1 focus then quickly resign the keyboard with the keyboard resign button and tap textfield #2.
If I tap between the two fields without manually resigning the keyboard I don't see this delay.
I've tried debugging the app to see the program flow but I'm not good enough with the debugger to actually trace anything, I always end up in assembler.
I know that the delay happens after textFieldShouldBeginEditing returns and after inputAccessoryView returns, but before a kUIKeyboardWillShowNotification is fired. My question is, what happens between these steps? What does the program flow look like between the call of inputAccessoryView and the notification for UIKeyboardWillShowNotification?
I believe that if I could just figure out what IOS is executing in this delay I could come up with a work-around.
I honestly believe this was an IOS 8 problem. After changing the target to 9.3 this issue seems to have all but disappeared.
It seems like the fade animation between the launch screen and my first view is really slow.
I don't think it used to be like that. Is there a way to control the speed of that transitional animation?
I looked at some apps on my phone and the launch screen doesn't fade as slowly as mine. What things could I have done to affect that?
(No I don't have slow animations turned on, only the fade animation is slow)
In WWDC 2012 video iOS App Performance: Responsiveness they enumerate a whole list of issues that have impact on the app startup time, ranging from attaching to unnecessary frameworks, optional linking to frameworks that you really could make required, the use of static initializers, overly complicated initial scenes, too much information stored in preferences, etc.
That video covers a range of topics, like the above, which impact startup time. In the demonstration, they show how one might benchmark the startup time. Unfortunately, in my experience, there's a good chance that you might not be able to do anything to fix this issue (e.g. you need certain features and therefore need certain frameworks), but it's still an illuminating video and it might give you some ideas of things you can try to alleviate the start-up performance issues.
If your app splash screen show more time, so please check following things in your app.
1. AppDelegate.m
in didFinishLaunchingWithOptions method have you called any heavy method which takes more time for finish task if yes then change that method location, basically in appDelegate class don't write any heavy methods.
2. first view of your app.
check viewDidLoad() method, if you call many method or any heavy method from here then your launch image will show still your control not come out from viewDidLoad method, so if you want call any methods at view launch time then call them from viewWillAppear or viewDidAppear method (in viewDidAppear method don't call any UI related methods)
I never figured out what was going on here, but the next day when I started up xCode and the simulator it was back to the normal loading time.
I am getting a strange behavior when I reopen my app after it loses focus from the home button. On the simulator the app screen goes black for 5 seconds or more before the application is resumed. On the test device, the application either does the long delay or quits entirely and resets to starting state. I have put NSLog debug comments in the “applicationWillEnterForeground” and “applicationDidBecomeActive” but these only appear after the long delay so I will assume for now that nothing in these functions cause this delay.
I am using the following components in my program:
* a Tab Bar Controller
* 2 Timers, the Map kit
* IP socket streams
* 24 ViewControllers strung together on a storyboard.
* quite a few background images and image buttons
I would happily post code if I know what parts of the program was causing this error, but as it is I am clueless. Has anyone else experienced this type of error? Do any of the components I have listed have a history of causing similar errors?
I was quite far in development when this bug was discovered and I did not test for loss of focus via home button during the incremental development process. Other, smaller projects (which used sockets and timers) did not suffer from the same bug on the same test hardware.
I am using “applicationWillResignActive” to disable the timers, and close the streams. I am using “applicationDidBecomeActive” to restart the timers, and reopen the streams. The delay is occurring before “applicationWillEnterForeground” and “applicationDidBecomeActive” is run. Further more I tried disabling the code that initiates the streams and timers, but this did not have any effect on the bug.
I am using xCode4.4.1, ios6, and am building exclusively for iPads.
It's possible that the debugger is playing tricks with your mind regarding when it shows that you hit a breakpoint and the code execution of applicationWillEnterForeground. I suggest you commit your most recent code to source control and start deleting sections one at a time till you see the behavior go away.
I have a hidden UITextField that when a the user is required to enter a character from the keyboard is sent:
[txtField becomeFirstResponder]
This text field has an event on editing changed that then calls a function to handle what was entered how I need it.
The user then selects an okay button that calls the following:
txtBox.text = #"";
[txtBox resignFirstResponder ];
I have tracked some memory problems all the way through to the line [txtField becomeFirstResponder]. When this is called, my Apps memory usage doubles on the spot and I receive a memory warning (even though code run). If I remove it (I have no keyboard of course!) but the memory issue goes away. I have read and tried a few approaches like removing the keyboard at Delegate level but without success. I am almost at the point of creating my own Keyboard.
Even though it is a lot I could probably work with this increase providing it would get properly released once I dismiss the keyboard - but it doesn't. The footprint of the App just gets heavier and heavier and for the life of me I cannot work out why.
First question is, is it possible that above is causing me the problem? I presume it is unlikely.
If not, any suggestions where to look / why I would receive such a rapid increase?
Heres a screenshot of Instruments - red line indicates where I call becomeFirstResponder:
http://i.stack.imgur.com/E7PaU.png
(they wont let me upload it - sorry!)
That isn't a good way to track memory leaks/problems. If there is a memory leak, instruments will show a leak, and that you can fix. You shouldn't assume the OS will free up memory just because you closed the keyboard (if anything, it probably is lazy loaded and cached).
Though I never had a problem with that, It is possible that your memory footprint increases when you show the keyboard. You didn't say how much memory is actually being used, so I will assume it is a small app and doubling that when opening a keyboard should be fine.
The OS caches all frozen open apps so memory is always tight. When receiving memory warnings clear what you can and let the OS handle the rest. If needed it will kill background apps. It doesn't mean that something is wrong with your app.