Embedding Databases

The majority of mobile apps work with data. Building database applications has always been one of the strongest Delphi features. In this chapter, we are going to learn how to build data-driven mobile user interfaces (UIs) in FireMonkey, how to use the FireDAC database access framework, and how to embed databases on mobile devices.

While mobile apps rely on data from the internet, building a fast and responsive app always requires caching some data locally. For this reason, using a database in your mobile app is very important, and this chapter will help you understand how to do it. As an example, we are going to build a simple mobile app for managing a todo list.

This chapter will cover the following points:

• Data-driven apps
• Modeling data
• Choosing a database
• Accessing databases with FireDAC
• Building a data-driven UI
• Using visual live bindings
• Fast UI prototyping

The objective of this chapter is to learn how to build a...

Technical requirements

The source code for the examples covered in this chapter can be found at https://github.com/PacktPublishing/Expert-Delphi_Second-edition.

Data-driven apps

In this chapter, we are going to go through the steps of building a simple mobile app with an embedded database for managing a list of todo items. Before jumping into coding, let’s first look into the overall application architecture. The more complex the system we want to build, the more important it is to properly structure it.

The typical approach is to divide and conquer; break a big problem into smaller problems that are simpler to solve. The most common approach in software development is to break the whole system into clearly separated tiers. In a data-driven app, we should be able to identify at least two logical parts: the UI and data access logic. Clear separation of these two tiers enables a plugin architecture, where the UI can connect to different data access blocks in a standard way and the UI can be replaced without touching the underlying data access layer.

In the context of a Delphi app, we can split our project into three independent...

Modeling data

The uToDoTypes unit is where we can add data types that are shared between the UI and the data access module. To achieve a proper level of separation between the UI and the data access logic, we should define the interface for communication between the two tiers of the application. The data module will implement it and the main form of the application should use this interface as the only way to communicate with the data module. In this way, we have true plugin architecture. The UI can be developed independently, and we can provide different implementations of data access logic without affecting the rest of the application. Our data-driven app could be using different types of embedded databases and different data access frameworks, or maybe later we would want to switch to storing our data in a plain file or cloud storage.

The ToDoList app will be dealing with todo items, so it makes perfect sense to declare in the common types unit a type that will represent a single...

Choosing a database

As mentioned before, the majority of mobile apps work with data. If you are not building a calculator app or an arcade game, the ability to store the data that your app is using can be very valuable. When designing your app, you need to make some architectural choices upfront. Where and how is my data stored? One obvious solution is to store your data in the cloud. This approach is the most common, but what if you do not have network access? You still want to be able to work with your app, and with the latest version of your data. This is the main reason why you also want to store your data locally on the device.

In simple cases, storing data as plain files, text, or binary is sufficient. However, it is also possible, and generally better, to embed a complete database system locally on the device. There are many relational and non-relational embedded databases available. If we think about an arbitrary database as just another mobile framework available from the...

Accessing databases with FireDAC

Now that we have a database, we need a way to access it, reading and writing data via SQL commands. The best way to do it in a Delphi application is to use FireDAC, a very powerful data access library, which has been a part of the product for many years and offers access to a dozen different database engines with native and specific drivers.

To keep the demo app simple, we are going to use SQLite as the database engine and our ToDo List app will have just one database table called ToDos. SQLite has a simple type system and effectively a column can store null, integer, real, text, or blob values.

In our design, we are going to use an integer Id value as the primary key. We will also need the Title and Category text fields. The key FireDAC component that we will need is a FireDAC database connection. There will also be query components connected to the database connection.

Let’s see how we can add a data access layer to our sample app...

Building a data-driven UI

We can now build the GUI of the app, using the services provided by the data access layer we just built.

The data access logic has been implemented and it is available through the IToDoData interface. This should be the only way for the UI logic to access data. That is, we are going to implement the GetToDoData method in the main form’s unit that will return the reference to the data access interface. The following is the code for that:

uses uDMToDo;
function TFormToDo.GetToDoData: IToDoData;
begin
  if DMToDo = nil then
    DMToDo := TDMToDo.Create(Application);
  Result := DMToDo;
end;

In this way, we have achieved true plugin architecture. If we decide to change the underlying database access logic, the database access framework, or the database platform, we only need to make sure that the new class implements the IToDoData interface, which is available to the GUI code through the GetToDoData method...

Using visual live bindings

There are many tools for developers on the market. What makes Delphi one of the most productive development environments is the Rapid Application Development paradigm, where you can use reusable components and very quickly assemble them together to create working applications. In Delphi, there is hardly a prototyping phase of the project. When you are building an app, it very quickly starts to look like the final product. Most applications work with data. The GUIs that we design typically display information coming from a database or a service in the cloud. In Delphi, you can preview the data at design time.

There are two visual frameworks in Delphi for building GUIs. There is the Visual Component Library (VCL), which is arguably the best library for building native applications for Windows. There is also the FireMonkey multi-device library for building cross-platform GUIs for all supported mobile and desktop operating systems. The VCL has a concept of...

Fast UI prototyping

Live bindings are not limited to string properties. You can bind different simple and complex data types. One of the really cool components that you can use to quickly design a data-driven UI is TPrototypeBindSource. This component can emulate a data table and generate test data for display. In this way, we can very quickly prototype GUIs.

Let’s see how we could use live bindings to quickly prototype the UI of our ToDo List app:

1. Reopen the ToDoList project in the IDE, right-click on Project Manager, and select the option to add a new project to the project group.
2. Create a separate folder for the new project and save the main form’s unit as uFormToDoTest, the project as ToDoTest, and the whole project group as ToDoGrp.
3. Change the Name property of the main form of the new project to FormToDoTest. Now, copy the list view control from the FormToDo form onto the FormToDoTest. We have our dynamic list view design in the new test form.

   Let...

Summary

In this chapter, we have learned how to build data-driven apps and embed databases on mobile devices. We have looked at creating the database, building a data mapping layer, and building a GUI associated with it. Database access is a critical feature for most apps given that you cannot always rely on local files in various formats, like we saw in terms of JSON and XML earlier in the book. A database offers better-structured storage, in most cases. Also, a database can be the local cache of a remote database you can access using various techniques for building cloud clients or multi-tier architectures, which are the topics of the following chapters.

In the next chapter, we are going to reuse the visual part of our ToDo List app and use cloud data storage as the underlying implementation of the IToDoData interface.