I'm currently migrating my app on ios 7 and I've been stuck for hours on the new navigationcontroller/bar management.
Before, when we had a navigation controller, we had a snippet like this :
UINavigationController *navController = [[UINavigationController alloc]initWithRootViewController:[[MainViewController alloc]init]];
In interface builder, we had the choice to set an existing navigationbar for the view and everything match the content of the real view.
OK so now, i have no clue of how to design properly with interface builder.
I still have my snippet to initialize my navcontroller. However in the interface builder for my MainViewController if I set a status bar to translucent or opaque navigation bar, i have an offset of 44px at the top (see below).
Interface Builder_________________________And the result
Now, if i set status bar to none, there is no offset at top but since the view on simulator is smaller because of navigation bar the bottom of the view in interface builder is cut off.
Interface Builder_________________________And the result
I guess i'm really missing something here but i can't find any topic or apple info in iOS7 Transitions Guide about that.
Thanks for your help
EDIT
As we can see in the pictures, the first child of the view is a UIScrollView which contains both labels, the problem does not appear when there is no scrollview. It also appears if it's a UITableView.
If a label is outside the UIScrollView, there is no offset to that label.
OK so i found the solution, I have set in my controller the property:
self.automaticallyAdjustsScrollViewInsets = false
I don't really understand the true benefit of this property though, (or why the default value is true)
The only documentation i found was there:
https://web.archive.org/web/20160405135605/https://developer.apple.com/library/ios/documentation/userexperience/conceptual/TransitionGuide/AppearanceCustomization.html
https://developer.apple.com/documentation/uikit/uiviewcontroller/1621372-automaticallyadjustsscrollviewin
Update
In iOS 11 automaticallyAdjustsScrollViewInsets is deprecated
You should now use:
self.tableView.contentInsetAdjustmentBehavior = .never
I also encourage you to check this question and its answer to get a better understanding of those properties
#Justafinger's answer worked like a charm for me as well.
Just wanted to add that this setting can also be adjusted easily from the interface builder.
Select your view controller
Click the 'Attributes Inspector' tab
Uncheck 'Adjust Scroll View Insets'
Enjoy!
I was running into this same issue, but I found a rather odd property on the ViewController in interface builder that seems to have been causing this for me. There is an "Extend Edges" set of check boxes. I removed the "Under Top Bars" check, and everything started laying out properly for me.
With automaticallyAdjustsScrollViewInsets set to YES (the default setting) there is a mismatch in scrollview positioning between ios6 and ios7, so to make them consistent you need to disable this setting. However, ios6 will crash if it comes across automaticallyAdjustsScrollViewInsets, so you either need to make a programatic change of automaticallyAdjustsScrollViewInsets conditional on ios7 or else switch off the option using the storyboard/NIB
I had a similar problem, after dismissing a viewController, the contentOffset from my tableView was changed to (0, -64).
my solution was a little weird, I tried all the other answers but had no success, the only thing that fixed my problem was to switch the tableView position in the controls tree of the .xib
it was the first control in the parent View like this:
I moved the tableView right after the ImageView and it worked:
it seems that putting the table view in the first position was causing the trouble, and moving the table view to another position fixed the problem.
P.D. I'm not using autoLayout neither storyboards
hope this can help someone!
I also face this problem.
UIScrollView content size is calculate by OS as other sizes, origins provided by constraint system - that's why OS has doubtfulness.
How to fix - You should explicitly define content size of UIScrollView:
Embed scrollable content to UIView (I rename it to ContentView)
Add constraints:
ContentView.Weight = View.Weight and ContentView.Height = View.Height
It seems like a work around solution is to view the storyboard file as "iOS 6.1 and earlier" (select storyboard file->File inspector->Interface Builder Document->View As. Positioning subviews in this mode shows the offset.
Thank you guys for the solutions! I struggled for hours trying to solve the problem. Everything was ok when there was no Navigation Bar involved but it went haywire the moment I embedded the ViewController in a NavigationController.
I solved it by unchecking the Adjust Scroll View Insets and the Under Top Bars. Both of these are located in the ViewController's Attribute Inspector. Thanks a million!
Accepted answer by #streem caused some weird behavior with UILabel acting as sections.
This worked for me:
if let navBar = navigationController?.navigationBar {
scrollView.contentInset = UIEdgeInsets(top: -navBar.frame.size.height, left: 0.0, bottom: 0.0, right: 0.0)
}
Related
I recently came across a fairly new cordova plugin called cordova-plugin-qrscanner (https://github.com/bitpay/cordova-plugin-qrscanner). I have been using other QR Scanners before, but those simply overlay some kind of native camera UI until the QR has been scanned and then return back to the app.
However, the approach of this plugin is a bit different. The camera is actually shown "behind" your app and you have to make everything transparent in order to see it.
This is very interesting because you can then easily add custom overlays with HTML and CSS. However, I am not quite sure what the best approach is here.
After adding the plugin and simply calling QRScanner.scan(displayContents); you can't see anything, but the scanner is already running in the background. I then recursively removed any styles (see simplest way to remove all the styles in a page) from the app and set the background-color to transparent to see if it worked. It did, but I could obviously still see the text that was displayed before.
I guess I could create and push a new page with my overlay on it, set the background-color to transparent and then navigate back once the code has been scanned. But this feels really hacky.
Does anyone have a better solution for this?
For example, is there a way to "swap" the whole visible part of the app with the overlay and restore the state after the code has been scanned?
Thanks for your help.
EDIT:
It's not the same plugin, but this article is relevant to my question.
http://www.joshmorony.com/ionic-go-create-a-pokemon-go-style-interface-in-ionic-2/
Applying the css styles works, but again, the rest of the app is not usable then.
#Andreas I had the some problem a few weeks ago. Here is how I fixed it:
1) First of all, create a class called lowOpacity on your theme/variables.scss, it has to be global, if you create it in the page's scss adding it dynamically won't work:
.lowOpacity {
opacity: 0;
}
2) When you show the qrScanner, you should apply the class to the ion-app element, and optionally register a backbutton action:
this.qrScanner.show().then(()=>{
let unregister = this.platform.registerBackButtonAction(()=>{
this.closeQrScanner();
unregister();
});
window.document.querySelector('ion-app').classList.add('lowOpacity');
});
3) Remeber to remove the class after the qrScanner scanned something ot was closed:
closeQrScanner() {
this.qrScanner.hide().then(()=>{
window.document.querySelector('ion-app').classList.remove('lowOpacity');
}); // hide camera preview
}
ngOnDestroy() {
this.closeQrScanner();
}
Hope it helps
I wouldn't make the app transparent, since I don't see the point of that.
Instead you would just show the contents of the camera in a div in your page, and layer other HTML elements on top of that using a higher z-index than the element containing the camera image.
As #vrijdenker said you should display the camera content to the right level and do not weirdly hack the CSS.
To do that you can remote debug your app to localise the camera container and apply some CSS on it to modify the z-index / display / etc.
Remote debug on Android:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/
Remote debug on iOS:
https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
You can do that on real device or on simulator
My app has a multi-pane tutorial-style view that users swipe through to learn about the app. This is implemented very much as described in this tutorial. Having implemented it for both iOS 7 and 8, I'm comparing how they work, and finding issues with the latter — I'm running Xcode 6 GM here.
It seems that the UIPageViewController is rendering the views after the transition is complete. I overrode the delegate methods to see what was going on:
- (void)pageViewController:(UIPageViewController *)pageViewController willTransitionToViewControllers:(NSArray *)pendingViewControllers
{
NSLog(#"Frame size before: %#", NSStringFromCGRect([(UIViewController*)pendingViewControllers[0] view].frame));
}
- (void)pageViewController:(UIPageViewController *)pageViewController didFinishAnimating:(BOOL)finished previousViewControllers:(NSArray *)previousViewControllers transitionCompleted:(BOOL)completed
{
NSLog(#"Frame size after: %#", NSStringFromCGRect([(UIViewController*)previousViewControllers[0] view].frame));
}
And here's a sample output:
Frame size before: {{0, 0}, {600, 600}}
Frame size after: {{0, 0}, {320, 568}}
This manifests like so: swipe to the left to pull in the next view, and note a 32-pt white space at the bottom of the new view. Once the transition is complete, it jerks into its proper layout.
Is this a bug in iOS 8, perhaps? I'm all out of guesses at this point.
I figured out you need to base your constraints on the view and not the layout guide of your view controller. This will ensure your view controller respects the constraints you set prior to the transition in a PageViewController.
you can do this like so:
Remember to uncheck "Constrain to margins"
For anyone having this issue, for me it appeared to be that I was laying out views "relative to margin" (a new feature in iOS 8).
Instead of:
Use:
I've been struggling with this for a few days.
I tried to implement it by instantiating the page ViewController from the storyboard. There was a definite resizing occurring. Checking the frame size in
pageViewController:viewControllerAfterViewController
pageViewController:willTransitionToViewControllers
pageViewController:didFinishAnimating:previousViewControllers
The frame size would always change between the calls to 1 and 3. Sometimes before 2 and sometimes after.
If you're also using storyboards, I was able to resolve the issue by extracting the page UI elements into its own XIB file, setting the constraints in IB and then creating the pages with a call to initWithNibName.
Not a complete answer but it returned me to feeling productive.
Hope it helps.
For me solution was to pin top of the tableView to superview:
Editor -> Pin -> Top Space To SuperView (iOS8)
It is a bug in iOS 8 but I found a workaround:
Add an empty view on top of the statusbar in your Storyboard. The height of the view should be as much as the y-value of your object that is being moved.
I'm setting up a UIRefreshControl in my uitableviewcontroller, but there is a big gap between the navbar and the top of the uitableview. Playing with 'adjust scroll view insets' doesn't help, as the controller will underlay the navbar at startup. I could disable 'under top bars', but I want that ability when scrolling. When poking around in the debugger, I noticed at various times the tableView.contentInset is offset by 82 points, which is different from the ususal 20/64 pt offset people talk about regarding the new ios7 bar behavior. What's going on here?
Found a solution while poking around more; hope it saves someone a few hours!
I needed to instantiate my UIRefreshControl after viewDidLoad:, or avoid setting its attributedTitle in code at least until after that (e.g. if I enabled refreshing of the table in IB). Setting the string inside viewDidLoad: messes up iOS's layout of the control+tableview, but it's ok within viewWillAppear: or later once the geometry is set. And I think 82 points is the height of the UIRefreshControl. Setting the refresh title in IB would've also avoided this problem, except that I was doing so in code because I didn't want to have to enable refreshing in IB all the time with each of my tables.
Having recently switched to autolayout in Xcode 5 (and having watched the developer video from WWDC 13), I'm finding things to work pretty well with the exception of a View-Based NSOutlineView.
Before autolayout, this worked. Everything works fine and is in the right location, but now, specifically when I scroll, some of the new entries (and not all of them) end up in the wrong place, always larger and slightly higher.
The problem goes away once they are redrawn, but I don't understand the mechanic for drawing these NSTableCellViews and when they are created by the Outline View. I mean, it looks like they are created at some point, the program is guessing about the proper constraints, and then fixing them after a redraw.
It would be really nice to post an image to explain this, but can someone explain the life cycle of a view in an NSTableView or NSOutlineView?
I had to grapple with that issue myself and I was able to fix it today. This will happen if you are using any content inside an NSTableCellView that needs to be resized to fit into its cell or any subview of it. I fixed this problem by using an NSImage with the exact same size as a placeholder NSImage I added as subview to the NSTableCellView on IB. This resizing will break the constraints you added to or expect in this view.
Why?
And sometimes there's this:
Is it a bug? Is there a fix? I just dragged a button and a textfield to the view controller.
That's odd, few things that come to my mind
Check if you're using autolayout or 'auto resize subviews'
Check if you programmatically do any layout
Check if you're working with portrait/landscape orientation
I doubt it's a bug, such an obvious problem would have been fixed by now