Designing Application Data

Let us review the application data structure that enables the functions demonstrated in the previous topic.

This topic describes the data structure used for Kii Balance. Note that it will not always bring the best result for your mobile app. Kii recommends reviewing the optimization techniques described in Optimizing Application Design at the end of this tutorial before you design your mobile app.

Designing data for Kii Balance

This is an example of a bucket and KiiObjects used with Kii Balance.

Income and expense data is stored in a bucket in the user scope. The name of the bucket is balance_book.

The other users cannot access the stored data because the data is in the user scope. To access the data, login as the user who owns the scope is required. This requirement prevents unauthorized read or write access.

One KiiObject corresponds to one income or expense entry.

{
  "amount": 150000,
  "name": "Salary",
  "type": 1
}

Each field stores the following value.

  • amount

    100 times the amount of income or expense. For example, this field stores 150000 for $1500.00. For the reason, see Avoiding real numbers.

    The amount field stores a positive value even for an expense entry because the type field below is used to distinguish income and expense entries.

  • name

    A string that describes the income or expense.

    If the user enters nothing, "Income" or "Expense" is set according to the entry type (income or expense).

  • type

    1 for income and 2 for expense.

Aside from the above fields, Kii Cloud has several predefined fields such as those for the KiiObject ID (_id), creation time (_created), and modification time (_modified). Kii Balance displays the creation time in the data listing screen.

With certain types of the Kii Cloud SDKs, these predefined field values are obtained through dedicated APIs such as the getCreatedDate() method. The developer portal displays the direct name of each predefined field.

Avoiding real numbers

Kii Cloud can store a real number as a value. However, you might want to avoid real numbers in certain circumstances such as when designing the amount field.

  • Generally, floating-point arithmetic is not suitable for the balance calculation because it will cause inaccurate calculation.

  • Real numbers stored in KiiObjects cannot be correctly queried because real numbers whose fractional part is zero are treated as integers. For example, 1.0 will be indexed as an integer 1 while 1.1 will be indexed as a real number 1.1. You cannot get expected results because the difference between the different types of values will not be correctly evaluated.

In order to avoid these issues, Kii Balance multiplies a value in dollars with 100 and stores the value in cents in a KiiObjects. Note that, however, Kii Balance does not query KiiObjects with the amount field.

It is often appropriate to convert field values to integers when designing data for actual applications. Especially, it is essential if data is queried with real numbers.

Identifying KiiObjects

Kii Balance uses KiiObject IDs for internal processing.

KiiObject IDs are used to uniquely identify KiiObjects within a bucket. You can let Kii Cloud automatically assign IDs or specify them in the mobile app. When you design data, assume KiiObject IDs are unique only within a bucket, even though Kii Cloud assigns UUIDs and there is little possibility of conflicts.

By the way, Hello Kii displays KiiObject URIs in the ListView in the data listing screen.

A KiiObject URI contains information identifying the bucket for the KiiObject as well as the KiiObject ID. Therefore, it uniquely identifies the KiiObject within an application. However, a KiiObject URI is a concept specific to the Kii Cloud SDKs and you cannot use it in the REST API.

Other objects such as a user can be also represented by their ID and URI. For more information, access the link in the learn more section below.

Ensuring data consistency

Notice that Kii Balance does not store the balance in a KiiObject. It calculates and displays the balance from all the retrieved KiiObjects.

It is difficult to keep the consistency of summary data of other records like a total value and such design can cause inconsistency. For more information, see Optimizing Application Design at the end of this tutorial.

What's next?

This is the end of the overview section. Let us review the mobile apps in detail.

Go to Android Mobile App for Android.

Go to iOS Mobile App for iOS.

If you want to learn more...

  • For the data structure of Hello Kii, see the topic for implementing the data listing screen in Hello Kii for Android and Hello Kii for iOS.
  • For more information about the query feature and design considerations, see the topics for querying KiiObjects for Android and iOS.
  • For more information about object URIs and IDs, see "Object ID and URI" (Android, iOS, JavaScript).