I'm far far down the road of having built all my nice buttons and things in a XIB, and I had the sudden realization that people will pay $200 more for the lower quality laptop "Cause it's pink!" but I digress.
I need to somehow centrally control the colour scheme of my app, and change colours on the fly. I have a couple ideas, like maybe a singleton "Theme" object with a few kvo compliant properties holding theme colours and fonts, then have the view controller "listen" for changes, and re-paint everything when the theme changes.
Problems with this so far: I'd need to have a pointer to every single UI object, including things like table view cells - which seems like a pain. Another possibility would be to subclass all my themed UI objects, maybe get them to register as observers on their own, but that makes me wonder about the overhead needed for this, maybe KVO isn't even the way to go here, I don't know.
So I'm wondering if anyone could share what they've done in the past, what works and what leads to big problems?
Thanks!
Update
I ended up going with a singleton object called SkinDispatcher, which only contains a lot of properties that are meant to be observed by UIView subclasses. Then I made quick and dirty subclasses of UILabel, UIButton, UITextField, anything else I happened to use.
These subclasses each looked up their tag number and used it to register for changes to the applicable fonts and colours, in awakeFromNib.
Next I made a class specifically for loading a style, which essentially opens up a plist file full of keys holding font names and R|G|B|A colours, reads them in and sets them to the applicable property in SkinDispatcher, as determined by key name. The last step (yet to be tried) is to set an observer on the StandardUserDefaults key for skins, props to the answerer for that idea.
You already mentioned a possible approach, namely using KVO. ANother possibility is to register for a specific notification, and react accordingly when the notification arrives in your view controller.
Related
Thank you for reading this.
These are my first steps in the iPhone Ipad app programming.
In order to learn from scratch (and because I know my app would need dynamic views), I decided not to use Interface Builder.
My question is(regarding the fact that I don't use IB): how would one use Views and Controllers?
I think I understand the MVC concept as it is repeated over and over again in the tutorials I follow, but after the "MVC explanation" part, nothing is made to make it clear "on the field" and closer to the real world (Earth being Xcode here).
Worse, sometimes it seems that some tutorials mix these two concepts up and use one word to say the other.
I read around here a lot of questions (and answers of course) based on the matter but I still don't get it. Sometimes it's too generic, sometimes it's too specific (for me at least).
For what I think I understood, the UIView is the static View when the View Controller is the logic which links the View to the data and those 3 concepts must be separated.
This separation, while a bit clearer with the use of Interface Builder seems to get quite blurry when you code everything as it becomes a virtual soup.
Technically, should I create a specific ".h" and ".m" file for each View AND ALSO for each associated Controller?
If I understand the MVC pattern, it's seems that I should but when I follow tutorials (without IB) it is never the case, view and controllers are created and manipulated within the same implementation files.
Any high level (I'm a noob, don't forget) but still applicable explanation of the use and best practices?
Let's say I want to create a simple app with a green view I can swipe to get to a red view.
I know for sure that I would need at least an:
xxxappDelegate.h
xxxappDelegate.m
xxxView.h
xxxView.m
What else?
1)Where should I put the the second view (along with the first one in "xxxView" or should I create another class h and m file?)?
2) What would the controller(s) do, for that kind of application? In which files would they be created and in which files would they be invoked and how would they "control" the related view?
3) Mainly, regarding to MVC pattern and the fact that there would be no IB, how would you organize that app?
I know it's a lot if you go into the details and code but that's not the point here.
Thank you. This - as simple as it seems - would be of a great help and is not as easily found in tutorials as you might think.
I understand the tutorials I read but they are so particular. As soon as I try to create something on my own which is not a "Hello World" screen, I realize that something is missing, logic wise.
Thank you very much for your help.
Sorry, but I can't get past your first paragraph. If you don't use Interface Builder, you are not going to be a successful iOS programmer. It's that simple. The best advice I've ever read about this is in this Aaron Hillegass interview:
Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file. As a result, their project has a lot less code. Programmers who have spent a few years working in Visual Studio get freaked out. They ask me stuff like, "Can I write Cocoa apps without using Interface Builder? I like to see the code. Maybe I can just explicitly create my windows and the views that go on it?"
It is difficult to explain how the NIB file (and a few other scary ideas) create leverage. It is that leverage that enables one guy in his basement to compete with a team of engineers at Microsoft or Adobe. It is like I showed a chain saw to a early American colonist, and he said, "Can I cut down the tree without starting the engine? I don't like the noise. Maybe I can just bang it against the tree?"
Yes, it's hard to generalize after reading specific tutorials, but you will learn. I thought the learning curve was insurmountable when I first started, but if I can become a programmer that gets paid to write Cocoa software, you can too. Just keep reading and practicing. Don't fight the tools--use them.
Early:
In order to learn from scratch (and because I know my app would need
dynamic views), I decided not to use Interface Builder.
Later:
As soon as I try to create something on my own which is not a "Hello
World" screen, I realize that something is missing, logic wise.
I think what is missing logic wise is that you have accepted your assumption that Interface Builder was a crutch and that to learn "from scratch" you had to avoid using it. You are trying to learn the MVC design pattern but you are not willing to use the tools that have been designed to support it.
In Apple's own documentation they discuss the fact that sometimes there is value in having combined roles—Model Controllers and View Controllers—and that is worth reading, as it may explain some of the code examples you're reviewing. But my primary advice would be: before assuming you know better than the people who built the tools, trying using them the way they recommend. It might be an eye-opener.
Additions later:
OK, so to try and actually answer your questions...
1)Where should I put the the second view (along with the first one in
"xxxView" or should I create another class h and m file?)?
If I am understanding correctly and the two views you are thinking of here are the red and the blue displays to the user, you wouldn't have a second view—what you would do, whether in IB or in code—is to have an element in your view on which you changed a colour property... This would be done programmatically whether you were setting up the parent view in IB or in code.
2) What would the controller(s) do, for that kind of application? In
which files would they be created and in which files would they be
invoked and how would they "control" the related view?
There would be a view controller that would implement the gesture support, and would provide a method for changing the colour of the item in the view between blue and red when that swipe gesture was successfully received. I would have a ViewController.h and and ViewController.m. I think if you were implementing the View entirely in code, it would be implemented in the ViewController.m rather than having a separate View.m. (If you were using IB, you would have a ViewController.h, ViewController.m and ViewController.xib, with the latter providing the basic setup of the view elements and layers.)
You would create a ViewController instance in your AppDelegate.
3) Mainly, regarding to MVC pattern and the fact that there would be
no IB, how would you organize that app?
As above.
If you really insist on going without IB (and I agree 100% with SSteve) then in addition to the files you list you will also want to use a UIViewController. Now, it is important to know that you only need to create header and implementation files when you are adding or changing default behavior.
In you case, the view can probably just be a generic UIView, so you wouldn't need the files. What you would do is subclass UIViewController, and put the swipe logic there. In the swipe logic code you would probably just change the background color of the view.
You would instantiate the view controller in the delegate (in this case anyway) and create the view in the view controller's loadView method. That is required since you won't be using IB.
Personally though, I think that IB does a great job of encouraging proper MVC patterns, and if you are just starting then you should go with IB.
In practice you mostly do not make classes for views, unless they need to do custom drawing or display.
For lightweight configuration of views, that is often done in the viewController's viewDidLoad (or I guess in your case loadView) method.
Yes it's a good idea to keep model and view separated, but that's also balanced with the equally good idea to reduce the amount of code that exists. The less code that is written, the fewer bugs you will have.
Since you are just starting out at this point I would absolutely start by using ARC, and using IB - even though I'm sure you're tired of hearing that from everyone, I'll give you an alternate take. Less code means fewer bugs. And the fact that so many experienced developers are telling you to use it should be a giant clue about what a productive path forward is. I mean, are you doing this to build applications or learn every corner of the UIView class?
To speak to your code example, you do not need the UIView custom class. Just create use a UIViewController's main view as a container view, place a UIView inside with the background set to red. On swipe (using a gesture recognizer attached to the container view) call the UIVew method to swap in a new green-background UIView for the existing red view, you can even define the transition style.
Or create a scroll view in the container view, set up the red and green view inside the scroll view, set the content size and enable paging on the scrollview.
Or create a custom UIView class as you had, listen for touch events and slowly adjust two subview positions to follow the drag action.
Or use an OpenGL backed view, and based on the gesture recognizer pan the scene you are observing with two triangles for a green rectangle and two triangles for a red rectangle.
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.
This is Cocoa Touch (et al), iPhone, XCode only.
After completing my first commercial iPhone app, I'm struggling a bit to find a way to start and expand an app from scratch which gives the most linear development (i.e., the least scrapping, re-write or re-organization of code, classes and resources) as app specs change and I learn more (mostly about what Cocoa Touch and other classes and components are designed to be capable of and the limitation of their customization).
So. File, New Project. Blank window based app? Create the controllers I need, with .xib if necessary, so I can localize them and do changes requested by the customer in IB? And then always subclass each class except those extremely unlikely to be customized? (I mean framework classes such as UIButton, CLLocation etc here.)
The question is a generic 'approach' type question, so I'll be happy to listen to handy dev practices you've found paid off. Do you have any tips for which 're-usable components' you've found have become very useful in subsequent projects?
Clients often describe programs in terms of 'first, this screen appears, and then you can click this button and on the new screen you can select... (and so on)' terms. Are there any good guides to go from there to vital early-stage app construction choices, i.e. 'functions-features-visuals description to open-ended-app-architecture'?
For example, in my app I went from NavBar, to Toolbar with items, to Toolbar with two custom subviews in order to accommodate the functions-features-visuals description. Maybe you have also done such a thing and have some advice to offer?
I'm also looking for open-ended approaches to sharing large ("loaded data") objects, or even simple booleans, between controllers and invoking methods in another controller, specifically starting processes such as animation and loading (example: trigger a load from a URL in the second tab viewcontroller after making sure an animation has been started in the first tab viewcontroller), as these two features apply to the app architecture building approach you advocate.
Any handy pointers appreciated. Thanks guys.
Closing this up as there's no single correct answer and was more suitable for the other forum, had I known it existed when I asked :)
If you want to know the method I ended up with, it's basically this:
Window-based blank app
Navigation Controller controls all, whether I need to or not (hide when not used)
Tab Bar Controller if necessary
Connect everything <-- unhelpful, I know.
Set up and check autorotation, it might get added to some view later.
Add one viewcontroller with xib for each view, you never know when they want an extra button somewhere. It's easier to copy code than make the max ultra superdynamic adjustable tableviewcontroller that does all list-navigation, etc.
Re-use a viewcontroller only when just the content differs in it, such as a detail viewcontroller.
Minimize code in each viewcontroller by writing functions and methods and shove them in a shared .m
Everything that's shared ends up in the App delegate, except subclassed stuff.
Modal viewcontrollers are always dynamically created and never have an xib.
Been researching how to send data from one child view to another child view. The application has several views, where one is kind of real-time Settings view. Changes in settings should effect stuff inside other views.
NSUserDefaults seems to be popular, but I don't want persistent data nor automatic saving into database/file. Looks like potential slowdown, which I want to avoid.
Second popular thing is passing a reference to some common top level object into each child view. Just haven't found any tutorial, which would show me in detail how to do this... Most likely so easy, no tutorial is needed - after you figure it out once! Would appreciate, if you can point me to right direction (URL)!
Question: I'm thinking about using one "singleton object" to store "global data", access it from everywhere anytime. What could wrong with this? If I create it at e.g. appDelegate.m it should exist before anyone tries to access it, right?
I'm looking at this sample code.
I would recommend using delegates and/or notifications.
Instead of creating a new singleton in the app delegate, add the necessary data (or, even better, references to the data) in the app delegate and have the views have references to the app delegate.
You can also set up notifications so that your views can keep track of changes to the data that they display.
The beauty of a singleton is that it is automatically created when you first access it via some [singletonClass sharedInstance]. So you don't need to "create" it while launching. If it is global data that needs to be accessed from any view singleton might be the right way of doing this.