I am contemplating a small iOS project in which the most natural user interface is probably for the user to drag symbols from a "well" at the bottom of the screen onto targets at the top of the screen. Conventionally, one would expect to see the symbols, perhaps with high transparency or as outlines, accompany the drag, and some sort of feedback from the symbol or the target when the target is reached.
I don't see any built-in classes for handling this in Cocoa Touch, but it seems like a very common sort of interface and I bet there are established best practices and/or libraries for handling it. Can anybody offer me any pointers?
There's a great tutorial built some time ago regarding touch motions and in your case drag and drop.
The relevant functions are under the UIResponderClass under Responding to Touch Events.
Related
I am planning to develop my first app in Cocoa. I have been collecting ideas for the UI and have settled in with the design very similar to iPhoto (i.e. library style or 'shoebox' application as referred by Apple's programming guide). In a nutshell I need master detail kind of setup like in iOS (iPad's UISplitview).
To achieve this should I put a NSSplitview and on the left panel have a NSTableView and on the right panel have a NSCollectionView?
Are there any examples/boilerplate or tutorials for creating app in OS X?
Your instincts are correct. You might decide eventually you want something more customizable that an NSCollectionView, but it’ll get you started fast and you can do most of what iPhoto does with it. (You can’t do rows with varying #s of items on them, like Delicious Library does, unless you write your own view.)
I am learning cocoa, and I am creating an application that will require similiar layout to the screenshot below (this seems like a very common layout approach).
What kind of controls/architecture would this type of Cocoa application be?
I'm still in my early stages of learning/reading, and I know of document based applications only so far, but this type of layout doesn't seem to look like a document based app since it doesn't really require multiple windows opened.
If it isn't document, is there a name for other design patters or layouts?
From what I now so far, I would describe this like:
I would be grateful if someone could give me a detailed overview of the high level design for an app like this i.e. things like: # of panels, views used, controls, controllers etc?
Also, a few quick sub-questions:
what kind of menu controls are those in the left pane, then expand and display sub elements?
When preferences windows are displayed, what is that effect called that makes it display in an animated way (like the address book does), where it is a small window that expands to its correct size in an animated fashion.
You are right that this is probably not a document based application, as they open documents in new windows by default.
To layout the window like that, there’d be an NSSplitView that contains the 3 panes. Each pane may optionally contain a view loaded from an NSViewController, which can help keep the code modularised, but it depends on what you’re trying to do if this is appropriate.
The left pane would be an NSOutlineView (a NSTableView subclass), the middle an NSTableView, but I’m not sure exactly how the right-hand side view would be created (lots of custom NSViews and other things, possibly WebView)
That popover options window is possibly a NSPopover (which contains an NSViewController), but that’s only compatible with OS X 10.7, so may also be totally custom for backwards compatibility and easier customisation.
Also note this is a fairly complicated example you’ve given, with lots of custom controls that are probably harder to create than they look:
To get the outline views on the left to have unread counts and icons (from memory) is not built into AppKit, so was all custom created. To do things like that, you’ll need a solid understanding of NSCell vs NSView, and ideally also know about Core Animation layer backed views, and what to use for different aspects.
The window has a taller-than usual title bar. This means the developer probably had to do some crazy stuff to get it to work, if not create the whole window from scratch.
That’s just the start. There’s lots of really nice design in there that’s custom and done from scratch.
Designing Mac apps can be hard sometimes. AppKit is pretty old (back from the NEXT days), and has lots of legacy stuck in it. UIKit on iOS on the other hand is quite nice – Apple clearly learned from their past and made things much better.
I’ve hardly touched on the controllers and model behind all that. There’s lots of different ways you could do it. For persistence, you could use CoreData, sqlite, NSKeyedArchived, just to name a few. Brent Simmons (past developer of another RSS reader, NetNewsWire) wrote some interesting blog posts about that:
http://inessential.com/2010/02/26/on_switching_away_from_core_data
http://inessential.com/2011/09/22/core_data_revisited
The way you design your model & controllers really depends on the specific problem. Cocoa really forces you to stick to MVC though – if you don’t, things are guaranteed to end up messy.
I hope that all helps! I’m really only just learning myself too.
Apple refers to this type of application design as Single-window, library- (or “shoebox”) style and gives a number of recommendations for this design choice in the docs.
(see Mac App Programming Guide)
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.
I'm in the midst of porting a win32 app to cocoa. Wherever possible, I'm using IB, since... well its way easier in every way possible, obviously. One thing is the designer and the win32 dev set up all the button assets on a massive "sprite sheet" such you move around the viewport to determine button state. Similar to how yahoo does CSS sprites on their home page (http://d.yimg.com/a/i/ww/met/pa_icons/20100309/spr_apps_us.png)
Can IB be setup to handle this type sprite strip with the default buttons, or are we SOL on this one? I can certainly fire something up programmatically that would do this, but would like to incorporate as much of the default button behavior and selector hookup in IB.
Thoughts?
Josh
This isn't supported in IB because it is really not a Cocoa way of setting button images. I understand why you would use sprites in CSS but in a native program (on any platform) it seems really unnecessary and inefficient.
I honestly think it would be much less work for you to forget about using the sprites. Out of curiosity, are these buttons going to be for standard user interactions, or something more along the line of buttons for a game? If it is for standard user interactions (open file, change font, etc.) then I strongly recommend using the stock buttons as much as possible, although I understand that this might be out of your control. The reason is that the worst ported apps are usually the ones that try to keep visual fidelity with their Windows counterpart.