Telerik Platform Data Model

Telerik Platform Data Model

Telerik Platform allows you to define your data model. It consists of one or more content types, each containing a set of fields. To work with the data model from the Backend Services Android SDK, you must define corresponding classes in your app. The Backend Services Android SDK will take care of calling the Backend Services RESTful API and translating the data to/from instances of your classes.

While the above scenario is the most common (to have a class for each content type in Telerik Platform), it is also possible to consume dynamic data from the SDK. You could use the built-in Item class that comes with the SDK. It will allow you to work with any Telerik Platform content type and access your dynamic data in a Hashtable-like manner.

System Fields

Each Telerik Platform content type has several built-in fields. Every item has values for those fields. Here is a list of the system fields:

  • Id – the unique ID of the item
  • CreatedAt – the date and time when the item was created
  • ModifiedAt – the date and time when the item was last modified
  • CreatedBy – the ID of the user who created the item
  • ModifiedBy – the ID of the last user who modified the item

Values for those fields are maintained internally by Telerik Platform, you can read them, but you cannot modify them.

Defining Your Data Classes

Data classes are classes that represent a single record from a content type. For example, if you have a content type named Books, you will need a data class to represent a single book in your Android/Java application.

The standard way to define your data classes is to extend the **DataItem**class. This will give you the following features out-of-the-box:

  • Working with Telerik Platform system fields
  • Updating items only by setting properties
  • Accessing dynamic properties

Here is a sample class extending DataItem:

public class Book extends DataItem {
    private String title;
    private String author;
    private Date publicationDate;

    private UUID pictureId;

    public String getTitle() {
        return this.title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
    
    public String getAuthor() {
        return this.author;
    }

    public void setAuthor(String author) {
        this.author = author;
    }
    
    public Date getPublicationDate() {
        return this.publicationDate;
    }

    public void setPublicationDate(Date publicationDate) {
        this.publicationDate = publicationDate;
    }
}

Alternatively, you could implement the DataItemBase interface. It will give you the same functionality, but you will have to implement some parts by yourself. Our recommendation is to always extend DataItem, unless your object model does not allow for that.

Creating an Access Point to a Content Type

The flow is as follows:

​1. Obtain an instance of EverliveApp class. Either create it or use some singleton instance. More information about instantiating EverliveApp can be found here.

​2. Being a "fluent interface" API using the EverliveApp (app) object to get all items (books) looks like following.

RequestResult booksRequestResult = app.workWith().data(Book.class).getAll
().executeSync();

In English the upper statement means: use EverliveApp Book type and get all items (books) synchronously (which means that it will block the calling thread). Generally all calls to the cloud data is wrapped in facades (for example in the previous code getAll() method returns GetByFilterFacade). All facade types extends from a parent class FacadeBase which defines synchronous and asynchronous calls infrastructure. All facades returned a RequestResult instance. RequestResult provides options to check if the request was successful or not, get the result or error information.

if (booksRequestResult.getSuccess()) {
    ArrayList books = (ArrayList) booksRequestResult.getValue();
    for (Book book : books) {
        System.out.println(book.toString());
    }
} else {
    System.out.println(booksRequestResult.getError().toString());
}

In order to use this code you should define a Book class that extends the com.telerik.everlive.sdk.core.model.base.DataItem class and is mapped to your Telerik Platform content type. More information can be found here.

​This is the basic flow and it is valid for both system and user-defined content types. In the following sections you will find detailed examples for each available operation.

Mapping Types

When creating your data classes, it is important to know what Android/Java type to use for each property so that it can be properly serialized. In the following table you will find the proper type mappings.

Telerik Platform Type  Java Property Type
 Id  UUID
 Text  String
 Number  Number
 Date and Time
 Date
 File  UUID
 Geo Point
 telerik.everlive.sdk.core.model.system.GeoPoint()

Mapping Fields

Now that you know what types your properties need to be, you can easily mimic the Telerik Platform data model in your Android app. However, there are still a few points that might give you trouble: ignoring certain Android properties when making requests to the service and mapping Android properties/classes to Telerik Platform fields/types.

You often need to have some helping properties in your classes, which do not need to go to the server. The Backend Services Android SDK allows you to mark them as ignored. This is done using the ServerIgnore attribute. If this attribute is not set to a readable property, the value of the property will get stored in the cloud, even if the name of the property is not defined in your Telerik Platform data model. Here is an example:

public class Book extends DataItem {
@ServerIgnore
public String clientOnlyProperty;
}

Another popular scenario is where the names of your Java properties differ from the fields in Telerik Platform. The Backend Services Android SDK allows you to map the properties to their matching server field using an attribute. The attribute is named ServerProperty. An example:

public class Book extends DataItem {
@ServerProperty("publication_date")
private Date publicationDate;
}

ServerProperty annotation contains some other very important settings that control the behavior of the entitled property. These properties are as follows:

  • genericClassName - a fully qualified name of the generic class (type) used when the property is generic (ArrayList<Class>). In Java and therefore in Android there is no way to get the generic type at run-time due to type erase, so in order to be able to deserialize the type correctly Android SDK needs the generic type.

  • writeToServer - a boolean value that indicated that this property should not be stored on the server or not. Very useful in cases when we have a client side calculated value that should not be stored on the server. For example we have two fields "FirstName" and "LastName" on the server, while on the client we have a property "DisplayName" which combines both fields. Obviously we do not need to store property "DisplayName" on the server, since we already have this information.

  • readFromServer - a boolean value that indicates if the entitled property will be read from the server or not. For example sometimes we store a sensitive information like passwords or something like that - information that should not go to the client.

Here is an example of how to use ServerProperty annotation with complete syntax.

public class Book extends DataItem {
@ServerProperty(value = "Tags", genericClassName = "com.telerik....Tag",writeToServer=true, readFromServer=false)
private ArrayList tags;
}

Last but not least, you must map your Java classes to their corresponding Telerik Platform types. Normally, if you want a type to store information about, say, books, you will name it Books in Telerik Platform. However, it makes more sense to name your .NET class Book because it will represent a single book record. The mapping is done using the ServerType attribute.

@ServerType("Books")
public class Book extends DataItem {
...
}
Start a free trial Request a demo
Contact us: +1-888-365-2779
sales@telerik.com
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.