Application architecture

From Smart Mobile Studio
Revision as of 13:07, 14 July 2014 by Bear (Talk | contribs) (Created page with "<p> While different from delphi both in philosophy and medium, smart tries to preserve some of the characteristics we all know and love from delphi. For example the way you c...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

While different from delphi both in philosophy and medium, smart tries to preserve some of the characteristics we all know and love from delphi. For example the way you create, attach and move a visual control is the same, as are the names of common properties and methods. The general layout of the component hierarchy is likewise heavily inspired by delphi and how pascal programmers think. But these similarities are essentially just cosmetic. There is no escaping that the document object model (DOM) is a very different landscape than we are used to. But that’s why we have the VJL in the first place, as leverage.

As we all know, learning a new programming language or dialect is really not that hard, the hard part is gaining a deeper understanding of the framework and memorizing the class names and functions involved. Luckily the VJL was designed by a delphi developer – so anyone with a background in object pascal should feel at home with little effort.

The IDE has a built-in class browser that is very helpful. You can find it under the Tools menu:

Smart Mobile Studio classbrowser Use the class browser to examine the RTL

Although the units of the VJL are many (and growing) – the heart of the system is really only made up of 3 central files. When you get to know these and what they do everything else will fall into place. So let’s have a look.



As the name implies this unit is all about low level functionality and the system, which in our case is the document object model. In many ways this unit is a blend between system and sysutils under delphi, here you will find functions for creating, interacting with and obtaining information directly from html entities (all controls are pure javascript under Smart. We don’t map our javascript onto a prefabricated design). This is also the home for common utility functions, data-type declarations and record types.

The only real difference between the sysutils under delphi and w3system under VJL, is that we have isolated common utility functions into their own name-space (as class functions), making everything more organized and easier to work with. So TVariant contains all the variant functions, TRect all the functions for manipulating rectangles – and so on.

Here is what the TVariant namespace looks like:

	TVariant = class
	class function asInteger(const aValue: Variant): Integer;
	class function asString(const aValue: Variant): String;
	class function asFloat(const aValue: Variant): Float;
	class function asObject(const aValue: Variant): TObject;
	class function asBool(const aValue: Variant): Boolean;
	class function isNull(const aValue: Variant): Boolean;
	class function isString(const aValue: Variant): Boolean;
	class function isNumber(const aValue: Variant): Boolean;
	class function isInteger(const aValue: Variant): Boolean;
	class function isBool(const aValue: Variant): Boolean;
	class function isNAN(const aValue: Variant): Boolean;
	class function CreateObject:Variant;
	class function CreateArray:Variant;

W3system is also home to our browser drivers. When you execute your application, the application begins by checking what browser you are using – and initializes a driver for it (note: drivers are written in smart, there are no external dependencies involved in this). By using drivers we manage to handle advanced techniques, such as hardware accelerated graphics and transformations, from a common code-base. Any peculiarities are handled by the driver and the rest of the RTL don’t have to worry about it.

If the idea of drivers sounds like overkill for something as trivial as a web app, we must remember that there are subtle but important differences between browsers. For instance webkit browsers favours “length” as a property in some javascript objects – but mozilla favours “size”. Through the drivers we are able to keep vendor specific clutter to a bare minimum.



This unit is where visual controls are first introduced. The most fundamental class which implements the mechanism for self creation, attaching itself to – and detaching itself from another element, is TW3tagobj. From this basic object the following hierarchy is built:

  • TW3component
    • TW3Movablecontrol
      • TW3Customcontrol

Just like the object hierarchy in delphi, from TWinControl to TCustomcontrol, each descendant adds specific behavior and properties to the model it has inherited. TW3component adds the ability to house child components. It also introduces the familiar delphi component constructor, which takes an owner component as a parameter.

TW3Movablecontrol adds properties like left, top, width and height (and associated methods like moveto, setbounds etc) and thus allows you to move an element around. This class was added between TW3component and TW3Customcontrol to provide a lightweight alternative for game and multimedia programmers. It is especially suited as a “sprite” (see unit w3sprites) which can be manipulated in both 2d and 3d via the built in Sprite3d engine (see w3sprite3d).

TW3Customcontrol is the class all visual controls inherit from. It inherits the full richness of methods and properties from it’s ancestors, but adds sub-objects like background, font, border management, size restriction, css style management and scroll information. These sub objects are created on demand, so unless you access these from your code they remain dormant.

TW3Customcontrol is also the class that introduces support for gestures, touch and multi-touch – and all the events standard html entities expose. Depending on the entity a TW3Customcontrol represents, some events may not fire. For instance, if the control represents a html5 canvas the onScroll event will naturally never fire. Since there is a limited number of events under the DOM TW3Customcontrol publishes all of them.



This unit contains the standard visual controls that ship with Smart Mobile Studio. It is a great unit to inspect if you want to learn how to create your own custom controls (which is much easier than it sounds). You will notice that the controls all override one method in particular: makeElementTagObj. This function (implemented in TW3tagobj as a virtual method) is in charge of creating the actual html tag you want to work with.

As of writing the unit contains the following visual controls (not counting sub controls or auxiliary classes)

  • TW3Memo
  • TW3ComboBox
  • TW3Label
  • TW3Image
  • TW3Button
  • TW3CheckBox
  • TW3EditBox
  • TW3Panel
  • TW3ToolButton
  • TW3ToolbarButton
  • TW3Toolbar
  • TW3HeaderControl
  • TW3PaintBox
  • TW3ListItem (iPhone menu item)
  • TW3ListMenu (iPhone menu list)