Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been developing solely for iOS for a fair few years now and consider myself to be fairly competent with iOS and Objective C. I would like to further expand my skills and move into the realm of desktop applications for OS X.
Considering the hugely different paradigms for both platforms concerning view controllers and window controllers (to name a few), I am struggling to find a decent starting point to get my feet wet as my knowledge of the iOS SDK is causing confusion when reading through the OS X documentation.
To me, the major classes for iOS would be UIViewController (and it's variants, UINavigationController and UISplitViewController) and UIView. Getting to grips with these makes learning their subclasses (such as UIButton, UITextField) easier to understand whilst also getting something up on the screen to provide visible results.
Currently, it is my understanding that NSViewController is not necessarily the same counterpart to UIViewController. Also, considering that OS X applications can have multiple windows, UIWindowController is completely foreign to me and I do not understand how this would sit within the hierarchy of an application.
Would any seasoned OS X veterans be kind enough to suggest which classes would be the most useful starting point for me to read up on and play around with? What would be helpful to me at this point is to find which area of the SDK I should be focusing my efforts on to fully discern the differences between iOS and OS X.
Edit:
I am not asking for a list of tutorials. I would much prefer for someone to explain either the difference between paradigms for a multiple view controller hierarchy (iOS) to a single window setup of OS X and/or recommend which classes would be best investigated as a starting point to get something on screen such as NSWindow and NSWindowController.
OS X is pretty similar to iOS in the regard that it also follows the MVC concept. However, the whole user experience is different due to the fact that OS X usually works with a larger display and uses mouse and keyboard for the input, so a 1:1 mapping between let's say NSViewController and UIViewController isn't possible. Normally, you have window controller which kinda acts as you would expect your view controller to under iOS. However, instead of transitioning between view controllers, using eg. a UINavigationController, you either present a second window as a modal sheet, or you just open it as panel or similar.
Just look at your average Mac application, most things that under iOS require multiple view controllers and transitions between them, work with just a single window which contains everything. View controllers under OS X are much less useful than under iOS, however, they work great to keep different logic split up in multiple classes, or when you want to display different content within a window and change between that (think of Xcode, the left and right pane are always the same, but the content in the middle, text editor, target editor etc, changes. That would be a place to use multiple view controllers).
My advice would be to not try to iOS'fy a Mac application. While you can keep your underlying logic the same, the presentation of your application should be fundamentally different due to the fact that the whole user experience on OS X is vastly different. If you aren't sure how to work with things like NSWindowController, NSDocument, and everything, the documentation and sample code provided by Apple is in most cases pretty darn good (though, some examples are older)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
So I'm just starting developing an iPhone application and I've been told to not use Storyboard. I've read that the alternative is using xib files - can anyone recommend good tutorials using xib files?
Thanks
Storyboards are a relatively new feature to Xcode and Cocoa. Arrived with Xcode 4.2.
For decades (see history), NeXTSTEP/OpenStep/Cocoa programmers have been building individual nib/xib files, loading them with ViewControllers. When the user does something to cause the app to move to the next nib/xib, the current view controller instantiates another view controller that loads its desired nib/xib. That new view controller is then shown on screen.
Storyboards are not magic. They just reduce your programming load a bit, handling that loading and displaying of one view controller from another. They still use the same nib/xib technology underneath, you are just less aware of it. Think of a Storyboard as an automatically managed collection of xibs. A superset of nib/xib, rather than a replacement.
In iOS, we often get the new view controller on the screen by pushing it onto a UINavigationController's stack. The Back button automatically appears to close the current view controller and return to the previous one.
There are pros and cons to Storyboards. For relatively simple apps with a certain flow of views, they can be handy.
But there are reasons to not use them. One reason is if moving from view to view is somewhat arbitrary and not easily laid out in a Storyboard. Another reason is that some views are more easily done programatically on-the-fly rather without defining any nib/xib. Typically such views have only one, or very few, components. UIListView and UIWebView are two examples of single widgets that may fill the screen and can therefore be more conveniently created in code.
Tutorial and books abound. Some show both Storyboard and non-Storyboard ways of doing things. Look for some older iOS 5 or 6 books to see more non-Storyboard ways.
Some new articles and Apple docs may push Storyboard because they are the new fresh thing. I suggest taking a more measured approach. Rather than saying Storyboards are the greatest thing or saying Storyboard are terrible, consider them as yet another tool. Sometimes you may want to use them, sometimes they not fit your needs optimally. Also you can mix them, doing part of your app with a Storyboard, and part without.
You can use storyboards (.storyboard files), use older interface builder (.xib files) or do everything programmatically.
I recommend to use storyboards, makes many things easier and less writing, storyboard is similar to interface builder and my opinion, when creating iOS app, it's better choice than older interface builder. And you still can do many things programmatically, e.g. change properties of objects created in storyboard etc.
So if someone says, don't use storyboards, it's his/her opinion and I suggest that you try it out and make your own opinion about it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am writing my first native iPad app and I have a general UI question. I am horrible at user interface design and I'm looking for general guidance on what to use for my layout. Specifically I have a pretty simple master detail app that fits nicely into the generic app template that XCode provides. The app keeps track of inspection dates for equipment. I have a master view where the people enter info about a specific device (make, model, serial number, name, location, point of contact, email, phone, etc). The master view presents just location and name. When they click the master, all the data is displayed in the detail view.
There is an annual inspection required for each device and there is a standard form that is to be filled out. There are 20 items to inspect and I need to collect/display a label (the inspection step), status (pass/fail/whatever) and a comment field for generic text.
So I need to execute an inspection. I could just hand layout 20 uilabels, 20 ON/OFF switches (or 3 position), and 20 UITextViews but that sounds really kludgy. I could put the three items in a custom UITableViewCell but I'm not really comfortable that is the right UI approach either.
How would you map an existing paper process (this starts as a pdf that is printed) to an iPad app? Would you make it look as much like the old paper as possible?
One thing I have learned is that when people have an expectation as to how the information will be presented, then you should conform to that expectation. This is why Apple has interface guidelines for general application development. However, in your case, your guideline should be what your user is already expecting. If that differs from the Apple guidelines, I recommend you lean heavily toward your users' expectations. In this case they may be expecting something along the lines of how the paper form is set up.
Without seeing the original paper form, it's hard to advise you how it can be converted into a Master/Detail format while conforming to their expectations that were set by the paper form.
However, you may find it helpful to augment that by adding views that allow them to focus on individual devices, showing the three fields that you mentioned, with the Master/Detail arrangement. At the same time, they should be able to revert to a view they are familiar with, even if it is only to view the status (rather than to update status).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been writing iOS apps for a while now and gradually went from doing the UI entirely programmatically to using the Interface Builder intensively. I'm now thinking about using the new Storyboarding feature for some of my new projects, but I don't have enough experience or knowledge with it to calculate the advantages and disadvantages of doing so.
Can anybody give some examples or information about when using Storyboarding payed off and when it was a waste of time?
Advantages of Storyboarding
It's cool - suave way to design interfaces
Use of StoryBoardSegues to identify navigation/modal relationships
If your app supports multiple devices, good way to organize different views (by storyboard file rather than naming, etc)
Nice for prototyping
Prototype UITableViewCell can save time
Disadvantages of Storyboarding
It's a runtime feature, so I believe it is only available in iOS 5
StoryBoardSegues are kind of rigid in my experience and you may make use of prepareForSegue a lot
Like IB, not very friendly with other display engines and toolkits
Makes it hard to share designs for a single view or set of views - you have to send all or nothing
These seem kind of superficial, I guess I haven't given it much thought... At first I was gung-ho about story boards, but now I've reverted to IB or even just programatic view configuration... The more I use them, the less I like them, and the more they feel like a gimmick/waste of time.
Edit
I wrote this answer a few years ago. I have left it the same as before for posterity, although some points are likely no longer relevant (ie the fact that it requires iOS 5+).
After some time, my opinion hasn't changed on storyboards. As others have mentioned, they're okay if you are working solo on an app with few views to manage, but they become a real pain with source control & collaboration. In addition, I prefer one-file-one-object, and storyboards obviously bundle stuff together (as does IB, but to a lesser extent).
If I were writing an app meant to be maintained for any serious length of time, I would go with programmatic view configuration over IB, but definitely IB over storyboards.
Another disadvantage with Storyboarding not mentioned is that merges can be very difficult if not impossible if there are conflicts.
Update: It also occurred to me that it puts logic in two places. If your segue is not doing the right thing it might be because of an error in prepareForSegue or it might be because you named your segue incorrectly. Doing things programmatically is, in the end, not that hard.
At the latest WWDC (2013) Apple Devs strongly recommend using storyboard and built in IB stuff to do most of your code for you instead of writing it by hand because you are much more likely to avoid deprecation and take advantage of feature updates via automated conversions.
The lone disadvantage is the difficulty in allowing git collaboration on storyboards, as there will be conflicts on virtually every commit.
If you are a solo programmer, you should always be using storyboards.
I have a similar background to you - I started with mostly building my iOS UI programmatically since IB was not really user-friendly, but lately decided to use IB more and more, since it is better for designing the UI and works fine for standard-elements.
With the new Xcode I switched to Storyboard, since they provide a full view of the application. It is possible to generate the complete UI (with all views) in a single File, which can be used for prototyping and which I can view my colleagues before writing the first code line. It is far better and easier than designing with photoshop or similar tools.
However if you use a lot of your own UI elements/controls or something using a different "engine" (cocos2d, OpenGL, etc.) it is usually better to generate the UI programmatically, since these "engines" are not really integrated with IB/Storyboards.
I have learn the storyboarding by following the tutorials from the raywenderlich's website and there is a lot of stuff about the storyboard.
Here is the link to site: http://www.raywenderlich.com/5138/beginning-storyboards-in-ios-5-part-1
Advantages of storyboard:
1) Before you start developing app you can see all the screens of the app.
2) You can visually see the relationship between each screen.
3) It can help to reduce the amount of the code specially in case of UITableView you can use prototype cells and static cells to design your TableView in storyboard.
4) In case if you have to work on someone else code you can get the better understanding of the flow of the app by viewing storyboard in short time.
5) You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.
6) If you are doing client based work then some clients want to see the prototype of the app before start developing it, here storyboard helps you a lot.
Disadvantages of storyboard:
1) For storyboard you will need a big screen specially in case of iPad.
2) I also experience a difficulty while copying views from other apps to storyboard.
3) I also experience problems in storyboard when multiple developers work on the same project by using git repository.
By reading and understanding the advantages and disadvantages you can judge your self when to use storyboard.
One Word (DON'T)
One of the biggest disadvantages of storyboard aside from the git conflicts that make it impossible for two or more persons to work on it. but also if the project went so big and you have +40 screens , if you insane enough to move anything just one pixel in any view controller you have in the storyboard, you'll have a very huge compilation time, that you can build your app and make it run in more than 5 minutes, and of course don't let me start with archiving to give some one adhoc of the app .
after this painful experience I totally fell back to the oldy goldy great xib files and deleted the storyboard file in a huge fire celeberation .
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.