I am working on my app to customize button accordingly. However once I change my button accordingly, now it has became irresponsive. You could see my code as follows. By the way, this button still works when I run on iPhone 4. It is really strange!
once I change my button position it works, but it wont work the position I want!
float screenSizeHeight=[UIScreen mainScreen].bounds.size.height;
if(screenSizeHeight==568)
[positionButton setFrame:CGRectMake(184,280,77,30)];
if(screenSizeHeight==480)
[positionButton setFrame:CGRectMake(184,240,77,30)];
Hand Bag button is not working!
Check your condition :
if(screenSizeHeight==568)
In both cases you have used screenSizeHeight == 568 so replace one with screenSizeHeight = 480
Hope it helps you.
Check your Default-568h.png image get added or not. If it isn't added , you mainscreen returns bounds as 320x480.
Note : 1) If you rotate device , check your main screen bounds. It may lead to confusion. You can try Better way to use it.
2) This Default-568h.png is only allowed when building an app using Xcode 4.5 and the iOS 6 SDK
3) When you ask a UIScreen for it's Bounds you get the bounds of the screen, which is the whole device screen. (the status bar is part of the screen)
Related
I'm making a react-native based app, and I can partially use Swift code by react-native's NativeModule feature.
My app will be used as Split view / Slide over mode in iPad, and I want to know if my app is in the left-side, right-side, or Slide-over.
I could get width and height, also origin (CGPoint) by this code.
let window = UIApplication.shared.windows.first
// Then getting X, Y like this...
window.frame.origin.x
Now my app has only one webview, made by react-native-webview.
So I guess, since the webview is the whole content of the app, and it fills app 100%, so it always returns app.
I want to know, not in webView's perspective, but in app's perpective, the POSITION relative to the screen.
For example, if my iPad width is 1400, and if my app is on the half right side, x should be 700.
And if it is on left side, it should be 0.
I really struggled this, but couldn't find any solution.
FYI, I drawed a diagram for this question.
As I wrote on the above, I tried UIApplication.shared.windows.first.frame.
But it only show the CGPoint of webview, not app relative to the screen.
There is no API for getting 'X' or 'LEFT' in react-native-dimension too.
onLayout also not helpful.
I've got a few buttons with text inside. If i run the app on an iOS 10 device, it works and shows the text fine. But running the app on iOS 9 the text inside the button is like "squashed" or "compressed"(the text on version 9 is missing the top and bottom part of the text). I'm not sure why this is happening, I've tried messing around with the hugging and compression settings on the UI Builder, but this hasn't really fixed the problem.
Not sure why it works on 10 but not on 9....The image above shows what the text looks like on iOS 9 ONLY!
I'm just seeing if this is happening with anyone else? or if anyone knows how to solve this problem?
I appreciate any help given! Thanks in advance!
You have to use "adjustsFontSizeToFitWidth" property of titleLabel of your button
Example:
myButton.titleLabel.adjustsFontSizeToFitWidth = YES;
There are a few possibilities:
The height of the button during runtime could be wrong. Try setting a border to the button, run and observe the button outline to see if the height is correct.
myButton.layer.borderColor = UIColor.black.cgColor
myButton.layer.borderWidth = 1
If the height is wrong, it means the constraints could be incorrectly set up.
Another possibility might be contentEdgeInsets, titleEdgeInsets properties of the button having larger than intended top and bottom values.
I have been trying to center a PickerIOS, but I am probably missing the underlying logic behind a Picker, because I just want its width to be full screen.
I can manage to do that with iPhone 4s / 5s, but when I run it on the iPhone 6, the Picker seems to be on the left, with some space on the right side.
I have been trying to use alignItem:'center' with a wrapper around the picker, but that just makes it disappear. I have also tried alignSelf, but still doesn't work.
I thought that Picker, by default, had its width to full screen or does it adapt according to the length of the elements?
Do I have to place it in a Flexbox in order to get it centered with a full screen width?
mask1: {
height:120,
overflow:'hidden',
justifyContent:'space-around',
marginTop:50
}
I find out that the style of PickerIOSItem cannot change, and only works fine in NavigatorIOS. I review the example of UIExplorer and there is no more style binding to the Item. Maybe it's a bug.
I just noticed the iOS 6/7 Delta property found under the UIView's structs layout.
What is this for and why is this missing from AutoLayout?
Note: I noticed this question a while ago, but I'm only posting my answer now because the NDA has been lifted
Why does it not appear for AutoLayout?
As you may have noticed, iOS 7 brings about a whole new look. The look of UI elements have changed, but also so have some of their sizes (or metrics in general). This can make interface design to accommodate both iOS 7 and it's predecessors a bit of a pain.
Apple's official line is to use AutoLayout to solve this; this should take a lot of the hassle out of laying out UI elements for you. Sometimes incorporating this is not easily done, especially if you must still support iOS 5 for business reasons, or your interfaces are managed in a way that makes implementing AutoLayout difficult. As such, Apple seems to have provided a way to make your job a bit easier if you fall into this niche category, and they've called this iOS 6/7 Deltas.
Ok then, what does it do?
Whilst the label in Interface Builder is a bit unclear as to what 'Delta' means in this context, the code contained in the .xib file that corresponds to this feature is a bit more clear:
<inset key="insetFor6xAndEarlier" minX="-50" minY="-100" maxX="-50" maxY="300"/>
The key name insetFor6xAndEarlier explicitly states what this does; you can provide alternative insets for UI elements when run on iOS 7's predecessors. For example, the above defines the following delta change:
x: 50
y: 100
width: -100
height: 200
Whilst the values stored in the .xib doesn't correspond to the quoted values directly, there is a correlation between them.
x: -minX
y: -minY
width: minX + maxX
height: minY + maxY
The images below shows this change visually. It's quite an extreme example, but it's to demonstrate its ability. I would only expect in practice to have delta changes of only a few pixels.
You may notice that the values are the inverse for the iOS 6 view; this is because the deltas are relative to the type of view you're working with. If you're editing for iOS 6, the deltas there are in order to transform the element correctly for iOS 7 (the reverse of the example above).
In order to view the different styles, you can change the way Interface Builder presents it based on the OS it would be running on. This is contained within the File Inspector->Interface Builder Document (1st tab on the right bar), as so:
Does this exist if I like to code my interface by hand?
Not directly, but you can easily achieve the same effect by having conditional checks on OS version within your code, and setting the correct position/size accordingly. The delta ability exists in Interface Builder because there would be no straightforward way to have conditional positioning without having code to do it, and the point of Interface Builder is to get a much code out of the way as possible for UI.
Overall...
Apple strongly recommend that you use AutoLayout, it makes your life easier in most cases. If you can't use it (for reasons mentioned above), deltas provide you with the flexibility to position your UI elements appropriately, based on the current OS's metrics, without the need to manually reposition them in code. A good example is to adjust for the lack of status bar, but there are plenty of other use cases.
Naturally, if you're only developing for iOS7 and above, you don't need to know this feature/won't discover it. Only if you need to have iOS6 devices running your application when built with the iOS7 SDK, without autolayout, do you need deltas.
At the time of writing (21st August), I can't find any documentation regarding this feature, nor any mentions in the WWDC material. I've had a play around, and after a bit of research, that is what I've discovered.
This actually refers to the Delta between layout position from iOS6 to iOS7.
In iOS7, some views can hide the status bar or have it transparent and, in effect, it is overlaid on top of your view. So if you put a UI element at (0.0, 0.0) on iOS6, it will appear below the status bar, but on iOS7 it would appear partially covered underneath the status bar. So in that case you would want a delta that matches the status bar height (20.0 points) so that the layout looks the same in iOS6 and iOS7.
I believe this isn't needed if you use autolayout, but of course, then you lose iPad1 support, which many of us aren't willing to concede at this point in time.
I know this is already been answered, just adding a small variant hoping it could also help those who don't use auto layout and still want to support iOS 6.1 and earlier versions.
Read this Apple's Transition Guide - Supporting earlier version
Choose 'View as' to 'iOS 7.0 and Later'
Base UI for iOS 7. For iOS 6 give suitable delta value. Use preview to see how this will render in iOS 7 and iOS 6 device.
Quick steps:
Select each immediate children of root view individually and add 20px to its 'Y' value.
Then, select all immediate children collectively and give delta Y as -20px. You can also do this in batch or individually.
AutoLayout requires at least iOS 6.0. If you want to support iOS 5.0 you couldn't use AutoLayout.
And those deltas are used to help you adjust the view position on different iOS version(mainly iOS 7 and iOS version lower than 7).
I use those value to help me like this picture.
To see iOS 6/7 Delta in action, I will demo with a SegmentedControl that appears properly on both iOS 6 and iOS 7 devices.
First, select your .Xib or ViewController in Storyboard. Uncheck Use Autolayout and select "View as iOS 7 and later"
In the Interface Builder canvas, place your SegmentedControl so that its origin.y is 20. In iOS 6/7 Delta, choose -20 for DeltaY
This will make your the SegmentedControl laid below the Status Bar in both iOS 6 and iOS 7 devices
Another useful quotes from Developer’s Guide to the iOS 7 Status Bar
Deltas can be set individually for each view and work as you would
expect. If your storyboard or nib is set to view as iOS 6, then
setting the deltas will cause that view to be shifted and/or resized
by the set delta amount when run in iOS 7. Alternately, if your
storyboard or nib is set to view in iOS 7, then the deltas will be
applied when run in iOS 6
If you are using AutoLayout, then Delta is not available.
Try this (tested in iPhone 4s running iOS6):
- (void) viewWillLayoutSubviews {
//iOS 6 workaround offset
if ([[[UIDevice currentDevice] systemVersion] floatValue] < 7) {
self.view.clipsToBounds = YES;
CGRect screenRect = [[UIScreen mainScreen] bounds];
CGFloat screenHeight = 0.0;
screenHeight = screenRect.size.width;
CGRect screenFrame = CGRectMake(0, -20, self.view.frame.size.width,self.view.frame.size.height+10);
self.view.frame = screenFrame;
}
}
This is a curious one.
I have an IBOutlet UIScrollView playScrollView whose height is exactly 1/3 of it's contentSize's height. The app is in landscape. I call this code...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, page * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
... (the int page ranges from 0 to 2) to start on page 1 (displaying the middle third) then go up or down as needed when the user presses buttons.
This works fine for iOS4 both device and simulator, and has been live on the app store for months with no problems. Even iOS5 devices are fine with existing builds, it was only when the app was recompiled for iOS5 that it stopped working correctly on iOS5 devices.
Since updating to XCode 4.2, This doesn't work for iOS5. It goes one page too low, showing the bottom page when it should show the middle. I can get the code to work for iOS5 (device and simulator) by changing page to (page-1)...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, (page-1) * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
...but of course this breaks iOS4, which works fine with the old code, but gets stuck one page too high with this new code. iOS4 and iOS5 are exactly PLAY_VIEW_PAGE_HEIGHT out-of-step (288 pixels, a third of the height of playScrollView). The same thing happens if I use setContentOffset: instead.
One other curious thing, probably the key to this. If I don't do the scrollRectToVisible at all, then iOS4 sits at the top of playScrollView, wheras iOS5 shows the middle third, (ie PLAY_VIEW_PAGE_HEIGHT pixels down).
I could detect the iOS and use different code for each, but that's a horrible kludge. If it's an iOS5 bug and they fix it in a future release, that would break the live app.
Has anyone any ideas, or noticed anything similar? Thanks.