Skip to content

Design Patterns in Xojo: Singleton

One of the best things that Xojo offers to programming newcomers is that they can simply jump-in and start to write code. In a matter of a few hours they’ll have a functional app! Nothing new here. (Or for not-so-newcomers, a fast way of creating a functional prototype from a idea).

CandyMachine.pngBut as these users advance in their Xojo skills, they probably will care about coding better and to embrace the OOP way of doing things. After all, Xojo is a modern programming language with Classes, Inheritance, Interfaces and a bunch of the usual OOP paradigms that have much to offer: reusability, better maintainability and a lot of flexibility.

When we talk about OOP, Design Patterns arise! Design Patterns are like  recipes, well known solutions or best practices, to a series of problems or situations that emerge again and again in our OOP designs.

These Design Patterns are so common that you are probably already using some without knowing it. And if you are curious about what are the most common and the code design problems they solve, then you have to definetly take a look into the BOOK (yes, in uppercase): “Design Patterns: Elements of Reusable Object-Oriented Software

In this post I am going to focus on one of these particular Design Patterns and how to implement it in Xojo: Singleton.

OOP is mainly about the instantiation —or object creation— from a Class definition that acts like a template; so we can have several of these objects around sharing the same behaviour but with a state of their own. Well, the Singleton pattern is the “opposite” thing. The answer to having (generally) just one object around from a particular Class.

Why should we want this? The short answer: to limit the access or “enty point” to a main functionality of your apps, or when the created object has a high cost or high impact in used resources.

Implementing the Singleton Pattern

The key to implement this Design Pattern in your apps is to limit the instantiation of the Class to just one object. So let’s see how can we achieve this using the Xojo language features. These are the ingredients to the recipe!

A Class Constructor whose scope is set to Private. This is the way we will ensure that the Class consumer will not be able to create several instances using the usual syntax:

Dim myInstance as MyClass = new MyClass
Dim myInstance as new Myclass

A Shared Method (also known as Static Method or Class Method in other programming languages). This will be the entry point we will use in order to retrieve the unique instance allowed by the Class.

A Shared Property whose scope is set to Private. This one will be the responsible to hold (point to) the unique instance from… the same Class!

Now that we know what the ingredients are, let’s create our own “Hello Machine” as a Singleton Class. Obviously this is not the most useful class in the world, but maintaining the functionality to a minimum will help to focus on the main point about how to implement this Design Pattern in Xojo.

The “Hello Machine” Singleton

Start the new project creating a new Class using Insert > Class. Then, go to the Inspector panel and name the Class as “HelloMachine”.

With the new Class item selected in the Project Browser panel (the leftmost), add a new property to it using Insert > Property. Name the new property as “Counter”, set the Type as Integer and the “Default Value” to 1. This is the property that will inform us about how many times has been invoked the class.

Add a new method to the HelloMachine Class (Insert > Method). This will be in charge of providing the real functionality to our Singleton class. Use “Greet” for the method name and set the Scope to Public. Now, type the following code for the just created method:

MsgBox "Hello World! Is not funny being the only one instance on Earth?" + endofline + endofline + "You have invoked me " + counter.totext + " times."
counter = counter + 1

Now it is time to create the class members that will make our HelloMachine behave as a Singleton one.

Start adding the Shared Property that will be in charge to hold the unique class instance used by the App. Use Insert > Shared Property for that. Select the just added shared property and using the Inspector panel type “sharedInstance” for the “Name”, and set the type to “HelloMachine”; that is, the same Class type we are just defining (it sounds kind of weird, I know).

Now is time to add our Class Constructor. Remember that this one is the special Method whose code is executed every time we want to create a new instance (object) from a particular class.

Use Insert > Method and type “Constructor” on the “Method Name” field of the associated Inspector panel (or choose “Constructor” from the dropdown menu). Make sure you set the Scope of the Constructor method as Private. This way we will be sure that nobody will be able to directly instantiate new objects from the class.

Finally we will write the method that will act as the entry point to retrieve the unique instance available from the class; that is, the instance shared among the App.

Use Insert > Shared Method and type “getInstance” for the “Method Name” field. Make sure to set the “Return Type” field to “HelloMachine”.

Select the “getInstance” shared method and type the following code on the associated Code Editor:

If sharedInstance is Nil then sharedInstance = new HelloMachine
Return sharedInstance

As you can see, all the “magic” consists to verify if has been created already a HelloMachine instance (holded by the sharedInstance Property), returning it if is the case or instantiating and returning it, if otherwise. Voilá, a Singleton Class!

Singleton At Work

Once we have finished our Singleton class definition, let’s use it in our App. Add the Open event to the default window, for example, and type the following code in the Code Editor:

Dim myHelloMachine as HelloMachine = HelloMachine.getInstance
Dim myOtherHelloMachine as HelloMachine = HelloMachine.getInstance

As you can see, we are not instantiating new objects from the Class, just using the Public method to retrieve the unique instance managed by the own Class.

Just for fun, try to instantiate a new object from the class using the regular syntax (I mean, with “Dim myHellowMachine as new HelloMachine”) and you will get a Compiler error. That is, no way to have several objects around!

Download an example using the Singleton Design Patter from this link.

You can watch the video (in Spanish only) that talks you though this example.

Javier Rodríguez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has used Xojo since 1998. He is in charge of and the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app, among others.

More Posts From Javier:

Methods Overloading: Computed Properties, Setters and Getters

*Read this post in Spanish