Objects

• 1: Object Categories
• 2: Object Types and Instances
• 3: Object Fields
• 4: Field Content Tags
• 5: Unique Field
• 6: Object Relationships
• 7: Autofill Fields
• 8: Data Objects
• 9: Lookup Table Objects
• 10: State Objects
• 11: User Profile Objects
• 12: True/false fields as Switches
• 13: Badges

1 - Object Categories

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.

2 - Object Types and Instances

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

• Fields
• Relationships

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

Comparison with spreadsheets

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

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

Fieldname

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

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 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.

UID

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

Relationships

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.

 
  
  erDiagram
    CUSTOMER ||--o{ INVOICE : has
    CUSTOMER {
        text uuid
        text name
        text company
        text email
    }
    INVOICE {
        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:

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

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:

8 - Data Objects

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.

Supabase

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

Firebase

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

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.

   Column names

   Column names will correspond with object field names, so they, like object field names, need to be lower-case, without spaces or hyphens.

   

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

Paste in the Google Sheet Link to let Logiak read the data.

10 - State Objects

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 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

Switch

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

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.

Polymorphism

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).