Delphi 10.3 Rio FireMonkey apps are cross platform with a single codebase and single UI that target the Android, IOS, Macos, Windows, and Linux platforms (FMXLinux was recently added to Delphi 10.3 Rio Enterprise and Architect). You can also deploy Delphi FireMonkey apps to the web using websockets and HTML5. The method for doing this is basically the FireMonkey app runs on a Windows or Linux server and it’s canvas draws are sent to the web browser via a websocket. Each user connection runs one copy of the app on the server (so one user one app). The server is running the app so it needs enough hardware for however many concurrent apps you want to run.
For FireMonkey Windows apps this can be achieved through Thinfinity VirtualUI. Thinfinity is a commercial product which a cost per concurrent user. The user connects to the Thinfinity server, Thinfinity launches the FireMonkey app, handles the user input, and sends the drawing to the browser client. Thinfinity has been around for quite a few years and I would consider it a pretty mature product. It supports enterprise features like load balancing and ActiveDirectory login. You can also use it with Windows apps written in other languages (like C++ and C#).
For FireMonkey Linux apps this can be achieved through FMXLinux and Gtk Broadwayd. FMXLinux is also a commercial product but has recently been made available to Delphi 10.3 Rio Enterprise and Architect developers for free (just open GetIt and install it). FMXLinux allows FireMonkey apps to run on Linux desktops using the Gtk UI library. Gtk comes with an application called Broadwayd which will stream the Gtk app out to HTML5 via websockets. Broadwayd runs on a single port (8080) per app and you can click compile in Delphi 10.3 Rio and see your FireMonkey app in the browser served up from you Linux machine if you start the broadwayd server prior to deployment. If you want to run a pool of FireMonkey apps on Linux like Thinfinity does on Windows you can set up a Linux bash script to do so.
The purpose of the bash script is to run X number of FireMonkey apps through broadwayd (remember 1 app per port) and then use a load balancer make all of the apps accessible via a single port. In order to do this second part there is a Linux package called balance which can do this for you. One limitation of it is that it will only do 16-32 apps in it’s app pool unless you compile the source yourself. You can install balance with “sudo apt install balance” on Ubuntu or “yum install balance” on CentOS. Broadwayd and balance are open source and free applications but the solution is also not as polished as Thinfinity UI. You could also build something in Delphi using TidMappedPortTCP instead of using balance. For commercial deployments I’d recommend going with Thinfinity though.
Here is the sample bash script I put together which handles hosting multiple apps on a single port for you. Save the script as gtkcloud.sh and “chmod +x gtkcloud.sh”. It takes two parameters. The first parameter is the path to the app you want to run and the second parameter is the port you want to run the load balanced app on.
#!/bin/bash
for i in {1..16}
do
nohup broadwayd :$i &
export GDK_BACKEND=broadway
export BROADWAY_DISPLAY=:$i
$1 &
#echo ""
done
servers=""
for ii in {1..16}
do
let port=8080+$ii
servers="$servers localhost:$port:1 %"
done
echo $servers
balance $2 $servers
Example usage is as follows and would host 16 instances of /root/FireMonkeyPaintDemo on port 81.
./gtkcloud.sh /root/FireMonkeyPaintDemo 81
And that is all there is to it. You can run your Delphi FireMonkey apps on Android, IOS, Macos, Windows, Linux, AND the web using a single codebase and single UI.
If you are new to working with a full featured framework like Firemonkey you may be wondering at the size of the apps that Delphi 10.3 Rio Firemonkey generates. The Firemonkey Framework has hundreds of thousands of lines of code that allows you to jump ahead and start building the app you want to build now instead of the bricks in the road to get there. Hopefully this infographic will provide some insight into what makes up an APK/IPA cross platform application deployed from Delphi 10.3 with the FMX framework. The infographic covers Android, IOS, Windows, and Mac OSX apps/packages/libraries/archives created using the Firemonkey framework. Tools that utilize the Firemonkey framework are Delphi 10.3, C++Builder 10.3, and RAD Studio 10.3. The infographic only covers Release mode (something you could deploy to your customers). I have also included a VCL section in the infographic so that you can compare the Windows only VCL framework to the cross platform FMX framework. Also keep in mind that when you use debug information or are in Debug mode your file could be significantly larger. The sizes of the generated files are included in the green circles. There is the normal compiled size and then there is the compressed or packaged size. APK and IPA files are packaged and compressed. The compressed sizes for Windows and Mac OSX were achieved using the 7Zip format. Here is some information directly from the infographic as well about what units are included in a FMX app on Android (it is slightly different on each platform) and how those units effect the size of the deployable file.
Let’s start off with a Hello World app which is basically a FMX form with a TLabel on the form. This comes out to around ~5.88MB when deployed to Android as an APK. Even though this is a Hello World app there is already much more functionality here than just the ability to print out ‘Hello World’ to the screen. A true ‘Hello World’ would be much smaller because it would lack these Firemonkey framework units. The FMX and RTL units included are:
Next up I’ve listed what I call a Basic App that clocks in at ~6.45MB. A basic app has some more visual controls available to it like a TListView, a TEdit, a TListBox, a TTabControl, a TMemo, and even some access to advertising. Here are the FMX units included (in addition to the units from the Hello World app):
This next tier of app size I’ve termed Services because it is basically some Android JAR files which when fully included bring the app up to around ~6.61MB. These services are basically helper services for Android (some of which are provided by Google) like Google IAP, GCM, and Analytics. You can include and exclude each of these files from your APK separately. Here is a list of the additional files:
android-support-v4.dex.jar, cloud-messaging.dex.jar, fmx.dex.jar, google-analytics-v2.dex.jar, google-play-billing.dex.jar, google-play-licensing.dex.jar, google-play-services-*.dex.jar (there are a number of play services covered by this wildcard)
Next up we have what I have termed the Consumer App style app tier which rings in at around ~9.50MB. Obviously if you add more or differently functionality the size of your app can fluctuate greatly. You could also build games and they might fall in this size range depending on how many external graphics and sound you used. This type of app includes more functionality like the RESTClient, the in app purchases unit, sensors, a grid component, and the camera component. Here are the additional FMX and RTL units included by the IDE when these new components (in addition to all of the above) were added:
Lastly we have the Enterprise and Database App tier which comes in at around ~11.1MB+ but can increase size from here the more you add to your app. This includes FireDAC functionality for accessing an SQLite database, LiveBindings to bind the data to a grid, accessing various path utility functions, and creating ini files for settings storage. At this level you can add tens of thousands of lines of code and lots of forms and the app could still be around this size. The RTL and FMX units included when this functionality was added (in addition to all of the above units) are as follows:
You can also take a deep dive into the Firemonkey Framework itself using the Delphi Unit Dependency Scanner. The unit dependency scanner will show you all of the units that your app uses and all of the units that those units use in a treeview. It will also show line numbers of each unit and a total line number count of your entire project.
The developer team over at KSDev has an add on called FMXLinux available for Delphi 10.2 Tokyo FireMonkey that allows you to compile your cross platform Delphi FireMonkey apps to Linux. Normally you can compile your FireMonkey apps to Windows, OSX, IOS, and Android but FMXLinux brings FireMonkey to the Linux platform. FMXLinux requires the Enterprise Edition of Delphi because it contains the Linux compiler. It is pretty amazing that a third party is able to add an entirely new platform to Delphi as an add on package which speaks to the power of the Object Pascal RTL architecture. FMXLinux allows your FireMonkey apps to run on the desktop in popular Linux distros like Ubuntu. It utilizes Gtk for it’s control framework on Linux. Gtk also has a way to output Gtk apps to HTML5 and display them in the browser using Gtk Broadway. This basically means you can output FMXLinux apps to HTML5 and display them in the browser (which means FMXLinux actually brings you two platforms: Linux and HTML5). In addition to all of that FMXLinux allows you to use FireMonkey’s graphical capabilities on Linux in CGI scripts and KSDev provides an example. FMXLinux is a commercial tool so there is a cost involves to use it.
Auto Tables is an automatic low code REST API generator for RAD Server. The easy to use interface allows for the quick automatic configuration of a REST server and client SDK with dynamic endpoints providing read, write, and delete access to your data. Everything can be generated from your database tables in just a few clicks. Database tables can be made available with enterprise permissions for over 30 different databases including databases such as MySQL, Microsoft SQL Server, and InterBase. Additionally, you can automatically generate endpoints for over 80 more data sources using the Embarcadero Enterprise Connectors. It provides powerful API generation functionality rivaling that of DreamFactory, LoopBack, and Sandman without the complexity.
A graphical Auto Tables for RAD Server Endpoint Editor is provided to help you set up, create, and edit your Auto Tables for RAD Server endpoints. Once you configure your endpoints you can either generate a new RAD Server project or you can save them out for loading into an existing Auto Tables for RAD Server ResourceModule. The configuration format is the standard FireDAC JSON.
Full source code for the Auto Tables RAD Server ResourceModule is provided so you control your REST API server. This gives you the freedom to enhance and modify the source code as needed for your own solutions. AutoTables for RAD Server outputs a Delphi RAD Server project, a Delphi REST client project suitable for LiveBindings, a Delphi REST SDK, an OpenAPI 2.0 api spec file, and a Swagger UI documentation interface. The OpenAPI 2.0 api spec file allows you to generate clients for your REST API in the following languages: ActionScript, Ada, Apex, Bash, C#, C++, Clojure, Dart, Elixir, Elm, Eiffel, Erlang, Go, Groovy, Haskell, Java, Kotlin, Lua, Node.js, Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Swift, Typescript
Auto Tables endpoints utilize a ResourceName for the root segment and then a single dynamic segment for the specific endpoint. The default ResourceName is v1. Parameters are passed in via the query string. An example endpoint would be:
/v1/myendpoint/?PageId=1
API Versioning
You can utilize the ResourceName segment to create different versions of your API. The default name is v1 for version 1 but you can change it to v2, v3, v4 etc. when you release different versions of the same API. By utilizing version numbers you can run different versions side by side and eventually depreciate older versions.
Request Types
Auto Tables makes the GET, POST, and DELETE HTTP/S request types available as endpoints in RAD Server.
GET
If RequestType is set to GET then a standard HTTP/HTTPS request with a query string coming in will trigger that request. GET Actions include Table, SQL, AggregateSQL, and Method.
Table – TableName field will be used to return the full database table
SQL – SQL field will be used to execute the SQL query and return the result
AggregateSQL – SQL field will be used to execute the SQL query list and return the results
Method – Method field will be used to execute the custom Method
POST
If you set Request Type to POST the defined endpoint will expect a FireDAC JSON format to be submitted in the body of the request. POST Actions include Table, SQL, AggregateSQL, and Method. The FireDAC JSON will be loaded into an TFDMemTable. If the auto increment field (ID) is zero Auto Tables will create new records with the submitted rows. If the auto increment field (ID) is greater than zero Auto Tables will edit and replace the existing record with that auto increment id using the data from the submitted row.
Table – TableName field will be used to append or edit submitted records
SQL – SQL field will be used to execute a SQL query and return the result
AggregateSQL – SQL field will be used to execute a SQL query list and return the results
Method – Method field will be used to execute the custom Method
DELETE
If you set Request Type to DELETE the defined endpoint will require an auto increment field (ID) parameter to be passed to it. A DELETE SQL statement will be executed to delete the auto increment id that was passed to the endpoint. DELETE Actions include Table, SQL, AggregateSQL, and Method.
Actions
There are a number of actions that can be taken when an Auto Tables endpoint is requested. These Actions include Table, SQL, AggregateSQL, and Method.
Table
Table will automatically return a database table from an endpoint via TFDTable as FireDAC JSON.
SQL
SQL will automatically execute the set SQL statement via TFDQuery and return FireDAC JSON when the endpoint is requested. The Params field can be used to define parameters such as PageId and Limit.
AggregateSQL
Aggregate SQL is a collection of SQL statements which are all executed and returned in a single response. Each SQL statement is executed separately and its result is added to an TFDMemTable. Once all of the SQL statements have been executed the TFDMemTable is returned from the endpoint as FireDAC JSON.
Method
Method actions allows you to define a custom method for each endpoint which will be requested. The custom methods must be defined in the Auto Tables for RAD Server ResourceModule code and have direct access to AContext, ARequest, and AResponse in RAD Server.
TableName
The TableName field is used by the GET, POST, and DELETE RequestTypes. When the RequestType is GET the TableName field is used to define the name of the table that will be returned via the endpoint when the Action is set to Table. When the RequestType is POST the TableName field is used to determine on which database table to append or edit records. When the RequestType is DELETE the TableName field will be used as the database table on which the DELETE SQL statement will be executed against.
SQL
The SQL field is used to hold the SQL the SQL Action and the SQL list for the AggregateSQL Action. The SQL list for the AggregateSQL Action consists of name=value pairs where name is the name of the field that will be returned in the FireDAC JSON from the endpoint and value is the SQL statement used to fill the name field with a result. Any number of name=value pairs may be used in the AggregateSQL field limited only by the capacity of your database to execute all of the queries and the length of the SQL field itself. The SQL field accepts FireDAC style parameters in the format of :PageId which get resolved to the parameters listed in the Params field.
SQL Field Example For SQL Action
SELECT * FROM Log LIMIT :PageId,25
SQL Field Example For AggregateSQL Action
log_count=SELECT COUNT(*) FROM Log; most_recent=SELECT last_modified as most_recent FROM Log LIMIT 0,1; most_recent_error=SELECT message as most_recent_error FROM Log LIMIT 0,1;
Built In Default Params
There are a number of built in parameters you can use in your SQL statements. These include :UserId, :Username, :TenantId, and :Body. UserId returns the RAD Server UserId. Username returns the RAD Server Username. TenantId returns the current TenantId that is being passed in to RAD Server. And Body returns the contents of the POST body.
Method
The Method field is used to define the name of the custom method in the Auto Tables ResourceModule for RAD Server that will be executed via the endpoint when the Action is set to Method. You can create your own methods using the sample code below. Simply rename the customMethod() function as needed and utilize that name “customMethod” in the Method field.
function TAutoTablesResource.customMethod(AContext: TEndpointContext; ARequest: TEndpointRequest; AResponse: TEndpointResponse): TMemoryStream;
end;
Params
The Params field contains a comma delimited list of parameters that can be passed in to the query string on an endpoint. The parameters are made available or utilized by the various actions.
Reserved Params
The format parameter is reserved for Auto Tables to allow you to return one of 4 formats. You can pass ?format=CSV to return the data as a CSV file. You can pass ?format=XML to return the FireDAC results as XML. You can pass ?format=BINARY to return the FireDAC results as binary. And finally the default format is FireDAC JSON so any other value or an omitted format parameter will return FireDAC JSON.
Params for the SQL and AggregateSQL Actions
For the SQL and AggregateSQL action the parameters are available as parameters in the SQL query. The parameters are automatically inserted as properties and are quoted properly to handle escape characters. For example if a PageId parameter is defined in the Params field the :PageId variable would be available for use in the SQL field such as “SELECT * FROM Log LIMIT :PageId,25”.
Params for Method Actions
The parameters defined in the Params field are directly available to you via the ARequest object in the custom methods.
Macros
The Macros field contains a comma delimited list of macros that can be passed in to the query string on an endpoint. The macros can be used in the SQL field and provide access to the FireDAC Macros functionality. Macros can contain SQL database fields and are directly substituted in the SQL string.
Macros for the SQL and AggregateSQL Actions
For the SQL and AggregateSQL action the macros are available as direct string replacement macros in the SQL query. It utilizes the !macro syntax provided in FireDAC. However, the macro strings are sanitized against the list of fields in the table.
Groups
Users and Groups are already built into RAD Server. You can have users in multiple different groups. The Groups field in Auto Tables for RAD Server should contain a comma delimited list of RAD Server Groups that should have access to this endpoint. A blank Groups field would allow users who are not logged into RAD Server to access the endpoint. Utilizing this feature you can create a wide variety of permissions for access to the endpoints.
UniqueID
The UniqueID field is used to hold the UniqueID field name for the POST and DELETE RequestTypes. Both RequestTypes utilize a primary key type field to know which field in the table to use for adding, editing, and deleting records. The UniqueID field allows you to customize the name of that unique id field. By default the field name is ID.
Auto Tables for RAD Server Endpoint Editor
The Endpoint Editor allows you to automatically create, quickly customize, and easily edit all of your RAD Server endpoints. It is built in a wizard type interface with multiple easy to use steps. Everything you need to get your REST API server up and running fast is auto generated for you.
It will automatically generate a Delphi RAD Server project, a Delphi REST Client project to connect to RAD Server, and an OpenAPI (Swagger) specification file for your REST API. Additionally, you can copy the dataset component for the server endpoints to the clipboard or you can copy the REST endpoint connection components for the client to the clipboard.
Copy DataSet Component
You can copy the TFDMemTable with all of the endpoint configuration in it to the clipboard. It can then be easily pasted into an existing project.
Generated RAD Server Project
The automatically generated Auto Tables for RAD Server project has all the code already in it for handling the endpoints you have configured in the editor. The project is created from a template in the templates subdirectory. You can edit the template prior to generating your Auto Tables for RAD Server project and customize it as needed.
Copy REST Components
You can copy all of the REST components that needed to connect to the Auto Tables for RAD Server into the clipboard. They can then be easily pasted into an existing project.
Generated REST Client Project
The automatically generated Auto Tables for RAD Server REST Client project has all the code already in it for connecting to your Auto Tables for RAD Server endpoints that you have configured in the editor. The project is created from a template in the templates subdirectory. You can edit the template prior to generating your Auto Tables for RAD Server REST Client project and customize it as needed. Additionally, a Delphi SDK is also generated for the Auto Tables for RAD Server. Generation of SDKs for other languages can easily be added to the modular SDK generator.
Generated OpenAPI
In addition to the server project and client project that can be generated by editor it will also generate an OpenAPI specification document in JSON format. The OpenAPI file can be used to automatically generate SDKs or client projects using tools like OpenAPI-CodeGen or SwaggerHub to automatically create clients in a variety of languages like ActionScript, Ada, Apex, Bash, C#, C++, Clojure, Dart, Elixir, Elm, Eiffel, Erlang, Go, Groovy, Haskell, Java, Kotlin, Lua, Node.js, Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Swift, and Typescript.
The OpenAPI spec generator has a number of different fields it needs filled out to generate a propert OpenAPI spec. These fields include Title, Version, Description, Terms of Service, Contact Name, Contact Email, Contact URL, License Name, and License URL.
The RAD Server Field Service Template provides an end to end field service application template for routing appointments, managing parts, and user administration. It is made up of a REST server module, a desktop client, and a cross platform mobile client. The template can give you a head start in building your own field service solutions. You can download the Field Service Template for free through Embarcadero GetIt.
Note: This post is an excerpt from the Field Service Template app documentation.
Introduction
The RAD Server Field Service Template utilizes a RAD Server based REST server module for the server side. On the admin side there is a FireMonkey based desktop client for adding, viewing, and managing appointments. Additionally, the admin client allows you to manage parts inventory and do user administration. The offline capable cross platform client app is built in FireMonkey and it can be deployed to Android, iOS, macOS, and Windows. There is a single codebase and single UI. It allows you to view pending and completed appointments, map their locations, and mark them as completed. You can also view parts inventory and receive local notifications when new appointments are synced from the server. Both LiveBindings and FireDAC are used extensively through the Field Service Template to provide a low code solution.
LiveBindings
LiveBindings is the low code technology built into Embarcadero RAD Studio which allows you to rapidly build and deploy database applications by connecting fields and controls together in the IDE. LiveBindings is used extensively in the Field Service Template to reduce the amount of CRUD code. InterBase tables and TFDMemTables are LiveBinded to various controls to allow editing fields with little or no code.
FireDAC is a Universal Data Access library for developing applications for multiple devices, connected to enterprise databases. With its powerful universal architecture, FireDAC enables native high-speed direct access from Delphi and C++Builder to InterBase, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, DB2, SQL Anywhere, Advantage DB, Firebird, Access, Informix, DataSnap and more, including the NoSQL Database MongoDB. Within the Field Service Template FireDAC is used extensively with LiveBindings to connect to the InterBase and IBLite databases. FireDAC also features a local SQL functionality which allows executing SQL queries against the in memory tables.
RAD Server (EMS) is a turn-key application foundation for rapidly building and deploying services based applications. RAD Server enables developers to quickly build new application back-ends or migrate existing Delphi or C++ client/server business logic to a modern services based architecture that is open, stateless, secure and scalable.
InterBase is a full-featured, high performance, zero administration, lightweight, embeddable relational database for software developers. RAD Server uses InterBase for storing it’s users and groups. InterBase also provides an IBLite Edition of InterBase which can be deployed with your apps. You can find out more about the different editions here:
The Field Service Template consists of a RAD Server backend connected to an InterBase database. RAD Service provides REST endpoints which both the Field Service Admin and the Field Service App connect to for performing CRUD operations. Additionally, there is a Field Service Setup app which you will run on the same machine as RAD Server to setup the Field Service Template database and sample data.
Field Service Admin
Field Service App
Field Service Server (RAD Server)
Field Service Setup
You should deploy and run the projects in the following order:
RAD Server Dev Server needs to be running for the Field Service Setup app to connect to and create the user accounts.
Field Service Setup app will help you set up your database, the tables and data, and your EMS user accounts.
Field Service Server is a RAD Server side REST resource which both the Admin client and the App client interface with. It should be deployable on Windows and Linux through IIS, Apache, or the stand alone RAD Server (EMS) server.
Field Service App is a RAD Studio FireMonkey based client application for Android, iOS, macOS and Windows. The client application should allow you to select a tenant from your RAD Server and then log in as a user. Once logged in it will download the sample appointment and parts data for your current tenant and allow appointments to be completed. Once an appointment is complete it can be submitted back to the server if there is internet access. If the Field Service App is offline it will save the changed data until it is online again.
Field Service Admin is a RAD Studio FireMonkey based client application designed for desktops on Windows and macOS. The Admin app can be used to create and edit appointments, view completed appointments, create and edit parts, and create and edit users.
Field Service Server
The Field Service Server is the RAD Server module for the Field Service App and the Field Service Admin to interface with.
The end points mainly return the FireDAC JSON format which can be easily loaded in to a RAD Studio client or access via standard JSON in a non-RAD Studio environment. FireDAC JSON can be loaded into various FireDAC components like TFDQuery and TFDMemTable using LoadFromStream and LoadFromFile.
Endpoints:
GET fieldservice/appts/:PageId – Returns FireDAC JSON containing the appointments list. For Managers it is all appointments. For Technicians it is only their current day appointments for their user account.
GET fieldservice/parts/:PageId – Returns FireDAC JSON containing the parts list.
GET fieldservice/technicians/:PageId – Returns FireDAC JSON containing the users list. For Managers it is all users. For Technicians it is only their own account.
POST fieldservice/update/appt – Receives FireDAC JSON containing an appointment ID and NOTES for an existing appointment, stores the data, and sets the appointment to completed.
POST fieldservice/appts/0 – Receives FireDAC JSON for creating or editing appointments. Returns FireDAC JSON with the IDs. Only users in the Managers group can use this endpoint. Passing an ID of 0 will create a new record while using an existing ID will edit the existing record.
POST fieldservice/parts/0 – Receives FireDAC JSON for creating or editing parts. Returns FireDAC JSON with the IDs. Only users in the Managers group can use this endpoint. Passing an ID of 0 will create a new record while using an existing ID will edit the existing record.
POST fieldservice/technicians/0 – Receives FireDAC JSON for creating or editing users. Returns FireDAC JSON with the IDs. Only users in the Managers group can use this endpoint. Passing an ID of 0 will create a new record while using an existing ID will edit the existing record.
DELETE fieldservice/appts/:Id – Takes the Id to be deleted as the last segment parameter in the URL and deletes the appointment record. Returns JSON. Only users in the Managers group can use this endpoint.
DELETE fieldservice/parts/:Id – Takes the Id to be deleted as the last segment parameter in the URL and deletes the appointment record. Returns JSON. Only users in the Managers group can use this endpoint.
DELETE fieldservice/technicians/:Id – Takes the Id to be deleted as the last segment parameter in the URL and deletes the appointment record. Returns JSON. Only users in the Managers group can use this endpoint.
User Permissions:
User permissions are governed by the {$DEFINE GROUPPERMISSIONS}. You can comment or uncomment this line for dev and live deployments. User permissions are ignored when {$DEFINE GROUPPERMISSIONS} is commented out.
By default there are two Groups setup which are Managers and Technicians.
Different data is returned depending on if the user is in the Managers or Technicians group. Some operations are only allowed by users in the Managers group.
Database Schema:
The FireDAC JSON format is used to pass data back and forth between the server, the Admin client, and the App client. The database schema for the Appointments, the Parts, and the Technicians tables are the same across all four applications. You can save the data from each of the application’s TFDMemTables out to file and load it into each of the other applications.
Field Service Admin
The Field Service Admin project is built in RAD Studio Delphi using FireMonkey (FMX). The Admin app connects to RAD Server on the backend via a REST API. You should be able to log into the Admin area by selecting a Branch ID (Tenant ID) plus entering the login and password for a user in the Managers Group. For this template the default user is manager1.
Be sure to configure the EMS_SERVER and EMS_PORT const in uMainForm.pas to point at your development server. The default is localhost 8080.
The Branch ID is stored with each data table so each branch will only see its own set of appointments, parts, and users. Each branch has its own users and groups as well. The Branch system is built on top of the Tenant functionality in RAD Server.
Appointments
Appointments are records that can be created, viewed, and edited in the Admin client. They can also be assigned to a Technician. Appointments can be viewed and completed in the Field Service App. Appointments have various fields like Appointment date and time, customer title, description, address information, phone number, location, photo, status, and notes. The photo field supports PNGs and JPGs. Addresses can be converted to longitude and latitude using the Locate button utilizing the Google Geocoding API.
History
The Service History list is a view into the Appointments and only shows Appointments that have been their status set to Complete. Technicians using the Field Service App submit completed appointments and include notes. The History view utilizes TFDLocalSQL to show only the completed appointments.
Parts
Parts are records that can be created, viewed, and edited in the Admin client. They can also be viewed by Technicians. Parts have various fields like title, description, location, quantity, and photo. The photo field supports PNGs and JPGs.
Users
Users are records that can be be created, viewed, and edited in the Admin client. They also show up as an individual profile to logged in Technicians. When a user is created in the Field Service database it also creates a shadow user in the RAD Server Users API where their username and password are stored. By default users can be in the Managers Group or the Technicians Group. The Group information is also stored in the RAD Server Groups API and the server accesses the RAD Server User and Group data for the permissions.
Data Sync
The Data Sync tab in the Admin client is where JSON data is downloaded from the Field Service Server REST endpoint and loaded up into the various in memory TFDMemTable components. Data for the Appointments, Parts, Users, and Groups is all downloaded on this tab. You can also request to Refresh the data at any time to get new updates from the server. Additionally, there is a background TTimer which will refresh the data from the server automatically on an interval.
Architecture
The architecture of the app is built in a low code rapid application development style using TTabControls for handling pages and individual frames for each page. TActionList is used to consolidate much of the code in the MainForm. There are two TTabControls on the MainForm. The first one contains the Login frame and the second TTabControl. The second TTabControl contains the rest of the frames. Within the ApptsFrame, HistoryFrame, PartsFrame, and TechsFrame there are additional Master/Detail TTabControls.
If you want to make changes to the design time frames be sure to edit the frame itself and not the version of it that is embedded in the MainForm. This will keep your changes consolidated in one place. If your changes don’t update in the MainForm you can delete the Frame from the MainForm and re-add it. Be sure to add it to the correct Tab and set to Align Client after you add the frame.
The frames are built to be as modular as possible with TBindSourceDB components used as endpoints for the LiveBindings. This allows you to easily re-use the frames in your own projects by connecting the TBindSourceDBs to your own datasets.
A TFDLocalSQL component is used to provide SQL access to the various TFDMemTables via TFDQuery components. This allows the App to provide query results for filtering some of the datasets.
Permissions
The Field Server Admin app will make an additional call after it logs in to download the list of Groups that the current user account is in. It will check to see that the user is in the Managers Group. If the user is not in the Managers Group it will log you back out. There are additional permissions in the Field Server Server which govern what data is sent down to which users as well. Only users in the Managers Group will receive the full data and be able to make changes to it.
Customize The UI
You can quickly and easily customize most of the look and feel of the app with three easy changes. In TMainForm there is a BackgroundRect, a BackgroundImageRect, and a EmeraldDarkStyleBook control. You can change the background color of the app by changing the BackgroundRect.Fill.Gradient property. You can change the image that is overlayed over the entire app by changing the BackgroundImageRect.Fill.Bitmap.Bitmap property. The background image works by being above all of the other controls, having a low Opacity, having a HitTest of False and a Locked property of True. Finally, you can change most of the rest of the theme by loading different Premium Styles into the EmeraldDarkStyleBook control.
You can customize the header logo of the Login screen on the LoginFrame. There are a few other places where the custom green color is used on some elements in the TListView controls and some the search icons using a TFillRGBEffect.
You will need to update the BackgroundRect and BackgroundImageRect in the GroupsListForm, the TechsListForm, and the TenantForm as well. There is a BackgroundImage control in the LoginFrame if want to customize the background of the Login page. Remember that you will need to load one style for each of the four deployment platforms. You can access the Premium Styles here:
The Field Service App client project which is built in RAD Studio Delphi using FireMonkey (FMX). The client is targeted for deployment to Android, iOS, macOS, and Windows. The Field Service App client connects to RAD Server on the backend via a REST API. You should be able to log into the App client by selecting a Branch ID (Tenant ID) plus entering the login and password for a user in the Technicians Group. For this template the default users are technician1 and technician2.
Be sure to configure the EMS_SERVER and EMS_PORT const in uMainForm.pas to point at your development server. The default is localhost 8080.
The Branch ID is stored with each data table so each branch will only see its own set of appointments, parts, and users. Each branch has its own users and groups as well. The Branch system is built on top of the Tenant functionality in RAD Server.
Appointments
Appointments are records that can be viewed in the Field Service App client. When you are logged in as a Technician you will only see appointments assigned to you, marked as pending, and with a date of today. Appointments have various fields like Appointment date and time, customer title, description, address information, phone number, location, photo, status, and notes. You can view a static map of the address of the appointment plus you can press a Locate button to bring up an interactive map of the address. You can also click on the phone number on a mobile device and it will launch the call functionality of the device. Technicians can enter notes about an appointment and mark it as complete. The notes and status change are sent to the server.
History
The Service History list is a view into the Appointments and only shows Appointments that have been their status set to Complete for this technician for today. Newly completed records show up in the History tab even if they have not yet been synced with the server yet.
Parts
Parts are records that can be viewed in the Field Service App client. Parts have various fields like title, description, location, quantity, and photo. Parts are not editable in the Field Service App but the data does get updated when synced from the server.
Profile
The profile section shows the current Technician that is logged into the Field Service App and their various information. You can also choose to disable the local notifications here. Profile information also shows up in the TMultiView menu.
Notify
The notify section shows new appointments that have been downloaded from the server that have not yet been viewed by the current technician. Choosing a notification here will take you to the appointment for that notification. Local notifications are also implemented and when new appointments are received local notifications will be sent to the device. The notification functionality is built so that you can implement your own remote notifications using the same system if needed.
Data Sync
The Data Sync tab in the Field Service App client is where JSON data is downloaded from the Field Service Server REST endpoint and loaded up into the local IBLite database. Data for the Appointments, Parts, and Technician is all downloaded on this tab. You can also request to Refresh the data at any time to get new updates from the server. Additionally, there is a background TTimer which will upload and sync the completed data from the Field Service App automatically on an interval. A cloud icon will appear in the upper left of the Field Service App when there is data to be synced in the queue.
Architecture
The architecture of the app is built in a low code rapid application development style using TTabControls for handling pages and individual frames for each page. TActionList is used to consolidate much of the code in the MainForm. There are two TTabControls on the MainForm. The first one contains the Login frame and the second TTabControl. The second TTabControl contains the rest of the frames. Within the ApptsFrame and the HistoryFrame there are additional Master/Detail TTabControls.
If you want to make changes to the design time frames be sure to edit the frame itself and not the version of it that is embedded in the MainForm. This will keep your changes consolidated in one place. If your changes don’t update in the MainForm you can delete the Frame from the MainForm and re-add it. Be sure to add it to the correct Tab and set to Align Client after you add the frame.
The frames are built to be as modular as possible with TBindSourceDB components used as endpoints for the LiveBindings. This allows you to easily re-use the frames in your own projects by connecting the TBindSourceDBs to your own datasets.
Offline Caching
The Field Service App is able to work offline once you have logged into your account at least once. The next time you log into the app it will use your previous RAD Server Session ID for any new connections it tries to make to the server. The data from the server is cached as JSON files and stored in the IBLite database. The Appointments are saved as appts.json, the Parts as parts.json, the Techs as technicians.json, and the Tenants as tenants.json. If no connection to the server is available the data will be loaded from those files instead. Additionally, if there is no internet connection it will save the appointments and notes that you have marked completed in the History table of the IBLite database. When the next time an internet connection is detected it will upload those changes.
The Field Service App has a local History table where is stores the local changed state of the Appointments. Even if you re-sync the data from the server and your changes have not been uploaded yet it will apply your existing local changes to this new data until which time it is able to upload the changes to the server.
If you log out of the existing account the local database is deleted until you log in again. If you log out before uploading your changes then you changes would be lost.
Notifications
The local notification functionality built into the Field Service App relies on the cross platform TNotificationCenter component that is built into RAD Studio. There is a local IBLite Notify table in the Field Server App where it stores the current state of notifications (whether the user has viewed them already and whether they have been sent to the user’s platform).
When a new Appointment is downloaded from the server during a data sync a new record is added to the IBLite Notify table. A notification is sent to the platform through the TNotificationCenter when this happens. The user can view the notification by clicking on the record on the Notify tab. Once a notification is viewed it will no longer be displayed on the Notify tab.
Each platform handles notifications differently. You should be able to hook up remote notifications as well through this existing local notification system.
Customize The UI
You can quickly and easily customize most of the look and feel of the app with three easy changes. In TMainForm there is a BackgroundRect, a BackgroundImageRect, and a EmeraldDarkStyleBook control. You can change the background color of the app by changing the BackgroundRect.Fill.Gradient property. You can change the image that is overlayed over the entire app by changing the BackgroundImageRect.Fill.Bitmap.Bitmap property. The background image works by being above all of the other controls, having a low Opacity, having a HitTest of False and a Locked property of True. Finally, you can change most of the rest of the theme by loading different Premium Styles into the EmeraldDarkStyleBook control.
You can customize the header logo of the Login screen on the LoginFrame. There are a few other places where the custom green color is used on some elements in the TListView controls and some the search icons using a TFillRGBEffect.
The Profile screen for the technician has a background image in the ProfileFrame called HeaderBackgroundRect plus a BackgroundRect control. The Profile is also displayed in the TMultiView control on the MainForm with another control named HeaderBackgroundRect as well. Change the Fill.Bitmap.Bitmap property on both controls.
You will need to update the BackgroundRect and BackgroundImageRect in the WebBrowserForm and the TenantForm as well. Remember that you will need to load one style for each of the four deployment platforms. You can access the Premium Styles here:
There are quite a few Firemonkey component sets available for Delphi Berlin which can get you ahead of the game when developing for Android and IOS. Think of component developers as another part of your team: they do the foundation work for you so you can focus on the actual functionality. Here are thirteen of these component set developers which give you access to everything from FFMPEG video playback to amazing grid capabilities to in app payments to cross platform math libraries to artificial intelligence libraries to scripting components to database access components to native maps to bar code reading and even enhanced camera functionality. Achieving success through third party components is a powerful developer force multiplier.
Alexander Sviridenkov provides the HTML Component Library which contains an HTML Component Library, an HTML Report Library, and an HTML Editor Library. The components are written in Object Pascal and do not use WebView or any other plugins or third party controls. The library contains an HTML parser, an XML parser, a CSS parser, DOM classes with JQuery support, SVG rendering, HTTP/HTTPS clients, and an HTML rendering engine.
Devart provides enterprise grade universal data access component suite called UniDAC. This is an amazing data access component suite which provides direct database access from Android, IOS, Windows, and Mac for a variety of databases. It is possible to connect to Oracle, SQL Server, MySQL, PostgreSQL, and SQLite without using a client library with these components. They also have a SecureBridge offering which provides SSH, SSL, and SFTP components for Firemonkey in Delphi Berlin.
Dew Research provides MtxVec which is an object oriented numerical library for mathematical, signal processing and statistical functionality. On Windows machines it leverages mathematical, signal processing and statistical SSE2, SSE3, SSE4.2 and Intel AVX 1.0 and AVX 2.0 instruction sets. The add ones for MtxVec are DSP Master which is the advanced signal processing package, Stats Master which is the statistical package, and Data Miner which are the artificial intelligence enabling components.
Flash AV Software Corp. provides professional components based on the FFMPEG library and they have a huge number of features. If you are doing video playback professionally on Android and IOS this is the component set to have. They have FFMPEG wrappers for Android, IOS, Windows, and OSX but their components are separated by platform. It features H264 Hardware Decoder playback on some devices devices and support both ARMV7 and ARMV7S CPUs. The formats it supports are all formats supported by FFMPEG and in addition it can play videos from memory stream, HTTP, HTTPS, RTMP, and MMS.
JVESoft provides the JVESoft Components Suite which is a large set of components which are vary useful for any developer releasing professional consumer level apps on Google Play and the Apple App Store. The suite comes with a large number of third party ad component integrations, analytics, in app purchases, push notifications, simplified setting storage and social login components.
Mitov Software provides quite a few components but for Firemonkey in Delphi Berlin they offer IntelligenceLab, AnimationLab, and LogicLab. IntelligenceLab consists of components with everything from classifiers, to converters, to filters, to generators, to timing components, to training components. These components could be used to build OCR applications, computer vision functionality, SPAM filters, AI, speech recognition, and decision making functionality. AnimationLab comes with three different components which are ALTimeline which allows you to manipulate components and their properties based on a timeline, ALMass which allows you to apply mass effects to Firemonkey 3D components, and ALDrag which allows you to apply drag effects. LogicLab allows you to simulate and display logic conditions using tools like logic operators, segment decoders, binary encoding & decoding, ALU & magnitude comparer, and more.
RiversoftAVG provides a number of component sets including SVG Component Library, Charting Component Suite, Genetic Algorithms, Fuzzy Logic, and Inference Engine Component Libraries. The SVG Component Library allows you to Load, Edit and Save SVGs as SVG and Delphi Binary. Vector graphics are drawn at runtime which allows them to appear smooth regardless of the resolution and DPI of the device. The Charting Component Suite has over 19 different chart types which include area, arrow, pie, line shape, bubble, donut, candlestick, and graph to name a few. The Genetic Algorithms set is a powerful genetic algorithms and genetic programming solution. The Fuzzy Logic set has 29 different fuzzy hedges like addition, about, not, very, normalize, and many more. It does fuzzy correlation and inference. Finally, the Inference Engine is a powerful set of components which implement rule based intelligence and fuzzy logic.
Steema provides TeeChart Pro which is a charting component library that offers hundreds of Graph styles in 2D and 3D for data visualization, 56 mathematical, statistical and financial Functions for you to choose from together with an unlimited number of axes and 30 Palette components. Additionally, they have the Steema Business Intelligence component set which is open source and in active development. The SteeBI project is set to provide the an effective way for specialists and analysts to turn data into meaningful visualizations and reports.
TMS Software provides a massive number of Firemonkey interface and data exchange components. They include TMS Charts, TMS Cloud Pack, TMS FNC Chart, TMS FNC UI Pack, TMS Filters, TMS FlexCel, TMS Pack, TMS WebGMaps, TMS WebOSMaps, TMS iCL, and TMS mCL all for Firemonkey. There are all kinds of buttons, HTML components, charts, gauges, web browsers, maps, native controls, Excel components, cloud connections, and much much more. All of the Firemonkey components can be licensed as one giant Firemonkey Component Studio or each set can be licensed separately. Additionally, they provide a set of business components with ORM, scripting, workflow, REST/JSON libs, data replication, and data modeling functionality.
VIRT Laboratory’s paxCompiler provides an amazing set of Object Pascal, Basic, and Javascript scripting components. It is an embeddable compiler and interpreter engine that allows you to import the interface sections from your Delphi Berlin units and access the rest of your code from the interpreted script itself. You can access the main form of your application from the interpreted script for example. It also supports compiling executables on Windows and evaluating script at runtime. If you’re building any kind of scripting into your apps be sure to take a look.
WinSoft provides a huge number of individual components and library wrappers for accessing various devices like bar code recognition readers, the device cameras, COM ports, JDBC, DirectX Joystick, JSON files, CSV files, NFC, PDF, HID USB, and many more. Check each individual component for it’s device compatibility because they all vary across Android, IOS, OSX, and Windows. You can also get all of the components in one giant Winsoft Component Package.
Woll2Woll provides a versatile grid component suite called FirePower for all the Firemonkey platforms in Delphi Berlin which are Android, IOS, OSX, and Windows. It allows you to embed controls like buttons and images into the grid. It supports multiple columns and you can multiple select columns as well. It has seamless filtering and allows you to use in memory information from FireDAC and TClientDataSet. Records or cells can have custom fonts or custom colors for even more flexibility.
There are many more free and commercial Firemonkey components out there from other developers and vendors that we weren’t able to cover in this article.
If you are new to Delphi, new to Firemonkey, or new to mobile app development it can be a lot of information to take in all at once. Hopefully this guide will help you hit the ground running and accelerate your multi platform development with Delphi 10 Seattle. This information also mostly applies to Appmethod and C++Builder. The guide is going to cover video tutorials for building Android and IOS apps, integrating analytics, adding push notifications, working with IoT devices like Arduino and beacons, and finally on a more advanced level using enterprise services to really take your Firemonkey apps and Delphi deployments to a whole new level on Android, IOS, OSX, and Windows.
Delphi Android And IOS Overview
Learn about the Delphi development environment for mobile devices and all about the different sensors and functionality you have access to in this video. The video is for Delphi XE6 so also view the next video below to see the latest upgraded Firemonkey features in Delphi 10 Seattle.
Firemonkey Overview
Firemonkey is a rapidly evolving frame for development on Android, IOS, OSX, and Windows. Find out all of the newest features and functionality that are available in the latest version under Delphi 10 Seattle in this video.
Debugging Across Devices
Debugging applications across all the Android, IOS, OSX, and Windows platforms can be tricky. Learn how to effectively debug your multi device applications in this video.
Deploying Your Apps To Google And Apple
Developing your app can take some time but getting it deployed into the Google and Apple apps stores can be tricky. Learn how to setup and deploy your Android and IOS applications in this video.
Push Notifications
One way you can send information to your apps and keep your users engaged is to use push notifications. There are a lot of different ways to do this and it can be complex to support both Android and IOS methods. Learn how to use the Kinvey BaaS service to implement push notifications in this video.
Track Usage With Analytics
Use the analytics data to improve your apps instead of blindly developing new features. Learn to utilize the AppAnalytics component to start collecting data on how your users use your apps in this video.
Inter App Communication
If you are a long time Delphi developer and you have VCL applications that you want to get talking to Android and IOS devices or you just want all of your devices to easily communicate with each other you should take a look at AppTethering. Learn to use AppTethering for inter app communication in this video.
Talk To Arduino Devices
You can use Arduino devices for a variety of automation and sensor collection tasks. Learn how to use Delphi to talk to Arduino devices in this video.
Utilize Localized Geo Location
Integrate Beacons and beacon fencing into your apps for localized geo location services within buildings. Learn how to use the BeaconFence library to create localized events based on user locations with beacons in this video.
Quickly Deploy An Enterprise Cloud
Leverage the Embarcadero Enterprise Mobility Services cloud service to get your enterprise development up and running quickly. Learn how to create custom endpoints, implement push notifications, and create a custom login system in this video.
Programmable and internet connected devices like the Arduino are exploding in popularity. There are quite a few videos on up YouTube showing fun integrations between Delphi and various bluetooth, wifi, and serial connected devices. Here are the top 10 Delphi device integration videos I’ve seen.
Some of them utilize Delphi XE8 Firemonkey apps on Android and IOS while others are simple Delphi 7 VCL apps using a COM port. There are three different Arduino integrations, two different drone integrations, a brain interface integration, a robot arm integration, a depth sensor integration, an animatronic head integration, an integration with beacons and mobile devices, and a gesture control integration. Three runner ups are listed at the end and they are a swimsuit integration, IP camera integration, and a temperature sensor integration.
Add your favorite Delphi hardware integration videos I’ve missed in the comments below!
#1 Animatronic Terminator Head Controlled Via A Delphi XE8 Android App
There are four different servo motors that control this creep animatronic head. Is that the Firemonkey light in his eyes?
#2 Delphi Firemonkey Android App Controlling LED Lights In The Room
This is a slick looking control interface for changing the room lights by sliding the colored bars in this Delphi app. Another similar video is here.
#3 Audience Member Controls A Drone Using His Brain Via Appmethod App And An Emotiv Headset
Nothing says this is the future like watching a guy fly a hovering vehicle with his mind. There is a second longer video with more explanation and background that you can watch here.
#4 Robot Arm Sketches Letters Via An Arduino And Delphi Control App
The Delphi app in this video is actually playing back a list of commends to create the sketch.
#5 Demonstration Of Accessing Microsoft Kinect Depth Data From Within Delphi
You can see the depth data made available via the Kinect SDK in this video. Includes sample source code.
#6 Ultrasonic Ping Pong Game Build In Delphi And Controlled Via An Arduino
This one is awesome because of the ultrasonic controllers. The Delphi and Arduino source for this integration is available in the YouTube description. The runner up to this video uses a knob but it also has a speaker (check it out here).
#7 Appmethod Control App Used To Pilot A Parrot AR Drone Around The Office
It’s hard to top a brain controlled drone but sometimes you just need the drone to go where you want and that’s where controlling it with a Delphi app comes in.
#8 Medical App Built In Delphi On Android And IOS Utilizes Check Ins Via Beacons For Distance
I believe the apps demonstrated in this video were covered in a webinar by Embarcadero and you can find all the resources for building the apps here.
#9 Appmethod Reads Data From A Myo Gesture Control Armband To Move A TRectangle
There is also a second video here where the armband is used to control a photo app in Delphi with gestures.
#10 Slick Looking Delphi App Used To Control An Arduino Via Wifi And Bluetooth
You can test out this app demo yourself and get the Arduino side of the source code here.
BONUS: Connected Swimsuits That Monitor (Via Delphi) How Much Sun They’ve Received
It isn’t quite clear how Delphi (or Appmethod) is used. I assume it is used by the sunlight monitoring device as the control app on a tablet or phone.
DOUBLE BONUS: IP Cameras And I/O Controllers Connected And Controlled Via An A Delphi Android App
This video is good but it is someone long as it contains a lot of technical details and a lot of connected devices. Really good showcase of technology.
TRIPLE BONUS: Read Temperature Data From An Arduino Device Using Delphi And Display It In An App
This integration with Delphi is achieved via simple serial port interface.
You can utilize these tips when building Firemonkey apps with Rad Studio XE8, Delphi XE8, C++Builder XE8, and Appmethod for Android, IOS, Windows, and OSX devices.
In a mobile world it is more important than ever to secure and compress your data connections. Your users are hopping from hotspot to hotspot and switching between 2G, 3G, and 4G as they travel while using your apps. You never know how fast the data connection will be or who might be trying to snoop on your enterprise data. Delphi XE8 uses the platform native HTTP clients for it’s REST requests so that it’s SSL/TLS implementation is always up to date. You can secure other types of connections using SSH tunneling.
If you are deploying a local database like SQLite (or Interbase) with your app you can encrypt the local database by setting a password. Whether it is company enterprise data, user medical data, or even user photos encrypting your local database will help keep your app data and your user’s app data secure.
It is never a good idea for your users to feel like your app is frozen while it does a calculation or loads some data. Using a native progress or activity dialog can keep your app fast and responsive while your app performs work in the main thread or even other threads.
With mobile apps especially it is always a good idea to check for a network connection prior to attempting to open a connection. Users on mobile devices can enter and leave connectivity at any time as they travel and your app should be built with this in mind. This applies to REST, app tethering, and straight TCP/UDP connections. Some mobile platforms (like IOS) even require that you make network connections outside of the main thread so utilize anonymous threads as much as possible.
Whether you are sending an enterprise notification about a company event or notifying a user that they have a new message increasing user retention by utilizing push notifications can really help your app succeed. Push notifications are what allow you to re-connect with a user even though the user is not currently running your app. You can utilize the BaaS components in Delphi XE8 to implement push notifications through Parse and Kinvey or you can use a third party component which implements the Pushwoosh API.
There are nine premium styles that come with Delphi XE8 Firemonkey and they can really give your app a professional look. Utilizing premium styles can also allow you to provide a light and a dark theme so your users can decide which works best in their lighting environment (Hint: the dark themes work great in full sun environments). Be sure to test out using gradients and images on your form backgrounds to really make these premium themes pop.
When building multi platform apps be aware of the different buttons and events available on each platform. You can handle the back and menu (VK_MENU in OnKeyDown and OnKeyUp events) buttons on Android devices so your users will have an intuitive flow inside of your apps. You can also utilize events like FinishedLaunching, BecameActive, and EnteredBackground to handle changes in your app’s lifecycle. There is also a bonus component called TfgApplicationEvents which gives you easy access to OnIdle, OnOrientationChanged, and OnStateChanged.
The standard TListView component that comes with Delphi XE8 takes one-two lines of text (a title and a detail), an image, and an accessory icon on the right. If you want to display more lines of text in each item you will need to add a custom ItemAppearance. One of the custom ItemAppearances that can be installed supports 4 lines of text (a title and 3 details). Additionally, you can create your own custom ItemAppearances and add even more. Lastly you could also use a TListBox where you can embed any number of other controls within each TListBoxItem.
Delphi XE8 comes with a TAppAnalytics component which allows you to see how users are using your app. The feedback you receive from analytics allows you to make smart decisions on how to iterate the next version of your app. You can add custom event tracking anywhere in your app and send exception information automatically to the server for review. Seeing exactly where users may be getting stuck or what features they use the most is gold. The TAppAnalytics feature is a cloud service with both a free tier and paid tiers. There is also a third party component that allows you to also track your app usage using Google Analytics. Both components require an internet connection.
If you are new to working with a full featured framework like Firemonkey you may be wondering at the size of the apps that Delphi XE8 Firemonkey generates. The Firemonkey Framework has hundreds of thousands of lines of code that allows you to jump ahead and start building the app you want to build now instead of the bricks in the road to get there. Hopefully this infographic will provide some insight into what makes up an APK/IPA cross platform application deployed from Delphi XE8 with the FMX framework. The infographic covers Android, IOS, Windows, and Mac OSX apps/packages/libraries/archives created using the Firemonkey framework. Tools that utilize the Firemonkey framework are Delphi XE8, C++Builder XE8, Rad Studio XE8, and Appmethod. The infographic only covers Release mode (something you could deploy to your customers). I have also included a VCL section in the infographic so that you can compare the Windows only VCL framework to the cross platform FMX framework. Also keep in mind that when you use debug information or are in Debug mode your file could be significantly larger. The sizes of the generated files are included in the green circles. There is the normal compiled size and then there is the compressed or packaged size. APK and IPA files are packaged and compressed. The compressed sizes for Windows and Mac OSX were achieved using the 7Zip format. Here is some information directly from the infographic as well about what units are included in a FMX app on Android (it is slightly different on each platform) and how those units effect the size of the deployable file.
Let’s start off with a Hello World app which is basically a FMX form with a TLabel on the form. This comes out to around ~4.97MB when deployed to Android as an APK. Even though this is a Hello World app there is already much more functionality here than just the ability to print out ‘Hello World’ to the screen. A true ‘Hello World’ would be much smaller because it would lack these Firemonkey framework units. The FMX and RTL units included are:
Next up I’ve listed what I call a Basic App that clocks in at ~5.50MB. A basic app has some more visual controls available to it like a TListView, a TListBox, a TTabControl, a TMemo, and even some access to advertising. Here are the FMX units included (in addition to the units from the Hello World app):
This next tier of app size I’ve termed Services because it is basically some Android JAR files which when fully included bring the app up to around ~6.40MB. These services are basically helper services for Android (some of which are provided by Google) like Google IAP, GCM, and Analytics. You can include and exclude each of these files from your APK separately. Here is a list of the additional files:
Next up we have what I have termed the Consumer App style app tier which rings in at around ~8.91MB. Obviously if you add more or differently functionality the size of your app can fluctuate greatly. You could also build games and they might fall in this size range depending on how many external graphics and sound you used. This type of app includes more functionality like the RESTClient, the in app purchases unit, sensors, a grid component, and the camera component. Here are the additional FMX and RTL units included by the IDE when these new components (in addition to all of the above) were added:
Lastly we have the Enterprise and Database App tier which comes in at around ~10.4MB+ but can increase size from here the more you add to your app. This includes FireDAC functionality for accessing an SQLite database, LiveBindings to bind the data to a grid, accessing various path utility functions, and creating ini files for settings storage. At this level you can add tens of thousands of lines of code and lots of forms and the app could still be around this size. The RTL and FMX units included when this functionality was added (in addition to all of the above units) are as follows:
