With Project 7 started, today was really devoted to taking the data that we collected in the JSON file, parsing it out and displaying it on the iPhone. This meant working with information and displaying it using HTML.
If this project were simply building a small browser like we did in Project 4 which was the Safe Browsing project, this part would have been simple. The challenge we faced this time was that the information was not being displayed within a browser window but instead we would be rendering HTML from within a view controller. That was definitely new.
Apple of course made things easier for us by defining webView.loadHTMLString() which allowed us to pass a string made up of HTML commands. It would take that HTML and properly render it as if it were a web page but within the construct of a view controller.
As a refresher, here is the code we wrote that defined the HTML and the call to webView. loadHTMLString() within Project 7:
guard let detailItem = detailItem else { return }
self.title = detailItem.title
let html = """
\(detailItem.body)
"""
webView.loadHTMLString(html, baseURL: nil)
In the Project 7 Part 1 blog post I described this code so I won’t go into detail here of what it is doing. Instead I want to focus on one line of that code.
This line is rather interesting and not exactly self-explanatory. This meta data looks like typical HTML code you would find in the header of a web page, but it has a specific role to play.
Let’s start with the “viewport” part of the meta tag. A viewport is the screen real estate of a window that displays web content. What we are doing is telling iOS that we want to write web code into a certain part of the screen. This is important because we want the program to know what the boundaries are within the window where content should go.
When developing web sites to be consumed on computers, things are pretty simple. We can expect that most people in this day and age have a relatively large screen. In fact, according to StatCounter who tracks screen resolution on a global network of sites, the most popular desktop resolution is 1366×768 accounting for about 25 percent of all content consumers. Even at the low end most computers support at a minimum 1024×768.
If we want to display content within a browser on a desktop computer we have quite a large amount of screen real estate we can use. That makes designing a usable interface and presenting data easy. There is plenty of room to show a standard sized document from a width perspective and possibly even vertically without fear of running content off the side of the screen.
But with the advent of smart phones and tablets that standard screen size has gotten substantially smaller. With these smaller screens we have to format data differently. When the number of mobile devices were small it didn’t matter if it didn’t look good on a phone. But as of 2018, mobile internet traffic accounted for 52.2 percent of all Internet traffic meaning that for the first time the majority of visitors hitting a web page were doing so with a smaller mobile web device.
Getting back to the viewport discussion, this meta tag allows us to ensure that the data passed will fit within the confines of the mobile screen regardless of whether it is a phone or a tablet. The content portion of that meta statement tells the webView.loadHTMLString function what the width is of the mobile device it is being run on.
In a perfect world this might not be needed if all web content were responsive and built to check and define the width within the web page. But there is a lot of content that isn’t responsive so this meta tag helps to make sure the content is somewhat readable on smaller screens.
Notice on the width statement that we didn’t give it a number like 480 pixels or some constant. The reason for this is that mobile devices have many resolutions. By using the value “device-width” it tells the system to use the width of the screen in CSS pixels at a scale of 100 percent. This allows the content to flow and eliminates the programmer from having to specify a specific width for every different kind of device.
The last part of the meta tag is “initial-scale”. I think we have all used the zoom gesture on a web page to make content larger or smaller using finger pinches. Since we do not know if someone has zoomed in or out and to what level, we need to create a baseline. By making “initial-scale=1” we are telling the program to start at 100 percent and no zoom.
Those are all we used in this example, but we could further define parameters in the viewport meta tag describing “minimum-scale” and “maximum-scale” to tell the program how much zoom we will allow based on the content being presented. This can help to minimize the amount of horizontal scroll a user will have given the content being passed.
The viewport meta tag is extremely important and can be very powerful so it warranted a rather lengthy description to help understand how we can use it.
0 Comments
Trackbacks/Pingbacks