In the output window, when I bring up an menu (subview) over the current view, but NOT covering the iAd... I also, just to be sure, Did a BringSubviewToFront (iAds);
However, it still issues the message in the output.
Worse, if I touch on the ad it won't activate it. I'm pretty sure this would result in not only my app getting rejected, but also in making zero from ads...
I have several different views that I pop up in this fashion, one of them seems to not have the problem... However, I haven't figured out any differences between them...
-Chert
Turns out I had some old code that created a controller for that view (now a sub-view), and It appears that it was getting confused with a view having a subview that is registered to another controller from the controller that it is registered in... Can't say that I blame it for getting confused! -Chert
Related
Basically this issue started when I updated my app to run with iOS 9. Without making any change in the code now a white square appears over the picker view, but it works normally.
Note that the user can hide and show the picker views and the cells they're in. If you need more info leave a comment.
UPDATE: Here is the full screenshot of the Table View:
UPDATE 2: The following shows when I preview (press bar space button) the _pickerView property in the variables debugger. This makes me think the strange view is inside the UIDatePickerView and that it's a bug.
UPDATE 3: Extensive Research
So I finally did more research using the view inspector and the debugger and I got to some conclusion, although I still don't know how to solve it.
Using the view hierarchy debugger I found out the the white strange view it's a UIPickerTableView inside the UIDatePicker.
Here we can see the subject selected in blue and it's name at the top of the screen. I also wrote the whole hierarchy from the picker view to the subject so you can see it.
Next step was inspecting my datePicker var with the debugger to see if I could get to that UIPickerTableView causing problems. Inside it I could find 3 views, each one corresponding to each component (day, month, year). Let me show you the quick look of each one of these:
Click the pics to enlarge
In the first and the third one (day and year) we can see what look like some misplaced views next to the actual labels with the numbers. These properties, as you can see in the screenshot, are UIPickerColumnViews. I didn't go any further but you can imagine that if we inspect that property we would find the subject as a UIPickerTableView.
After all that I got to the conclusion that the misplacement of those views is what might be causing the issue. And that's all for today.
FINAL UPDATE
So some days after filing the bug report Apple answered and marked it as a duplicate. So I guess we just have to wait they fix it. You can check the radar at rdar://22566989
Apple Developer Relations marked my bug report as a duplicate, so I guess it is an SDK bug that they'll have to solve. It is still open by the time of this post (12 Oct).
Workaround
In the viewDidLoad() method change a property of the date picker, for example the mode. You don't have to leave it changed, you can set it to anything and then change it back to what you actually want.
Here's the hack that worked for me: If you change the UITableView separator style to None the problem goes away. Seems like a bug on Apple's end, like the numerous problems we are finding in iOS 9.9
I had the same issue, i discover that happened because my UIDatePicker was separate from view of my view controller. I added this view as a sub view in code. To solve this problem, i add the UIDatePicker in viewDidLoad method, this is helped me
I've had a crash report, it's a real edge case. I launch a pin security view from applicationWillEnterForeground (the feature is optional). However, I have some form sheets which I use in some situations in my app.
So the pin view is added as a subview on window and a keypad is presented.
When the form sheet is showing, it appears on top of the pin view (which is wrong) and an action on the form sheet causes a crash, when showing another keypad.
So I believe I need to dismiss any form sheets if the application resigns / becomes active.
I've looked into sending a notification to the form sheet in applicationWillEnterForeground, however I'll have to firstly determine if a form sheet is visible then add method to dismiss it every form sheet.
This seems a lot of work for an edge case, can anyone suggest an alternative approach?
For completeness here's the error...
The layout constraints still need update after sending -updateConstraints to <_UIKeyboardLayoutAlignmentView: 0x14e59b790; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = >. _UIKeyboardLayoutAlignmentView or one of its superclasses may have overridden -updateConstraints without calling super. Or, something may have dirtied layout constraints in the middle of updating them. Both are programming errors.
I've seen this...
NSInteralInconsistencyException - UIKeyboardLayoutAlignmentView
However, I'd still need to end editing in various form sheets, which I can't access from applicationWillEnterForeground.
OK, after researching the issue I discovered that I needed to observe the application state. On notification then check if various objects are load and if so, resignFirstResponder when the keyboard is shown (aka is editing) (I had a text field in an UIAlertView), dismiss an UIAlertView and then dismiss in the view controller used in dialog.
Shesh... so not as simple as I was hoping.
Although this is an edge case for me, I figured I should fix it.
I also found this which will dissmiss alertviews https://github.com/sdarlington/WSLViewAutoDismiss
Which will save me a lot of hassle in simpler scenarios.
Apparently since iOS4, Apple recommends cancelling UIAlertViews and UIActionSheets when an application becomes active.
So in an iOS app I'm using a UINavigationController as the root view controller. I then push a few ViewControllers on the stack, let's call them A, B, C and D.
Now if I try to pop D from the stack, I sometimes * run into the following problem:
After calling popViewControllerAnimated, the view of the topmost view controller (D) remains. If I display the stack however, it is displayed correctly, i.e. A-B-C is displayed and D is gone. The pop method seems to do just what it's supposed to but the view does not reflect this.
I have tried various other approaches, (popToRootViewController, popToViewController) instead but the behaviour doesn't change (i.e. the stack is printed correctly but D's view remains). I have called setNeedsDisplay on all views that seem to make sense.
After popping D, I can still push and remove other view controllers. The stack reflects those changes, the view does not. Also, D's view remains responsive, i.e. it is not frozen and the app does behave correctly in the background. All views are very simple, there are no tabbed views or the like, just a couple of labels and buttons.
I have read a number of posts on SO and elsewhere about people having similar problems but none of the solutions seem to fit here. Does anyone have an idea why this happens?
*_ I haven't been able to figure out under which circumstances exactly. I first thought it was because I am popping D very soon after pushing it, but it also occasionally happens when there is more time between push and pop.
Only reason i can think of where this might happen is if you are not doing that in a main thread. If you are doing it after some network call, then do make sure you are going back to main thread. Sometimes, app won't crash if you do UI work on background thread but rather will behave like what you are seeing!
The problem seems to have been one of timing. As I mentioned, the push and pop operations (of D) sometimes do happen rather quickly after one another. Adding a delay of 2500 ms solved the problem. Adding 500 ms did not (always). Since neither is acceptable to me, I switched to a custom container view controller and therefore didn't spend a lot of time on figuring out what the minimum delay would be.
Just as sidenote: Changing from dispatch_async to dispatch_sync didn't have any effect. The delay seems to be necessary either way.
Thanks for everyone's help. I'm going to close this thread - if someone can provide a more complete answer as to why things are the way they are, please post it and I'll mark it as the correct answer then.
I am not sure what I clicked, but I was making a home screen for my first app on which I am learning, and I added something called the "Root View Controller" How do I get rid of it? I didn't mean to add it.
Also, are controllers here kind of like the code which gets processed after a button is clicked? I have not gotten to that part of the tutorial :)
Thanks!
If you are using Xcode 4, you can easily delete controls by selecting them on the inspector area on the left. Just click the item to delete and hit backspace.
Edit: Saw the image now. Just click what you want to delete and hit back space. As simple as that.
The code that gets processed after clicking (touching actually) is linked through IBActions. You should look those up, since they are a VERY important part of apps. Let's say they are the "event handlers". Good luck.
Click on that "Root View Controller" to select it, then press your "Delete" key on the keyboard. That should remove it.
View controllers usually receive actions (i.e. the IBActions that #Fiire referred to... +1 to him!) when you press on a button. If you didn't set up any actions pointing to the accidentally created root view controller, you should be completely safe to delete the view controller. And if you did set up actions, you can find them using the object inspector and then "X" (cancel) out any connected actions from buttons or controls to the view controller.
Two points here, just to add to the other answers. First is that Xcode has a lot of levels of undo, so usually control-z can bring you back. But Xcode does crash and then you cannot undo. For this reason, I (like many other devs) use Git obsessively as they work to be able to recover from situations like yours. A test project like this is a perfect place to get your git on... or Mercurial or whatever solution you happen to like.
I'm trying to use the MFMailComposeViewController in an iPhone app I'm building, but I can't get it to work correctly. I was following the Apple's sample code MailComposer. As you can see in the sample, the MFMailComposeViewController lets you type in whatever message you want, and in the case of recipients you can either type the email addresses or pick them from your contacts. My implementation is exactly as in the sample, and the MFMailComposeViewController appears and disappears as expected. However, the controller seems to be in read-only mode; i.e., the user can't change any of the fields. I can change the values of the different fields programmatically before showing the controller, but once it's visible no modifications can be done to any of the fields. I have checked everything a bunch of times, but I can't find anything different between my implementation and Apple's. I'm stumped! Has anyone encountered this issue before? Any suggestions?
Thanks a lot for any help you all can provide!
Found the problem! A parent view controller in my application listens to shake gestures, which requires that view controller listening for shakes becomes the first responder. The parent view controller needs to call
[self resignFirstResponder];
before showing the MFMailComposeViewController. After adding that line, the MFMailComposeViewController worked like a charm.
In general, any view controllers listening for shake gestures should resign first responder before showing any other view controllers. Otherwise, the app will continue to respond to shake gestures even when the corresponding view controller is not visible, which can definitely lead to even worse problems than the MFMailComposeViewController showing up in weird read-only mode.