Chapter 8: Project Structure and Best Practices

The Go language comes with a well-understood set of best practices such as style, documentation, and code structure. Often, when applications start adding graphical user interface (GUI) elements, these best practices can be lost. Testing individual components and keeping a clean separation of types helps us maintain clean code that is easier to maintain over time. These concepts can be followed within GUI code as well, with support from a toolkit such as Fyne.

In this chapter, we'll explore how these concepts apply to graphical application development and how we can learn from them to make our GUIs easier to manage over time. We will cover the following topics:

• Organizing a well-structured project
• Understanding the separation of concerns
• Using test-driven development and writing tests for the whole application GUI
• Managing platform-specific code

Let's get started!

Technical requirements

This chapter has the same requirements as Chapter 3, Windows, Canvas, and Drawing; that is, you must have the Fyne toolkit installed and a Go and C compiler working. For more information, please refer to that chapter.

The full source code for this chapter can be found at https://github.com/PacktPublishing/Building-Cross-Platform-GUI-Applications-with-Fyne/tree/master/Chapter08.

Some parts of this chapter refer to managing platform-specific code, so it may be beneficial if you have two different operating systems available to work with.

Organizing your project

One of the design principles of the Go language is that you can start simple and build more structure into your project as it grows. Following this mantra, you can simply start a GUI project with a single main.go file inside a directory that's been created for the project. This will initially contain your entire application, starting from its main() function.

Starting simple

Once your user interface has grown from the very basics, it is a good idea to split it into a new file, perhaps named ui.go. Splitting the code in this way makes it clearer which code is simply booting an application (the main() function and helpers) compared to what is actually building the user interface.

By this time, you should be thinking about adding unit tests (if you have not already added them!). These tests will live in a file, alongside your code, that ends in _test.go – for example, ui_test.go. It is good practice to test all of your code, and for each new...

Test driving your development

The effort required to automatically test user interfaces or frontend software is often considered too expensive for the value it returns when it comes to avoiding future bugs. However, this is largely rooted in the toolkits being utilized or even the presentation technologies that have been chosen. Without full support for testing in the development tools or graphical APIs, it can be difficult to create simple unit tests without a huge amount of effort being needed.

One of the design principles of the Fyne toolkit is that the application GUI should be as easy to test as the rest of its code. This is partly made possible by the API's design, but this is further reinforced by the test utilities that we can provision. We will explore this later in this section. Using the following approaches, we will learn how a Fyne application can follow test-driven development (TDD), even for the user interface components.

Designed to be tested

The modular...

Managing platform-specific code

Back in Chapter 2, The Future According to Fyne, we saw that the Go compiler has built-in support for the conditional inclusion of source files based on a system of environment variables and build tags. As an application adds more functionality, especially from a platform integration perspective, it is possible that the toolkit will not provide all of the functionality you are looking for. When this happens, the code will need to be updated to handle platform-specific functionality. To do so, we will use a variation of the conditional build – using well-named files instead of build tags. This is easier to read at the project level and should clearly indicate which files will be compiled for which platform.

Let's create a simple example: we want to read text out loud, but our code only has the ability to do so on macOS (Darwin). We will set up a simple say() function that does what we want in the say_darwin.go file:

package main
import...

Summary

In this chapter, we explored some of the tips and techniques for managing a GUI-based application written with Go. By carefully planning the modules of an application and how they interact, we saw that we can make any application easier to test and maintain. Since higher test coverage is a factor when it comes to increasing the quality of software applications, we looked at how we can use these techniques to test our graphical code, which is a notoriously difficult topic. We stepped through an example of writing test code for a simple GUI application that could be run automatically.

When it becomes necessary to adapt to a specific operating system, we need to learn how our code can adapt. With appropriate abstractions or by writing platform-specific code that is switched out by generic fallbacks, we can keep our applications easy to maintain, despite operating system differences.

Throughout this book, we have been running examples from the command line, next to their...