I am new to iOS development and i am facing an issue.
Putting breakpoints in my app before running the app in simulator is causing unexpected behavior.
If I put breakpoints in my app then I am not able to type in to text controls or click buttons i.e. it makes entire view read only.
If I disable the breakpoints, my app runs fine.
Any pointers to this issue will be really helpful.
Thanks
You are hitting a breakpoint which pauses execution of the main (UI) thread. Your application will not be able to process touch events when it is paused. Click the play button in Xcode to resume execution.
Related
We have a hybrid app that is a mix of Objective C and Swift that is showing some strange behavior in classes that haven't been touched in a long time. If we do a fresh build from Xcode the app works fine, but if we close the app and restart it, it behaves totally different. We re-attach the debugger and have seen viewWillAppear called but viewDidAppear is not called after re-opening. Other things like NotificationCenter Observers don't fire after closing and re-opening either. We've tried to track this down and I wish there was code that I could share that would point in the right direction, but it's a general thing in the app that is happening across most classes. When building for test flight it behaves the way that misses the viewDidAppeaer and the observers.
SIAlertView sometimes freeze application on dismissal of alert view.
When clicking one of the buttons, even "Cancel" or any button, the handler block executed and everything seems to be in order, except that the UI becomes non-responsive, and I have to kill the application.
I'm using CocoaPods.
Can anyone suggest how to debug this issue or solve it?
Thanks in advance.
Since moving to Xcode 9 I observe a strange behaviour while resuming from a breakpoint on Simulator.
My app uses multiple threads significantly, and some breakpoints are set in the code on different threads.
Once the app stops on a breakpoint and then is resumed (repeated a couple of times on different breakpoints)
it freezes eventually forever, which looks like a deadlock on a main thread:
UI is unresponsive
(however some UI animations are played) and the callstack shows __ulock_wait on the main thread.
In the same time
other background threads shows various actions e.g. on logging mechanism (CocoaLumberjack),
downloading pictures (Alamofire), etc.
This is not happening while testing on the same breakpoints on a device connected to the Xcode or on previous version of Xcode.
I've also tested the behaviour on one of many PODs' demo app used in the app with the same result.
Described behaviour brings debugging experience to annoying level and even breaks possibility to debug some part of the code completely.
Could anyone confirm a similar, unwanted behaviour?
I have an app that work in background because i add App provides Voice over IP services to info.plist
when my app go to background and touch twice on home button and exist app from background , it crashed
how can i check why happen this problem?does any event call from AppDelegate when do it?
In Navigator -> Breakpoint Navigator: Add Exception Breakpoint
Now simulate your crash, your application will stuck on the line your app got stuck, check thread and objects allocations.
I guess this may help you out a little bit :)
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.