I have some CGPoints that need to be different for iPhone 4/4S vs. iPhone 5/5S/5C. How can I display different storyboards based on the iPhone screen size? I have checked some of the other questions, but they aren't quite getting the job done.
You don't need to have two separate Storyboard for the two sizes of the iPhones. There are two ways of achieving this:
Use Auto Layout
Use spring and struts
Without going into details on how to use those, you should be able to specify properties like "How far the view should be from bottom of the screen", etc. You can use those to differentiate the two screens.
Related
I'm creating a project that will run on versions, since the iphone 4 until iPhone 6 We all know that the resolution of the screens are different for each device.
In my case, to get around this I created three files .xib type, and in each one I modified the size of the view in xcode inspector attributes tab to stick with the same size of the devices.
I wonder if this way I'm doing is correct, and if there is no other better?
Of course. You should use AutoLayout.
Check the manual.
How it works at a glance: you just setting different relations between views in Interface Builder. It looks like:
I am attempting my first Cocoa Application after developing for iOS for the past few years. I have been "googling" around for awhile now but I guess I am not using the correct terminology to find what I am looking for.
In many applications OSX applications I see this little dot (or sometimes no dot at all like in XCode) which allows you to grab "an invisble" line? Which will resize two or three windows at a time while they are all bound together. How is this done? I'd like to implement it in my current app I am building. I have attached an image to clarify what I am talking about.
Thanks in advance
These are not windows. These are subviews of an NSSplitView
It's an NSSplitView. The line is the divider and can have 3 different styles:
NSSplitViewDividerStyleThick = 1,
NSSplitViewDividerStyleThin = 2,
NSSplitViewDividerStylePaneSplitter = 3,
(the style in the images of your question are the Pane Splitter style).
The content views can be easily added using Interface Builder, or programmatically using the [NSView addSubview:] method (NSSplitView derives from NSView).
You will want to control the splitter behaviour via its delegate (NSSplitViewDelegate).
Also note that the image in your question appears to show a split view within another split view, which is a fairly common way of laying out views.
I'm trying to create a navigation system similar to the iOS 7 native app switcher - in that I have a set of images along the bottom and a set of views above them, which scroll together, but at different rates.
I understand from a little digging that I need to implement a parallax scrolling effect, but what would be the best way to handle this? Should I set up two UIScrollView instances wide enough for the correct number of images/views, then set the contentOffset on one when I scroll the other? Is there a better way to ensure they stay in sync?
Apologies that this is something of a vague question, but specifically I'd like to know if there is a preferred means of implementing parallax while keeping the content in the two portions in sync in terms of both hitting the centre of the display at the same time, etc.
I've developed quite a few apps for iOS and am giving OSX apps a go. What would be the best approach to designing a UI like the split view on iPad apps? For a mac-based example, think of how the playlists work in iTunes. You select an option on the left, and a table view selects a different set of data based on what you selected.
Any ideas?
That sort of interface is known as a source list or source view. It's actually a special style applied to an outline view. Apple provides the SourceView sample code which illustrates the technique.
I'm designing a simple Cocoa app. This is basically my second Cocoa app (despite being good at CocoaTouch), so I'm looking for an in-depth pros/cons analysis of 2 possible solutions for a window flipping problem.
What I'm trying to make is an utility app that sits in the menu bar and has its preferences o its “flip” side, Dashboard-style. It would flip from http://cl.ly/1G2M3J2c142Z0V3K0R2e to http://cl.ly/021z2v2h232x310z1g2q and back.
There are multiple questions on SO about the implementation of this effect:
Core Animation window flip effect
Widget "flip" behavior in Core Animation/Cocoa
Flipping a Window in Cocoa
I've looked at the example code there. Besides neither of them being as smooth as Dashboard widgets (but I'm yet to get to “making it smooth” part), they also share another trait -- they all flip between two different windows.
Now, coming from iOS, the way I started implementing it is to have a single window, but swap between two NSViews.
So what are the pros and cons of these two approaches, and why did multiple unrelated Cocoa developers pick the first one?
Have two NSWindow's, and flip between them (hiding one and showing the other halfway through the flip).
Have a single NSWindow, but two NSView's, and switch the views halfway through the flip.
Is it more convenient to have things separated into different windows in Cocoa? Is it because you can use NSWindowController to manage their lifecycle? Are people just used to using windows because pre-Core Animation you couldn't give views a CA layer? Any other reason/convenience I am missing?
To the future generations: I believe people did it this way because they often flip between windows with different sizes, and then it's just less hassle to have them separate.
Also if you are looking for a good implementation, these guys nailed it: https://github.com/mizage/Flip-Animation