Titanium Mobile Ipad Master Detail view

It was been very easy to use Titanium Mobile to implement Master Detail view on iPad Apps.

In computer user interface design, a master–detail interface displays a master list and the details for the currently selected item. A master area can be a form, list or tree of items, and a detail area can be a form, list or tree of items typically placed either below or next to the master area. Selecting an item from the master list causes the details of that item to be populated in the detail area.

Obviously, the master-detail interface shown in iPad is the master area located at left and detail area located at right. When the functions displays on iPhone, because of the smaller screen, master view takes up full width, and then a detail item clicked, the detail view will be opened as a new window view.

The key idea to implement in Titanium Mobile concept is that:

On iPhone, we mostly creating our master view, likely a tableview, and attach with a master window (masterWindow.add(tableView)). When click into detail item, we create new item window and then open using tab controller (Ti.currentTab.open(itemWindow)). So that when user can click “Back” button from the tab bar to go back to previous view and click to open another detail view.

On iPad, after we creating our widget, we will attach the widget to a View object, which attach to the main window object (masterView = Ti.UI.createView(); window.add(masterView)). We create another detailView and attach to the main window object (detailView = Ti.UI.createView(); window.add(detailView)). We set the width of the masterView as a certain width constant, and then we adjust detailView.left attribute to the width constant, to make it stand at the right.

On iPad, to handle orientation changes, we need to also adjust the detailView.left attribute and its width in order to fits to the screen after orientation changes. The key code here:

if(Ti.Platform.osname == 'ipad') {
  descArea.width = Ti.Platform.displayCaps.platformWidth - IPAD_DOUBLEVIEW_WIDTH;
  Ti.Gesture.addEventListener('orientationchange', function(e) {
   descArea.width = Ti.Platform.displayCaps.platformWidth - IPAD_DOUBLEVIEW_WIDTH;
  });
}

Attached the example screenshots that I capture from the demo apps I implement the master-detail view on iPad using Titanium Mobile.

20140412-180654.jpg

20140412-180715.jpg

HTTP Request Gateway Timeout in Linode instances

Recently I faced HTTP request timeout in one of my Linode instances, and this post will illustrate how I overcome it.

OK, to the last, this is not Linode issues, but my setting issues.

First, this is a Node JS Express System to generate report. One HTTP request came in, a backend quite long running process (over 30 seconds) is running to generate the report and return the result, and it faced HTTP request gateway timeout.

The first thing I do is to add in one Express middleware, to explicitly set the request connection timeout in every connection.


var requestTimeout=120000;
app.use(function(req, res, next) {
req.connection.setTimeout(requestTimeout);
next();
});

This code add an explicit request timeout at 120 seconds for each HTTP request to Node.JS Express system.

But this still not solving the issues, the gateway timeout still happening.

After googling, what I found this issues on Linode other people facing is related to Nginx. Then I just realized that my application frontend is using Haproxy. I quickly find the Haproxy configuration file, and modified the following line


backend domain_reporting_backend
mode http
option forwardfor
timeout server 120000
timeout connect 4000

I changed timeout server value as 120000, and restart Haproxy service. Then the request gateway timeout is gone.

The conclusion is, Linode is not putting on the request timeout limit to applications hosted on it, is not like Heroku explicitly putting 30 seconds timeout limit, which if your HTTP requests last over 30 seconds, Heroku will hang up your request and your browser will see this gateway timeout error.