Working with Tabs in Gyroscope 3.2 July 10, 2013

The Gyroscope user interface is mostly recognized by its tabbed view. The tab system has been greatly enhanced in Version 3.2. Gyroscope developers can now write shorter and more robust code.

Changes to the tab functions are backward compatible. The following functions can still be called in the traditional manner:


If you are new to Gyroscope development, the tab system assigns each tab an internal, unique key. This key is used to switch tab focus and close view ports. If a tab is created with an existing key, the existing tab will be switched to. This saves a redundant request to the server, making the application highly responsive.

Tab keys are also used to keep track of viewing orders, so that when you close a tab that happens to be active, the view switches to the previously active tab. The "Back" button in the iPhone portrait mode also relies on this mechanism.

Each tab has a display title, which is specified by the "title" argument. A tab title is arbitrary and can duplicate other display titles, as long as the tab key is unique. The third parameter instructs the server to pull the content for this tab. Some tab loading calls may have side effects, such as creating, updating or deleting records.

The loadfunc field offers an opportunity to supply a user-defined call back function. This is handy for focusing on an input field that's only available after the tab content is loaded, for instance. Some old versions of Gyroscope don't have this parameter. Check your tabs.js to confirm.


Parameter Changes

In the new tab system the addtab and reloadtab functions are given a few extra parameters:


In case you're unsure of your Gyroscope version, check the above function signature. If the opts parameter is there, the version is at least 3.1, which supports non-closable tabs and POST requests. Only 3.2 supports rekeying and enforces proper tab order on a mobile browser.


POST Requests

When Gyroscope was first created, the tab system was primarily used for sending simple content displaying requests. All requests were sent as GET. To circumvent the URL length limit, a separate POST request was used to send lengthy data such as a description field; only then was the tab function called. This complicated programming.

Now each request is sent as POST, the optional data parameter can be used to transmit large data fields. Before taking advantage of this change, however, double check the Gyroscope version. Otherwise the app will seem to be working while missing the POST fields.


XHR Exposure in Callback Function

Ever since the introduction of callbacks in addtab/reloadtab, it has been possible to chain tab functions. It is therefore important to intercept the server response instead of simply displaying it in the content view. This is especially the case when creating a new record and the record ID needs to be validated.

In 3.2, the XHR object that's used to send the tab request is completely accessible to the user:




Optional Display Title (reload only)

Tab reload is often used to update the view of a current tab. Calculating and updating the tab display title is inconvenient and unnecessary in such case. That's why we made the title parameter optional in the reloadtab function. If no title is supplied, the original title is kept.




"Sticky Tabs"

A Gyroscope application typically has a home screen, or a "starter" page, which is essentially an initial tab. Though every tab can be closed, shutting this "welcome tab" could be bad user experience. Now you can make this tab "sticky", or non-closeable:


Of course the tab can still be close by calling the closetab function. But the close button is not displayed so that the end user won't accidentally close this tab.


Tab Rekeying (reload only)

The following code snippet is a staple for Gyroscope developers:


Now the above synchronous code can be rewritten in the following asynchronous fashion:


The new code is about the same length, if not shorter, and works better in a number of ways.

First of all, it's not using the synchronous ajxb function. This function halts the JavaScript execution and event handling of the entire application until the server response is received. The reloadtab function, on the other hand, uses a callback so nothing is blocked during the wait.

In addition, the original Add a New Record tab is reused and re-keyed to the new tab. This is a lot smoother comparing to the previous close-and-add routine.

What if the user clicks on the "Add" button multiple times before the server response? With ajxb this wouldn't be an issue but how about reloadtab? We thought about this too, and the reloadtab function ensures that there's only one in-flight request at any time. Subsequent requests are ignored until the arrival of the first response.

So there you go, new tab features in Gyroscope 3.2. Happy coding!