• Translation

For many of us developers, WebKit is a black box. We throw HTML, CSS, JS, and a bunch of images at it, and WebKit, somehow... magically, gives us a web page that looks and works well.
But in reality, how says my colleague Ilya Grigorik :

A web kit is not a black box. This is a white box. And not just white, but also an open box.
So, let's try to figure out some things:

• What is WebKit?
• What is WebKit not?
• How is WebKit used by WebKit browsers?
• Why are many WebKits not the same?

Now, especially after the news that Opera has switched to WebKit, we are surrounded by many WebKit browsers, and it is quite difficult to say what unites them and where they go their own way. Below, I hope we will try to shed some light on this issue. As a result, you will be able to better identify browser differences, submit bugs to the correct tracker, and conduct cross-browser development more efficiently. Standard Web Browser Components Let's list a few components of modern browsers:

• Parsing (Parsing HTML, XML, CSS, Javascript)
• Layout
• Rendering text and graphics
• Image Decoding
• Interactions with GPU
• Network access
• Hardware acceleration

Which ones are common to all WebKit browsers? Pretty much just the first two.

Each WebKit “port” implements the remaining components differently. Let's figure out what this means.

WebKit ports

There are many WebKit "ports" and I provide Ariya Hidayat, WebKit hacker and tech. Director at Sencha has the right to talk about this:

The most popular association with the concept of WebKit is usually Apple's version of WebKit, which runs on Mac OS X (the first and original WebKit library). As you can guess, the various interfaces are implemented using various native Mac OS X libraries, mainly focused in the CoreFoundation component. For example, if you define a colored flat button with a specific outline radius, WebKit knows where and how to draw that button. At the same time, the final rendering of the button (as pixels on the user's monitor) falls on CoreGraphics.

As I mentioned above, the CoreGraphics used is unique to each WebKit port. Chrome for Mac, for example, uses Skia.

At some point, WebKit was “ported” to different platforms, both desktop and mobile. This variation is usually called a "WebKit port". For Safari Windows, Apple also independently "ported WebKit" to run on Windows using its (limited implementation) CoreFoundation library.

...despite the fact that Safari on Windows is now dead. Besides this, there were also many other "ports" (see full list). Google has created and continues to support its Chromium port. There is also WebKitGtk, which is based on Gtk+. Nokia (and now Trolltech, which bought it out) supports the WebKit Qt port, which has become popular as the QtWebKit module.
Some WebKit ports

• Safari
  - Safari for OS X and Safari for Windows are two different ports
  - The WebKit nightly build is a build of the Mac source code "port" that is used for Safari, only newer
• Mobile Safari
  - Developed in a private branch, but was later opened.
  - Chrome for iOS (uses Apple's WebView; more on the difference later)
• Chrome (Chromium)
  - Chrome for Android (uses the Chromium “port” directly)
  - Chromium is also the basis for browsers: Yandex, Sogou, and soon, Opera.
• Android browser
  - Uses the latest WebKit source code available at the time of release.
• Even more ports: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Different ports can focus on different tasks. The focus of the Mac port is the separation between the browser and the operating system, and the provision of Obj-C and C++ bindings for embedding the rendering engine into native applications. The focus of the Chromium port is entirely on the browser. QtWebKit offers its port to be used together with its cross-platform application architecture as a rendering engine. What is common in all WebKit browsers

First, let's look at the common features that are used in all WebKit browsers:

You know it's funny, I made several attempts to write this paragraph. And every time, members of the Chrome team corrected me, as you will see...

And so, first of all, WebKit parses HTML the same way. Well, except that Chromium is the only port at the moment that includes support for threads for HTML parsing.

... Okay, but after parsing the HTML, the DOM tree is constructed the same way. Well, actually Shadow DOM is only enabled for the Chromium port, meaning the DOM construction varies. Also for custom elements.

…Okay, WebKit creates window and document objects the same way for everyone. True, although the properties and constructs they provide may depend on the use of feature flags.

... CSS parsing is the same. Eating your CSS and turning it into CSSOM is pretty standard. Yep, although Chrome only supports -webkit- prefixes when Apple and other browsers support the legacy -khtml- and -apple- prefixes.

...Layout...positioning? It's like bread and butter. It's the same everywhere, right? Well already! Subpixel layout and rich layout arithmetic are part of WebKit, but differ from port to port.

Super.

So, it's difficult.

Now, let's try to summarize what the world of WebKit has in common...

What is common to each WebKit port.

• DOM, window, document
  More or less
• CSSOM
• CSS Parsing, Property/Value
  differences in manufacturer prefixes
• Parsing HTML and building the DOM
  It's the same if we forget about Web Components.
• Layout and positioning
  Flexbox, Floats, block formatting context... everything is common
• User interface tools and developer tools, such as Chrome DevTools aka WebKit inspector.
  Although since last April, Safari has been using its own Safari Inspector, a non-WebKit, closed source one.
• Features like contenteditable, pushState, File API, most SVG, CSS transformation math, Web Audio API, localStorage
  Although the implementation may vary. Each port can use its own storage system for localStorage and can use a different audio API for the Web Audio API.

It's getting a bit confusing, so let's try to look at some of the differences. Now, what's not common to WebKit ports:

• Everything related to GPU
  - 3D transformation
  - WebGL
  - Video decoding
• Rendering 2D to screen
  - Anti-aliasing technologies
  - Rendering SVG and CSS gradients
• Text rendering and hyphenation
• Network technologies (SPDY, pre-rendering, WebSocket transport)
• JavaScript engine
  - The JavaScriptCore engine is in the WebKit repository. But there are bindings in WebKit for both it and V8.
• Rendering Form Elements
• Behavior of video and audio tags and codec support
• Image Decoding
• Navigation back/forward
  - Part pushState()
• SSL features such as Strict Transport Security and Public Key Pins

Let's take a look at one of them: 2D graphics are port dependent, we use completely different libraries to render to the screen:

Or to go into more detail, a recently added feature: CSS.supports() has been enabled for all ports except win and wincairo, which do not have css3 conditional features enabled.

Now, we're getting technical... time to get pedantic. Even what was said above is not entirely correct. This is actually WebCore, a generic component. WebCore is a layout, rendering, and DOM library for HTML and SVG, and is basically what people think of when they say WebKit. Indeed, "WebKit" is technically a layer of bindings between WebCore and "ports", although in normal conversation this distinction is largely unimportant.

The diagram should help:

Many of WebKit's components are switchable (shown in gray).

For example, WebKit's JavaScript engine, JavaScriptCore, is the default engine in WebKit. It is originally based on KJS (from KDE) from the days when WebKit started as a fork of KHTML. At the same time, the Chromium port switches to the V8 engine and uses unique DOM bindings.

Fonts and text rendering are a very big part of the platform. There are 2 separate paths for text in WebKit: Quick and Hard. Both require platform-specific support (implemented on the port side), but Fast only needs to know how to blit glyphs (which WebKit caches for the platform), while Complex moves string rendering entirely to the platform level and just says "draw this, please."

“WebKit is like a sandwich. Otherwise, in the case of Chromium, it's more like a taco. Delicious taco from web technologies.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Components, and shadow dom.

Now, let's expand the scope and look at several ports and several subsystems. Below are the five WebKit ports, note how the toolset for each is different despite the common components:

Chrome (OS X) Safari (OS X) QtWebKit Android Browser Chrome for iOSRendering Networking Fonts JavaScript

Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Chromium network stack	CFNetwork	QtNetwork	Fork of Chromium's network stack	Chromium stack
CoreText via Skia	CoreText	Qt internals	Android stack	CoreText
V8	JavaScriptCore	JSC (V8 is used elsewhere in Qt)	V8	JavaScriptCore (without JITting) *

* Footnote about Chrome for iOS. It uses UIWebView, as you probably know. According to UIWebView's capabilities, this means that it can only use the same rendering engine as Mobile Safari, JavaScriptCore (not V8) and a single-threaded model. However, some code is borrowed from Chromium, such as the networking subsystem, bookmark synchronization infrastructure, omnibox, metrics and crash reporting. (Also, JavaScript is so rarely a bottleneck on mobile devices that the lack of a JITting compiler has minimal impact.)

Okay, so where have we come from? And so, all WebKits are completely different now. I'm scared.

Not worth it! WebKit's coverage of "layoutTest" tests is enormous. (28,000 tests at last count), and not only for existing functions, but also for all regressions found. In fact, whenever you're learning new or "secret" DOM/CSS/HTML-5 features, the "layoutTest" test suites usually have an excellent minimal demo.

In addition, the W3C is making efforts to standardize the test suite. This means that we can expect that both WebKit ports and all other browsers will be tested with the same test suites, which will lead us to fewer quirks and a more interoperable web. To all those who put in the effort by attending the Test The Web Forward event...thank you!

Opera has just moved to WebKit. What will come of this? Robert Nyman and Rob Hawkes have already touched on this topic, but I will add that one of the important parts of the announcement was that Opera is moving to Chromium. This means that WebGL, Canvas, HTML5 forms, 2D graphics implementation, all these things will be the same on Chrome and Opera now. Same API and low-level implementation. Since Opera is based on Chromium, you may feel like you're cutting out your workload to check compatibility between Opera and Chrome.
I should also note that all Opera browsers will be migrated to Chromium. That is, Opera for Windows, Mac, Linux and Opera Mobile (a full-fledged mobile browser). Even Opera Mini, the thin client, will be switched from its current Presto-based rendering farm to one based on Chromium... and a nightly build of WebKit. What is this? This is WebKit, running on the same code as Safari (although some internal libraries have been changed). It's largely run by Apple, so the behavior and feature set are consistent with what you'd find in Safari. In many cases, Apple is conservative when it comes to including features that other ports implement or are experimenting with. Anyway, to use an analogy, think of it as... a nightly build of WebKit for Safari is like Chromium for Chrome. Add tags

In this article we will look at three browsers based on the popular WebKit engine. When it comes to choosing a web browser, users tend to look towards the most famous programs: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. At the same time, many people forget or do not know that Firefox, Chrome and, more recently, Opera are created on the basis of open source projects, which means that these programs can be modified.

This opportunity leads to the fact that many programmers have created several analogues of popular browsers that offer quite interesting features. So, let's look at several representatives of such software.

It is distributed free of charge, has a Russian interface, works on Windows, Android, Mac, iOS. This browser ten years ago was known as MyIE2 and was an addition to Internet Explorer, but a lot has changed since then and now the program uses the Webkit engine by default.

In the latest, 4th version, the browser offers several useful functions, among which the most interesting is the ability to store information in the cloud. This allows you to use your account in the program to transfer information between different devices, be it an Android gadget, an Apple campaign product, or a desktop PC.

The interface of Maxthon Cloud Browser, although made in the style of Chrome, has much more features. The sidebar displays icons for accessing extensions. It’s convenient that with one click you can disable or enable all installed add-ons, and you can download new ones from a special website.

It is distributed free of charge, has a Russian interface, and runs on Windows. A product of Comodo, which is better known as a developer of security software. Comodo Dragon is no longer a development, but a build, since its functionality is not much different from Chrome.

There are not many differences from the original browser, and they all relate to security issues. The first key difference from Google Chrome is truly incognito mode, Comodo Dragon does not use a unique user ID and HTTP-REFERRER, which does not allow you to track the user online.

The second difference lies in Comodo's core business - user security. Assumes the presence of its own secure DNS servers for traffic transmission. Moreover, at the user’s request, traffic not only from Dragon, but also from all other applications can pass through them. Secure DNS servers automatically block access to sites that have been flagged as untrusted by Comodo's proprietary web threat detection network.

It is distributed free of charge, has a Russian interface, and runs on Windows. “Yandex.Browser” is a recently released browser based on Chromium from the Russian company Yandex. In this product, the developers simply added Yandex services to the quick links panel. The “Turbo” mode, which can be found in Opera, was also added and improved. Overall, it’s not a bad browser aimed at Yandex users.

Android and iPhone - browser wars

Part 1. WebKit to the rescue

Development of a browser application responsible for monitoring network status

Content Series:

In total, the iPhone and Android platforms have more than 100,000 applications available for download from a variety of sources. This refers to “native” applications, i.e. applications that are developed and assembled using the appropriate SDK, and then installed on a mobile device. Such “native” applications allow you to effectively implement the technical capabilities of a mobile device, including support for wireless networks, Bluetooth and data storage, accelerometer or compass functions and other technological wonders and innovations that make mobile devices so attractive to users. The popularity of “native” applications for the iPhone and Android platforms is extremely high, but in addition, mobile devices provide ample opportunities for developing Web applications. Mobile technologies have long left childhood, and with them the mobile Internet has reached a certain maturity.

This article is the first in a two-part series on developing browser apps for iPhone and Android. The purpose of this series is to introduce the reader to the basic principles of creating your own mobile Web applications. The capabilities of mobile applications are not limited to running a website on a mobile device. We will look at the basic technologies and approaches used in the development of mobile applications, which make it possible to distinguish this section of software development into a separate independent discipline.

The popularity of the Web platform is explained by the fact that its use allows solving many problems that have traditionally been the bane of developers and system administrators. Among them:

• Installation issues: Installing Web applications is hassle-free—just install or copy them to the server and tell your clients what URL to point to in the browser.
• Scaling issues: Web applications easily scale to a pool of servers in a high-performance data center, and ready-made Web site management tools are used to serve the applications.
• Data archiving and recovery issues: Web applications use centralized data storage, thereby simplifying the task of recovery in case of failures.
• User Interface Considerations: The combination of HTML, Cascading Style Sheets (CSS), JavaScript, and graphics allows you to create a rich user interface that is significantly superior in functionality and appearance to interfaces developed using native SDKs. The latter, as a rule, are not able to provide a full-fledged presence effect for gaming applications and do not guarantee the necessary functionality for interactive information terminals.
• Ease of Use: Most applications require user interface elements that are simple and easy to use, allowing you to easily perform day-to-day operations.

The most attractive aspect of the Internet application distribution model is that it allows software to become a kind of subscription service, a mutually beneficial way to deliver software. "How?" - you ask. Let's look at this issue in more detail.

The Web-based software distribution model allows customers to try the product before purchasing with minimal risk and at a minimal price. If the client liked the trial version, then all that is required from him to further use the software product is to pay for the purchase with a credit card (or using PayPal). Moreover, the software as a service (SaaS) model provides users with a convenient and cost-effective way to purchase software without any significant upfront costs, ensuring a return on investment within the first month of use rather than in the distant future.

The fact is that there was practically no support for Web browsers on mobile devices. The situation changed dramatically with the advent of a technology called WebKit, which confidently took its place in the field of mobile devices thanks to the iPhone.

In just a few years, the iPhone platform has become the number one Web client in the world. Why? Because WebKit, coupled with a reliable Internet connection, made it possible to use Web services on mobile devices much more efficiently than on any other modern browsers. Other players in the mobile device market have also taken notice of the new technology, and the entire market can now be divided into companies that are using WebKit, companies that are going to use WebKit, and companies that are making up excuses not to use WebKit.

So what is WebKit?

WebKit and HTML5

WebKit is a browser engine used to support both the Mobile Safari browser on the iPhone platform and the browser on the Android platform. Of course, WebKit is used in other mobile devices, but for the purposes of this article we will limit ourselves to considering the iPhone and Android platforms.

WebKit is an open source project that originates from the development of the K Desktop Environment (KDE). Modern Web applications for mobile devices owe their birth to the WebKit project. The technological and design characteristics of a mobile device certainly play an important role, but mobile users are primarily interested in content. If a mobile device provides access to only a small portion of Internet content, then it is unlikely to make it to the top list of the most popular devices.

Most of us prefer to live a fulfilling life: if we open a Web site on a laptop while sitting at home, we expect to see the same content when we open that site while sitting on a train. Content is the main problem of mobile applications. No matter where we are or what we do, we need access to the data that interests us. WebKit technology provides rich content on the iPhone and Android platforms.

It is worth noting that WebKit is also used on desktop computers, such as the Safari browser, which is the main browser of the Mac OS X platform. Regardless of whether it is the desktop version or the browser engine for iPhone or Android, WebKit remains the most advanced technology available. supporting HTML and CSS. In fact, WebKit supports CSS styles that are not yet rendered by browsers on other engines - for example, a number of properties defined by the HTML5 specification.

HTML5 is a set of preliminary technical specifications that define browser-based technologies such as client-side data storage with SQL support, moves, transformations, and so on. The HTML5 specification is still a work in progress, but once the basic principles are clearly defined and implemented in browsers on most platforms, the humble beginnings of Web applications will become a thing of the past. Web application development will occupy a significant segment of the software development industry, and we are talking not only about applications for desktop browsers, but also for mobile browsers. Mobile applications will turn from a by-product into the main product in the Web application market.

Design features of mobile web application development

If you decide to master Web development technologies, then you have a very limited choice of tools at your disposal. First of all, the application can be created directly on the server as a file containing HTML, CSS and JavaScript code. In this case, HTML content can be supplied in the form of static HTML files, or can be generated dynamically through the use of various technologies working on the server side, for example, such as PHP, ASP.NET, Java Servlets, etc. In any case, from the point For the purposes of this article, it all comes down to HTML code, and the most important point for us here is that WebKit technology allows browsers to render HTML on mobile devices.

To run a Web application on a mobile device (iPhone or Android), the user needs to launch a browser and enter the URL of the corresponding service, for example: http://yourcompanyname.com/applicationurl.

At the same time, the range of proposed mobile Web applications is quite wide: from a standard Web site to a mobile Web application developed specifically for a specific mobile platform.

Displaying standard sites

The WebKit engine, combined with the intuitive and user-friendly user interface of the iPhone and Android platforms, allows you to view almost any Web site on your mobile device. Web pages are displayed quite correctly, unlike the previous generation of mobile browsers, which randomly transferred fragments of content or did not display them at all. When pages are loaded in a WebKit-enabled browser, the page content tends to scale. In this case, the scale is selected so that the entire page fits on the screen, albeit in a greatly reduced, often unreadable form, as shown in Figure 1. However, the page can be scrolled, enlarged, moved, providing convenient access to all content elements . By default, the browser uses a window that is 980 pixels wide.

While fully displaying a Web page in a browser window is a significant improvement over the experience of previous generation browsers, the capabilities of modern mobile technologies are not limited to this.

Web pages designed with mobile devices in mind

If you want your Web page to be accessible not only to regular web users, but also to mobile users, there are a few more options to consider for optimizing mobile Web applications.

Although WebKit allows a Web page to be displayed correctly on a mobile device's screen, there are certain differences between mouse-based devices, such as laptops or desktop computers, and touch devices, such as iPhone or Android smartphones. Touch devices differ in the physical dimensions of the “click” area, the lack of a function for hovering the cursor over any element, and a different sequence of events. Thus, if you want to create a website that is convenient for both regular and mobile users, you need to consider the following features of mobile devices:

• iPhone and Android browsers are capable of rendering an entire Web page in a fairly readable form—the rendering quality of these browsers is much higher than that of standard mobile browsers—so don't be in a rush to simplify your site design.
• The size of the fingertips is significantly larger than the size of the mouse pointer. Take this factor into account when developing site navigation elements. Don't place links too close to each other, otherwise the user will not be able to click on one link without hitting the next one.
• Hover elements will not work on mobile devices. The user simply cannot “point” his finger over any element in the same way as the mouse cursor.
• Events defined by pressing and holding the mouse button, dragging the mouse, etc. are implemented in a different way on touch screens. Some of these events may also work on mobile devices, but in general you should not expect the mobile browser and desktop browser to perform the same sequence of actions.

A detailed discussion of these aspects can be found in the article " iPhone in Action"(see section). In our article we will limit ourselves to considering the advantages of WebKit, and not its disadvantages.

Let's look at the most obvious problem iPhone or Android users face when accessing websites: limited screen size. In fact, the screen size of a modern mobile device is 320x480 or 480x320, provided the user prefers to view Web content in a landscape configuration. As you can see from Figure 1, WebKit is able to correctly display a Web page designed for standard desktop computers. However, when you scale a Web page, the text may become too small to read, so the user must scroll, pan, and zoom before being able to read the text. How to deal with this limitation?

The easiest way to create a page that displays equally well in a mobile browser window and a desktop browser window is to use a special meta tag viewport.

A meta tag is an HTML tag placed in the head of an HTML document. The simplest example of using the viewport tag looks like this: . By adding this meta tag to an HTML page, its display in the mobile browser window is scaled in the most optimal way (see Figure 2). Browsers that don't support viewport simply ignore this tag.

In some cases, it is useful to define the window scaling parameters in advance, as shown in Figure 3.

To define specific zoom options, specify the exact value of the content attribute of the viewport: meta tag. By changing the value of the initial-scale parameter, the image can be reduced or enlarged. For iPhone and Android platforms, it is better to use values ​​from 1.0 to 1.3. The viewport meta tag also supports minimum and maximum zoom, which allows you to limit the ability of the user to modify the zoom of the page as it loads.

While the design characteristics of the iPhone, in particular the 320x480 screen size, have remained virtually unchanged since its introduction, the parameters of devices on the Android platform have a fairly wide range, since mobile devices on this platform are produced by different manufacturers and are intended for a wide variety of user groups. Thus, if you want your Web application to be popular with mobile users, you should take into account the possible differences in screen size, resolution, and design features of Android devices.

Experience has shown that in addition to the design differences that exist between various Android mobile devices, the Android software itself attempts to set the settings of the loaded Web page depending on the properties of the mobile device's browser. In addition to stability, the Android platform has an ever-changing set of features and capabilities. Your specific Android device's settings will likely be different from your development environment, depending on the SDK version and device manufacturer. Figure 4 shows the browser setup screen in V1.6 Android Emulator. Screen settings provide the user with the opportunity to determine the level of image scaling on the screen (far, near, medium) or select the automatic page scaling mode.

In the world of mobile devices, the most constant thing is change, so the development and renewal of the mobile software market must be taken into account. For example, the Sprint Hero browser settings include a set of options that are completely different from the standard settings used when loading a Web page. The Hero browser is built on the Android V1.5 platform using a number of modifications made by HTC. Fortunately, using the viewport meta tag will ignore Hero's specific settings.

So far, we've seen that WebKit does a pretty good job of loading a Web page, albeit in a greatly reduced and hard-to-read form. We then extended control over how the page is displayed on a mobile device screen through the use of the viewport meta tag. The displayed page is now much easier to read and navigate. But this is still not enough to make our page look and function like a Web application.

Made for mobile devices

Let's move on to consider the design features of a Web page intended for a mobile audience. As a specific example, consider the registration page for the Google email service GMail.

This is what the page looks like in a desktop browser window:

In a desktop browser window, information content is displayed on the left side, and the registration window itself is in the right panel. In a mobile browser window, the same page has a completely different appearance.

The page shown in Figure 6 is definitely designed for mobile users. The screen displays only those page elements that the user needs for further work - no additional scrolling, panning or zooming is required.

Now let's look at the email view window of the mobile version of Gmail. Because the screen space available to the application is very limited, the message viewer has additional buttons and navigation elements. In this case, the displayed navigation elements overlap the window for viewing messages. Also, don't use too many frames or scrolling divs if you can avoid it. The mobile version of Gmail solves this problem by using a pop-up menu that appears as soon as the user finishes scrolling the page. The pop-up menu contains 3 buttons: Archive, Delete and More. When you click the More button, additional menu items appear (see Figure 7).

This is truly an application designed for mobile devices.

It should be borne in mind that we do not want to deliberately impoverish the design and reduce the experience of mobile users who have developed multifunctional browsers for the iPhone and Android platforms. From this point of view, it is useful to pay attention to the element displayed at the bottom of the Gmail page (see Figure 8):

If the user prefers the enhanced functionality of the desktop version, give them the option to download the appropriate version of the page.

Now consider the case where you want to create an application that uses Web technologies, but looks like a native mobile application.

Platform-specific content

The next step is to develop content specific to a particular mobile platform. This defines the format and interface of the page so that the resulting page looks like a native application for a specific platform, rather than a standard public Web site. What do we mean by "native" application?

Before we delve into the discussion of how to make a Web application as similar as possible to a native application for a specific platform, let's put aside the common features of the iPhone and Android browsers and briefly touch on the visual differences that exist between these platforms.

iPhone applications have their own specific look and interface. Show someone a screenshot of an iPhone and, unless they just fell off the moon the other day, they'll almost certainly immediately say it's an iPhone. Show the same person a screenshot of an Android mobile device, and the answer will no longer be so clear. What is the reason? There are several possible explanations. Firstly, the iPhone appeared on the market much earlier than Android-based devices and managed to gain a huge number of fans. Think about the people lining up to pay top dollar for the limited features of the V1 iPhone. Whether you like the iPhone or not, this Apple product is currently the market leader. What about Android?

The Android platform is a relatively new product, and in many aspects acts as the antipode of the iPhone, as it is designed primarily for the open community. The Android platform is used in a wide variety of devices (phones and other household appliances). For simplicity of discussion, in this article we will limit ourselves to the use of Android in mobile phones.

Over time, the number of Android devices in the world will surpass the number of iPhones. This is because Android devices are made by a variety of companies and will be supported by a wide variety of data networks. With such a significant number of players in the Android mobile device market, we should certainly expect some fragmentation of the market based on the appearance and parameters of the devices. This trend can be seen in the SenseUI interface from HTC. This attractive look and feel is not supported by the underlying Android SDK and is not compatible with other Android devices. Motorola, Google and Verizon have joined forces to develop a new Android-based DROID device. This is the first commercial product on the Android 2.0 platform.

Compare the variety of Android systems with the consistent look and feel of the iPhone. The iPhone is a particularly valuable property of Apple. The appearance of iPhone apps may change slightly over time, but these minor changes are unlikely to compare with the various versions of Android systems, which are numerous even now that the platform is in its very early days.

So, what needs to be done in order to bring the appearance and interface of the application as close as possible to “native” programs?

If we had faced this challenge before the advent of Web 2.0, it would have been a serious problem indeed. Early attempts to support multiple client browsers (mobile and desktop) relied on several approaches, for example:

• Development of completely parallel sites
• Dynamic content generation depending on the userAgent parameter
• Using proxy servers that could transform content depending on each specific device. A similar technology was successfully used by RIM to provide access to email from a client’s mobile device.

Such approaches may be quite acceptable in cases where development is carried out by large, well-funded teams. What should the rest of the world do? Not everyone has significant financial resources, highly qualified specialists and unlimited time to implement such strategies. In addition, as we have already noted, the mobile Internet of the previous generation of browsers cannot be called convenient or popular to use, so in any case you should not dwell on outdated methods and approaches.

Fortunately, we won't have to do this. In the era of WebKit and CSS, differences in the appearance and interface of different mobile devices can be overcome by using style sheets and media queries, which allow different styles to be used depending on the specific type of device. Media query technology allows you to obtain information about the client. Traditionally, the browser sends the server a userAgent value, which allows the server to identify the specific browser and determine the content that should be sent to the client. Using a media query, the browser chooses the style of the page based on its capabilities. The following example demonstrates selecting a style sheet designed for smartphones: . And this query defines a desktop style sheet: .

Internet Explorer V6

At the time of this writing, Internet Explorer V6 occupied approximately 20-30% of the total browser market, however, discussing the capabilities of IE V6 is beyond the scope of this article.

More information about media queries can be found in the draft specification (see section).

Let's look at an example of using media queries to develop an application that displays the status of network servers.

Network monitoring program

The purpose of this application is to monitor the operation of several servers. Independent software developers often need to support multiple applications on multiple servers. If you have been involved in software development for any significant time, then you have probably already encountered different types of servers and different types of applications. All this means that it is quite possible that you will not be able to use a single tool to track the performance of all the necessary applications. In this case, it makes sense to use a mobile network monitoring application (netmon). The application provides all the required functionality, while remaining flexible and easy to access from a mobile device.

The netmon application includes a list of servers that need to be monitored. Key performance indicators (KPIs) are collected for each server. Key performance indicators are a primary tool that MBA students have been using for years to assess the current state of a business. From a Web application hosting perspective, the following indicators can be used as KPIs:

• Number of transactions over the past period of time
  • Orders
  • Requests for catalogs
  • Emails
  • Number of page views
• Time elapsed since last transaction
  • Order
  • Electronic Data Exchange
  • Messages from a business partner
  • Uploading a file from the vendor via FTP
• Is the database available?
• Last backup date
• Average order amount (in dollars)
• Amount of free disk space
• Bandwidth for last hour, day, month

The above metrics and other similar operational parameters allow you to assess the health of a specific system or application. For example, during the holiday season we look at the number of orders placed on some of our sites. If the data does not show a stable increase in the number of orders every hour, we conduct a more detailed analysis of the situation.

Because each application has its own requirements and resources, netmon must be flexible enough to accommodate each application's needs. To provide this level of flexibility, we begin by defining the most general data structure to account for the state parameters of each system. In Part 2 we'll take a closer look at where this data comes from and how it is updated. For now we will limit ourselves to the following information:

• Site name
• Site URL (home page)
• URL to get updates
• Status: OK or not
• Quick Summary: A description of the server status that will either be OK or contain a text string indicating the most severe problem for that server
• Elements: This is a set of name/value pairs that we will need to pass the current KPI values ​​for the corresponding site.

Our application will display the resulting performance indicators in an easy-to-navigate format, making full use of CSS, jQuery, and WebKit to draw the user's attention to problem areas. As we have already mentioned, the main goal in developing this application is the ability to run it on the iPhone, Android platform and on a desktop computer in the Safari browser.

Network monitoring application development

Modern Web pages must be created in a declarative form that defines the organizational structure and content of the page. Page positioning and formatting is done using Cascading Style Sheets (CSS) and, in most cases, JavaScript. In fact, JavaScript libraries have become so popular that their use today is the rule rather than the exception. In the application discussed in this article, we will use the popular JavaScript library jQuery. Our application will run on iPhone, Android and desktop platforms. The same HTML code will be used, and any necessary differences will be implemented in style sheets. It must be noted here that we have not consciously put any significant effort into designing an attractive appearance for the application. Moreover, striking colors that do not harmonize with each other were deliberately chosen as the background in order to attract additional reader attention to the organization of style sheets. In Part 2 we'll slightly improve the appearance of the application, but for now the HTML code looks like the one shown in Listing 1.

Listing 1. Application HTML code if (navigator.userAgent.indexOf("iPhone") != -1) ( document.write(""); ) else if (navigator.userAgent.indexOf("Android") != -1) ( document.write(""); ) else ( document.write(""); ) function setupTestData() ( try ( netmon.initialize(); if (netmon.resources.length > 0) ( jQuery.each(netmon .resources,function (index, value) ( ​​$("#mainContent").append(netmon.render(index,value)); )); $(".serverentry").click (function() ($(this ).find(".serveritems").toggle();)); $(".serveritems").hide(); ) ) catch (e) ( alert(e); ) ) My Network Resources My Servers My User Agent

A quick look at the proposed HTML code reveals the following main features:

• The code uses two external JavaScript files: one jQuery library file and one helper file for our application.
• The code uses the viewport meta tag to scale the displayed content.
• The main style sheet is defined by the netmon.css file.
• The userAgent parameter is used to define the auxiliary style sheet. Depending on its value, the style sheet will be loaded for iPhone, Android or desktop browser.
• The page load process uses jQuery and a helper function defined in the netmon.js file to display the data.
• The main page code uses several div tags.
• Finally, the code contains a link to a page that shows the userAgent string. This link has nothing to do with the operation of the application and is used for demonstration purposes only.

Before we get into the details of the stylesheets and netmon.js file that actually define the basic operation of the application, let's take a look at our application in its current state. Please note again that we are using three different style sheets: one for each of the three supported platforms. To make the application development process more visual, each table defines its own background color. In Figure 9, our page is open in the Desktop Safari browser and has a blue background.

Figure 11 shows the appearance of the application in the iPhone browser window (background color is green).

The main style sheet stored in the netmon.js file is shown in Listing 2.

Listing 2. Main stylesheet body ( color: #888888; font-family: Helvetica; font-size:14px; margin: 0px; padding: 0; ) .details ( margin: 0px; padding: 0px; background-color: white ; border: solid; border-width: 1px; -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px; ) .OK ( color: #000000; ) .BAD ( color: #ff0000; ) .odd ( background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) ,to(#999)); ) .even ( background-image: -webkit-gradient(linear, left top, right bottom,from(#999) ,to(#ccc)); ) .serverentry a ( float: right; color: #ffffff; ) .serveritems( color: #000; ) #header h1 ( margin: 0; padding: 0; text-align: center; color: #000; )

Using a different style sheet for each platform allows you to achieve the following tasks:

Change the color scheme of the page. This allows, firstly, to clearly demonstrate the role of the style sheet, and secondly, to show how easy it is to select the desired style sheet depending on the value of the userAgent parameter.

Set different font sizes for mobile and desktop platforms.

Check the relevant WebKit functions. This would make a significant difference if the application was running in a browser without WebKit support, such as Firefox.

Listing 3 shows the code for the iphone.css file.

Listing 3. File iphone.css body ( background-color: #00ff00; ) .serverentry ( -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border -bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px; ) .name ( font-size: 2em; ) .summary( font-size: 1.5em; ) .serverentry a ( font- size: 1.5em; )

As we can see, the background color of the body tag is green (#00ff00), and the font size is adjusted to make it easier to read on a mobile device screen. Finally, let's take a look at the netmon.js file, which defines a list of servers and a function that prints each server's data (used in Listing 4). Part of the file code has been omitted for brevity; its full text is available in section ).

Listing 4. Netmon.js file var netmon = ( initialize: function () ( ), resources: [ ( name: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http:// msiservices.com/netmon.php", status: "OK", summary: "OK", items: [ (name: "DiskSpace", value: "22.13 GB"), (name: "Database Up?", value: "Yes") ] ), ( name: "server 2", homeurl: "http://someurl", pingurl: "http://someurl/netmon.jsp", status: "OK", summary: "OK" , items: [ (name: "DiskSpace", value: "100.8 GB"), (name: "Database Up?", value: "Yes") ] ), // additional entries clipped for brevity ], render: function( index,itm) ( try ( var ret = "; ret += ""; ret += "" + itm.name + " Show
"; if (itm.status != "OK") ( ret += "-" + itm.summary + "
"; ) ret += ""; jQuery.each(itm.items,function (j,itemdetail) ( ret += ">" + itemdetail.name + "=" + itemdetail.value + "
"; )); ret += ""; ret += ""; return ret; ) catch (e) ( return "Error rendering item [" + itm.name + "] " + e + ""; ) ) ) ;

If the status bar of any server is not OK, then the corresponding server entry is displayed in red, as can be seen from the class definition in the CSS file. In addition, if checking the server status reveals any problems (the status is not OK), a brief description of the problem is additionally displayed. Figures 9-11 show that Server 4 is running out of free disk space. When you click on the line of this server, a detailed message about the problem will be displayed on the screen (see Figure 12).

Clicking the show link to the right of a server name opens that server's home page. Having such a link is very convenient for two reasons: firstly, it will save you from the unpleasant need to memorize the URL of each server, and secondly, it will save you from the even more unpleasant need to enter this URL from the keyboard of your mobile device ( even the most convenient one).

So, if we manage to successfully run netmon on a mobile device, the task of maintaining the servers should not cause any problems.

Conclusion

This article introduces the principles of developing Web applications for iPhone and Android using WebKit technology. In Part 2, we'll expand the capabilities of our application by adding data updating functionality using Ajax calls.

What is Webkit?

Browsers such as Midori, Maxthon, Konqueror, Arora and others were created based on the engine. But it's not just little-known browsers that choose Webkit. We present to your attention two “giants” in the world of browsers - Safari from Apple and Chrome from Google (these browsers). It is unlikely that anyone would argue that these browsers have little functionality and low operating speed. In addition to desktop browsers, Webkit has also penetrated mobile platforms, which once again confirms the advantages of free software. The same Safari Mobile, developed for iOS, successfully uses this engine. Standard browsers for the Android, HP WebOS, and Samsung Bada platforms are also built on Webkit.

It is an engine on the basis of which many browsers have been developed. It is quite fast and lightweight, and perfectly handles all the standards accepted in the web environment.

With all this, this engine is freely distributed software. These are the components that allowed it to become very popular among browser developers.

History of Webkit

You may have wondered: “Why free software?” Let's look at the history of its creation. The parent of Webkit is also a freely distributed engine, which is being developed for the graphical environment of Unix family systems. This engine is called KDE. Back in 1998, a team of programmers working on KDE decided to release their own browser for this graphical environment.

Such a browser was released and named by the creators of Konqueror. The engine underlying this browser was called KHTML. 3 years later, in 2001, Apple decided to create its own browser, for which it used KHTML sources, as well as the KJS JavaScript engine. As a result of this synthesis, the Webkit project was created under the “wing” of Apple. On its basis, at the beginning of 2003, the first version of the browser from Apple was released - .

Another “monster” in the world of information technology, Google, also took Webkit as a basis when creating its own browser. And this is another plus to the engine’s merits. Since Google decided that he was right for them, that says a lot. The developers themselves stated that it was decided not to reinvent the wheel, because Webkit fully satisfies the company’s high requirements for supporting web environment standards, as well as fairly high speed in operation.

Today the engine continues to actively develop and has great prospects. This is no wonder, because both Apple and Google are working to improve it. And this is in addition to the official engine developers. Those, in turn, stated that they are in the process of work, the result of which will be the release of the second generation of their product, the distinctive feature of which will be the built-in architecture of separate processes (today this is implemented only in).

A popular web page processing engine that powers Apple Safari and Google Chrome. Is free software. It is characterized by high speed and excellent support for web standards.

WebKit is the web processing engine that powers many browsers. Among them are two of the “Big Five” - and also less popular ones - Maxthon 3, Rekonq, Epiphany, RockMelt. Konqueror, Midori and Arora. Mobile browser developers also use this engine in their products, in particular, Safari Mobile for the iOS operating system and browsers built into the Android, Samsung Bada and HP WebOS mobile platforms.

This variety of browsers is due to the fact that WebKit is free software and can be used by anyone who adheres to a number of certain conditions.

WebKit originates from a free web page processing engine developed within the popular graphical environment for operating systems of the *nix family - KDE. In 1998, the KDE developers decided to create a browser specifically for this graphical environment.

The browser is called Konqueror, and its engine is KHTML. In 2001, Apple began thinking about creating its own browser and took the source code of KHTML and the KJS JavaScript code processing engine to work within the new project. The project was called WebKit.

In January 2003, Apple introduced the first release of the Safari browser, which uses the WebKit engine. Over time, Konqueror developers included the ability to use WebKit along with KHTML. Despite the fact that KHTML is already behind WebKit in terms of capabilities, developers continue to work on it.

Google also decided to use the WebKit engine when creating its browser. Company representatives cited better support for web standards and high speed as the reason for this choice. In addition, Google planned to use the labor of Apple developers. Considering that programmers from two corporations and many independent developers are currently working on the engine, you can be sure that WebKit will become even better.