How to Take Retina Display Screenshots on PC using Firefox

In previous posts we looked at how to create mobile application projects using Apache Crodova and we saw how we could use HTML5, CSS, and JavaScript to develop mobile applications on this platform. And we also walked through the submission process of your app to various app stores (Apple’s App Store and Google Play).

One component of the submission process that we didn’t really cover is the process of taking screenshots of your application. These are required to create the “preview” aspects of your app that the app store will present before a user purchases/downloads your app. Obviously there are any number of ways you can take screenshots… everything from browser extensions, to online services, to pushing the “PrtSc” button on your keyboard. But one of the things that inevitably comes up is the need to take high resolution screenshots, particularly those of the retina displays of iPhones and iPads (displays with 2x and 3x pixel densities). Taking screenshots at these resolutions will lead to some pretty large screenshots. You can see the full list here in Apple’s developer documentation. As you can see, some of the screenshots require some fairly large dimensions. At the time of this writing, the 5.5 inch iPhones require dimensions of 1242 x 2208 pixels for hi-res portrait and 2208 x 1242 pixels for hi-res landscape. The iPad pro screenshots have to be 2048 x 2732 pixels for hi-res portrait and 2732 x 2048 pixels for hi-res landscape. Those are pretty big and you may not have a way of capturing a display this large.

So what to do? Fortunately there is a way to take high pixel density screenshots using the Firefox web browser. You don’t even need an extension and you don’t need a monitor with a high DPI (dots per inch) display. Here is how you can do this…

1. To start it is assumed that you have your app viewable as a demo in the
2. Open Firefox and from the menu select Tools > Web Developer > Responsive Design View.
3. Set the resolution according to what you need. e.g. for 4.7-inch Retina displays (iPhone 6) set 750×1334, and for 5.5-inch Retina displays (iPhone 6 Plus) set 1242×2208
4. Open the hamburger menu in Firefox and set the zoom level e.g. for 4.7-inch Retina displays (iPhone 6) you can set the zoom to 200% and for 5.5-inch Retina displays (iPhone 6 Plus) you can set the zoom to 300%. Firefox will change the pixel ratio according to the zoom level and will respond to resolution media queries. This will give you the correct responsive layout and high DPI rendering.
5. Press Shift + F2 to open the console and type in “screenshot” (and maybe hit space bar) then <ENTER>. This part is important. You must use the console instead of the screenshot button to get a high DPI screenshot. Using the little screencap button in the developer tools is no good. If all goes well, you should see some kind of indication on the screen that the screenshot has been saved/created

Now you will have a high resolution screencap with the correct dimensions that you can upload into iTunes connect! Thanks Mozilla!

Base64 Encoding Web & Icon Fonts in CSS

For quite some time now, web developers have been making use of web fonts quite ubiquitously to add an intricate level of design to websites. Believe it or not, there was a time (late 90s / early 2000s) when there were only a handful of “web safe” fonts that developers could use and know that they’d be rendered consistently in all browsers across all systems. The main problem always has been that if the system did not have the font specified in CSS installed then the browser will usually fallback to some default font like “Times New Roman” (Ewww!) or something else. The only way to get web fonts rendering across all browsers on all systems is to have some way of downloading/importing the font into the web page that the user was viewing.

There were earlier attempts to solve this using things like cufon (*cringe*) but eventually browsers came around and all started supporting the loading of web fonts in CSS. With this approach you could include font files and reference them in your CSS like so…

@font-face {
    font-family: 'Rokkitt';
    src: url('fonts/Rokkitt-webfont.eot');
    src: url('fonts/Rokkitt-webfont.eot?#iefix') format('embedded-opentype'), 
         url('fonts/Rokkitt-webfont.woff') format('woff'), 
         url('fonts/Rokkitt-webfont.ttf') format('truetype'), 
         url('fonts/Rokkitt-webfont.svg') format('svg');
  font-weight: normal;
  font-style: normal;
}

This approach was taken from the “bulletproof @font-face” syntax detailed by Paul Irish from Google in the article here. At the time it was written it was necessary to use all those different font formats because different browsers supported different font formats in implementing web font functionality. By putting something like the above in CSS a developer would be able to use the “Rokkitt” web font simply by specifying the font-family…

h1, h2, h3, h4, h5, h6 {
    font-family: "Rokkitt"
}

As long as the paths to the font files were set properly in the @font-face block all the headers would be rendered in a slick web font called “Rokkitt.” And the great thing about web fonts is that they are not just limited to typefaces. You could also load up an icon font in the exact same manner to easily implement a vast catalog of icons into your project. Using something like Font Awesome, which was/is used by the very popular Bootstrap front-end framework developers can do something like this…

@font-face {
    font-family: 'FontAwesome';
    src: url('../fonts/fontawesome-webfont.eot');
    src: url('../fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'), 
            url('../fonts/fontawesome-webfont.woff2') format('woff2'), 
            url('../fonts/fontawesome-webfont.woff') format('woff'), 
            url('../fonts/fontawesome-webfont.ttf') format('truetype'), 
            url('../fonts/fontawesome-webfont.svg#fontawesomeregular') format('svg');
    font-weight: normal;
    font-style: normal;
}

And then use icon fonts in a project like this…

.fa-glass:before {content: "\f000";}
.fa-music:before {content: "\f001";}
.fa-search:before {content: "\f002";}
.fa-envelope-o:before {content: "\f003";}
.fa-heart:before {content: "\f004";}
.fa-star:before {content: "\f005";}
.fa-star-o:before {content: "\f006";}
.fa-user:before {content: "\f007";}
.fa-film:before {content: "\f008";}
...

By assigning the content of a particular glyph of the icon font to a class you can add that class to an element like so…

<i class="fa fa-heart"></i>

and an icon will appear inside that element! Pretty slick!

Base64 Encoding Web Fonts
As great as web fonts are, their usage does add something that we have to maintain: the font files themselves. The hitch in all this is that you have to make sure that the paths to the font files are correct and in a place of the same domain so they are not susceptible to being blocked by CORS security in browsers. However, different systems might not allow the placing of files on a server or it just might be a pain to try to manage if you have many different web fonts for different implementations. Whatever the reason, if there were some way to take the actual maintenance of the physical font files out of the equation we would probably be much better off. Fortunately for us, there is a way to do this. What we can do if we don’t want to deal with putting the files on the system? Base64 encoding to the rescue! As it turns out, there is a way that we can load up these fonts without even having to deal with the font files if we encode the fonts as Base64.

@font-face {
    font-family: 'Name';
    src: url(data:font/opentype;charset=utf-8;base64,XXXXXX);
    src: url(data:font/x-font-woff;charset=utf-8;base64,XXXXXX) format('woff'),
           url(data:font/truetype;charset=utf-8;base64,XXXXXX) format('truetype');
    font-weight: normal;
    font-style: normal;
}

Where the XXXXXX slots indicate where you would actually paste very very long Base64 encoded string for that particular file. And if we are not concerned about supporting IE8 or 9, or older versions of Chrome or Firefox, all we need is the WOFF format because this format is supported in all modern major browsers: Microsoft Edge, Internet Explorer 11, and the latest versions of Chrome and Firefox. So really, we just need to the one Base64 string of the .woff file.

@font-face {
    font-family: 'Name';
    src: url(data:font/x-font-woff;charset=utf-8;base64,XXXXXX) format('woff');
    font-weight: normal;
    font-style: normal;
}

All you have to do is to convert a .woff file for a web font (or icon font) to a Base64 string. There are plenty of online tools that will do this for you such as this one here.

If there is one downside here, it is that this technique *will* make your CSS slightly larger but it likely all balances out in the end because you have one fewer HTTP request to make.

Develop Apache Cordova Applications with HTML5 & JavaScript

In a prior discussion we looked at how to set up a project so that we could develop an Apache Cordova application using HTML5 and JavaScript. In that section we mostly covered how to set up, build, and run the project — which consisted of the same application in the www folder that Apache Crodova bootstraps when you create a new project. In what follows we will look at the approach for actually writing own code for our app and will look at how an app in Apache Cordova gets initialized. We will also look at how we can extend the Apache Cordova platform by using plugins to give ourselves additional features and functionality that will make for an all around better user-experience (UX) for the users of our app.

Now that we have our project set up and all our platforms added all that we have left to do now is create our application by creating what basically amounts to a website that runs HTML and JavaScript in the “www” folder. How should one develop for Apache Cordova? Personally, I would delete all of the boilerplate files and folders and start from scratch. That is what we will do here. Just take a quick note of how things are referenced in the index.html file and do the same for your own files.

In doing this, I have modified the index.html file in the “www” folder to the following…

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">
        <meta name="format-detection" content="telephone=no">
        <meta name="msapplication-tap-highlight" content="no">
        <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width">
        <link rel="stylesheet" type="text/css" href="css/index.css">
        <title>Cordova Application</title>
    </head>
    <body>
        
        <div id="main">Initializing...</div>
        
        <script type="text/javascript" src="cordova.js"></script>
        <script type="text/javascript" src="js/index.js"></script>
    </body>
</html>

Note: Do not worry about that “cordova.js” reference or the fact that this file is nowhere to be found in our “www” folder. Apache Cordova will utilize this in the proper context when the app runs (so leave it in there).

So as far as the index.html goes, there is nothing too fancy. I have a css file (index.css) and a js file (index.js). That is all you need to get started.

Next, let’s look at our JavaScript in the index.js file. There is really only one thing you need to make note of when you develop Apache Cordova applications in JavaScript. There is a special event that Apache Cordova uses to tell the platform that the everything is loaded and the device you are using is ready to start running JavaScript in your Cordova application. This is what is known as the “deviceready” event. It only fires when you are running an app within a Cordova context (i.e. on a device or an emulator of a device). In a lean version of JavaScript for a cordova application would look like the following (in index.js)…

var app = {
    init: function() {
        document.addEventListener('deviceready', this.main, false);
    },
    main: function() {
        document.getElementById('main').innerText = 'App is ready...'
    }
};

app.init();

Here we are calling the “init” function which will add a listener for the “deviceready” event. When this event fires the “main” function will run, which in this case just changes the inner text of a div element So if we run this using

$ cordova emulate android

or

$ cordova emulate ios

from the root of our project we will see our device boot up, our app launch, and if all goes well we will see the text “App is ready…” so we know that our event is firing.

Read More »

Create Mobile Applications for iOS and Android with HTML5, JavaScript, and Apache Cordova

Obviously at the time of this writing in the 2nd decade of the 21st century, you are no doubt well acquainted with the immense proliferation and impact that mobile apps have had in and on our world. It was not long ago that we were all sitting at our computers at our desks for the large majority of the time we spent in our various avenues of technological communications over the Internet — complete with our with our giant monitors, whirring computer fans, buzzing drives, and the garbled noise of dial-up modems. Now, mobile phones and tablets probably make up as much, if not more, of our time spent working, playing, and communicating online. Everyone has a ~$100 to $600 smartphone (i.e. computer) in their pocket. And with this rise of mobile, apps found on the popular stores — like Apple’s iOS App Store, Google Play (Android), Amazon and a host of others — have completely transformed the way that we do anything and everything because well, there is an app for anything and everything. Every single facet of life probably has an app to manage some aspect of it. Need to remember to breathe? There is an app for that! Yeah, that is a joke (probably)… but there are plenty of “real” apps out there (e.g. iBeer) that are just as pointless. Fun and goofy, yes, but pointless. And they all post their pointlessness to Facebook and/or Twitter.

Whether you want to develop an app to manage some minute aspect of life or just create a fun game, or whatever else, you can download the SDK for the platform(s) that you want to release your app on, do some tutorials, and start building. That’s all well and good, but if you want to port your application to another platform (e.g. release an iOS app also for Android), you will essentially have to try rebuild the same app using the languages in tools of a different platform. For example, iOS apps for iPhone and iPad have traditionally been developed on a Mac in the Xcode IDE using the Objective-C programming language (though Apple has recently released a new language called Swift that can also be used to build iOS apps). Android apps, by contrast are built using Java and Eclipse or the more recently released Android Studio. Native Windows Phone apps are built using C# and XAML in Visual Studio. Other platforms have their own setups. If you want to take this approach you definitely can, but it should be fairly apparent that developing and maintaining a number of different codebases for multiple platforms quickly adds up to a lot of time, effort, and often money as the sizes and complexity of your apps increase.

At the same time as the rise of mobile in the past decade, something else has occurred: the rise of HTML5 and JavaScript web applications. Beginning at around 2009 – 2010 one of the more noticeable developments was the rise of websites and web applications making use of more open technologies such as HTML5 and JavaScript to bring interactivity and 2-way communication between clients (usually browsers) and servers. With Flash on the way out due its proprietary nature, resource hogging, security issues, poor SEO — along with its being snubbed by Apple for support on iPhones and iPads for basically all these reasons — meant that something had to fill the void. HTML5 and JavaScript moved into this space and developers started turning to it for creating interactive “app-like” experiences.

Wouldn’t it be awesome if there were a way to write a single application in HTML and JavaScript with a single codebase and have a way to port this application to all of the different mobile platforms? I am so glad you asked.

Apache Cordova — also commonly known as “PhoneGap” (the only difference between the two is propriety) — allows us combine combine these open technologies together with the SDKs of the various mobile application platforms to make native mobile applications using technologies such as HTML and JavaScript. You can basically create a small static HTML and JavaScript website or web application and this code will be imported into native iOS, Android, Windows Phone projects and configured specifically for the respective platforms. Thus, you *do* still have to have the SDK of the platform installed to build, run, and release the apps. So to create an iOS app you will still need a Mac and Xcode. To create Android apps you will need to install the Android SDK (which comes with the Android Studio IDE). If you don’t want to mess around with Android Studio, you can just try downloading the old standalone SDK tools here and updating from there. But the important aspect of using Cordova is that the HTML and JavaScript that each project will pull in and build will be the same across all platforms. Want to release an update with some slick new features or fix some bugs that have been reported by your users? You need only change your code in your HTML and JavaScript. You don’t have to try and rewrite the same code and/or functionality in a different language on each platform. From there all you need to do is run a few simple commands from the command lines and your HTML and JavaScript will get built and converted into an application that can run on the platform(s) you are targeting.

In what follows we will explore what it looks like to use Cordova to create a mobile application in HTML and JavaScript that can run on a number of different platform. For our examples, we will build our app for iOS and Android, but the process is essentially the same for building for other platforms (e.g. Microsoft Windows Phone, Amazon Kindle Fire). You would just need to download the SDKs for those platforms if you wanted to run your app on those types of devices as well.

Read More »

Better List Item Grid Tiles with CSS

One of the more common ways that you see collections of items displayed on the web are tile based layouts. Usually these tiles will consist of a container with an image and some sort of descriptive text below the image or as an overlay. Accomplishing this sort of layout in HTML and CSS is not particularly difficult but in some scenarios there are some interesting challenges to tackle, especially when it comes to responsive views. We will explore some of these in what follows.

Certainly in doing a layout of tiles you could use the grid of a CSS framework like Bootstrap or Foundation to put each individual tile into a grid column. But there are, shall we say, annoyances that come with trying to do this. For one thing, because Bootstrap is on a system of rows and grids you will have to count the number of items as they come back to figure out when to close out one row and start a new one. For example, if you wanted a two column grid of items and you were returning markup from the server you would have close out the Bootstrap row on every second item. We’ll be using PHP in our example. I do realize that normally in a production-grade app you would not (or should not) mix this UI content with your server sided logic like we do below. You’d probably use a templating engine of some sort. But this is just an example for the purposes of illustration… and developers do mix these two components together at times as I am sure you are probably aware.

So let’s say we have an associative array $data that has a “text” property as one of its keys. We could print the value of each item in our set in a Bootstrap grid layout like so…

$count = 0;

foreach ($data as $item) {
    if($count == 0) {
        $markup .= '<div class="row">';
    }

    $markup .= '<div class="col-md-6">'. $item["text"] .'</div>';
    
    if ($count++ %2 == 0) {
        $markup .= '</div>'
        $count = 0;
    }

}

Which might give us something like what we see here.

This works but it seems a bit awkward and weird. Because we are using a 2 column grid we have to count every other item and close out the row before starting a new row. If we wanted a 3 column grid we’d have to count every 3 items and so on. This might work okay in some scenarios, but in others we may not have the luxury of being able to use the Bootstrap grid with ease and consistency. What if, say, these results that we currently have could also be appended to via AJAX calls? You see a lot of this sort of thing on sites like Pinterest or Instagram and their infinite scrolling capabilities. As you scroll to the bottom more content gets loaded dynamically from the server from client side calls made in JavaScript.

The point is if you use Bootstrap and want to keep the layout consistent you’re going to have to always be keeping track of how many items you have and where you are in the Bootstrap row closing and opening phase. It’ gets a bit messy and awkward to maintain as functionality gets a bit more dynamic and complex. There probably is, for lack of a better term, a “cleaner” implementation we can take a look at.

Read More »