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.
Related
I searched and thought about this a long time and couldn't find a satisfying answer:
I want to create an application with a NSView in which hundreds of elements are drawn which are still interactive and should react on dragging and hovering.
Now, it seems to me, that these elements should be NSViews, because the NSView can handle all these events, but at the same time if I draw hundreds of NSViews, I think it is a bit of an overuse as I have read here (Avoid the Overuse of Views).
For comprehension let's say I want to make something like the Finder Desktop with hundreds of documents and folders on it that react to drag and hover events.
What is the right approach to this?
I am using SemanticZoom in my project. it works fine but is not handled gracefully. What can I do to make its work more smoothe?
Since your question is quite vague, the general recommendation I could give you is to make the zoomed in and out views similar in structure. For example, if your zoomed in view displays a mostly-horizontal GridView then your zoomed out view should display a similarly structured, horizontal layout. Consider the Start menu in Windows 8. A FAIL would be if the zoomed out view showed grouped icons stacked vertically - that would be visually jarring. The best practice is to remain consistent between views, just changing context.
If what you mean is the performance of the animation, then it might be that the complexity of your two views is more than you can reasonably show on YOUR hardware. Be happy you discovered this on your hardware instead of your users discovering it on theirs. There is no real resolution to this other than decomposing your two views and reconsidering the complexity of the overall design. Before you do this, test of a simple set of views and see.
Semantic zoom should be easy for the user to understand. More importantly, you SHOULD use it because it is a regular part of a metro application and users are right to expect it. The execution of the animation is hardware based so you should have a fluid transition. However, all hardware is not created equally, so don't push the limits - just make an excellent app.
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
I've been trying to get this right for weeks now, and though I've learned a lot through my misfires, at this point, I just need a solution. The issue is with unpacking the seemingly overlapping graphics and UI APIs included in Cocoa, many of which produce similar effects, but feature unique limitations that I've often discovered only after investing many hours into an implementation.
I'm new to Cocoa, but not to programming, and I'm trying to create a Mac app with a very customized UI – think Capo, Garageband, or Billings. One view in my window will display an ordered list of subviews, each of which does a lot of custom drawing, and each must support a "selected" state and drag-reordering. The subviews do not need to support being dragged outside of their superview.
Ideally, a drag will give animated feedback as it happens, pushing neighboring sibling views to make space, e.g. toolbar icons or the Safari bookmarks bar. The trouble is, I can't seem to land on the right pack of technologies to get this right. I've done the subviews as NSView subclasses in an NSCollectionView and also as CALayers in a custom CollectionView-like NSView, and neither seems to offer the perfect solution. That said, the first option seems the better of the two for its superior handling of mouse events.
I've not yet tried doing this as a TableView, and I don't want to go down that path without some indication I'm on the right track. Extensive Googling has shown only that there aren't any up-to-date resources on CoreAnimation-enabled reordering or dragging. As such a standard feature of the OS X UI, I feel like this should be easier!
Any help from anyone on what the right tools are for this job would be greatly appreciated. TIA.
Background: I recently got two monitors and want a way to move the focused window to the other screen and vice versa. I've achieved this by using the Accessibility API. (Specifically, I get an AXUIElementRef that holds the AXUIElement associated with the focused window, then I set the NSAccessibilityPositionAttribute value to move the window.
I have this working almost exactly the way I want it to, except I want to animate the movement of windows. I thought that if I could get the NSWindow somehow, I could get its layer and use CoreAnimation to animate the window movement.
Unfortunately, I found out that this isn't possible. (Correct me I'm wrong though -- if there's a way to do it this way it'd be great!) So I'm asking you all for help. How should I go about animating the movement of the focused window, if I have access to the AXUIElementRef?
-R
--EDIT
I was able to get a crude animation going by creating a while loop and moving the position of the window by a small amount each time to make a successful animation. However, the results are pretty sub-par. As you can guess, it takes a lot of unnecessary processing power, and is still very choppy. There must be a better way.
The best possible way I can imagine would be to perform some hacky property comparison between the AXUIElement info values for the window and the info returned from the CGWindow api. Once you're able to ascertain what windows in the CGWindow API match AXUIElementRefs, you could grab bitmaps of the current window contents, overlay the screen with your own custom animation draw of the faux windows, then as you drop the overlay set the real AXUIElementRef's to the desired-end-animation positions.
Hacky, tho.