Android Tutorial B4A: Getting Started for Delphi Developers

B4A: Getting Started for Delphi Developers

Borland introduced the Delphi programming environment in 1995. At the time Delphi was a revolutionary new tool for Microsoft Windows-based application development. It provided an integrated development environment (IDE) that included a visual User Interface (UI) development tool, integrated debugger, and a rapid application development (RAD) framework providing standard objects and event handlers to greatly speed development. Delphi used the Object Pascal programming language.

Basic for Android (B4A) is a development environment from Anywhere Software, which shares many similarities with Delphi. B4A runs on a Windows-based environment but its purpose is to develop applications targeting Android-based devices. The B4A development environment uses the BASIC programming language to produce native Java code that is then compiled using the standard Android development tools. Similar to Delphi, the B4A environment includes an integrated debugger, visual designer, and provides a RAD framework with many objects and libraries to speed Android development.

Getting started with B4A is easy. There is a free trial version that you can have up and running in a matter of minutes. Follow this link for more information:

Basic4android (Basic for Android) - Android programming with Gui designer

There is also a Remote Compilation tool that makes trying B4A even simpler. There is no need to install the Android development toolset on your computer. Since Android-based devices are the target for developed applications, B4A provides a tool called the B4A Bridge that easily transfers and installs applications on to a target device. If you have installed the Android development toolset, you can create an emulated Android device, running on your Windows-based computer, instead of using a physical device for the target.

One of the biggest differences between developing for a Windows-based environment and developing applications for Android is understanding the Android Application Lifecycle – the different states of execution that an application can have from its launch to exit.

In a Windows-based environment an application has two states: created and destroyed. When an application is launched it is created and begins executing. There can be many applications executing at the same time (sometimes called foreground and background). The top-level, or foreground, application has the input Focus – it receives mouse clicks and characters typed on the keyboard. Applications running in the background do not have the Focus, but are still executing. For example, a spreadsheet can be calculating in the background while, in the foreground, you type a memo in Notepad.

An Android-based application has three states. An application can be Active, Paused, or Stopped. Only one application is Active at a time (although applications can be listening for events, ready to become active, as in the case of a service application). The following quote is from the official Android documentation:

Every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications.

See the following link for more information and a tutorial about the Android application lifecycle:

An application will change from the Active to the Paused state as the result of some external event, such as: the user pressing the Android Back or Home buttons, a device orientation change (rotating the device between landscape and portrait modes), an incoming phone call or text message.

When an application enters the Paused state a different application becomes Active. If the Android operating system determines that it needs to reclaim the memory used by an application, it will move the application to the paused or stopped state, halt the process, and remove it from memory.

If an application is in the paused state and the application becomes reactivated, the application’s process does not need to be re-created. From the stopped state reactivating an application requires the process to be re-created.

The tutorial above describes several subroutines that are automatically created by B4A for a new application and executed at various points during the application’s lifecycle: Sub Process_Globals, Sub Globals, Sub Activity_Create(FirstTime), Sub Activity_Resume, and Sub Activity_Pause(UserClosed). The following lists some events that may occur during an application’s lifecycle and the subroutines that are invoked in response.

Application launched, process created
1. Sub Process_Globals
2. Sub Globals
3. Sub Activity_Create(True)
4. Sub Activity_Resume

Note: Both Process_Globals and Globals are executed. Activity_Create FirstTime is True.

Device orientation change
1. Sub Activity_Pause(False)
2. Sub Globals
3. Sub Activity_Create(False)
4. Sub Activity_Resume

Note: Process_Globals is not executed but Globals is executed.

Android Back button press
1. Sub Activity_Pause(True)
On reactivation
1. Sub Globals
2. Sub Activity_Create(False)
3. Sub Activity_Resume

Note: In Pause, UserClosed is True. On reactivate Globals and Activity_Create with FirstTime equals False are executed.

Android Home button press
1. Sub Activity_Pause(False)
On reactivation
1. Sub Activity_Resume

Note: UserClosed is False.

Incoming phone call
1. Sub Activity_Pause(False)
Phone call ended
1. Sub Activity_Resume

Note: UserClosed is False.

In B4A and Android, Activities roughly correspond to Forms in Delphi. In a Delphi application the MainForm is automatically created and shown when the application starts. In B4A the Main Activity is created when the application launches. In order to show a screen the activity’s Layout must be loaded (using Activity.LoadLayout). This is usually done in the Activity_Create subroutine. Layouts are developed in B4A using the IDE's Visual Designer.

Applications in Delphi and B4A can have multiple forms (layouts). In Delphi you use the Show or ShowModel methods to display a form. One way to display multiple forms (I call them forms since they are not necessarily layouts) in B4A is to create an application with multiple activities. Each activity might have its own layout. The following tutorial describes creating an application with multiple activities in B4A:

Another way to accomplish multiple forms in a B4A application is to have one activity with multiple panels containing the UI objects for each form. The panels can be brought-to-front or sent-to-back, made visible or not visible to accomplish the effect of having multiple forms. Either method has its advantages and disadvantages. See these discussions about multiple activities:

Basic4android Search: multiple activities

The Object Pascal language used in Delphi is considered Strictly-Typed. The BASIC language used in B4A is less so. It is important to understand a variable’s Scope. Variables declared in Sub Process_Globals are public variables and can be accessed from other activities. Variables declared in Sub Globals can only be accessed from within the activity, and variables declared within a subroutine are local to that subroutine.

From the list of events above we see that when an activity is resumed in response to the Android Back button being pressed or a device orientation change that the Sub Globals subroutine executes. The activity variables declared in this subroutine will be re-declared and the previous values lost. If the previous values will be needed after the resume, they should be saved during Activity_Pause and restored in Activity_Resume.

In Delphi variables are declared within a Class or the “var” sections of a unit, implementation, method, … In BASIC and B4A variables are Dim’d. Dim is an executable statement. It can be located anywhere within a subroutine. Its function is to create a new instance of the variable of a specific type. The function of Dim can be thought of as both the Delphi procedure New() and a variable declaration such as:

i: Integer;

Some other differences between the Object Pascal language of Delphi and the BASIC language of B4A:
  • In Delphi the first character of a string has the index 1. Index 0 is used for the length of the string. In B4A the index of the first character of a string is 0.
  • Subroutines in Delphi are called procedures and do not return a value. Delphi functions return a value. In B4A subroutines return values.
  • Delphi code statements are free-form. A statement can continue across multiple lines and ends with a semicolon. In B4A each line contains a single statement. Statements can be continued on the next line by placing an underscore character at the end of a line.
  • Variable type casts in Delphi need to be explicitly performed. Conversions between two variable types are also explicit, for example, in Delphi you might see the statement s := IntToStr(i); to convert an integer value to a string in preparation for printing. In B4A variable types are automatically converted as needed. The statement s = i converts the integer value of i to a string.
  • User interface objects in both Delphi and B4A contain a property named "tag". In Delphi this property is a long integer. In B4A the tag property is an object – this is really handy. The tag property can accept a value of any type: string, floating-point, integer. It can also be a complex variable type such as a list, map, or a custom type’d variable.
There is an extensive collection of reusable libraries and objects available for B4A. In addition, there are many third-party libraries that are available to be incorporated into a project. See the following two links:

Basic4android (Basic for Android) - Android programming with Gui designer

Libraries - Basic4android Wiki

Shortly after Delphi was introduced in 1995 a large and dedicated user community emerged. Compared to the present, the Internet was in its infancy. Websites were created and groups formed where Delphi users could interact, ask questions, and share solutions.

The same dedicated user community has evolved around Basic4Android. The B4A forums at:

are very active. Users from around the world gather to ask questions, exchange ideas, share code, or just interact. Documentation for B4A and an extensive repository of tutorials and code examples is available at their website:

Basic4android (Basic for Android) - Android programming with Gui designer

The transition from Delphi development to B4A is straightforward. The differences in the application lifecycle and the few language differences between Object Pascal and BASIC are the only significant hurdles. There are many similarities between Delphi and B4A.

B4A offers a RAD development environment that allows fast and efficient code development for Android-based devices.


Active Member
Licensed User
Longtime User
Nice article. You might want to consider creating a "Delphi" library that mimics the original delphi language/syntax so that delphi users that are perhaps porting code can keep it pretty much intact without significant changes and/or help reduce the learning curve.

Here are a few simple examples:

Sub Pos(substring,s as string) as int
    return s.indexof(substring) 'might have to add "1" to be compatible with delphi's result cause of the diff between b4a and delphi
end sub

sub Length(s as string) as int 'might be able to use object and test for various types and use their "size" method
end sub

sub StrToInt(S as string) as int
    return S 'I realize b4a automatically does this already.  It's just for porting purposes so you don't have to spend a lot of time changing code
end sub

sub InttoStr(integer as int) as string
    return integer
end sub

'perhaps some constants, such as msgbox results

Now of course a delphi->b4a converter would be amazing. Then again, Delphi is suppose to be getting a major "mobile" upgrade which would likely reduce the need for b4a since it's suppose to do iOS and android with the same code base. Personally I like how b4a seems to be simpler and cleaner with a lot of things that I'm working on. I'm nearly done porting a 20,000+ line delphi app to android. Quite the endeavor. Sure could of used a lot of porting tools a while ago. Good thing the hundreds of SQL Server tables and storedprocedures it interfaces with doesn't need to be ported.

It would be further nicer if we didn't always have to precede custom library procedures/variables with the library name. I understand multiple libraries could use the same routine/variable names, we just need a way to prioritize them and if there is a collision we could choose to qualify them if the specific one we want is not top dog.