PIXEL
DOCK

I like the smell of Swift in the morning…

The curious case of the missing social buttons

Posted: | Author: | Filed under: HTML, iOS | Tags: , , , | No Comments »

Now for something a bit off-topic. As a side project I handle a friend’s company’s website. He asked me to add a button that links to his facebook page and another button that opens the review form for his company’s google page.

Easy peasy. I made two images and embedded them in a link element:

<a href="https://www.facebook.com/...">
   <img src="btn-facebook.png" />
</a>
<a href="https://goo.gl/...">
   <img src="btn-google.png" />
</a>

As expected everything worked as expected. Not exactly rocket science.

Until I looked at the webpage in Mobile Safari. The two buttons were not showing up there. They were showing in Chrome for iOS but in Mobile Safari: no Facebook button, no Google button!

As it turned out the image filenames were the problem. Naming them “btn-facebook.png” and “btn-google.png” was triggering my Mobile Safari’s content blocker app!

The solution was really simple. Just renaming the image filenames did the trick:

<a href="https://www.facebook.com/...">
   <img src="btn-f.png" />
</a>
<a href="https://goo.gl/...">
   <img src="btn-g.png" />
</a>

Now the images are “hidden” from the content blocker and show up in Mobile Safari.

How to avoid the ugly flickering effect when using CSS transitions in iOS

Posted: | Author: | Filed under: CSS, HTML, iOS | 2 Comments »

Recently I used CSS transitions to animate some images inside an UIWebView. Everything worked fine and the transitions where really smooth. I used the translate transition to move the images that where inside a div HTML element:

<div id="image-container">
   <img src="img-1.png" />
   <img src="img-1.png" />
   <img src="img-1.png" />
</div>

To move the images I created a CSS class that contained the transition:

.move {
   -webkit-transform: translate(50px,100px); 
}

Then I would add the CSS Class to the

to move the div and the images contained in it.

document.getElementById('image-container').className = "move";

This worked as expected. However, when the images moved, there was an ugly flicker. It turned out that this is caused by a CSS property call “backface-visibility”. Normally this is used, when you do 3D CSS transitions (e.g. 3D rotations). “backface-visibility” determines whether the backside of a HTML element is visible, when it is not facing the screen. As I am not doing any 3D transitions it should not matter how this property is set. Wrong. Obviously in Webkit Browsers it does matter. To fix the ugly flickering you have to add the following to the CSS class:

.move {
   -webkit-transform: translate(50px,100px); 
   -webkit-backface-visibility: hidden;
}

And thats not enough. The flickering became less but it was still there. Only after I also set the “backface-visibility” property on the images themselves, the flickering went away completely:

.move {
   -webkit-transform: translate(50px,100px); 
   -webkit-backface-visibility: hidden;
}

.move img {
   -webkit-backface-visibility: hidden;
}

I don’t know if this is a bug in Webkit or if there is a logical explanation for this behavior, but setting “backface-visiblity” to “hidden” on all animated elements did the trick.

Dismiss keyboard in HTML form displayed in UIWebView inside modal view controller

Posted: | Author: | Filed under: HTML, iOS | Tags: , | 2 Comments »

Recently I encountered a problem with the keyboard while displaying a HTML form inside a UIWebView: The HTML form was a simple form to ask the login credentials from a user. Nothing more than 2 text input fields and a submit button. When the user tapped on an input field the iOS Keyboard came up, as it should. But then, when the user tapped the submit button, the keyboard stayed in placed and was not dismissed. The normal behaviour would be that the keyboard would be dismissed as soon as the textfield loses it’s focus. But somehow this was not happening.

I found several solutions on how to dismiss the keyboard programatically by either using javascript or calling resignFirstResponder on the UIWebView when the form was being submitted, but the keyboard would still not go away.

Then I found the solution to that problem. I turned out that the lingering keyboard was a UI design choice by Apple. The keyboard dismissal is disabled when you present your UIWebView using a modal ViewController with presentation style UIModalPresentationFormSheet!

The solution is quite simple: You have to override your ViewController’s disablesAutomaticKeyboardDismissal method:

- (BOOL)disablesAutomaticKeyboardDismissal {
    return NO;
}

After that the keyboard will be dismissed as soon as the input fields lose focus (or the form is being submitted).