I've seen many people saying it's easier to code your UI directly than to manipulate them in IB.
I know how to create UI objects from code but it just seems unnecessarily complicated, especially when you have 10+ subviews/controllers in one view(screen).
1. How do you visualize the UI layout when you create UI from code?
2. How do you make sure you are following the apple guidelines when placing the UI objects? (IB shows the blue dashed line to suggest you the correct(i guess) positions)
3. How do you manage to separate the UI creation part and the UI placement part in code? (maybe to figure out the UI layout easily)
and so on..
I wish there was a tutorial or example that can answer the above questions but hard to google.
Thank you for any suggestion.
I am creating my UIs from code with config files.
I have a test iPhone app that reads a config file and displays the UI, so i can tweak it.
Related
I am trying to implement the following kind of tabs into my Application. I have first tried it with creating buttons. So can anyone guide me how to create this kind of interface ?
I want to clarify that this are the groups & it will be dynamically created & it can be in any number.
Any suggestions & references will be highly appreciated.
Thanks in advance.
I've been implementing pretty much exactly what you are asking in an app im working on, i've uploaded the source files here. its pretty much plug-and-play, just make a TabView where you want your tabs and hook up the delegate methods. can swap out all the images with your own (my tabs were underneath something and not on top so they will look upside down initially for you).
Dont really have time to explain the inner workings of it all, but if you play around with the code im sure you will manage to customise it how you want. otherwise, just learn from it and implement your own.
edit: oh and there is some code that changes how the tabs look depending if iOS 7 or not, you will get an error when first importing it because i have a variable in my appDelegate isIOS7 which you can either implement in your app, or just take out all the relevant iOS 7 checks in the code
I was asked by a client to make a "skinnable" app and I don't really know what that means.
I googled like crazy and I didn't found a clear answer or an example.
If anyone has a clue about this, any tip would be appreciated.
Thanks.
Generally this means the app will allow the user to choose different looks for the UI, each of which will have a different color scheme, feel, etc.
What I actually did with my project. I decided to use multiple storyboards to give me greater control over the entire UI and UX of each theme. I programmatically link them all together via a master storyboard that links them all together. That's what I did, and it works very very well. Performance is great, while still maintaining high level of fine grain control over each theme. You can even keep your Header and Implementation files the same for individual view controllers, just so as you keep the names the same on the storyboard.
So for instance, one of my apps that I'm working on called Jam-mout (A music player) has multiple high quality themes. (Image attached). Each theme has it's own storyboard.
For iPhone apps, where the majority of the GUI design is provided by the operating system, you could do it by setting custom Navigation bar background images, custom button graphics, and different fonts/sizes/weights and whitespace. Make sure you're working with a designer who's familiar with the iPhone GUI (if you're not working closely with a designer this is going to be a nightmare).
I recently put together an app for a client who wanted a heavily customised GUI: http://itunes.apple.com/us/app/gogoparis/id428497937?mt=8. A 'skinnable' app would have several sets like this, so the user could choose between several different overall styles. (I hope your client has an enormous design budget!)
my post here should help you get started:
What is the recommended method of styling an iOS app?
if you need live theme changes, each theme in this example could post notifications when the user selects another theme (or skin) - then you can update either the theme instance itself.
alternatively, you can create identifiers for themes which are mapped (NSCFDictionary) to a central theme factory. an example identifier for a specific view for use with the theme factory could be a string MONImageSelectorTableCellThemeIdentifier.
an example manager/factory which handles all theme loading and vends references to themes:
#interface MONThemeManager : NSObject
//...
- (MONTheme *)themeForCurrentlySelectedSkinForViewWithIdentifier:(NSString *)identifier;
//...
#end
beyond that, it's hard to answer your question in more detail without knowing your requirements. the implementation of skinning an app can range from very simple to very very complex. good luck.
Already some good answer here, but I'd add that if you use a ui toolkit such as Three20
you can skin everything using CSS as you might for web pages.
I do realise this is an old post, but I thought I'd share my penny on the matter:)
To make any Cocoa app skinnable you need you think of 3 aspects of the app:
1) Uniformity: By this I mean that on all windows, views (including buttons, text inputs etc...) you want to have a 'standard' that will apply throughout the app. This is the first thing you need to look at. Although iOS and OS X alike already have 'themes' as to put it i.e. Apples default way of shading and laying things out, you can override these (refer to the individual view / window etc... documentation.
2) Performance: With skinning etc... performance is always an issue when it comes to writing your own drawRect etc... methods. The code apple have in place for the 'default' is already optimised, so you need to keep a close eye on the performance of the app whilst you are doing this. Good examples are: Do I use an image with a gradient, or do I use NSGradient? Both of which have performance issues when it comes to rendering them, but it's a question of which is the better of the two
3) userDefaults: This is generally the area where you'd be getting your 'skin settings' pulled from. userDefaults is basically where you store all of the information which you generally set in a preference pane.
If I were you I'd look into the class reference of it:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/
Furthermore, here's a nifty example of using userDefaults:
http://mobile.tutsplus.com/tutorials/iphone/nsuserdefaults_iphone-sdk/
Hope this helps!
When I started with IPhone development I preferred using Interface builder for creating views in my application. With time I considered the option of creating the application via code which I really feel comfortable working with.
Now, when I know both ways to create my user interface, I have doubts which way to follow. I keep thinking where to use IB and where to use code. How can I figure out before starting with my application, which way should I create my UI?
There are a number of factors that can influence your choice. It can come down to personal taste, but there are some advantages to using Interface Builder.
The first thing to recognize is that UI design is inherently a visual task. Interface Builder can allow you to create and modify a UI much faster than you can in code. Rather than endlessly tweaking CGRect values in code, then recompiling, testing, and repeating this process, you can instead get direct visual feedback about your changes. This means you can refine and polish the UI much more efficiently, and even test out radically different layouts without too much time or effort.
Another important point is that if you can create and layout a control in Interface Builder, that means there is less code in your view controller. Less code is always a good thing (less bugs, easier to maintain, ...).
So I believe you should try to define as much of the layout and properties in Interface Builder as you can. This can be hard for people who prefer "full control" over things. Many years ago, visual GUI editors were renowned for doing the wrong thing, and developers often shunned their use over doing everything by hand. But Interface Builder is pretty good at what it does, and you can easily dive into code when you need to.
The situations where you would create controls purely in code are when you need to dynamically create a number of objects, for example thumbnail buttons for a photo gallery, or if you have custom layout requirements.
For example, if you have a label whose height is dynamic at runtime, and you want to layout a bunch of controls underneath it (taking its height into consideration), that can only be done in code (UPDATE: iOS 6's Auto-layout can do this now). You can either create and layout everything in code, or you can still create the controls using Interface Builder and just give them arbitrary positions in the XIB which are modified when you lay them out in code. It's not uncommon to see this in some of my XIBs:
The buttons along the top can be created and layed out fully in IB, but the image views below need their images and positions to be calculated at runtime. So we just give them arbitrary positions in the XIB. Some might find this ugly, but it saves time and effort on writing code to create the image views and set up their properties. Again, less code is a good thing.
Other times you may want to use code is setting certain explicit properties. Let's say you have an image view which needs to receive touch events because it has some gesture recognizers added to it. You need to set the "User Interaction Enabled" property to TRUE. It can be better to do this in code because the requirement is more visible and you can leave appropriate comments as to why you are setting the property. It's also harder to 'lose' the setting like you can in interface builder if you need to delete and recreate a bunch of views.
I think for many applications that use the stock UI, Interface Builder is a great tool to rapidly get things up and linked with the underlying code. Also, it really stresses the paradigm of the View being separated from the Controller as you really can't push code into places where it shouldn't be.
That being said, I use it less and less the more I learn about how to rapidly code interfaces due to the fact that they may need to be more flexible or need a variable number of UI elements based on the Model behind it.
Use interface builder as per your requirement. It's depend on you that how you manage things. See creating a custom cell using interface builder is much easier to update at a later stage while using code you have to do a lot of changes if layout changes. Also you can visualize the view before running the actual app but in code you cannot you just have to assume.There are both prons and cons of both things.
I'm the programmatic guy, and I simply don't want to use Interface Builder. I feel out of control, and besides that my GUI is about 90% custom all the time.
Literally every book does everything in Interface Builder and claims that this is the one and only great way to have real MVC going on.
Example: One of those books mentions that programmatically creating an UINavigationController with an Root View Controller and everything else that belongs in there is a big mess and won't be reusable when porting to the iPad, while doing this in XIB is a clever decision. Then the port to iPad using UISplitViewController will be a simple task.
So when I make iPhone apps and want to port those to the iPad too, what strategies work to reuse as much code as possible? I'd like to learn more about how to separate my code and achieve a better overall architectural design without using Interface Builder.
For those who want to tell me I must go with IB: Again, I do a lot of custom UI where IB is often just in the way. And not to mention all the animations. I really have my reasons. For people who make default UI IB is really fine - but please, I don't want to start a fight for IB vs programmatical UI or default UI vs custom UI! It's all about how to achieve great reusable code when doing everything programmatically, and both have their pros and cons.
Although you did not ask for it, I feel compelled to make the case for why people in general (perhaps not you) should consider IB, and then address the issue of custom components.
I use a lot of animations and custom components. And I love to use IB...
The key is to use IB for its strengths, and then decide what to do with the rest from there. What then are the strongest points of IB? Connections, placement, auto-resizing and customizations.
Connections are linking aspects of views and controllers together. It's faster in IB to drag out a few connections to delegates or references, than it is to write the code that forms the connections. And, it's a quick place to review all links to the UI you are building.
Placement IB also does well at. There's a fair amount of code involved in setting up any GGRect correctly. Not only is it easier to enter and review coordinate and size details in IB, but the tool automatically sizes a lot of elements properly for the container and the control, and offers many guides to help things line up properly - that kind of thing can take a lot of repeated testing to get right.
Related is auto-resizing. Although I don't feel that many screens can actually have auto-reiszing rules that rotate the screen and come out the other side looking just right (I almost always do rotated views as a separate XIB file), there still are a lot of shifts that can occur in the course of running your application that make it really useful to have these defined just right. The best example of this is the enlarged status bar while you are on a call.
Lastly comes customization. This again can be a lot of tedious code to write; try setting up all of the properties on a UILabel manually and it'll have you yearning for quick changes in IB.
With all that said, what is a good approach to custom components? I like to use UIViews in IB screens, with the class type set to a custom UIView that then fills out the display at runtime. But at least IB helps me get composition, placement and auto-resizing just right with minimum fuss, and also wire aspects of that custom view into a controller.
The one thing that would really lend IB to use with custom components is if it would simply let me set values for any simple properties the custom view had - then I could adjust parameters like a corner radius or whatever else I had going on.
I urge you to think on IB a little more, as it's a huge productivity boost when used correctly. There should be nothing about IB that gets in the way, it's there to boost your output.
One book I really liked was Erica Sadun's iPhone Cookbook 1st edition. It did everything programmatically.
Unfortunately the second edition is bloated.
If you reuse lots of your custom UI objects, it would make sense to write a code which
reads a plist (or a more general XML file) specifying how the custom UI objects should be placed / animated
and then creates your custom UI objects accordingly.
It's like writing a mini-xib file format tailored to your UI objects; you can also feel that you're in control of everything, as an added bonus.
First: No, none of the content should be loaded from the web. All content parts are shipped with the main bundle.
I have n images and mass of text (including lists). Instead of building all view parts programmatically in objective-c if was thinking of using an UIWebView and build "only" the HTML dynamically.
Does anything speaks against it?
How does UIWebView work with local content?
Links and resources welcome.
Thanks
I would not recommend using the WebView for building application UIs. It introduces many elements that may cripple the user experience. Well, it basically depends on the complexity of the UI.
I created an App UI in WebView myself, using JavaScript and all that advanced CSS animations/transforms that WebKit has to offer, but in the end it was not good for the consumer. My goal was to make the app skinnable, but if something goes wrong - for example in JS - the WebView is stuck, except you spend the time into building a WebView wrapper for your app that deals with this.
That said I, i don't know how complex your UI is going to be, but I would say using IB or building the UI in code with cocoa is still more efficient.
Regards, Erik
I've thought about using web views in these situations sometimes, but then decided against it. 99% of the time, it's better to design the screen in Interface Builder. That will be as fast as or faster than creating an HTML page, and will give you all the benefits of elements functioning as expected (text input for example) and the possibility of customizing things programmatically. But of course, in many scenarios a web view might be the way to go (in fact, several standard UI elements have underlying web views).