I'd like to know more about the pros and cons of using interface builder when developing iPhone/iPad apps.
I've written a fairly complex and customized app that's on the app store right now, but all of the interfaces are hand coded as they are fairly complex. I've customised the navigation and tab bars with backgrounds, table view cells are manually drawn for speed, and some views are complex and scalable with many subviews.
I'm pondering whether or not to start using interface builder but I'm not sure to what extent I'll use it and whether it's worth it at all. Is it quicker? Can things still be easily customised?
Any advice would be most welcome!
There is absolutely no reason not to use it. One thing that scares people off is their experiences with other GUI tools, things that generated code for them or some other mess. Then the problem becomes that it is hard to round-trip the interface, you cannot easily modify things once they are generated because of the complexity of pushing those changes back into the emitted code.
Interface Builder does not generate code, it uses NSArchiver to read and write an actual object graph for the GUI. This has many benefits, starting with the fact that you can easily round-trip the interface and make incremental changes. It really is all good, use it. :-)
Personally I've found Interface Builder quite tricky to ramp up on, and sometimes it doesn't expose all the properties I want to edit (although this may have changed in the newer versions), so generally I've tended to create my UIs in code.
If you do use Interface Builder, make sure to consider localization. Apple's iPhone Developer docs recommend that the NIB be a localized resource that gets translated. That way the translator can see if the new text fits in the view. Unfortunately this means the translator needs to be capable of opening NIB files and editing them (or a developer needs to get involved in the translation process).
Personally, I prefer providing localized text resources and setting the text to the UI in code. I then provide comments in the Localizable.strings file saying how long the text can be, and providing any context the translator might need.
There are no cons.
Why dont use it? It makes everything easier :)
Related
Merging interface builder files with others (and even myself from a different computer) can be a real challenge. The XIB xml is certainly better than NIBs but even as xml, I've found cases where merging and getting a consistent and valid XIB was harder than just taking the other and manually redoing the changes made.
I'm wondering what other folks are doing who have multiple folks who can potentially collide on XIBs.
Was merging a consideration for going all code? Do you use XIBs just for layout and code the rest? Or, have you had any luck merging XIBs and over time you just get better at manually reading?
EDIT: My current approach is using it for strict layout (what it's really good at and painful to code) and setting all the options and data via code. I find code much easier to merge but laying out controls in code is tedious. Thoughts?
Was merging a consideration for going all code?
Yes, No, and "Portions Of". It depends on things like:
The people involved
the complexity of the UI
the quality of the implementation you need.
the expected lifetime of the implementation
But yes, it has been, and it often is when the case is just not trivial -- Otherwise, you just fight it by decomposing XIBs into smaller pieces. That can work pretty well (or not), depending on what you are faced with.
Do you use XIBs just for layout and code the rest?
Depends on a lot of things.
XIB-only has its restrictions, and is much like code duplication. I use it at times for prototyping, other times because that's what somebody else favored.
"A little of both" can require a lot of glue. At times, it can be pretty disorganized -- e.g. "where's that action really set?". Of course, this can also be used to achieve what some would consider a good balance of XIB and programmatic separation. The simpler the XIB is, the less often it will need to be adjusted, and less likely it will cause merge conflicts.
Code-only is my preference, but there are people who just prefer WYSIWYG, and people aren't very familiar writing UIs programmatically. As well, if quality, reusability, and maintainability not requirements (e.g. bang out a prototype), then code-only can be overkill.
Or, have you had any luck merging XIBs and over time you just get better at manually reading?
No real luck -- just by breaking them into smaller components. Unfortunately, the "Decompose Interface" option (from IB3) is not available in Xc4's editor.
I have found that IB is better for layout as you mention, but probably that's just me cause I was raised this way.Plus code is way more re-usable than layouts.
As far as I'm concerned during the runtime both act the same though I'm not 100% sure about that. Prototypes are less painful in IB than in code, I know that for sure and clients will not take any value on you prototyping in code.
What I do is don't bother trying to merge, just accepts the branch version completely or you version. It means you have to be a bit disciplined about who get to change the interface code, and on commits and updates, in practice we haven't found it a problem but I guess it depends on your environment.
Don't use this as an excuse to stop using interface builder, there is nothing worse than trying to dig through someone else's code to find a button so you can work out what happens when a use clicks it.
Without Interface Builder you are not respecting the MVC separation.
I'm a totally blind developer who would like to do iPhone development. From what I've heard most of Xcode is accessible with voiceover, the screen reader built into the Mac. My understanding is that the interface builder is mostly to completely inaccessible for blind users. Assuming I can not use interface builder is there an alternative way of creating simple to moderately complex user interfaces? I really don't want to spend $600 on a Mac to find out that it will be nothing more then a paper weight for me.
You don't necessarily need Interface Builder. In fact, some friends who work at Apple say they mostly code the interface. If you can code so far, i'm sure you can code the interface as well.
I'm also a blind developer. Over Christmas I purchased a second hand Mac, and spent 2 weeks on exactly this.
It was certainly possible to develop a complete app without Interface Builder. I used tricks like setting the text in a label, sizing the label, and then programatically calculating the absolute position for the next control by adding some space between controls.
Probably like yourself, I've always wanted to create things myself as it's more fun, and you can experiment more quickly. There's also a certain amount of pride - if you can do it yourself, who needs to hire help.
But what I realised is that my UI was pretty functional, but not at all esthetically pleasing. Most iPhone apps don't just have UI controls on a plain background - there's often a lot of colorful icons and pretty backgrounds involved.
The deal braker for me, personally, was reading the Apple guidelines and seeing that you need icons which conform to some pretty stringent guidelines, in at least two different sizes. The application icon is important as this is much of how people choose whether to download something.
So, if I have to hire a designer to make my icons, I may as well get them to lay out the UI.
Ideally, Interface Builder would be accessible enough to drag controls onto a view (not possible today), and bind them to code. We could then develop an application with no regard for how the controls were layed out, hire a designer, let them do whatever they want with the xib and our code would continue working.
Just my thoughts based on personal experience - there are many resources for learning to create UIs without IB if that's the route you choose.
Interface builder is provided as one way to design user interfaces, but it does not do anything that can't also be done in code. It's a way of building object archives containing (mostly) user interface objects, which can be un-archived and used at run time. But the same objects and properties could be set up in Objective-C and would work just as well.
Apple usually does a better job with accessibility. If Interface Builder is not accessible, I suggest filing a bug at http://bugreport.apple.com/ about it.
I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
I have a friend who is a graphic designer & user experience designer who will be collaborating with me to develop an iPhone app. He does not have previous iPhone experience. What is the best way to work with him on developing the user interface, i.e. custom colors for UITableViews, UIButtons, etc? We've looked into Photoshop mock ups, but that depends on me (the developer) implementing what he drew in Photoshop, which might get tricky.
Most of the methods I've thought of have long turn around time, i.e. he uses Photoshop, sends me the image, I develop, send him a test build of the app, he doesn't like it, rinse, lather, repeat.
Do you think it's feasible to set him up with Interface Builder so he can modify XIB files? Potentially, he could build and run the app in the simulator...
Does anyone have experience doing this? Any suggestions?
Thanks much,
-dan
This goes for a developer or designer. The best way in my opinion is to mock up designs in photoshop, debate on what is good and what is bad, then send the final mock ups to the developer.
The reason you want to do it this way is because your designer can't do everything he wants to do by simply using the IB. You need to allow your designer to express his creative freedom without the burdeon of figuring out how to use a piece of software correctly.
You can find plenty of templates of iPhone and iPad components on the web. Having those components will make it very simple for your friend to put together concepts. It will also keep things consistent so you can have an easier time implementing them.
A Great Collection of iPad Resources
iPhone Materials
One suggestion is to start with the elements that do not need graphic design but you know they will be there, this will be things like table views, tab bars, any UI element provided by UIKit or even custom UI elements that you make...I would say you will probably have most of your app made by this approach and will look VERY plain...once you have that basis you should be able to work with the graphic designer and identify where and what he needs to make, it should also be pretty easy for you to integrate it since it will probably be mostly images or textures, things like animations and such will have to be handled by you anyway...just a suggestion, hope its helpful
Omnigraffle is your best bet for quickly mocking out UIs. It produces nearly photorealistic mockups. It's easy for non-artist to use but can also utilize imported images of arbitrary complexity if he needs to do something fancy.
If you want my advice, keep the graphic designers away from the app until it is fully functional logically. They should only be brought in at the end of the process to tweak the UI.
They cause train wrecks if they come into the process early. Everybody in that field has been trained first and foremost to create visuals that attract attention. In an UI, that always translates into flashy, non-standard elements that turn into annoyance with repeated use. A good UI is essentially invisible to the user. Ideally, they should notice it only because they notice that they don't notice it. (It's all very Zen.)
People trained to attract attention in the blizzard of competing images of a media saturated world don't make invisible interfaces. They make "in your face" and "look at me!" interfaces that get old in a hurry.
Don't get me wrong: a good graphics person can really enhance an interface by the skillful and subtle use of proportion and color. Unfortunately finding a good UI graphics person is a challenge. Be prepared for fights over what works transparently versus what looks cool and draws attention the first time you see it.
Is there any reason to not write iphone apps without useing the interface builder?
(or in other words, is it ok to write apps without the builder?)
Personally, my applications use no NIBs within them, but that's more of a matter of how I started doing development than anything else. I transitioned over from doing Mac development (where I use Interface Builder almost every day) to iPhone from when the first beta SDKs were released. Initially, there was no Interface Builder, and even when it came you couldn't do a lot of things with it, so I never took the time to really get to know it on the iPhone. It's more a matter of me doing what I'm familiar with.
Jeff LaMarche makes a convincing argument in his article "Don't Fear the Interface Builder" for you to use Interface Builder wherever you can, and I encourage new developers to learn to use it first before dropping down to programmatic user interface generation. It saves you a tremendous amount of time for interfaces using standard elements.
Some people have argued that there is a performance benefit to be had using purely programmatic interfaces, but Matt Gallagher ran a series of benchmarks and found that this speedup is only typically on the order of 5-10%. If you really want to shave that last bit off of your application's startup time, you might be able to have the best of both worlds with Adrian Kosmaczewski's nib2objc, which generates Objective-C from your NIB files.
However, there are plenty of times that you'll need to manipulate interfaces programmatically, such as for custom views and animations. This code can exist in parallel with Interface Builder without too much confusion. Again, it's more of a matter of personal preference at this point, but my recommendation is to use Interface Builder due to the time it can save you.
I've never written an iPhone app that uses Interface Builder (.xib files), but that's just personal taste: I like applications to be 100% code.
The reason is that I don't like applications that require design-time tools if you need to change something later on. It creates a dependency that may not be a problem today or next month, but it can become a problem in 3 years time.
So, the answer is: yes, it's fine to write iPhone apps without using Interface Builder.
Sure, it's absolutely fine to write apps without IB. It takes a little bit more setup (I believe there are some modifications you have to make to your Info.plist file), but it's certainly possible, and people do it all the time.
Personally, I prefer using Interface Builder for most tasks, but usually just to get the basic layout in place (so I don't have to deal with calculating rects, etc). Any further customization I prefer to do in code.
You can edit .XIB files by hand if you want to. They're XML, after all. Can't help having at least one of them in the project. Alternatively, you can create all your controls from code. The latter takes less typing, as far as I can tell.
Then, there are some apps where a XIB file would be of no use. I'm talking about games, where artistic/design considerations beat the convenience of having native widgets.
So yes, it's OK on both design level (no native widgets) and implementation level (yes native widgets, but sans IB).