1 - Object Categories

Object category

Categories of Object

There is really only one kind of Object: a structure with fields and relationships which map onto a database table.

But then we have three other purposes that we are treating in the same way as objects, so that we can reuse as much as everything else in Logiak: they share the same UI for being configured, can be used in much the same places as “normal” objects. Avoiding proliferation of concepts, is part of minimisation to avoid large learning curve.

  • User settings
  • User profile
  • Lookup table

We’ve conceptualised these three things also in terms of objects.

Data Object

  • Normal data object - for your Apps to create, update and delete records
  • Can have relationships
  • Each type maps to a database table
  • You can have any number of Data Object types
  • There can be any number of instances of any of these types

Table Object

  • Data defined statically
  • Data maintained offline in a Google Sheet
  • Each type maps to a database table, but with data
  • Can have relationships, as long as keys exist
  • You can have any number of Table Object types

State Object

  • Not in the database, but local storage
  • You can have any number of State Object types
  • Exactly one instance of each State Object exists
  • No need to create
  • Can be updated (only)

User Profile Object

  • Maximum of one User Profile Object type per Project
  • Requires Apps to have Login
  • Has auto-fill email field as unique field
  • Exactly one instance per User
  • Can be updated

2 - Object Types and Instances

Object can be used to mean type or instance depending on context

Object Type

An Object Type is the definition of a data structure. A template for a specific kind of data.

In defining an Object Type, you specify

Object Instance - a record

An Object instance represents actual data - an instance is a record of one of the defined Object Types

Every instance of an Object Type will contain values for all of the fields and Relationships defined by the type.

Comparison with databases

Logiak Object Spreadsheet
Type the definition of the database table (which columns and relationships it has)
Instance a row in the table, containing data valuess

Comparison with spreadsheets

Logiak Object Spreadsheet
Type the column headers of a spreadsheet - definition of what the column contains
Instance A row in the spreadsheet, containing data

Example spreadsheet

This spreadsheet, for example, would correspond with a Logiak Object type which had the fields:

  • id
  • firstname
  • lastname
  • company
  • address
  • city
  • county
  • postal
  • phone1
  • phone2

While the rows from 2 onwards each represent an instance of that type

3 - Object Fields

Object fields

Object Fields

An Object Field has:

  • A Data Type - is it a number field? a text field?
  • A fieldname
  • An initial (default) value
  • (optionally) A display name
  • (possibly) content tags


Object field fieldnames have to be “symbolic” - meaning they should not be like a normal name or sentence. They have to be:

  • lowercase
  • containing no spaces or hyphens

Field names have to be unique within an Object (you can’t have two fields called remark) for example.

Avoid database reserved words

Object field names will also becomes the names of database table fields, so there are certain database keywords which cannot be used. Logiak will notify if any of these occur.

Display names

Display names are free text. If given, the display name is used when the field is presented to the user (e.g. in an Object View), otherwise the fieldnames are used.

Editing display names

Symbol “Edit sets”

When you have a symbol field, the idea of the user being able to edit fields of an instance raises an issue. Whereas the user will know how to edit a number, text, or a date, how does the user know what to do with a symbol field.

Symbols are eseentially Logiak-internal things.

The solution is to select a Symbol Set (defined at the Project level), to be the field’s “Edit Set”.

Then, when the user goes to edit the value of the field in an editable Object View, there will be a drop-down menu containing the options within the set.

4 - Field Content Tags

Tags give extra meta-information about what a field stores

Content tags

We keep the data types to just a few and use tags to note types of content which should be handled specially.

Example: Email

If you want to store an Email in a field, it makes sense for that field to be a text field.

But when emails are presented to the user, it makes sense that they are not just presented simply as text - ideally there should be some indication that this is an email, and perhaps the UI should afford the user of clicking on the email to open a mail client.

This is how you tag a field to denote that it is an email field

5 - Unique Field

Field guaranteed to have unique values for each instance

Field with unique values

There are few restrictions object definitions but one of them is that there must be, for every object, a field whose values are guaranteed to be different for each instance.

In familiar computing terms, what we are saying here is that every Object must have a Primary key, with the limitation that the Primary Key must be one field rather than a composite.


For this reason, by default, when an Object type is first created, an Auto-Fill field called UID is automatically added and assigned as the unique field.

UID stands for Unique Identifer.

When an Object type is first defined, by default the unique field is assigned as a UID field.

Auto-Fill fields are fields where Logiak assigns values automatically.

In the case of UID, Logiak assigns to each instance a Universally-unique identifier as the UID.

Possible to assign other fields

So, quite frankly, you don’t need to worry about the uniqueness issue.

But if your data already has an “id” or some field which is guaranteed to be unique for each row, then you could assign that field as the unique field for that object, and delete the UID field.

Simply click “change” and select the field you want to use as the Field with unique values

6 - Object Relationships

Objects can have relationships to other objects


An Object in Logiak is defined by its name and its fields, but also its _relationships- with other objects.

Relationship example

Let us think of an example to illustrate.

Suppose we have a customer Object which has three fields: name, company and email, and you bill customers by sending them invoices. Each invoice applies to a customer therefore, and any customer “has” zero or more invoices which apply to them.

    CUSTOMER ||--o{ INVOICE : has
        text uuid
        text name
        text company
        text email
        text uuid
        date invoice_date
        number amount
        boolean paid

Same example in Logiak

In Logiak, the fact that each invoice has a customer is represented explicitly in the definition of invoice, like this:

This video shows how customer and invoice are configured:

Example of defining a relationship

Relationship values

Relationships are represented by fields at the database level, so in the above example, when looking at the data in your backend, you would see a “customer” column in the invoice table/structure.

As with traditional databases, the value of that field will be the value of the Unique Field of the customer object to which the invoice belongs.

7 - Autofill Fields

Object fields which are automatically given values by Logiak

Auto-fill fields

Auto-fill fields are special object fields you can add to an Object

They are automatically given values by Logiak.

They are given values when an instance is created or updated.

UID example

When any Data Object is created, by default it is given a field called uid and this field is assigned to be the field with unique values (which database people call ‘primary key’).

Note auto-fill fields are represented in light blue to distinguish them from normal fields.

This UID is an example of an auto-fill field. When an instance of invoice is recorded by Logiak, it obtains values for all fields and relationship from configuration, but the uuid it just assigns a value itself (and it assigns a UUID).

There are several such fields available and they are all are given specific semantics by the Logiak system:

Fieldname -
UID each record is assigned a unique uuid at time of creation. Does not change.
CREATED each record is assigned time at creation. Does not change.
MODIFIED initially same as created, is changed whenever record is updated
USER_EMAIL email of the user who created the record (if anonymous user => this will be null)
USER_UID Backend system uid of user who created the record
LATITUDE if GPS on device in use, latitude of location when record was created. Is overwritten on upd
LONGITUDE if GPS on device in use, longitude of location when record was created. Is overwritten on u
APP_VERSION_CREATED the x.y.z of the apk version being used when record was created

8 - Data Objects

A Data object is the “normal” database object

Data object is the “normal” database object

What we mean by “normal” here is that a Data object very much corresponds with a spreadsheet on the one hand, and with a database table on the other.

A Data Object is a defined structure for holding certain kinds of data.

It has fields and it can have relationships

On device

if you deploy a Logiak App to a mobile device, each Data Object is represented by a table in SQLite on the device.


When a backend is used which uses a relational database, a table is created in the database for each Data Object type.


When Firebase is used as the backend each Data Object type is a collection and each instance a document in that collection

9 - Lookup Table Objects

How to make use of a static data table in a Logiak App

Lookup Table objects: Static data

Table objects allow you to incorporate static data tables with your application.

The static data is essentially encapsulated in an Object, and then you can use the data within your App in the way any other Object is used.

The steps to achieve this are:

  1. Make a Google Sheet containing your data
  2. Create a Table Object
  3. Configure the Table Object, copying and pasting a Link from the Google Sheet

Sample data: Customers

Let us use the uk-500 data

We will pretend that these represent a table of important Customers.

Normally, customers may be dynamic data rather than static data, but this is convenient for illustration.

How to define a Table Object

These are the steps, that we will explain below. The user interface is also very supportive of these steps.

  • Prepare data in a Google Sheet
  • Create the Lookup Table Object
  • Add fields to the Object corresponding with Column Names
  • Give Logiak Access to read the Data
  • Paste in the Google Sheet Link to let Logiak read the data.

Prepare data in a Google Sheet

  1. Open a Google Sheet and copy and paste your data table in
  2. Make sure the data is in contiguous columns (i.e. no empty columns) and that the first row of the sheet contains column names.

Create a Lookup Table Object

Now let us create a Lookup Table Object in our project. Call it customer

You see that for Lookup Table Objects, there is a third tab called Sheet which guides us step-by-step through the configuration we need to do to be able to use the data in our App.

Add fields to the Object corresponding with Column Names

  • Make sure you have a column with values which are unique for each row
  • copy and paste the column names into the fieldnames box and select the data types
  • select the unique field..

Give Logiak Access to read the Data

  • Click on the Sharing button of the Google Sheet
  • Change the Access to “Anyone with the Link”
  • Then copy the Link

10 - State Objects

Think “settings”

State is NOT in the database

A State Object has nothing to do with the database.

It is a collection of information stored locally on a device.

So it is a very different thing in a way, but it is treated as an Object along with all the others, which means that you can refer to data within a State Object instance in exactly the same way as with all the others

Single instance

There is always only one instance of any particular State Object, but you can define any number of State Object types.

Available everywhere

A State object instance is “available” everywhere, meaning you can locate an Object View for the State Object anywhere in the Component Flow and it will work.

In contrast, normal data object have to be located downstream of a user selection.

11 - User Profile Objects

User Profile objects define profiles

User Profile Object

In defining the fields of a User Profile object, you are defining the information maintained about each user, whether the users do that themselves, or it is done on the backend.

User Profile Object is like any other..

You define a User Profile object just as you define a Data Object.

There are some special characteristics of User Profile objects:

Particularities of the User Profile Object

  1. You can define a maximum of one User Profile object per project .
  2. Apps using User Profiles must have Login as their START component, so that users authenticate themselves.
  3. User Profile objects have no relationships with other objects

Editing a User Profile

The User Profile component can be used to give users access to , and the ability to edit, their own profile information.

12 - True/false fields as Switches

True/false fields play a big role in opening up possibilities for configuration


A switch is something with two states - on and off.

A true/false field has two states: true and false.

There are several places within Logiak where true/false fields of an Object can be used to guide how the App behaves.

Actions Component

List row formatting

List Filtering

Custom Layouts

13 - Badges

Badges are how an existing Object type can be used in Maps and Cards components

We want to be able to have Cards and Maps which have clickable elements. Not only should they be clickable, but they should be the selection of a record, as with many other components in Logiak.

Then we can have these components as integral parts of chains of user interactions within an App - a point can be clicked and a record therefore identified, which can lead to other displays and functions relating to that record.

For example, if we have a system dealing in “incidents” of some kind, and the incident data includes a lat,lon pair, then we can have a map where the selection of a marker in the Map is a selection of a whole incident.

The problem Badges address

There are some components which require not only that you specify an Object type, but also that the Object has specific kinds of data which the component makes use of.

For example, to configure the Map component, as with many others, you simply specify an Object type.

Then, the Map component plots a location, one for each Object instance of the given type.

To plot points, the Object type evidently needs to contain the right kind of information: either latitude and longitude values (which makes it easy), or else some address information that we can use geodecoding to find latitude and longitude from.

So it seems like you would have to define Objects specifically for use in Map, with fields labelled “latitude” and “longitude”.

However, you might already have data with fields not named in that specific way. Maybe the fields are labelled “lat” and “lng” or something, and maybe it is very inconvenient or for whatever reason impossible to do so.

This is where Badges come in.

To use an Object with Map, it doesn’t have to have any specific names for fields, it just has to have the right kind of information. If it has the right kind of information, you can make it have the “location” Badge. Any Object type with the Location Badge can be used with Map.

How Object is given a Badge

All you have to do is to go into that Object, go to the Badges tab, and indicate from which field the latitude value should be taken, and from which field the latitude value should be taken.

Then your Object has the “Location” badge. The Map needs not a specific object, just any object with the Location badge.

Adding LOCATION badge to an Object called city


In computing people use this fancy term to refer to when one can treat one thing as if it were also another thing (poly = many, morph = form).