I am working with the default UIPageViewController template from Apple. Basically just dabbling with it to learn how it works.
I would like to load a background image for the dataview controller and resize automatically it according to the orientation (rather than loading different images).
Is there any quick way I'm missing to determine the size of each page in landscape orientation? I don't mean
self.pageViewController.view.frame
which seems to give the size of the entire view including both pages, but rather the size of one of the two pages shown in landscape orientation. I've achieved more or less what I need with something like this
CGRectOffset(CGRectInset(self.pageViewController.view.bounds,125,0), -125, 0)];
but surely there must be some better way? This feels like an ugly hack.
Thanks in advance!
I havent worked with the split view UIPageViewController yet, but as I understand it, you'd pass in two views which would be rendered as the two pages. So why not let the page views determine the size of the graphic itself based on how the UIPageViewController has set it in the frame?
Related
I've been working hard, searching the internet on that problem for 3 days and I'm now running out of ressource.
Currently porting an iOS app to MacOS (deployment 10.11). The problem:
I have a view hierarchy as below:
NSScrollview
documentView
grouping view
tiling view one
array of NSImageView (each one being a tile)
tiling view two
array of NSImageView (each one being a tile)
The two tiling views are overlaying completely, depending of UI one may be hidden or the second one has opacity set below 1.0 to blend the two tiled view.
Because of opacity requirement, as well as performance, views are CAlayer backed. This is done from IB where the to NSScrollview is checked for Core Animation. Thereoff, all the view tree is (implicitly) layer backed.
Works as expected, scroll, magnify, etc..
Then I need to make an image out of the document view to generate an SCNMaterial content (3D view).
On iOS the documentView renderInContext works as expected, and allows an image to be created.
On Appkit the context stay transparent, so is the image, a valid object while as if clearColor.
If the documentView.canDrawSubviewsIntoLayer is set at creation, the view tree renders OK. This can't be the solution since it prevents opacity setting to work.
Even when one tiling view is hidden (no opacity compositing) rendering fails.
I read that some kinds of views are not rendered. I don't use them. There are no filters, no masks, beside a default masksToBounds setting on all the view tree. I don't know why and where it is set. I tried to unset it on all the views at creation with no success. It is set again somehow, on the grouping view below the documentView. This may be the problem but why this property is out of my control ?
Alternative way to get view tree rendering, bitmapImageRepForCachingDisplayInRect: / cacheDisplayInRect:toBitmapImageRep: works the same : ok with canDrawSubviewsIntoLayer, KO otherwise. Apple code examples to make a texture out of a view are using either one of the two methods.
There are plenty of posts, mainly on SO, complaining about CALayer renderInContext and code to custom render a layer tree. Nevertheless, most are quite old and now there must be a simple standard way to achieve it.
Edit: among other attempts, I tried to set each view wantsLayer, with no success.
Well, as often when you post a request for help, you finally find the answer by yourself… Here it is:
Given the view tree as listed in the question, I achieved to render it by setting canDrawSubviewsIntoLayer on each tiling view. This way, the opacity compositing between layers is working, AND the views are rendered.
I post this as an answer, because it solves the problem.
As of WHY this works, here is my guess, but this is not a authorised answer: Each NSImageView tile, subviews of tiling view, have their origin set to their frame. This is not a transform on the layer but a position of the frame in the coordinates of the tiling view. This is a difference with the iOS code version where the tiles are positioned by a transform. I'm going to test further, and see if using a transform rather that a frame origin makes a difference to renderInContext.
Edit: after more testing it appears that the iOS version has a transform AND an offset to the tile.
So the only clue is that the layer system get lost when rendering in context on OSX when some subview have an offset ??
Summary:
The key point to the solution is to find the right layer where to set canDrawSubviewsIntoLayer
My app is a game and the menus have many labels and buttons and I cannot get all of the different screen sizes(iPhone 4/5/6/6+) to look acceptable from the same set of constraints.
Is there a way that you use to synchronize all the views together to look the same on all different screen sizes?
The project is locked to only portrait so I don't need to consider rotation.
For Autolayout, you
Consider the screen sizes you want to support.
Which view/buttons/labels/imageview etc you want to remain fixed while in
different screen size.
Which view/buttons/labels/imageview etc can be scaled to fit the screen.
Now if by scaling the things you can fit on the screen then you are good to go. But if you still can't find way then you would probably need to you use scrollview and and add a UIView (let's call it content view) to it put your all stuff in it and constraint them vertically all the way from top to bottom.This video can help you if you want to use scrollview
https://www.youtube.com/watch?v=UnQsFlMGDsI
what i'm trying to do is displaying a set of images in a grid like fashion but with different sizes as for images in landscape or portrait position, this excludes using the NSCollectionView because the item prototype's size can only be set once...
i'd go and add subviews programmatically to a scrollView but this yet again when the window's size changes and the scrollView get a bigger width, there will be just blank spaces on the right side...
you can checkout the image below for a better understanding...
http://i.stack.imgur.com/NVJjP.png
thanks in advance you guys...
what i ended up doing was implementing a purely mathematic algorithm where i calculated the (x,y) position for every new added photo depending on the previously added photos and it did a pretty good job... the container holding the photos was embedded in a scrollView, needless to say that i had to calculate the height of this container as well.
I have a NSView that houses about a dozen WebViews populated with HTML generated from the application. When I first init them, I wait for - (void)webView:didFinishLoadForFrame: to fire before laying them out and adding them to the view based on the documentView frame.
How would I go about resizing these WebViews along with the window? Is there a way to get the desired size of the WebView for a given width?
Since all you're using the web views for is rendering MarkDown, you should instead investigate MacDown or MarkdownLive. These render MarkDown directly into an NSTextView. This will be MUCH more efficient than multiple WebView objects.
In future, you should ensure that your question includes what you're actually trying to achieve because there's often a simpler way to do what you want than the way you think it perhaps should be achieved.
I am working on a data entry application and I am considering using a fluid layout approach ala Swing and Silverlight where the controls resize based on the window size. My question is simple: what feedback if any have you received from users on each of these approaches? Screen size aside, I will still have a vertical scroll in place so I am wondering if I would be best served to simply go the fixed route and absolute position/size content.
Do not go the fixed route. If the user resizes the window, they do so for a reason. The widgets should resize appropriately. I can think of no valid reason to ever use a fixed layout except in vey specialized circumstances.
That being said, don't have a layout where input fields wrap. That would be very disconcerting. Just let your widgets grow and shrink naturally.