Leading and Trailing constrains behaives depending on device langauge direction. To create an app that only support english requires to select every trailing/leading constraint and disable the respect language direction features. that converts the constraints to left/right constraints.
I remember that I used to disable creating leading/trailing constraints by default. instead, my constraints created as left/right constrains by default.
I am not quite sure how I used to do that. I thought that its related to the Use Base Internationalization feature in the project general settings. That didn't work.
I remember before that the project by default disables the Use Base Internationalization feature in older xcode versions. now its enabled by default.
Any idea how I can automatically force left/right constraints instead of leading/trailing constraints?
Edit:
I just run an app that use base internationalzation and the constraint is leading/trailing and it didnt go RTL even that the device language is Arabic!
As long as you only support English as a localization in your project, there should be no work needed to guarantee that your app will always be LTR, even with leading/trailing constraints.
Related
I have an iOS Application that supports different languages, which uses LTR Storyboard and RTL Storyboard, and reads from Plists. When I run the app on my Device with English iOS Version, everything looks perfect when switching between the languages. But when I change the iPhone OS Language to RTL languages. The UI is messed up.
This happens especially when I enable Localizations to change the app name on home screen.
Any idea why does that happen?
The whole menu is messed up for example, it's to the left side while it should be to the right side, and the menu items icons must be to the left and the labels to the right.
RTL Language on LTR iOS Language Device i.e English
RTL Language on RTL iOS Language Device
This is because you are use leading and trailing constraint.
In a LTR environment leading means left while in an RTL environment, leading means right.
This is Apple way of helpings us to deal with RTL/LTR easily :[ in your case, not so much...
To disable this behaviour, change the semantic attribute of your views.
Semantic Content
If you lay out your views using leading and trailing constraints, the
views automatically flip positions when switching between
left-to-right languages (like English) and right-to-left languages
(like Arabic). However, some interface elements should not change
their position based on the reading direction. For example, buttons
that are based on physical directions (up, down, left, and right)
should always stay in the same relative orientation.
The view’s semanticContentAttribute property determines whether the
view’s content should flip when switching between left-to-right and
right-to-left languages.
In interface builder, set the Semantic option in the Attribute
inspector. If the value is Unspecified, the view’s content flips with
the reading direction. If it is set to Spatial, Playback, or Force
Left-to-Right, the content is always laid out with the leading edges
to the left and trailing edges to the right. Force Right-to-Left
always lays out the content with the leading edges to the right and
the trailing edges to the left.
Assuming that you are already using Auto Layout,
Make sure you have done the following
Remove fixed width constraints. Allow views that display localized text to resize. If you use fixed width constraints, localized text may appear cropped in some languages.
Use intrinsic content sizes. The default behavior for text fields and labels is to resize automatically. If a view is not adjusting to the size of localized text, select the view and choose Editor > Size To Fit Content.
Use leading and trailing attributes. When adding constraints, use the attributes leading and trailing for horizontal constraints. For left-to-right languages, such as English, the attributes leading and trailing are equivalent to left and right. For right-to-left language, such as Hebrew or Arabic, leading and trailing are equivalent to right and left. The leading and trailing attributes are the default values for horizontal constraints.
Pin views to adjacent views. Pinning causes a domino effect. When one view resizes to fit localized text, other views do the same. Otherwise, views may overlap in some languages.
Constantly test your layout changes. Test your app using different language settings, as described in Testing Your Internationalized App.
Don’t set the minimum size or maximum size of a window. Let the window and its content view adjust to the size of the containing views, which may change when the language changes.
See more
Probably a matters of constraints. In the storyboard, you can use the preview editor to get a .. well.. preview, of your UI in diffrent device size in different language.
My question is that, can I trust on
Resolve autolayout issues’ - “Add missing constraints”
option(as in the attached Screen shot), which automatically adds constraints to the objects present in the storyboard?
I used this and tried running the app in all screen formats and it works fine, so can I continue using this or is it wrong to consider “Add missing constraints” for the constraint design. I’m new to auto layout and any kind of response, explaining this concept will be appreciated. Thanks
Utilizing the automatic constraint system is a bad idea. Most of the time, it won't work dynamically for all screen sizes. It generally adds constraints so objects appear correct in the current resolution you're designing in.
For example, it may pin a label you have placed in the center of an iPhone screen based on the distance from the left edge of the screen instead of the X value. That distance from the edge is going to stay the same when you run it on an iPad and it's going to be significantly off-center to satisfy that constraint.
However, depending on the situation, it could pin them correctly (IE leading edges to the super view instead of a constant). You can use the automatic constraint system for suggestions to reference what you need to add still, but I would not rely on it for dynamic UI.
Spend your time learning autolayout instead of throwing darts in the dark, it's really not as intimidating as it seems!
No you should not trust. Add missing constraints will add constraints that are missing. It will not add constraints that's your design actually want.
So I suggest you to understand what constraint you'll require to complete UI.
`For every control, Compiler need to know its : x,y,width and height.
For example : You drag & drop UILabel on your xib. Now you add top space constraint. So compiler will give warning. Need constraint for : X position.
On above example width and height will take according to text of label. Now you had given top space so its y position is known.
But for X you didn't give any constraint. In this case if you use Add missing constraints. compiler will add constraint for x position according to your placement. It may be your require constraint or may be not.
No iT just add the required constant so may be they are fixed so remove all constraints and try again.
Just like what the others say, "Add Missing Contraints" will always give the result of the layout that you desired. It's best that you learn to add constraints manually. But, there are times that you can be lazy for a couple of seconds by using that method but only for very simple layout.
I'll just share my thoughts about when should we use this method.
I use "Add Missing Constraints" when:
My layout is very much simple, it's like I know that when I do it automatically will yield the same result as doing it manually. This help saves a lot of time.
I am setting up constraints manually, but sometimes I don't know what constraints I am missing because the object that I am setting the constraints still shows red lines(missing constraints). This is just my purpose of learning.
I haven’t been able to pinpoint the cause of an issue i’m having , regarding our company project.
I have notice that in all the auto layout views in the project , the views that appear to be attached to a specific side in interface builder,
are presented on the opposite side after the build.
I.e when i am adding a view to a storyboard view controller, than creating an horizontal space constraint to it’s superview leading margin (left side) it appears ok on interface builder and the preview, but after the build, it appears to be inverted on simulator/device , the view has the same horizontal space but to the opposite side ( right side on this example).
The same issue happens to all the views that are already were on the app (the views that supposed to be on the right side appear to be on the left side and vice versa )
I spend hours to figure out what cause this invert with out any success (the issue happens only in our project), i even tried to change the project definitions according to a new one.
I’ll appreciate if you will be able to help me on this matter.
I'am adding the screenshot of the view in interface builder, the preview and the simulator
There are two kinds of horizontal constraint — universal and language-bound.
The universal constraints are called Left and Right. The meanings of these constraints never change.
The language-bound constraints are called Leading and Trailing. Their meaning depends on the language environment in which the app is running. If the language is like English, Leading is left and Trailing is right; but if the language is like Arabic or Hebrew, which are written from right to left, Leading is right and Trailing is left. This allows labels to be constructed that work correctly regardless of writing direction.
This distinction is drawn in Interface Builder with the "Respect language direction" menu item; to get the universal Left-Right constraints, uncheck it:
So, you may be using Leading and Trailing correctly and appropriately for some views, but it sounds from your complaint as if you have accidentally used Leading and Trailing for some views where you meant to use Left and Right.
It happened when you have Right-to-left system language, for example hebrew or arabic. It's default Apple feature.
If you change system language to English everything should be ok.
I have localized my application in arabic. While in arabic culture, I need to mirror my views using constraints like trailing and leading. what are the best practices to have a flipped view?
It may be interesting to note that when set to Arabic, its culture is set as #"ar-AE". I guess flipping the view doesn't work with the #"ar-AE" locale, although I'm unsure whether that's a bug, or if some arabic countries write LTR, thus making sense not to systematically flip the view.
Long story short what constraint settings are required to actually convert view into "Arabic" and properly flip a view?
Yes, using Leading and Trailing constraints is in theory all you should have to do.
The language variant should be independent of the appended region, and fall back to the generic language for layout information. If you are seeing LTR views in ar but not ar-AE, you should file a bug at bugreport.apple.com.
In one of the WWDC 2012 videos, Auto Layout By Example, they demo an OS X app using Autolayout, and at about 7 or 8 minutes in, he shows how for a single view, you can uncheck a box in the Attributes Inspector, and the box is called something like "Translates Autoresizing Mask Into Constraints". Now, I'm well aware of the code equivalent of this box, the translatesAutoresizingMaskIntoConstraints boolean, but I can't seem to find this checkbox anywhere in either iOS or OS X projects. My project uses Autolayout. I really would like this checkbox, because one of things I'm struggling with in learning Autolayout (and converting a springs/struts app to AL) is the million constraints Xcode has generated for each view, and how to clean them up and sensibly override some/all in code. What I'd like in order to do this conversion one view at a time is to turn off those auto-generated constraints.
Why can't I see this checkbox? I'm using Xcode 4.6.
That checkbox is available in Interface Builder (IB), but only if you are developing Cocoa projects targeted for OS X. For iOS, it's not available at present. You can only set it programmatically.
Auto Layout on iOS from my understanding - and others feel free to pitch in here - is not a full implementation of what is available on OS X.
To be honest, given what you say afterwards, this checkbox is probably something you don't need to worry about. I think it is important in upgrading OS X projects to Auto Layout, but generally for iOS it's unlikely you'll be mixing one and the other. I.e., you either checkbox your Xib in the File Inspector to "Use Autolayout" or you don't.
That said, there is one use case where you may need to mess with that flag. That's if you want to create a standalone Xib file for a view, and then load that programmatically using loadNibNamed. When doing that, by default old style Auto Resizing constraints are converted into new style Auto Layout constraints. Typically I want to add my own so I set that flag to zap 'em.
myView.translatesAutoresizingMaskIntoConstraints = NO
Anyway that's another story.
Here's the link for more info, although you've no doubt had a look at it already:
Adopting Auto Layout
One thing I'd say is that if you're struggling with Auto Layout in the beginning - and you wouldn't be human if you weren't, we all have been - then I'd stick with Interface Builder and think about the golden rules. The most important one for me is that it hates ambiguity. It's like a vacuum in nature. Before you can delete the constraint that you don't want, you have to add the one that you do want then zap the old one.
The other mistake that I made was mixing Auto Layout and frames. So I'd do some code that checked the frame width then apply that to the constraints. Bad mistake. That really ends in tears. When you get into Auto Layout it's essential to really forget about doing anything with CGRect, frame, etc.
Stick with it though. Start with some simple views in IB and experiment. There is method to the madness, really.
One more link also worth looking at is:
10 Things You Need To Know About Cocoa Autolayout