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).
Related
I have been making the native iPhone app and I have never used a xib, I mainly used to make the application in run time based, but know with the introduction of Main Story Board. I just want to know which one will be easier for using run time based which I mainly used to or start using story board.
Both have its own advantage and Storyboard has more options and ease when used in the right way (that is why it is introduced!).
By using storyboard
You can avoid so many line of code for page navigation and all
Complete picture of project is visible
By xib
Used a lot and hence more easy
Independent,so can be worked better
For working as a team xib is preferrable since the conflicts can be less if each team member working in seperate files
MY SOLUTION
Since it is possible to use both in same project. I use both in my projects. To take the both advantages according to my requirement.
You'll probably want to use a Storyboard(s) in the long run. However, there are pros and cons:
Pros
You can see your whole project
You avoid a whole lot of nasty code
You can visually 'hook' stuff together
Cons
Only available >iOS 5.0 <<<<Huge!
In my personal experience, I usually use Storyboards - the percentage of devices running < iOS 5 is actually quite low.
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'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 :)
How do you design a UI like Facebook?
Is it hard to implement a custom skin into a iphone app? How is it done?
Do I need to follow apple's guideline? What if I don't want to?
How do you design a UI like Facebook?
Facebook's iPhone app appears to be built around using UITableView in various guises. It looks like it adheres to the Apple Human Interface Guidelines.
Is it hard to implement a custom skin
into a iphone app? How is it done?
Skins are just graphic elements that are designed to have their image components swapped out. They are not difficult to implement.
Do I need to follow apple's guideline?
What if I dont want to?
Apple will not penalize you for a non-standard interface. The only interface restrictions are (1) some issues of obscene content and (2) you can't create the illusion that the device itself is broken, has crashed or otherwise failed.
A bit of advice. Don't use non-standard interfaces.
Good interfaces are almost by definition standardized so that users don't have to think about them. Novel interfaces slow users down even if they have no problems otherwise. Just try switching rapidly between Mac, Windows and Linux sometimes. None of the interfaces has major problems per se but having to stop and think how to do something in each particular interface is a pain. You can create the same problem by using a good but non-standard interface within an app.
That is assuming of course that you can actually create a good interface. There are far, far more ways to make bad interfaces than there are to make good ones. Most interfaces fail even those designed by interface gods. The standardized interfaces are the result of tens of thousands of hours of testing and years of experience. You're unlikely to whip out something really new and useful your first time out.
If you try something novel I suggest you mock it up first and then test let people test it without giving them any instruction. You'd be surprised how complex it can get. We used to just make photoshop mockups and then ask test users what they thought each element did or which element they would choose to accomplish a particular task. We were surprised at how poorly our (the developers) perception of the interface overlapped with the perception of the users.
In sum, a novel interface is more likely to hurt your app than help it.
With regard to how to build an app like Facebook, check out Three20. In particular, the TTLauncherView is the class that implements the Springboard-like grid of icons.
3- You don't need to follow the AHIG. But be careful if you don't, because it's very easy to go wrong doing so. Users like to not have to learn anything new. They know the typical Apple software UI, so if you use it, users will know how to use your app as soon as they buy it. If you don't use it, it is important to make sure that the UI is exceedingly easy and intuitive, and looks good to an iPhone user's eyes (and fingers).