Building Cross-Platform GUI Applications with Fyne E-Book

Andrew Williams

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch
• Veröffentlichungsjahr: 2021

Seitenzahl: 380

Beschreibung

The history of graphical application development is long and complicated, with various development challenges that persist to this day. The mix of technologies involved and the need to use different programming languages led to a very steep learning curve for developers looking to build applications across multiple platforms.
In Building Cross-Platform GUI Applications with Fyne, you'll understand how the Go language, when paired with a modern graphical toolkit such as Fyne, can overcome these issues and make application development much easier. To provide an easy-to-use framework for cross-platform app development, the Fyne project offers many graphical concepts and design principles that are outlined throughout this book.
By working through five example projects, you'll learn how to build apps effectively, focusing on each of the main areas, including the canvas, layouts, file handling, widgets, data binding, and themes. The book will also show you how the completed applications can then be run on your desktop computer, laptop, and smartphone. After completing these projects, you will discover how to prepare applications for release and distribute them to platform marketplaces and app stores.
By the end of this book, you'll be able to create cross-platform graphical applications with visually appealing user interfaces and concise code.

Leseprobe

Building Cross-Platform GUI Applications with Fyne

Create beautiful, platform-agnostic graphical applications using Fyne and the Go programming language

Andrew Williams

BIRMINGHAM—MUMBAI

Building Cross-Platform GUI Applications with Fyne

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Lazar

Publishing Product Manager: Richa Tripathi

Senior Editor: Nitee Shetty

Content Development Editor: Tiksha Lad

Technical Editor: Gaurav Gala

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Joshua Misquitta

First published: January 2021

Production reference: 2300321

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-316-2

www.packt.com

To the fantastic Fyne community, everyone involved in the project, or who uses it in their own work. Without your contributions and involvement, there would be no toolkit to write about.

– Andrew Williams

Contributors

About the author

Andrew Williams graduated from the University of Edinburgh in 2003 with a bachelor’s degree, with honors, in computer science. After university, he went to work as a software engineer and has gained over 15 years of commercial software development experience across a variety of programming languages, including Java, C, Objective-C, and Go. Andrew has spent many years working as a CTO with many early-stage and growing software start-ups. He has been a core developer in large open source projects, including Enlightenment, EFL, and Maven, as well as involved in maintaining various community websites and tutorials. Andrew’s passion for building tools and services that make software development simpler led him to start authoring books on the subject.

Endless thanks go to my wife, Michelle, for supporting and encouraging me through the development of Fyne and of this book. Many thanks also go to my friends and family for providing motivational messages throughout a challenging year. Thanks to my excellent reviewer, Jacob Alzén, for his time and dedication in making this book the best it could be.

About the reviewer

Jacob Alzén is an engineering student, programmer, and privacy advocate from Sweden. He started out his software career as a volunteer doing community support and release testing for Brave Software and later translated the whole browser into Swedish. This sparked an interest in privacy issues that resulted in the primary usage of open source software on Linux. He has more than five years of Linux experience along with a couple of years of experience in C++ and Go programming. Jacob has also taught C++ programming at both beginner and intermediate level during his own studies at the Curt Nicolin Gymnasium in Sweden.

Table of Contents

Preface

Section 1: Why Fyne? The Reason for Being and a Vision of the Future

Chapter 1: A Brief History of GUI Toolkits and Cross-Platform Development

Understanding the history of the graphical user interface

Popularity of the desktop computer6

Moving to the web9

Smartphones and mobile apps10

Exploring the evolution of GUI toolkits

Platform-specific toolkits12

Cross-platform toolkits13

Hybrid apps14

Comparing native graphical apps to web UIs

Development speed versus delivery15

Visual style16

Technical constraints16

Options for cross-platform native toolkits

Visual style17

Compiled versus interpreted18

Interpreted options18

Compiled options (C-based)19

Compiled options (other languages)20

Summary

Chapter 2: The Future According to Fyne

Technical requirements

Starting with a clean slate

Designing for modern devices24

Parallelism and web services25

Building for any device26

Best practices have moved on26

How Go is a great fit for this challenge

Simple cross-platform code28

Standard library29

Concurrency30

Web services30

High level with system access31

Looking good with Material Design

Color palette34

Standard icons36

Designing APIs for simplicity and maintainability

Semantic API37

Modular37

Testable38

Extensible40

A vision of the future

Beautiful apps42

Simple to learn42

Platform-agnostic43

Distribution to all platforms43

Summary

Further reading

Section 2: Components of a Fyne App

Chapter 3: Window, Canvas, and Drawing

Technical requirements

Anatomy of a Fyne application

Application48

Window49

Canvas50

Container51

Understanding CanvasObject and the canvas package

Canvas demo52

Adding objects to our window54

Combining elements55

Scalable drawing primitives

Coordinate system59

Pixel output – rendering images

Images59

Raster61

Gradient63

Animating a transition65

Looping animations66

Implementing a simple game

Adding a timer to move the snake68

Using keys to control direction70

Animating the movement72

Chapter 4: Layout and File Handling

Technical requirements

Laying out containers

Manual layout78

Using a layout manager79

Hidden objects80

Standard layouts

MaxLayout81

CenterLayout82

PaddedLayout82

BoxLayout83

FormLayout84

GridLayout84

GridWrapLayout85

BorderLayout86

Combining layouts87

Using the container package88

Cross-platform file handling

URI93

Reading and writing94

User file selection95

ListableURI96

Implementing an image browser application

Creating the layout97

Listing a directory99

Loading the images101

Loading the app faster102

Creating a custom layout for the image elements105

Changing a directory107

Summary

Chapter 5: Widget Library and Themes

Technical requirements

Exploring the design of the Widget API

Focus on behavior111

Rendering a widget 112

Card115

Check116

Entry117

FileIcon118

Form118

Hyperlink119

Icon119

Label120

Pop-up menu120

ProgressBar121

RadioGroup122

Select122

SelectEntry123

Slider123

TextGrid124

Toolbar126

Grouping with the collection widgets

List127

Table129

Tree131

Adding structure with container widgets

AppTabs133

Scroll135

Split135

Using common dialogs

ColorPicker137

Confirmation138

File selection138

Form139

Information140

Custom dialogs

Understanding themes

Built-in themes142

User settings143

Included icons144

Application override145

Implementing a task list application

Designing the GUI147

Defining the data149

Selecting tasks152

Filling in the details154

Summary

Chapter 6: Data Binding and Storage

Technical requirements

Binding data to widgets

Understanding data binding164

Supported data types165

Creating, reading, and writing bound data166

Listening for changes167

Using data with standard widgets169

Adapting data types for display

Formatting types into strings171

Parsing values from the string type172

Propagating changes through conversions173

Binding complex data types

Using lists of data174

Using data maps177

Mapping structs to a data binding179

Storing data using the Preferences API

Get and set values180

Supported types181

Fallback values181

Removing old data182

Binding to preferences183

Implementing a water consumption tracker

Constructing the user interface184

Binding data to the UI187

Storing with preferences189

Summary

Chapter 7: Building Custom Widgets and Themes

Technical requirements

Extending existing widgets

Overriding widget functions197

Adding new behavior199

Creating a component from scratch

Implementing the theme interface206

Providing customizations to the standard theme208

Implementing a chat app user interface

Creating a message widget210

Summary

Section 3: Packaging and Distribution

Chapter 8: Project Structure and Best Practices

Technical requirements

Organizing your project

Starting simple224

Adding new types225

Splitting code into packages225

Test driving your development

Designed to be tested229

Testing our GUI logic230

Verifying that the output is being rendered232

Continuous integration for GUIs 234

Managing platform-specific code

Summary

Chapter 9: Bundling Resources and Preparing for Release

Technical requirements

Bundling assets

Including multiple assets239

Automating bundle commands240

Checking for UI hints

Choosing metadata, icons, and app IDs

Application icons244

Describing your app 245

Application identifier (appID)245

Packaging applications (desktop and mobile)

Packaging for your current computer247

Packaging for a mobile device248

Installing your application

Installing on your current computer249

Installing on a mobile device249

Cross-compiling with ease

Using installed toolchains250

Using the fyne-cross tool253

Summary

Chapter 10: Distribution – App Stores and Beyond

Technical requirements

Building your application for release

Running the release command258

Sharing your app on the web261

Distributing apps to desktop app stores

Mac App Store263

Microsoft Store265

Linux and BSD distributions266

Uploading apps to Google Play and the iOS App Store

iOS App Store267

Google Play Store268

Summary

Appendix A: Developer Tool Installation

Installing on Apple macOS

Installing on Microsoft Windows

Appendix B: Installing Mobile Build Tools

Preparing for Android

Preparing for iOS and iPadOS

Appendix C: Cross-Compiling

Manually installing compilers

Cross compiling for macOS280

Cross compiling for Windows281

Cross compiling for Linux282

Using fyne-cross

Installing fyne-cross284

Using fyne-cross284

Why subscribe?

Other Books You May Enjoy

Section 1: Why Fyne? The Reason for Being and a Vision of the Future

Since their invention nearly 50 years ago, graphical user interfaces (GUIs) have been the standard way to interact with a software product. In this time they have evolved, and traditional graphical applications are being challenged by the ubiquity of web-based software and new interaction methods for smartphones and handheld computers. Despite these new trends, there are still many reasons why building a native graphical application could be the right strategy for your product—especially if it could be deployed to all the platforms available.

In this section, we will see how GUIs and the graphical toolkits used to program them have evolved. We will explore the pros and cons of the technologies over the years and how some can be used for cross-platform development. We will learn about the Fyne project, its background and vision, and how it aims to be an ideal solution to the evolving needs of GUI development.

This section will cover the following topics:

Chapter 1, A Brief History of GUI Toolkits and Cross-Platform DevelopmentChapter 2, The Future According to Fyne

We start with a short review of the history of desktop computers and traditional GUIs.

Chapter 1: A Brief History of GUI Toolkits and Cross-Platform Development

This book is aimed at exploring how to easily build robust and beautiful graphical applications that will work well across all operating systems and devices. Before we start looking at the details of how this is accomplished, it is important to consider the history of these devices and the landscape of graphical toolkits throughout the last 50 years. We start with a reminder of where GUI-based applications started and how far they have come.

In this chapter, you will be reintroduced to the Graphical User Interface (GUI), along with learning about toolkits that support app development and how they offer different approaches to cross-platform development. We will explore the benefits of coding a native GUI for responsive user experience and platform integration. Upon completion of this chapter, you should be familiar with the origins and challenges of graphical toolkits and the different approaches that have been taken during this journey.

In this chapter, we'll cover the following topics to provide a short history of GUI toolkits and cross-platform development:

Where GUI toolkits came fromHow they have adapted (or stayed the same) over timeHistorical approaches to cross-platform development

Understanding the history of the graphical user interface

In 1973, the Palo Alto Research Center (Xerox PARC) completed the Alto computer, the first commercial example of a graphical desktop computer. In most contemporary histories, this was the first example of what we understand as the GUI. While the screen orientation and lack of colors make it a little peculiar to the modern eye, it's clearly recognizable and includes many key components as well as a mouse and keyboard for interaction. While it took another 7 years to become generally available to the public in 1981 as the Xerox Star, it was clear that this was a dramatic step forward:

Figure 1.1 – Dynabook environment desktop (1976; Smalltalk-76 running on Alto). Copyright SUMIM.ST, licensed CC BY-SA 4.0

This development was a huge leap forward for the usability of computers. Up to this time, all interaction was through text-mode computer screens and keyboard or other text input devices. The graphical interface is much easier to learn for a novice looking to get started, and allows the quicker discovery of advanced features. While the command-line interface remains popular with programmers and other pro users, the GUI is the largest contributing factor to the rise of the desktop computer.

Popularity of the desktop computer

The introduction of a user-friendly graphical environment brought about a significant growth in the use of desktop computers. Around the time of the Alto computer, there were an estimated 48,000 desktop computers around the world. By 2001, this number had increased dramatically to over 125,000,000 personal computers shipped (https://en.wikipedia.org/wiki/History_of_personal_computers#Market_size). In 2002, the industry celebrated a billion computers shipped (http://news.bbc.co.uk/1/hi/sci/tech/2077986.stm), though numbers have declined more recently (see the Smartphones and mobile apps section later in this chapter) and fewer than 300 million were reported shipped in 2018 (https://venturebeat.com/2019/01/10/gartner-and-idc-hp-and-lenovo-shipped-the-most-pcs-in-2018-but-total-numbers-fell/).

As these devices reached the hands of consumers, and hardware became more capable, we started to see a focus on creating attractive user interfaces as well as a trend to establish or match fashion trends. The following are some important versions of Microsoft's Windows operating system:

The copyright for all screenshots belongs to Microsoft. Each image used with permission

As you can see in the previous screenshots, each major revision of the desktop environment brought new styles for the buttons, fonts, and other user interface elements. This is all controlled by the toolkit and represents an evolution in usability and style choices that we'll explore later in this chapter.

Whilst Microsoft were progressing with their GUIs, there were also many competitors, some of which may appear familiar and others with their own distinct styles; for example, the following popular systems:

Desktop screenshots from various operating systems 1985-2015. Each image has been used with the required permission under fair use policies

As you can see from the preceding desktop screenshots for various operating systems from 1985 to 2015, there have been dramatic shifts in the look and feel, whilst maintaining a certain familiarity. These desktop systems are all designed for running multiple application windows typically centered around document editing, file management, and utility apps. Additional software, such as games, photo management, and music players, appeared over the years, but the most ubiquitous, the web browser, was not commonplace until the late 1990s. The addition of internet access started a shift to a new era of computing.

Moving to the web

With the increasing availability of reliable internet connections, we started to see an increase in the amount of information being accessed from servers on the World Wide Web (WWW). Providing a good user web browser experience became of paramount importance and the fierce competition saw operating system manufacturers up against independent software developers (search browser wars in your favorite search engine to know more).

The WWW was first proposed by Sir Tim Berners Lee in 1981 and development began within the CERN (https://home.cern) project (codenamed ENQUIRE). The early web was made available to the public in 1993. As a distributed system that anyone is able to add to, innovation in design was even more rapid than in the desktop operating systems we saw earlier. Trends in design and usability quickly caught up with, overtook, and started to lead traditional software development:

Trends in website design (via Web Design Museum); copyrights belong to their respective owners

The web started as a project for providing access to data, born out of a frustration of how difficult it could be to access information on a different computer. What started as simple information retrieval quickly became a polished presentation of more complex information, and then began to become a place to submit or manipulate information as well.

A simple data access platform quickly grew into much more and before long, this emerged as a full application platform. In fact, due to the standards-based approach (overseen by the World Wide Web Consortium (W3C)), this was one of the first truly cross-platform development opportunities. A web-based application would be developed and made available to all computers in one go—a big advancement over previous attempts to develop for multiple platforms.

An additional benefit of delivering applications through a web-based solution was that you could support multiple types of application accessing the underlying data or functionality. A web-based API (Application Programming Interface) that had historically powered the user-visible website could be used by other devices as well. This design allowed traditional software to access the same data as the web-based delivery systems and contributed to the development of common-place architectures that support a multitude of different types of software – including the more recent mobile-based applications.

Smartphones and mobile apps

In 2007, Apple's Steve Jobs introduced the iPhone, a fresh new design for the concept of mobile computing. Although portable smartphone devices existed for many years before this event, the introduction of a slick new user interface, touchscreen input, and large screen for displaying video and web content had a significant impact on the market. Competitors (existing and newly created) were now racing to create the best user experience that could fit in the consumers' pockets. Although early devices touted that you could browse any website with ease, developers quickly adapted the content to be better presented on these smaller screens—often focusing on information that mattered on the move.

To satisfy the user demand for a more sophisticated and faster experience on these more limited (by hardware or internet connectivity) devices, the concept of a mobile app was born. These small pieces of software were designed specifically for a certain type of mobile phone (Android, iPhone, and others) and were made available by the platform's store or marketplace. Such software had large benefits over the web-based solutions that came earlier as they could be installed on the device, so they ran faster and were developed specifically for the given hardware, creating a better user experience and allowing access to the more advanced capabilities of each device (such as location detection, thumbprint sensors, and Bluetooth).

These native apps provided the ultimate user experience. The applications could be very fast (as they were installed on the device), adapt to the user (through access to local settings and data), and also interact with the operating system features (such as calendars, voice controls, and cutting-edge hardware sensors), all of which are not really possible when delivered through a web app. However, they came with a disadvantage for developers—not only did each platform look different, meaning that designs may need to be adapted, but they were also distributed separately and typically required different programming languages to develop. Now instead of reaching the whole world with a single application, a software company would need at least three different apps to reach their customers through their favorite devices:

iPhone and Android devices showing their similarities and differences

We will come back to the challenges of developing for multiple different hardware platforms later, but first, we will explore the graphical toolkits that underpinned the various technologies we have seen in this section.

Exploring the evolution of GUI toolkits

GUIs must be programmed like any other computer program, and just like libraries are created to provide standard components, a GUI toolkit exists to support building the graphical elements of an application. Many toolkits exist for different reasons—Wikipedia maintains a list of nearly 50 different projects, and growing, at https://en.wikipedia.org/wiki/List_of_widget_toolkits and https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries. To make sense of the huge number of options, we split them into categories, looking first at those built for specific operating systems.

Platform-specific toolkits

Each graphical operating system or desktop environment has a distinct look and programming style, therefore a graphical toolkit was traditionally created for each platform. Windows had the WinAPI (as well as WinForms and foundation classes), Atari was programmed using GEM, and BeOS used the Be API. Applications developed for Apple products have used various toolkits, but since macOS X it's called Cocoa (with desktops using AppKit and mobile devices using UIKit). Android devices are programmed with their own toolkit and other mobile platforms have explored other options.

The Unix and Linux operating systems have a more complicated story. Although the Motif toolkit was one of the first, the fact that its design offers multiple choices has meant there is no one true look or library. In the 1980s, before Motif was created, there was the OpenLook project that aimed to provide a standard interface look and feel for Unix systems. Although there were many different designs and toolkits to choose from, the main contributors to Unix decided that unification would help it compete with Windows and other desktop platforms. And so, in 1993, they chose Motif for future development.

One of the common features of desktop environment design is that it is frequently updated, as you could see in the screenshots of Microsoft Windows earlier in this chapter. Whether due to changes in fashion or advances in usability, these changes are expected and the Motif system did not adapt to them, and so new projects were created as alternatives. Later in the 90s, the GTK+ and Qt projects were started and provided a more modern, polished-looking user interface. Also, the Java platform launched with AWT (Abstract Widget Toolkit) in 1995, all of which were not platform-specific, opening a new world of cross-platform GUI libraries.

Cross-platform toolkits

The toolkits mentioned in the earlier subsection were all developed for a specific platform. They evolved along with the operating system design and are often developed using the manufacturer's preferred programming language. These challenges make it difficult (if not impossible) to create a single app that will work on all platforms. For that reason, the move to create a cross-platform toolkit requires taking a different approach and so developers started to design a library that could be written independently of platform specifics in a language that could be compiled for any of the operating systems it supports.

When GTK+ and Qt were created in the mid-1990s, they chose C and C++ (an object-based language derived from C), respectively. Both languages had wide adoption across most operating systems and were in use with some other toolkits already, keeping the barrier of learning low. The Java approach, however, was broader—to create a whole new language that would work across all of these platforms and deliver a graphical toolkit built on top.

Operating system and computer manufacturers have market power to sway technologies, and as new languages became available, they are able to force developers in the same new directions (such as Apple moving to Swift, Microsoft to C#, and Google moving their apps to Dart). However, the large open source communities built around cross-platform technologies are generally loyal to the language it is built with and so don't typically embrace such large changes. Therefore, these projects can be left behind in some senses and can encourage developers to look in new directions, such as web technologies.

Hybrid apps

As discussed earlier in the chapter, the WWW offered an attractive platform for delivering applications to users on multiple operating systems as well as providing a way to build apps once and run them on any computer. A web browser offers a highly customizable canvas so that, using Cascading Style Sheets (CSS), any HyperText Markup Language (HTML)-based application can be made to look like any design. This benefit brought a lot of popularity to web application development and even influenced some native toolkits to expand their theme capabilities to mimic this.

Websites, as described earlier in this chapter, were designed for information transfer—initially for read-only, and later for sending and editing data too. To get from this to a fully interactive application requires additional programming capabilities, and for this JavaScript is used. In the years since its creation, JavaScript has grown in popularity and complexity—there are now multiple package managers to handle the thousands of available packages that can be used in any JavaScript-powered app. Of these libraries, many are graphical toolkits for handling application interaction and layout, much like a traditional GUI toolkit. Of these, the most popular are currently React, Vue.js, and JQuery, though that list changes regularly.

When developing such JS based web-apps, the focus is on the user interface entirely (the frontend), whereas a full application may contain business logic and algorithms that may be part of the server infrastructure (the backend) of a web application. Historically, these separate parts of a complex application are created using different programming languages. This makes sense as there are different requirements for each area of a large infrastructure. However, for smaller applications, or to reduce technical complexity, it can be useful to use the same language for all parts—and so Node.js was created to support the JavaScript-based backend elements of an application as well.

Despite the benefits of distributing over the web, many companies still want to provide a traditional application that is downloaded and installed (the reasons are explored in the next section). To balance the speed of development and other benefits of web applications with the standard application package that developers are familiar with, a new breed of applications was created, nicknamed hybrid apps. These new apps are loaded in a standard container that loads the custom web application in a regular window like any other application on the system. Electron, Ionic, and React Native are all projects working in this space, offering a web-based app framework with varying levels of access to the system they are running on.

Alongside the evolution of graphical toolkits for cross-platform development, we cannot ignore the ubiquity of the web browser. Although it has the benefit of being present on most modern computers, it may not be the right solution for building your product – let's take a look at how these approaches differ.

Comparing native graphical apps to web UIs

Despite the benefits that web-based applications can deliver, every technology choice means making a trade-off in some area, so let's look at a few of the common issues that might influence your decision of whether to build a native app or web-based hybrid.

Development speed versus delivery

One of the main reasons to pick a web technology to build your application is the speed of development. The very nature of developing in this way means that you can live-preview your work in a web browser. The availability of browser-based editors also means that a design team can tweak the user interface without much code experience. Large portions of your web app could also be used in your hybrid application (or the other way round) to provide a high level of reuse and minimal additional work to support desktop and mobile delivery.

The trade-off regarding speed is found at runtime—as the applications require a web view to run the code, there is an impact on how fast the application can be loaded and executed. Each time a hybrid app is loaded, it creates a small version of a web browser inside the window, loading the code like a web page and starting the execution of the bundled JavaScript. To most users, this may not be so slow as to be frustrating, but when compared to natively-compiled applications, there can be a noticeable difference. Depending on the framework chosen, it is also common for this model to require a lot of memory—indeed, Electron has a reputation for requiring a lot of RAM, with the simplest application using nearly 70 MB just to show 'Hello World'.

The actual speed of execution may also be noticeably slower for applications built on web technologies. Due to the layers of abstraction, a web-based app will typically take more time and CPU cycles to perform the same operations than a compiled native application (though technologies such as WebGL and WASM (short for Web Assembly) are attempting to improve this). Therefore, if your application is likely to be CPU-intensive, or have lots of animated graphics, you may wish to benchmark different approaches to determine which platforms are capable of meeting your requirements for app responsiveness.

Another consideration may be automatic updates—would you like your apps to always be running the latest version? Some web-based toolkits offer the functionality to download application updates and dynamically load the new version without the user having to worry. This can be a large benefit, but could also be frustrating if your customers expect the software to work exactly the same every day until they opt to update it. Some people are also concerned about how applications of this nature may appear to phone home—that is, reporting back to a central server about how the apps are being used, and where, as part of the update process.

Visual style

Another main decision point for choosing web technology-based app development may be the power of the presentation layer (CSS). It is possible, using a combination of image assets and style-sheet code, to create almost any visual style desired. For developers (or indeed, the designers on their team) that desire a completely bespoke look to their application, this could be a great fit. It is worth considering how your users will use the application, however, and whether a completely custom look will inhibit the usability in any way.

This benefit of complete customization can become challenging if the application is intended to match the user interface style of the current system. As the rendering is infinitely flexible, developers can of course add tweaks to a style that make it look subtly (or substantially) different when running on certain systems. This type of adjustment can end up taking a surprising amount of additional effort—as each platform can have a different style over time. A GUI that attempts to match the system style but does not quite manage this is far more off-putting than the one that is clearly following its own style guide.

Therefore, it is probably best to avoid hybrid apps if you desire to blend in with the other apps on a system. Web technologies do offer a fast-to-develop, adaptable platform for cross-platform applications, but there are constraints to this approach that should be considered as well.

Technical constraints

Applications built with web technologies, even those built to look like system apps with hybrid frameworks, run in a sandbox. This means that they are limited in certain ways regarding access to devices and system features. The JavaScript APIs that grant access to underlying functionalities are constantly expanding to work around these constraints, but if your application would benefit from non-standard peripherals or integration into specific operating system features, then a web UI may not be the right choice for you.

Access to communications ports, peripheral devices not included in typical web APIs, and process management are some low-level elements of an application that would not be supported by default. Additionally, interacting with a desktop environment's system tray, search features, and some advanced file management may be difficult to access from within the JavaScript code. To attempt to bridge this gap, some hybrid toolkits allow native code to be written and loaded as libraries to access this functionality. Such extensions, however, would need to be written in the platform's own language (usually C or C++) and then compiled for each supported platform. Not only does this increase the complexity of application distribution; it can also detract from the single-codebase app design technique that using web tools offers.

In comparison to this, other approaches to cross-platform development typically provide an abstraction over all supported operating systems so that an app can be built just once, but where support is missing, they provide a way to get direct access to the underlying features. This is often in the form of a language bridge or a way to load system libraries from the higher-level language. This can involve needing to build with different programming languages, as discussed earlier, but with cross-platform technologies outside of the web sandbox, it does not normally increase the distribution complexity as much. Additionally, it is far rarer to find devices not supported by a native cross-platform toolkit in comparison to one that is based in an embedded web browser.

If some of the constraints of web technology cross-platform development mentioned in this section might impact your app, or if you would prefer not to be coding with HTML and JavaScript, then native toolkits are probably the right approach, which we will look at next.

Options for cross-platform native toolkits

As indicated earlier in this chapter, the idea of a cross-platform toolkit is not new—in fact, they date back to the mid-1990s, barely 10 years into the history of GUI development. It is important to understand that even among native cross-platform toolkits there are distinct approaches with different benefits and drawbacks.

Visual style

Cross-platform toolkits can be divided into two distinct visual approaches—the desire to match the look and feel of the system at runtime versus the delivery of a distinct look that will be consistent across all the environments. The Qt and GTK+ toolkits began with their own visual style that added the ability to be controlled by visual themes. Over time, they developed operating system-specific themes that allowed them to match the design of other applications on a system. In contrast, the Java AWT library was created as a code-level abstraction, meaning that programs would use operating system widgets to render despite the application being written for no specific platform. Interestingly, in 1998, Sun (the creators of Java) introduced the Swing toolkit, which offered a whole new look and feel that would be consistent across all platforms. This replacement user interface library slowly gained