I'm applying localization to an iPhone app I'm working on, and slowly going through all texts/strings/labels throughout the app to dynamically retrive the correct language translation done through Localizable.strings - I'm testing with two languages to make sure it's working properly. Naturally English, and also Czech.
So far I haven't had any problems until this one particular UILabel.
While using the iPhone and app in English, no problems at all. However when changing the iPhone language to Czech and testing the app, one of my UILabels won't even initialize. It doesn't even matter if I force the text like this:
- (void)viewDidLoad
{
[super viewDidLoad];
NSLog(#"show: %#", self.segmentedControlTitle);
self.segmentedControlTitle.text = #"test";
// Other code
}
Basically, when in the other language, it just displays the place holder text set in the Storyboard. All other titles that I have set so far work perfectly even using the actual localization method;
- (void)viewDidLoad
{
// The other code...
[self.segmentedControl setTitle:NSLocalizedString(#"VIEWALL_all", nil)
forSegmentAtIndex:0];
}
Any ideas? Can post more code if wanted, but I'm assuming everything is correctly established seeing as though it all works in English. It has to be something simple I've overlooked. I've tried Clean, deleting the app from simulators and my iPhone, trying the build again... same story. Happens on colleague's iPhone as well.
Thanks in advance. (Also I'm still a bit new to iOS dev just FYI)
Dave
Credit goes to Carl Veazey. Your comment helped me figure this out.
So I've learnt the lesson that when you apply localization, you can actually apply it to your storyboard as well - hence creating separate ones for each language.
So my problem was that the English version of the storyboard has the IBOutlet connection, whereas the Czech one did not.
Because I'll be applying all strings like this programatically from the Localizable.strings files, I don't need the storyboard to be localized - I have since removed the Czech version and am applying everything by code. I figure this is better practice anyway.
Thanks again!
Related
I have a Android background and now try to code for iOS.
I use Swift as the language and it works really good so far. Now I am getting some troubles to get my layout to work on different screen resolutions that means different iPhones.
I am using storyboards for my ViewController and for now everything worked well except getting UIImageViews to look the same on each iPhone.
I tried now for 2 whole days with dozens of different approaches to get my layout work, but without any success. If I place a single UIImageView on my layout I am able to set the constraints so that it looks the same on each iPhone. Once I place a UIImageView on top of my first UIImageView it destroys everything. I won´t tell you here what I already tried, because it was a lot and nothing worked for me.
I need really some hint or just someone who could just try it on his Storyboard and tell me how he achieved it to get it work. I am using Xcode 8.2.1.
This is how it should look like (iPhone 7):
This is how it looks on a iPhone 4s --> wrong! Proportions are not the same!
It's need more params and maybe UIStackViews.
https://github.com/OMGHaveFun/exampleAutolayout
I've been developing everything with xib files because we needed to suport iOS4.
Now we are finally supporting only iOS5 and iOS6, so I decided to give storyboards a try, so everything is fine and easy, but I have found myself doing a lot of code like this:
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:#"AddPlayer"]) { //Ugly
UINavigationController * navigationController = segue.destinationViewController;
PlayerDetailViewController * playerDetailsViewController = [navigationController viewControllers][0]; //Super Ugly
playerDetailsViewController.delegate = self;
}
}
I don't know about you guys, but I found this code very ugly and error prone.
Is there a better way for working with Storyboards? Should I got back to xib files?
I worked with Storyboards quite a lot in the last app we built where I work and yeah, I agree the boilerplate code gets pretty annoying after some time, but as far as I know using prepareForSegue is the only way to pass parameters when using segues.
You can't assign properties/delegates on a custom view controller from the Storyboard itself.
Would I go back to using XIB's if I only target iOS 5 & 6? It
depends.
If I had to build a small - medium app (not too many views and not a lot of cross-navigation between them) I would definitely use Storyboards. But when you have a lot of views and a lot of back and forth navigation between them, it really gets complicated to keep the Storyboard nice and tidy, and it feels like you are forcing yourself to use something that actually isn't the best.
On the other hand I feel Storyboards make it much easier to get a feel of the flow and general look of the app when starting from scratch, and you can even use them to create mock-ups that will actually look like the real thing.
So in essence it boils down to what your needs are when starting a project.
EDIT:
Another thing to take into account: if you use SVN/Git or any other VCS to work with a team, Storyboard file conflicts are a total bitch.
I agree that is an ugly code and to smooth my vision I created a macro:
#define WhenSegueIdentifierDo(segueIdentifier, block) if([segue.identifier isEqualToString:segueIdentifier]) block();
And in my prepareForSegue:
WhenSegueIdentifierDo(kModalVC1ToVC2, ^
{
//code
});
WhenSegueIdentifierDo(kModalVC1ToVC3, ^
{
//code
});
I also use constants instead of hardcoded strings (although I cannot use them on storyboard) to keep it more beautiful. I also use a convention: k + type of transition + origin view controller name + to + destination view controller name.
You could also use
navigationController.topViewController
instead of
[navigationController viewControllers][0];
Just my 2 cents...
That's just the nature of the beast. Objective-C using Cocoa conventions produces - (hopefully) self documenting, albeit, verbose code. Looking at your example, I have no problems determining your intention.
Now, if you wanted to make it pretty, you could encapsulate all this into a macro so that it would be condensed to one line. While it may be prettier to behold, it would certainly add unnecessary complexity in maintaing the beast. The end user isn't going care how pretty the code is -- unless it prevents adding new features.
As for discussing storyboards ... they are certainly different but having used them now for six months, I do appreciate having all my nibs in one centralized place instead of spending the time to look for individual files. It's much easier for me to find things by visual layouts, then parsing camel cased file names. That's just me.
My advice, give them time. In a few months if you find them inhibiting your workflow, then by all means, go back to individual nibs. They aren't going anywhere. At least for awhile.
Just my two cents. Good luck!
I have a question about universal app. My app will not have storyboards or xib file. There is possibility to write universal iPhone/iPad application without it? I found some tutorial how to create universal app with storyboard, but i don't want (i can't) use this feature in my project.
If it is possible What should i do? If i have to made changes only in ViewControllers? I'm start to do this, i'm not changing old project so i can do anythng - what should i learn/what should i remember?
I'm targeting to iOS 5.
EDIT:
I have a screen information in resource file and my rootViewController or any other ViewController will be created in compile time, so i can't have xib file for that, i can't put button on xib with Interface Builder becouse i don't even know how many buttons i will have there. I don't know how many screens i've got till i hit run in my project.
Not only can you write any type of iOS app without Interface Builder, it is actually much more testable and pliable. Some auto layout tricks are difficult (not possible?) in IB style projects, as well.
There is an incredibly impressive library called Masonry that wraps the NSLayoutContraint syntax. This makes it quite pleasurable to subclass views while not having to use ugly VFL or incredibly verbose NSLayoutContraint syntax (not even going to address frame setting...blech!). IB style apps also promote bad software development practices and anti-patterns (just dumping everything in a view controller presentation-wise. No Separation of Concerns!). Also, it is more difficult to work on larger teams (IMHO even small teams) while utilizing Nibs, Xibs, and Storyboards due to merge issues.
On top of all of that, you gain a much deeper understanding of the classes you are working with (UIView, UIResponder, etc.) when writing code in this manner (once again IMHO). There is an interesting article outlining some of these issues in more detail: http://doing-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html This is by no means the only article that discusses this problem. Also, this will help for your app delegate: creating a universal window-based iphone app without generated xib file
This is certainly possible, I have only used storyborads once in the many apps I have published. As for not using XIBs, I am not sure why you would want to do that. You can lay out your views at runtime in the init method, but I feel like that is just making things unduly hard on yourself. You can set a XIB up for the iPad and one for the iPhone so you can tailor the UI specifically to each device.
Perhaps if you go into a bit more detail about why you are imposing this requirement on yourself we can discuss if it si worth the effort to go down that road.
Good Luck.
I currently have an iOS application that was originally developer for the iPhone; it was then decided that it was going to be required for the iPad as well. However, there are not many changes to cater for this (only things such as layout, text size and a few others) - the app is just a bigger version for iPad in reality.
One of the things my app makes use of is a UITableView (with a custom UITableCellView). Each one of these then moves onto a UIView. In order to make it a bit more unique to the iPad, I would like to implement a UISplitView to combine these two, to make better use of the larger screen!
This application was handed to me from a previous developer. A large part (95%) of the UI was coded (and not done in Interface Builder). While I am picking up objective-c, there are still some things which throw me. Therefore, my question to you guys is: would this require a huge change in code if I was to combine my UITableView and UIView into a UISplitView? From what I have seen from playing around with the UISplitView, it doesn't seem so. However, because of all the rest being coded, I think the UISplitView will have to be, is that right? Or can I dump in an xib and string up the coded UITableView and UIView?
Final question, is there a tutorial anyone knows about where they have coded a UISplitView? All of them appear to be using Interface Builder.
I hope that is not too much information!
I have multiple custom fonts provided with my app, all defined in the app's plist correctly. I can load UIFonts with those custom fonts with no problems. UILabels using [UIFont fontWithName:#"some-custom-font" size:14] as font work flawlessly.
What doesn't work is CoreText methods.
I need to use those fonts in attributed strings, so I absolutely need the CTFontRef. Till iOS 5 I had no problem what-so-ever. Now, CTFontCreateWithName tends to return a font called .LastResort, instead of what I need. If I kill the app and relaunch, some of the fonts that failed last time do work now, but others don't. Seemingly random. If I call CTFontCreateWithName immediately on app launch, that specific font works later, but again most of the others do not.
I never encountered this kind of behavior before. My app isn't very memory heavy. This feels like some iOS 5 bug. Any help or advice will be very welcome.
I've only used custom fonts via UIKit. You may want to contact DTS, or definitely bugreport.apple.com