Autolayout treats iOS7 screen differently from iOS 6 - autolayout

Scenario: iOS6 & iOS7 (4"inch) sharing the same XIB.
Problem: Both display different layout, albeit sharing the same constraints, etc.
The following images are snapshots of simulated iOS6 & iOS7 version of the SAME Layout/Constraints:
Notice the different layout patter for the fields & button:
Question: How can I get iOS6 & iOS7 layouts in sync; i.e., behave the same?
Here's a snapshot of all the constraints:

It appears that I had two conflicting vertical spaces (that wasn't flagged by Xcode 5).
Near the bottom of the complaint list (see above), there are two 'Vertical Space' constants for the 'Please wait while we...' label: (92) vs (26).
By removing one of them (26), the (iOS 6) layout has adjusted to be in sync with its iOS 7 counterpart.
Still odd...
... why didn't BOTH environments behave the same in the first place?

Related

Viewing a site using Chrome developer tools to simulate an iPhone 12 looks different than viewing the site on an actual iPhone 12. Why is this?

Sections of my site look a little different on Chrome Dev Tools simulating an iPhone 12 than an actual iPhone 12. Why is this? I've signed up for browserstack. Do you guys think they produce an accurate representation of a site on different devices? Do you recommend any others?
This is the site (iPhone 12) on Chrome Dev: https://snipboard.io/OpU8aj.jpg
Same site on my iPhone 12: https://snipboard.io/vl6b8f.jpg
Notice the type in relation to the red background?
I'm wondering too... This is the first time I've used %'s for my padding and margins. I usually use em, rem or px. Could using percentages have something to do with it? I do understand the the percentage is based on the parent element. But still... not sure if that has anything to do with it.
Thank you
I was having the same issue. I learned, and I'm sure most of you know this, any iPhone above an iPhone 8, that Apple's documented viewport size is not the actual pixel size (w x h) that displays a website or app. I discovered this after researching Apple dev docs. There is now a "safe area" leaving room for native device buttons on the top and bottom in portrait mode, or both sides in landscape mode. You subtract the area for these buttons from the manufactures documented viewport size to get the real displayed viewport or "safe area". Of course it will be different for every device.
I hope i'm not breaking any rules with the following. I used "what is my viewport" https://whatismyviewport.com/ Pull up this url in any device and it will show the actual width by height in px, of that device. This is the actual size your website or app will be displayed at.
I am now able to set new media queries using the above info instead of media queries based on the device manufacturer's documented viewport size. This solved the issues I was having.

Xcode 9.3 IOS simulator screenshot always give same dimensions

I want to take screenshot of IOS app for App store submit. But the saved screenshot image dimensions is always 750 × 1334 no matter how i scale the size of simulator or change the iPhone model type, the outcome is always the same.
Solution tried:
Unchecked Optimized Rendering for Window Size, choose Physical size and save the screen shot with cmd + s.
I was try the solution above, but it is not working at all
Use the iPhone Plus simulators to get your screenshots (e.g. iPhone 6 Plus, iPhone 7 Plus, etc.). They will generate a 1242x2208 screenshot size. You are most likely using one of the non-plus simulators (e.g. the iPhone 6) since their screen size is 750x1334; they are NOT the 5.5" devices.

Plain <select> element vs Bootstrap's dropdown element rendered on mobile device

Today I've learnt something new, that <select> element rendered completely different on a desktop and mobile browser. The problem that I haven't use it before and almost all stuff I've done, is by using Bootstrap's elements.
So my question is actually 2 questions are following:
Why <select> tag rendered differently on mobile chrome and desktop chrome when I debugging in mobile mode? Is it intended behaviour or I can consider it as bug? For example open following page http://www.w3schools.com/tags/tag_select.asp from desktop browser in dev mobile mode and on a hardware device, you will see the difference.
What is the best approach to achieve consistency across various devices? Can I be sure that in all new mobile devices <select> will be rendered "in a mobile way", or just implement my own select element based on Bootstrap modal combined with List group as I've done here: http://codepen.io/anatoly314/pen/EPBmrM?editors=1010 ?
DevTools Device Mode does not emulate mobile-specific UA handling of form elements. This is actually very tricky to do since those things are compiled for that platform build.
The best thing to do is know there will be a difference. In the case of select elements it really doesn't matter much. Since the mobile UX is a full screen scroll selector of the choices.
The absolute best thing, as always, is use Device Mode as a guideline. It is not absolute nor can it be. You will always need to do on-device testing to verify everything works as expected. DM simply gets you 85-90% of the way there without issue.

Why does twitter bootstrap "hiccup" on Google Chrome when resizing?

I was playing with adaptative CSS by changing my Google Chrome window size when I noticed that the Twitter Bootstrap page seems to "make google chrome fail" on certain occasions.
Steps to reproduce (from a desktop computer):
Start with a blank Google Chrome tab, full screen
Visit http://twitter.github.com/bootstrap/
Gradually make the window narrower, letting go the mouse every 100 pixels or so.
Keep going until you get the "totally mobile version", at around 400px (The blue "View project on github" button is on top of the white "Download Bootstrap" button, and they are both full-width).
Now make the window thick again, letting the mouse go after every 20 pixels or so.
Chances are that you will get weird behaviour while doing steps 4 or 5 - Chrome gets confused about the sizes, or forgets to draw a vertical region of the page (which is rendered white). I've also managed to get a "phantom side pane" in some rare occasions.
I've tried in two different computers, and I still get the same issues (both using Ubuntu 12)
The thing is, other responsive sites don't have this issue. See for example http://css-tricks.com/ . You can change its size all you want, and Chrome never has any trouble rendering the multiple layouts it has (in fact, it has more layouts than twitter bootstrap).
So I can only conclude that this problem is twitter-bootstrap-specific. Probably related with the way the CSS rules or HTML content is written, or maybe related with the way files are structured.
I'm using twitter bootstrap as a base for one of my sites, and I'd like to solve this issue. Does anyone have any ideas on how to proceed?
If you believe this is bootstrap-specific this should be posted to the Twitter Bootstrap Github Pages instead of SO. However, I've been participating in an issue ticket reg. this which was closed after we pointed out that we're unable to reproduce the error on both Chrome / OS X and Chrome / Win 7 with the same browser build as the OP. This suggest that this is a platform specific chrome-error rather than a problem with the Bootstrap toolkit. With that said, I'd raise a ticket with the chrome team including your build # and OS/Platform setup.
Link to the Github Issue

Safari + jQuery thickbox = massive visual glitches?

I need help determining what the cause of a serious visual glitch is with one of my production websites. It is only happening with Safari - Chrome and all other browsers are fine.
http://www.philanthropicdirectory.org/search
This is a Drupal 6.x website, running the following simultaneously:
jQuery 1.3.2 (Drupal base/default)
jQuery 1.4.4 (This is used here and there by overriding the jQuery namespace to '$js' for certain advanced operations 1.3.2 can't handle)
jQuery UI 1.7.3
Thickbox 1.8.2.19 (I've slightly modified this .js)
TO REPRODUCE:
Click link (visit the page): http://www.philanthropicdirectory.org/search
Click twice (once to center) on any of the 5 'coverflow' panels to trigger Thickbox content
Once TB content loads, resize the browser window horizontally left or right
Notice the odd background-image and background-color offsetting
Switch between any of the 5 'tab' icons in the upper right of the modal system
At any point, use Web Inspector to uncheck and then recheck any CSS property, anywhere
Notice how this instantly clears/fixes all visual glitches
Resize the browser window again or tab between the other tabs, and notice the glitches return.
If you notice the same things I am, it'd be great to get your machine config and Safari version.
Before
After resizing
After tabbing
The images say it all, and as far as I could test, I can only reproduce this problem in the following setup, with Safari:
MacPro, 6-core Xeon (2010)
OS X 10.6.8
2 monitors: 1x 23" Cinema Display (old silver one) + 1x 27" Apple Cinema Display
ATI Radeon HD 5770 (Mac version w/01.00.436 Driver)
Safari 5.1+
I've tested other machines and other machines with earlier versions of Safari (4.x), and the problems are simply not present.
Is there anything you think I can test to figure out why this is happening?
PS: Only using one monitor at a time produces the same problems.
SOLUTION!
I noticed this happening with another website we've built - a website with nothing in common with the Drupal one with the problem here, save for the fact that this new one also has a Flash (SWF) file in the body, and I was applying a CSS property to an element with a negative z-index value.
It was happening on this new website because the container for the object in the HTML was set to
z-index: -1;
in order for elements positioned to overlap the object could be clicked on (otherwise, links on top of the object could not be interacted with).
I was able to permanently fix it by instead setting any elements positioned on top of the object
z-index: 1; /* or anything > 0 */
Given that solution, I hunted down any and all "z-index: -1" CSS on the Drupal website and sure enough there was an element within the Thickbox container that was shown on every tab - the big green "SEARCH" input button. It was styled that way because of visual needs (something to do with the fake inner-drop-shadow on the button).
I disabled the entire z-index property for this element, and lo-and-behold, the funkiness permanently disappeared on the Drupal website.
Hurray! It was surely providence that I came across the same issue more acutely on a different website.
Now I'm not sure the exact bug in Safari that is behind this without intense testing, but all I do know is that an object on the page + any element near it set to z-index: -1 equals total meltdown (on a Mac running Safari 5.x).
I checked in Safari 5.1 (7534.50) on an HP Xeon running Windows 7. I don't see any glitches.
That's weird. Sounds like a race condition of some sort. Maybe there is a bug in your ATI driver? Since it fixes itself when you re-render it, perhaps you could introduce some delay somewhere which might give it more time to render properly?

Resources