Our code was working with previous versions, but on iOS13 the custom notification content height is not working properly. Everything is visible as it should be, but the buttons are not clickable after a part of view. So for example after 320 pixel the custom views are not clickable. Running the same code on ios12 works.
func didReceive(_ notification: UNNotification) {
let content = notification.request.content
self.preferredContentSize = CGSize(width: self.view.frame.size.width, height: contentH)
self.view.setNeedsUpdateConstraints()
self.view.setNeedsLayout()
}
Any solution? Or is it an iOS13 bug?
##Update :
We are developing our app on iOS14 beta and the issue is still here. Just one thing is new related to this. When we are tapping the screen this is what we get.
NotificationContent[44466:2340668] [Assert]
UIScrollViewDelayedTouchesBeganGestureRecognizer was moved to a view
that isn't a scroll view, so we can't determine if the touch is on a
scroll indicator.
We are adding all the subviews to the viewcontroller's view (no custom containers).
Im not sure where you are setting the heights and widths from but alot has changed following IOS 13 for Notifications and Push notifications both , While push notifications remain a big hassel having to change tockens and more biggest effect for notifications is many of the UIApplicationDelegate lifecycle methods are no longer called.
There are now corresponding lifecycle methods in the UISceneDelegate. This means there is a need to listen to the UIScene.didEnterBackgroundNotification notification under iOS 13. Now that you may think that it does not have a direct effect on a height or a width of a notification , i faced something of that sort and having moving someone them accroding to the New lifecylce methods they rendered properly .
Im Not sure if your issue will be sorted but also take alook at the below link. Might help you.Even i refered to this while i was facing the issues
View controller responds to app delegate notifications in iOS 12 but not in iOS 13
Related
it's all start from a lot of warnings about the width of collectionView cells,
That was written to console every time I press home button.
I thought it's something with size of the cells and tried to fix it.
Only after some testing, I notice that viewDidLayoutView is called with wrong view.bounds, and that make the collectionView cell bigger(in width) than collection view.
For now, my fix is to check if app is on background state and ignore viewDidLayoutView.
why it's happen only in iPad and not on iPhone ?
it's whirred that only now I saw this happening. it's something new in iOS ?
what is the right way to handle this ? I don't use auto-layout
its calling with wrong bounds and I don't want to calculate all cells frames just for the user to return to the same orientation.
I feel like I'm missing something very basic here OR there is some change on iOS that I'm not aware.
why it's happen only in iPad and not on iPhone ?
Because when you click Home on an iPad and the app goes into the background, the runtime takes two snapshots, one in each orientation, to use in the App Switcher interface (and in preparation for when the app comes back to the front). That means it has to rotate the app, which triggers layout, and so your viewDidLayoutSubviews is called.
it's whirred that only now I saw this happening. it's something new in iOS ?
what is the right way to handle this ? I don't use auto-layout
its calling with wrong bounds and I don't want to calculate all cells frames just for the user to return to the same orientation.
I feed like I'm missing something very basic here OR there is some change on iOS that I'm not aware.
Well, iPads have been behaving like this for quite a long time. It isn't my job to explain why you haven't noticed. Basically you should not be doing anything time-consuming in viewDidLayoutSubviews.
for now, my fix is to check if app is on background state and ignore viewDidLayoutView
That's perfectly reasonable. I do the same sort of thing. For example (this is a different method, but it's the same idea):
override func viewWillTransition(to size: CGSize, with tc: UIViewControllerTransitionCoordinator) {
if UIApplication.shared.applicationState == .background {
return
}
// ...
}
Be warned, however, that if you are doing manual layout and you don't do it when the app when goes into the background, your App Switcher snapshots may look wrong. Also, the fact that you are not using autolayout is a red flag. You should probably use it.
In all versions of iOS — including every beta of iOS 11.0 except the GM, 15A372 — views inside of a UINavigationItem's titleView would receive touch events as normal, making it possible to have buttons in the title view.
In build 15A372, subviews of the titleView do not receive any touch events, so buttons in that view are useless. I've tested with both devices and Simulators running iOS 10 and don't see this behavior. I've opened rdar://34499607 about this and will update this question when I hear back, but I want to know if anyone else has encountered this, or has any temporary solutions.
Apple's documentation about the titleView property specifically notes that "custom views can contain buttons," making this a confusing change.
If this is the intended behavior, it's infuriating that they've waited until the almost-literal eleventh hour to make this significant change and neglect to include it in any documentation or release notes.
You can see this question link
Just override intrinsicContentSize property in your view:
import UIKit
class HeaderView: UIView {
override var intrinsicContentSize: CGSize {
return CGSize(width: 400, height: 55)
}
}
I'm currently building an iOS App in Swift and I got some problems. My settings view is a tableviewcontroller. It's a grouped one. My Table View is dynamic, fonts are dynamics.
I would like to interact to the change of font size from the settings app.
If my application was already running, the font size change but the layout is just broken. (change from the smallest to the biggest font)
Image : Layout bug
If I restart my app with the new font settings, there is no problems...
Here is a XCODE project example, you'll see the bug.
Could you please help me to find a solution ? Thanks.
The UIContentSizeCategoryDidChangeNotification is what you're looking for.
Per the docs:
Posted when the user changes the preferred content size setting.
This notification is sent when the value in the
preferredContentSizeCategory property changes. The userInfo dictionary
of the notification contains the UIContentSizeCategoryNewValueKey key,
which reflects the new setting.
Example callback implementation:
func handleContentSizeCategoryDidChangeNotification(notification: NSNotification) {
self.questionLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleBody)
}
After you change the font size try to call
self.view.setNeedsLayout()
it sets a flag in the UIView that marks it as needing layout change.
Also you can try to call
self.view.layoutIfNeeded()
Apple documentation says :
Use this method to force the layout of subviews before drawing. Using the view that receives the message as the root view, this method lays out the view subtree starting at the root.
Hope that help you
Finally, I found that it's an iOS bug. I find the same bug in the Apple Apps.
The bug happens when you set the smallest font, quit the app and set the biggest font.
Thanks for your help.
Bug Settings App
I have an UITableView with three dynamic rows. When displaying the UITableViewController the first time everything works fine. After a rotation the rows which have a data in it get an indentation despite I set setLayoutMargins to zero. I cannot reproduce this issue in another project until now. It is only appearing in iOS 8 but but only on one table. The same source for the table is working in a test project without problems. The only difference here is that it is in a container with some other views.
I checked auto layout constraints, the rotation methods, commented things out - all without success. The change of the indentation occurs between willRotateToInterfaceOrientation and didRotateToInterfaceOrientation or after viewWillTransitionToSize. I even updated to iOS 8.1 with the same results.
Has someone expeerienced a similar behavior?
PS:
What I've also noticed that when setting the layout margins to zero on iOS 8 the animation is not as smooth as it would be with the default values (with indentation). On iOS 7 the animation is always smooth.
EDIT:
I tracked some things down. If a UITableViewController is embedded into an UINavigationController the indentation happens on rotation. If you rotate further it goes back to it's set indentation (no indentation in my case).
If the UITableViewController is embedded into a container (and this container is in a navigation controller) than after the rotation the cell get it's default indentation back. If you rotate further this behavior stays the same (always indented).
Are some events not send to the child view controller or none of you uses a UITableViewController embedded into an UINavigationController?
In my opinion it is a iOS 8 Bug or a Xamarin Bug. Perhaps one other could verify if it is the same with his installation. I'm using Xamarin Studio 5.5.2 with Xcode 6.1.
One ugly solution to this is this:
public override void DidRotate (UIInterfaceOrientation fromInterfaceOrientation)
{
base.DidRotate (fromInterfaceOrientation);
// otherwise cells are indented! iOS 8 Bug?
TableView.ReloadData ();
}
One could use reloadData or reloadSection in didRotateFromInterfaceOrientation, despite it is a deprecated function. But there is no viewDidTransitionToSize and I also have to support iOS 7.
Edit:
Another solution I have come up with is to draw a custom separator line. This only works for iOS 8 and would answer the question (despite I've another issue on iOS 7 where this approach doesn't help).
So I'm creating and showing a custom window in my iOS app because I'm writing a dynamic alert view that also functions like a growl/toast alert. It works AWESOMELY in ios6 (Hopefully I can open source this baby and you can all check it out)
But anyway, when I run this in ios5, the window that my alerts exist on doesn't seem to rotate with the device/simulator. No matter what, my custom window stays in portrait mode.
The UIWindow is just a UIView subclass, so there's no nice 'shouldRotate' delegate method.
I'm kinda stumped on why this is happening in ios5 but not 6. Any help would be GREATLY appreciated ^_^
My window has a rootviewcontroller, which I completely forgot about. I just needed to implement
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation{
return YES;
}
To get it to work.
:-D
It's usually not recommended two use multiple instances of UIWindow in one iOS app. The only valid reason to do so is to support external screens. You should use a UIView instead, ideally managed by a UIViewController.
I assume, (since you didn't provide any code, I can only assume) the reason why your window doesn't 'rotate' is, that it's simply not getting any notifications about device rotation. Only the keyWindow receives them by default.
I would highly recommend to redesign your app to use a properly managed UIView instead. If you desperately don't want that for some reason, you would have to register your instance of UIWindow to receive the UIDeviceOrientationDidChangeNotification and then (in the handler) evaluate what the new orientation is and change the window's frame accordingly (plus maybe other things that need to be done in response to the orientation change)