uniform messages to the user and standard functions

Updated: November 8, 2016, Rolf Eckertz
The layout of the footer must be changed dynamically in same applications, a test with table is very promising, test in the browser are passed, tests with app mode have to be done.
Updated: October 28, 2016, Rolf Eckertz
Check if function exists and layout of navbar

There are two kinds of messages:

• messages that are a reaction to a user-input
• messages that are a reaction to things going on in the background

Messages are shown in the footer.area. In some cases the footer area also has to provide special navigation buttons for paging or scrolling, when swiping and mouse on scrollbar are not feasible.

That is why the footer area is constructed as follows:

• first line of the footer
• last message
• click on this message navigates to the display of the message buffer
• Problem:
• when used as App with Emulator of Intel XDK the formatting is not as expected, the text is presented in the same line as the buttons
• so: on Smartphones the text is NOT presented in the footer, an alternative is checked, my be a temporary popup will dd
• second line of the footer, button area with five buttons
• outer left button: navigate back 
• optional depending on application
• click calls standard-function-name "goprevious"
• inner left button: status indication server-connection
• color green - connected
• color red - connection got lost
• color yellow - connection is active (AJAX is executed)
• click calls display of system values
• middle button: number of messages
• counter
• in the future additional counters may be provided
• click calls display of messages in separate page
• inner right button: refresh button
• click neutralizes the input and makes no update (optional depending on application)
• outer right button: navigate forward 
• optional depending on application
• click calls standard-function-name "gonext"

Technical implementation:

• uihelper.putMessage(text[, severity]) - the central function
• put a message to the message queue (userMessages = []) with message and severity
• display the message in the activePage
• a maximum of 100 messages are cached, no persistence
• the message display area in the footer of the activePage is allocated, if it not already there
• uihelper.showAllMessages() - show all Messages, maximum 100, activated on click to menue point
• uihelper.refreshMessage() - show last Message on new page after change and transition
• function is called when new page is shown ("beforechange" function)
• function builds the contents of the footer
• the standard-function-names are checked if they exist on the page, if yes, then the navigation buttons are shown and the "refesh" button respectively - if no configuration parameters were passes
• the message-queue is stored in uihelper userMessages, access only via api 

Functions have to be checked dynamically, see http://stackoverflow.com/questions/8592047/check-if-a-function-exists-with-its-name-in-a-string

if (typeof window[strOfFunction] === "function") {
    // celebrate
    //window[strOfFunction](); //To call the function dynamically!
}

and

if ( eval("typeof stringFunction === 'function'") ){ /*whatever*/ }

There were several problems in the layout of the footer. Finally the following solution was found:

• for the browser
• the footer has a text-line and a navbar with five buttons
• the layout has a scrollbar beside header, content and footer, it the content needs it
• for an app with Intel XDK
• the footer cannot have a text-line, because it is presented beside the navbar and not above the navbar
• the five buttons in the navbar must be calculated in width with px and assigned to .ui-block-a to .ui-block-e, then the buttons have equal size and cover the whole width of the footer
• the scrollbar is presented aside of the content, it does not show beside header and footer

        if (appMode && appMode === true) {

            $("#" + actPageId + "navbar").navbar();

            var wnb = $(actFooter).width();

            var wne = (wnb / 5).toFixed() - 3;

            $("#" + actPageId + "navbar  .ui-block-a").width(wne + "px");

            $("#" + actPageId + "navbar  .ui-block-b").width(wne + "px");

            $("#" + actPageId + "navbar  .ui-block-c").width(wne + "px");

            $("#" + actPageId + "navbar  .ui-block-d").width(wne + "px");

            $("#" + actPageId + "navbar  .ui-block-e").width(wne + "px");

        } else {

            $("#" + actPageId + "navbar").navbar();

        }

The code has the following points:

• appMode is set in the application, if true it's app with Intel XDK,  if false it's node.js and browser
• actPageId is the string with the id of the activePage
• "navbar" is the suffix for the id of the navbar

The click-behaviour was strange: when you click in an empty area of the content, where no click-event is defined, then the header or the footer of both hide and show. This behavior makes sense when you want to show pictures fullscreen. This behaviour is prevented by global configuration:

$.mobile.toolbar.prototype.options.updatePagePadding = false;

   $.mobile.toolbar.prototype.options.hideDuringFocus = "";

   $.mobile.toolbar.prototype.options.tapToggle = false;


uihelper.refreshMessage (link, toPage) is only called by nta1010login and the central "controller" logic which is more a central support for navigation. refreshMessage is executed before the new pages are activated by the xxx999yyy.beforechange function that a standard page has to provide. That means:

1. the new page is prepared to show and set activePage automatically by the navigation
2. the refreshMessage is envoked generically and it changes the footer of the page
3. then the page-specific beforechange function is envoked to prepare the contents of the page
4. and this gives the opportunity to add specific information to the page in beforechange - and the layout of the content can be adapted accordingly