I'm experiencing a weird issue with my Swift 2.0 app.
I have a (editable) UITextView defined in my storyboard.
If I leave the text property empty in the storyboard everything is working as expected. But when I enter the text Kaasje (in the storyboard and recompiling), the app freezes when loading the nib (navigating through segue) and the CPU jumps to 100% (the app remains stuck).
The app will never reach viewDidLoad at this point.
It makes no difference when changing between fonts or fontsizes, behavior remains.
Pausing in Xcode does not leave me with anything useful, the main thread is busy without specifying any function. Nothing is logged to output nor any logs are created.
I'm running iOS9 on a iPad Air, the app has a built target of iOS8 and runs landscape-only.
Has anyone ever experienced anything like this before, and might have an explanation for this behaviour?
As far as my assumptions: Something goes wrong when calculating the text-size which results in a infinite loop while either calculating the size or adjusting the frame.
P.S. It happens with other texts too, but "Kaasje" always fails. It seems to fail when the the text is only 1 line. Longer texts tend to succeed aswel as leaving it empty.
As suggested in the comments there seems to be a bug in Xcode 7 in combination with iOS9.
I ended up recreating the entire view, the problem did not occur again.
Related
I am making a Xamarin.Forms project, and I am in the end of my app, but something really strange have happened. My app starts up with no labels (!?), meaning they are invisible or not created at all. Everything else seems to be working, until I press a button that is supposed to change the label - when I do this, the app freezes. I get no exception in Visual Studio, though.
One problem is that my breakpoints in PLC code never hits, only those I place in the iOS code. However, the buttons not related to changing a label works, so I know the PLC code have been ran. If I let the app run for a little while, and then press the pause-button in VS debugging to see where in the code I am, it stops at
UIApplication.Main(args, null, "AppDelegate");
.. in Main.cs. I dont know if this is correct or not, when I run on Android, I get a Break Mode - No code is currently running.
I have been trying for hours to debug, reinstall, restart, clean and rebuild, but nothing seems to help. My code works perfectly in Android, and it worked in iOS 1 week ago. Anyone have any ideas what is going on, or what I can do to debug some more? Or must I make a new project and try start over?
Edit: I have also tried different starting pages, and all are the same: all views loads except those with text in them. I have a page with an Editor in it, and I can write in it, but no text is appearing inside of it. Only button have visible text. I do not use a custom font for my labels, I have not specified anything.
Waking up fresh in the morning, I found my issue in 15 minutes..
After altering my Google search to TextView iOS instead of Label Xamarin, I found much more answers. Thanks to this question and answer.
Basically, changing anything on the labels in the constructor of the page (even after InitializeComponent()), will mess up the view. I moved my code outside of the constructor (in the protected override void OnAppearing() method), and now it is working again.
The freeze part was not related - this was my custom menu that covered my screen with an invisible layout eating up all clicking events. A bit confusing, none of these issues are present in Android, but there you go.
I'm having trouble with a slowdown that occurs in UITextView on iOS 7 when typing lots of text. I put a tracer in NSLayoutManager and identified that drawGlyphsForGlyphRange runs N*2 times, where N is the number of times your lines word-wrapped.
Here is the sample code:
https://github.com/philipkd/UITextViewSlow
To reproduce the problem run it on an iPad and attach a physical keyboard. Mash the letters and the space bar for about 15 seconds, and notice it slows down. Then when you try to type normally, it's really slow. That's an extreme example, but if you just try typing two paragraphs at a reasonable speed, it'll jam up.
This is not a problem with UITextView on iOS 6.
Turn off Background App Refresh in Settings General. Also, get rid of NSLog--they slow down beyond what it takes them to print.
I was able to reproduce the slow down effect on iPad under IOS7. In fact IOS6 did not have Background App Refresh.
I believe Apple aims for top of the line models, all others have to adjust.
Is the slows down happen when you plugged in (Xcode debugging) your ipad to the macbook/iMac? If yes, try to unplug the cable and try it again with the cable unplugged, see if it still slows down or not. If not, then it only happen when debugging process. (It's just my guess, since I'm not owner of an external keyboard)
Working on an AIR iOS app and noticed a strange thing.
In my app I have a navigation panel that displays over the main content-holding Sprite. Having this panel display was causing the app to crash on iPad1 (guessing too much memory). So I added a function to basically draw the content-holder Sprite (via BitmapData draw function) into a Sprite above it, and turn the content-holder visibility off. Basically, taking a screenshot.
However, I'm seeing on 2 different iPads now that any dynamically added text in the content-holder isn't being drawn. Sometimes, the first time it does, but not after.
One thing noticed is that turning off the cacheAsBitmap property of the text fields fixes the problem. Unfortunately, that is not an option as the app is very text heavy and the performance is noticeably slower if the dynamically generated text isn't bitmapped.
Any ideas on what may be going on?
Thanks in advance for any help.
-Mark
Looks like cacheAsBitmap on the dynamic text fields was the problem. By turning that off temporarily, taking the screenshot and then turning back on when done with screenshot, I was able to work around the issue.
Not sure if it's an AIR/iOS issue or maybe a lack of memory?
FYI, in case somebody sees similar problem. Hope that helps.
iOS 6 SDK. Xcode 4.5.
Using storyboard and arc. I am making an application that consists of a number of calculators that compute various formulas. On one scene, I'm using 8 UIButtons that have a PNG file as a background image, and they are labelled as different formula categories to allow the user to navigate to 8 different formulas which are contained in 8 different scenes.
I'm using modal segues and am utilizing the [self.presenting dismissViewController] method to dismiss each scene. That all works fine.
On one calculator in particular, I've set up the scene to resemble an actual calculator. I used a UIImageView with a UILabel on top of it to act like a display. Even without code attached to it, when running on my device, I notice that the transition gets hung up when segueing to that scene. I'm not sure why. Also, whenever I hit a button I get a receives memory warning in the console. I'm also showing a leak in instruments.
This app works perfectly in the simulator but not on the actual phone. I'm not sure what's wrong. Could it be my compiler settings? Or is it the fact that I'm not programmatically setting up the button images? Even when there is just a UIImage with a blue picture PNG and a label on top of it, no buttons or a viewcontroller for this view, it still gets hung up.
I'd appreciate any tips or tutorials or just plain tell me what I'm doing wrong lol.
Thanks.
I found out what was wrong. I was using a very high resolution image on each of those buttons. When I replaced it with a low resolution image the memory issue went away
I have an iOS app that, in one view, makes a toolbar in code. Nothing fancy here; just a bunch of standard UIBarButtonItems (initialized with initWithImage, and each one invoking a different selector), added (along with spacers) to the toolbar using UIToolbar setItems:animated (with no animation).
This works fine most of the time... but sometimes, after going to another view and back to this one many times, the toolbar's touch-handling appears to be off. It highlights and invokes the wrong button. It's not always the same wrong button, either; sometimes it's one right next to the one I actually tapped, but other times it is further away, even clear over on the other side of the toolbar.
There is no pattern to it, but if you try long enough (switching to another view and then back to this one), it always happens. It seems to happen more often when the other view is at a different screen orientation (forced by its shouldAutorotateToInterfaceOrientation implementation), but even when all views have the same orientation, it still happens now and then. When it happens, my selector gets invoked with a sender that matches the button that was actually highlighted, rather than the one I touched. So it really seems to be a matter of something in iOS not processing the touch correctly.
My google-fu has utterly failed to turn up any other reports of this issue... seems like it must be an Apple bug, since none of my code is involved in the toolbar touch handling. This happens both in the simulator and on the device, under iOS 4.3 (haven't tried other versions yet).
Has anyone else run into this issue? Any suggestions on how to avoid it?
OK, I found the problem. It wasn't the code that creates the toolbar itself; it was where (and how often!) it was being called.
This was legacy code, and we hadn't noticed that the create-the-toolbar code was being called from the view's didRotateFromInterfaceOrientation method (for reasons we can't imagine). That method gets invoked quite frequently, and the old toolbar wasn't being torn down, so it was creating toolbars on top of toolbars. Not too surprising that the touch handling went wonky in that situation.
Deleting the call there (and putting it in viewDidLoad like one would expect) solved the problem. Sorry for wasting everybody's time... but maybe the next person to stumble across screwy toolbar behavior will find this helpful.