I have figured out how to loclize, but it seems yo end up with a lot of paralell xib's.
Is there a good way to manage changes in xib's that as been localized, or do I have to be very strict about not localizing before the xib's are fixed?
I usually create outlets for those buttons and labels that need to be localized. I then localize these in viewDidLoad or awakeFromNib. This however does not allow you to also reposition and resize the buttons depending on the language, but for now I did not have to do that.
The problem I have with localizing the XIBs themselves is that, as soon as you want to add functionality (e.g. an additional button) later, you have to meticulously apply these changes to all localizations of that XIB. For me a XIB is almost never fixed.
Related
I am using xib-s for my UITableViewCells on iPhone. Now I need to convert my app to universal app. Do I have to create new xib-s (looking exactly the same way) for the iPad version? My current problem is that I am using grouped UITableViews. As the left and right margins on both devices differ, some of the controls on iPad are partly "out of the cells".
In case I need new xib-s (looking exactly the same way), do I need separate properties for the controls in the ViewController? For example, for a label named myLabel, do I need a second property myLabelIpad or is there a better way to handle that?
Cheers
My suggestion is to create new xib. But if there are small changes , then you can maintain one xib. However it depends on how different your iPhone / iPad versions are. For example, if the iPad version is just a bigger version of the iPhone one with a few extra buttons, etc, it's easier to use one UIView and just set the frames of the subviews appropriately.
First understand what you are up to. How do you want your iPad app to look like? How does it navigate. Ceratinly you want to leverage from the lager screen of the ipad. When ever you do that and the auto-resizing mechanism is not sufficient (which it rarely is) then go for a separated xib file.
Second - for each XIB which hosts the same number and types of UIView and UIConrol subclasses, you should be able to use the same view controller for two separate XIBs. Just link all conrols within both XIB to the related IBOutlet properties and IBAction methods alike.
However, when you take leveraging from iPad capabilites seriously then you are like to end up with a different set of view controllers. That is when you can combine the controls of several iPad views wihin one single iPad view and similar cases.
Nevertheless, think of using popups. The content of a popup could nicely correlate to what is a full screen on the iPhone. In that case you can use the same view controller again within that popup container.
Does this sort of answer your question? If not, then please be more specific.
Actually you can retain the same Table cell xib files. You just have to get the Auto resizing masks of the cell and its subviews right.
I have made a pretty little UI on storyboard but I'm quite new to XCode and Objective C (coming over from Java) and I'm having some trouble adding functionality. I know that I should make a subclass of UITableViewController (storeTableViewController) and set the class of the storyboard controller to that. The problem is that when I do that all my hard work in the storyboard is erased, and I can see where the code is conflicting with the showing of my UI (for instance, the tableView:numberOfRowsInSection returns 0 always), and I think that with enough time and patience I could program the UI, but is there any way that I can use all this work that I've done on the storyboard and still be able to add functionality? I want to set a text box at the top to be the first responder as well as be able to change an image and labels on command programmatically.
You should probably use IBOutlets. Connect the StoryBoard UI Object to IBOutlets and you can modify the properties of the UI objects from the code
You can declare IBOutlet link this
IBOutlet type variableName
Check this tutorial video which will help you a lot.
Video Link
I use the storyboard as a canvas. I plug in the outlets that I want and all the little details and then I go around and built the classes. That being said, you need to declare a urtext field outlet (depending to what you want it to do) then add the delegates necessary and allow it to perform on selector. Then you can declare the function. Linking it in storyboard is easy by control and drag.as far the image you can use an uiimage and declare its function and how it changes depending to what the changes are the code varies. My suggestion is to take screen shot of your storyboard and post it with your question so I/ we can help you with the code. But as far as your question goes I hope this answer satisfies you. Happy coding.:)
With the introduction of storyboard, I wouldn't select to create a .xib/.nib when I create a subclass of UIViewController, because I can just drag out a viewcontroller in interface builder and assign it to the new class.
So, with storyboard, when would i need to use the .xib/.nib file?
Thank you.
Storyboards don't completely remove the need for NIB files. One common example is when creating subviews to go inside a UIScrollView. You can't create the subviews separately in a storyboard; instead you have to create separate NIB(s) for the subviews and attach them to the scroll view programatically.
In fact, on almost any occasion where you have a need for subviews which change at runtime you'll want to use separate NIBs.
Storyboards are great for certain kinds of apps, but for anything even remotely complicated the old way works very well still. An additional benefit is that they co-exist nicely. You can put placeholder views in your storyboard and fill them programatically with NIB-defined views later on.
I guess, storyboard contains the .xib/.nib files for all your views. It present relationships between them and helps you to avoid confusion if you have a LOT of views. Also it saves your time and nerves when writing code.
I have tried out storyboarding lately and I do have mixed feelings about its use:
Pro's
Convenience: You might have to write much less code. So you can for example show a static view without having to write any code.
Overview: You can quickly see how the ViewControllers relate to each other
Efficiency: For the simple use cases I find the Storyboarding much more efficient than "the old way".
Example 1: Editor > Embed In > Navigation Controller and voilà, no more instantiating and configuring is required.
Example 2: You can make "Prototype Cells" for TableView which speeds up the creation of static table views dramatically. AFAIK this is not possible with nib files
It's cool :-)
Con's
I find that the re-usability somehow suffers with storyboards. Although I can segue to a given ViewController from multiple points, it is still limited since in one case I might use the VC as a Popover and in another as a Master-ViewController.
Assuming that you are working in a big team and different people are changing different parts of your application, having one monolithic storyboard which you then have to merge might pose a big problem team-work-wise.
I really would like to have some mechanism to include or reference existing nib files into the storyboard which is currently not possible.
So considering these points I still find storyboarding very appealing but it makes sense to combine both approaches which is not really a big deal. Additionally, this technology it is still quite new so it might improve in the (near) future.
If you use storyboards, you generally won't need to create separate .xib files. You can still use a .xib file if you want to -- it might be useful e.g. if you have a particularly complex view that you'd like to configure by itself. Most of the time, though, there won't be a need to do that.
I have a iPhone app I want to convert to an universal app so it can run on iPad. I have tried to find information about how to do it, but I don't find anything that answers my question. I have upgraded the iphone target in xcode to ipad. Then I get a new MainWindow-iPad.xib.
But I have many viewcontrollers and I have made those with code, not xib's. Do I need to have a if-clause in the loadView method that loads different viewcontroller depending on if the user has a iPhone or iPad?
It kind of depends on how you've implemented your loadView methods and how you want your iPad version to differ from your iPhone app.
If you just want your app to use the full screen, you can mostly just check the size of the screen and size your views appropriately and use the autoresizing mask to deal with things when you change orientations.
There are a few gotcha's with this approach, though. For example, modal views can work differently (not taking up the whole screen) and, obviously, the keyboard is a different size.
If you want to use completely different views for your iPad app then, yes, you'll quite possibly have if statements that tell it to use completely different view controllers.
Yes you have to create all xib's for iPad and then you have to write if-clause for Ipad xib to be loaded.
i want to customize my tableview, like the tipulator app for the iphone.
And heres my app:
Each UITableViewCell has a few subviews which you can replace with your own. They are:
UITableViewCell.imageView
UITableViewCell.contentView
UITableViewCell.backgroundView
UITableViewCell.accessoryView
As Gendolkari pointed out, Cocoa With Love has a great guide on custom UITableViews.
The theory is that you replace each of those views with an appropriate view to "skin" your UITableViewCells.
When replacing the background view, you check for the first and last cells when skinning the background view, otherwise you can use a "middle" background image. Implement it as a UIImageView. As far as the other views, use what you want.
Additionally, you can use a completely custom NIB file and load that in instead of the default styles provided by UIKit.
While the others are right in suggesting ways to subclass UITableView or its components, this screenshot doesn't look like it's showing a UITableView.
My guess is that they're just drawing custom images onto a background and checking certain areas for taps. What you should do is read up on the drawing methods as well as on intercepting taps and touches.
Here's a really good guide on custom styling for your table:
http://cocoawithlove.com/2009/04/easy-custom-uitableview-drawing.html
Create your own UITableViewCell, and use it, rather than a "generic" one.
You can do this directly in XCode with "File->New File" Then in "Cocoa Touch Class", choose "Objective-C Class" - and under the "Subclass" popup, select "UITableViewCell".
It well generate a XIB, which you can use in IB to customize the look.
Instantiate and pass-in there cells in your UITableView code, instead of the normal UITableViewCells.