Altova MobileTogether Designer

The example solutions 04-EditRecords.mtd and 05-EditRecordsOnStart.mtd are examples of how to edit data offline and go online solely to save data to a database on the server.

They are located in the following (My) Documents folder: Altova\MobileTogetherDesigner10\MobileTogetherDesignerExamples\Tutorials\OfflineUsage. Open the files in MobileTogether Designer and run simulations (F5) to see how they work.

Both solutions save data to a SQLite database on the server, AddressesIndexed.sqlite, The solution 04-EditRecords.mtd is different from 05-EditRecordsOnStart.mtd in one respect only: that records from the SQLite database are not displayed in the start screen of the former solution, but are displayed in the start screen of the latter.

Description of the example solutions

The example solution 04-EditRecords.mtd (design shown in screenshot below) displays the DB data in a table and allows users to edit the data. Fields of the table are linked to the $PERSISTENT page source. This means (i) that it is the contents of $PERSISTENT that are displayed in the table, and (ii) that edits you make in the table are stored in $PERSISTENT.

When the solution 04-EditRecords.mtd starts, the table is empty (see screenshot below). This is because the table has $PERSISTENT as its page source and $PERSISTENT is empty. Note also that the $DB1 page source is empty. This is because it has been set to Load Data = Not Automatically. In the Page Sources pane, right-click $DB1 to see the value of its Load Data setting.

In the solution, the following data edits are possible:

•A new record (row) can be added to the table and the fields of the record can be edited. To add a new row, click the Plus icon located to the right of the last row (see screenshots above and below). After you add a new row, the data of the row is stored in $PERSISTENT (see screenshot below).

•In the solution, a row can be deleted by clicking the its Minus icon (see screenshot above).

•The data in $PERSISTENT can be saved to the server by clicking Save to database. For an explanation of how this works, see the section Saving edited data by using primary keys and OriginalRowSets below.

•On clicking Refresh (circled red in screenshot below), all data rows are downloaded from the server to $DB1 and copied from there to $PERSISTENT (see the actions of the OnPageRefresh event as defined in this event's tab). Any data that was present in $PERSISTENT before the refresh will be deleted. Since the rows in $PERSISTENT are displayed in the table, the table now displays all the server records. Note that the Server Access setting for $DB1 has been set to On Demand. This ensures that the server will be contacted only when a request is made to the server, such as that for reloading database data. In effect, this means that users can work offline till they need to upload data to the server.

Key settings

The key settings of the (04-EditRecords.mtd) solution are given in the following table.

At solution start, load all data for editing

When the solution 04-EditRecords.mtd is started, the table is empty because $PERSISTENT is empty. If we want to show all the server DB data in the table, we could use the following strategy, which has been used in 05-EditRecordsOnStart.mtd. To see how this has been set up, open 05-EditRecordsOnStart.mtd and see the definition of the OnPageLoad event of the solution page.

1.Since the actions we want to carry out must occur when the solution starts, we create them on the OnPageLoad event of the solution's Start page.

2.Reload $DB1 via the Reload action. This downloads all DB data from the server to $DB1 (when the solution starts).

3.Delete all the records of $PERSISTENT via the Delete Node(s) action.

4.Copy all the record nodes from $DB1 to $PERSISTENT. by using the Update Node(s) action. Once the data has been appended to the $PERSISTENT tree, it will automatically be displayed in the table. This is because the controls in the table's cells have page source links to the nodes of the $PERSISTENT page source.

Saving edited data by using primary keys and OriginalRowSets

In both 04-EditRecords.mtd and 05-EditRecordsOnStart.mtd, the setting to create an OriginalRowSet node has been set to true. This setting is switched on via a toggle command in the context menu of the page source. In both our examples, whenever the page is refreshed (via the Refresh button), the $DB1 page source is reloaded from the server and two important steps are executed: (i) an OriginalRowSet node is created in $DB1 that contains an exact deep copy of the tree's RowSet node (that is, of all the rows of the server DB), and (ii) the RowSet and OriginalRowSet nodes are copied from $DB1 to the $PERSISTENT tree. This way we know what rows were originally present in the table before editing started: edited rows are in RowSet, while original rows are in OriginalRowSet.

Now if the table is edited, that is, if new rows are added or deleted, then, in $PERSISTENT, the number of rows in RowSet and OriginalRowSet will be different. Each row is identified by a unique primary key field named ID, which may not be NULL and is automatically set to an auto-incremented integer when the row is added.

When the data is saved to the server DB, the saving mechanism is as follows:

1.$DB1 is reloaded by using the Reload action.

2.From $DB1/RowSet, those rows are deleted that have the same ID as that of rows in $PERSISTENT/OriginalRowset. This ensures that all the original rows (before editing) are deleted from $DB1/RowSet.

3.The rows of $PERSISTENT/Rowset are copied to $DB1/RowSet. with the Append Node(s) action. These are the new, the edited, and the unedited rows in $PERSISTENT/Rowset that we want to save to the server. Rows that have been deleted from the table will not be in this rowset and so will not be copied to $DB1. As a result, $DB1 will now contain only the rows that we want to save back to the server.

4.A Save action saves the data from $DB1 to the SQLite database on the server, with only modifications being saved.