First time building a user interface, had a few general questions
1) Does it really matter if you drag and drop view objects into view controller.. or if you programmatically add subviews and specify frames and fonts? What's the better approach to take?
2) In the programmatic approach, I end up guessing frame values, (x,y) points, and then checking in simulator if I like it. Is this the right approach, or are there faster, better ways to build out the UI? Maybe methods I'm not aware of?
3) Any useful tutorials/pointers in the right direction on how to get started?
Thanks!
1) Both approaches are fine, but the Interface Builder is usually better if you have a more static UI. In a more dynamic app (where views appear and disappear, or if you use UIViewController containment), you need to add/show/hide some of the views in the code. Even in that case you can design individual views in the IB, to make sure they look good, and then instantiate and display them in the code.
2) If you design your views in the IB, then the problem of guessing the sizes largely disappears. In some cases it can be useful to have an empty view added in the IB, which acts as a placeholder for your dynamic content. Then, when you add a view to it in the code, you just use the superview's dimensions so your view fills the placeholder.
Related
It's really strange. The Prototype-Cell in my second UITableView isn't on top as it should be:
If I start moving it, than it's on top again, but after i drop it on my View, it is still in this strange way.
How can I change that?
As you see, the first Cell is okay, but the second isn't.
Well, it's difficult to understand using only an image, but I will give you some possible causes for that:
Have you applied a table header view by accident in the second table view? If you did, removing it will be the solution
Have you applied the proper view constraints in the table view and its cells?
If I were you, I would not try to embed two UITableViews in the same view controller this way, especially since you use storyboards with iOS 7. What I would do is to use embed segues. Just drag a container view for each of your view table views, and connect their embed segues to their appropriate table view controllers ( you need to create in the storyboard those, two). That way, you can set the constraints much easier, separate the logic between the two and have a cleaner interface. You can do that and see if that helps.
I am building a complex iPad application; think of it as a scrapbook.
For the purpose of this question, let's consider a page with two images over it.
My main view displays my doc data rendered as a single UIImage; this because I need to do some global manipulation over them. This is my DisplayView.
When editing I need to instantiate an EditorView with my two images as subviews; this way I can interact with a single image, (rotate it, scale it, move it). When editing is triggered, I hide my DisplayView and show my EditorView.
In a iPhone app, I'd associate each main view (that is, a view filling the screen) to a view controller.
The problem is here there is just one view controller; I've considered passing the EditorView via a modal view controller, but it's not an option (there a complex layout with a mask covering everything and palettes over it; rebuilding it in the EditorView would create duplicate code).
Presently the EditorView incorporates some logic (loads data from the model, invokes some subviews for fine editing, saves data back to the model); EditorView subviews also incorporate some logic (I manipulate images and pass them back to the main EditorView). I feel this logic belongs more to a controller. On the other hand, I am not sure making my only view controller so fat a good idea.
What is the best, cocoa-ish implementation of such a class structure?
Feel free to ask for clarifications.
Cheers.
Huge fat controllers are fine.
If necessary, just break off some "purely logical parts" from it and shove them in other "helper classes". And use tricks like categories extensively where you can.
Definitely go with a HFC (huge fat controller) if that feels right.
Then, just get on your engineering bike and slim the hell out of it!
You should definitely not avoid the right structure, the good structure, the structure you want, just because one thing will be too big.
Just slim that big thing down by outsourcing concepts, going nuts with categories, etc etc - every trick in the book.
My belief!
Some reasons to wrap a viewcontroller around your view:
to use it in an Apple API that requires a viewcontroller (popover views, modal views, navigation bars, tab bars, ...)
because the view can be invisible for a while, and so it makes sense to clean it up in low memory situations. The viewcontroller then guards the data that needs to survive such an unload-reload cycle.
because you just like the MVC pattern
I think the second bullet justifies a viewcontroller for your editable content view and another one for your non-editable content view.
In order to categorize a wide variety of unique views, I have an elaborate setup: main categories are selected via a toolbar, and then specific panes are selected in a category's NSScrollView. This looks like: window -> NSViewController controlling five views -> sub-NSViewController for each view controlling X views -> each view contains a core-plot graph. In short, nested NSViewControllers with a core-plot CPLayerHostingView at the end of nearly every path.
Before I even get to my question, feel free to point out that this is a poor implementation. In terms of user-friendliness, I think it makes sense, but the sheer number of nested objects makes me wonder if there's a better way.
Now then, assuming I've designed it the best possible way, the question itself: suppose I have selected a category and then a sub-item within, and am looking at a rendered graph. I desire the graph to resize appropriately if the window is resized. In Interface Builder I have done everything necessary to make this happen: everything from the CPLayerHostingView to the NSView in the main window have been set to autosize in all directions. Despite this, if I resize at runtime, the graph stays still and does not resize or move. In a design with zero or one NSView tiers this would be much simpler to debug, but I'm out of ideas in this scenario.
What tricks, programmatic or IB-based, can I use to make sure an NSView resizes according to a window resize many, many levels up?
Not only do you need to set the springs and struts, but you also need to make sure "Autoresizes Subviews" is checked.
I’m starting to develop my first full-blown Cocoa application containing a view which I would like to behave (and look) similar to Automator’s AMWorkflowView.
The basic features I’d like to achieve:
Positioning of subviews
Display of subviews in expanded / collapsed states
Multiple selection
Drag and drop
In order to get accustomed to Cocoa, I started with a custom NSView which mainly served as a container for the custom subviews and handled their positioning and multiple selection.
The subviews are also subclasses of NSView, and contain a variable amount of views themselves, like buttons, labels and popup menus, and therefore can have different heights.
This worked quite well, but before going on, I want to make sure to have everything neat and tidy according to the MVC pattern.
I suspect that there already is a class in Cocoa that facilitates the implementation of a view container, like maybe NSCollectionView.
It seems that there is no (easy) way to display differently sized views in an NSCollectionView, though. Should I continue implementing my custom NSView (probably using an NSArrayController for selection and sorting support), or are there better ways to go?
Any help is much appreciated
Unfortunately the answer is you'll have to roll your own. NSCollectionView does not allow for variable-sized items (which also rules out expanded/collapsed states).
For a limited number of items, you can accomplish this rather easily (you just need a container view that arranges the subviews properly when asked to layout, then you need to make sure you re-layout when things change). For many subviews, however, you'll need to take care to be as efficient as possible. This can start with laying out as little as possible (only those "after" the resized view, for example) and get as complex as caching a visual representation of a prototype view, drawing the cached images (fast!) for all but the view being edited, and only using/positioning a "real" view for the view being edited.
Drag and drop works the same as it always has, but none of the above accounts for the pretty animation NSCollectionView gives you. :-) It's fast and beautifully-animated precisely because all the subviews are uniform (so the layout calculations are fast and simple). Once you add irregular sizes, the problem becomes significantly more complicated.
The bottom line: If you need variably-sized views, NSCollectionView will not work and you'll need to roll your own or find someone else's shared code, but performance and beautiful animation will not be easy.
As I wire up my first fairly complicated Cocoa-Touch view I feel like I'm inadvertently slipping back into old procedural patterns and finding it difficult to shake them off...Though fully aware of many of the Cocoa (OO) design patterns I'm afraid I may be subverting them.
As such this view in question is quickly becoming unmanageable and I'm wondering if I might be approaching it the wrong way?!? The view is managed by a subclass of UIViewController. The view itself contains ±10 subviews. Some of these subviews "slide" in and out and contain their own subviews (controls, imageviews, etc) that slide along with them.
Without getting into too much detail I've found that I'm executing most (if not all, including animation) of my management code w/in the touchesBegan/Moved/Ended methods of my root View Controller. And it's become a mess of managing, setting & checking boolean properties. if (editingMode & panelAVisible).... if (editingMode & panelBVisible)... or *if (viewFlipped) { for (MyCustomView view in someArrayOfSubviews)} etc, etc... granted the UI of this app requires most of these views (or their contents) to be touched and moved by the user to different parts of the screen.
The main problems I'm trying to solve seems to be along the lines of: if viewA is present then you 3 views go hide (animated)...or, If viewB is touched then all objects contained in viewC are negative... etc.
Any clever (or rudimentary) OO approach to handling this? Perhaps make the subviews that contain views act as their own mini view controllers? I haven't been able to find too many (any?) examples of that though...
As you suggested at the end of your question, I would recommend having a subcontroller whenever you need logic for a particular subview. The point of a controller object is to keep track of state of the view and to encapsulate all that view logic that you were describing. Interface actions, such as if the user can move to a different screen, can invoke save logic, can create a new document, should be in the controller for that particular view. This will help maintain a separation of concerns between the various controllers and cut your convoluted logic down at the top level.
While it doesn't pertain to iPhone programming specifically, the book Cocoa Programming for Mac OS X contains good examples (especially in the chapter about how to do preference windows) of using subcontrollers and subviews in your application.
I think you should go along your last suggestion, make the subviews that contain views act as their own mini view controllers. Each (sub)view that presents a 'screen full of content' could/should be managed by its own view controller.
Animating between those views can be done with the build in navigation controller (you can actually hide the top bar of a navigation controller) such that you have the default slide animation. Otherwise you could indeed create your own animation while still using that navigation controller.
'The view itself contains ±10 subviews'. Some of these subviews "slide" in and out [..]'. These subviews you're talking about are perfect candidates for extraction from your one monolithic UIView.
The basic OO principle to use is how the navigation controller does it, by pushing and popping views on and off a stack. Each view pushed and popped is handled by its own view controller.
HTH
Edit: I now see you're not specifically talking about iPhone development. Still, have a look how its done there (especially the UINavigationController). You can still get the basic design idea