Page Architectures Explained (sort of)

We are working on a doc to explain the webapp architectures that one can create with MobiOne. I’ll take a shot at providing some basic info. to stand in until the doc is available in the Learning Center.

Using the Design Center, users create optimized mobile webapps and apps consisting of 1 or more individual user interface pages, aka, screens. The Visual Designer supports creating navigation links between design screens using GotoScreen actions. Application code in the form of HTML, CSS, JavaScript and metadata is generated for the webapp using either the Run in Test Center button or when using the Project>Generate Application action.

Note: these code-generation actions apply to the active Visual Designer. Thus you should only invoke them when the initial screen of your app is selected and visible in the Design Center. Your application generated code will have only 1 subdirectory named after the mian .mob file with _www suffix, e.g., custommgmt_www subdirectory. If you generate code for any screen other than the startup or main screen you will have multiple _www subdirectories. All but the <mainscreen_www directory should be treated as tmp code and deleted to avoid confusion later in the life-cycle of your app. MobiOne will ignore these tmp directories.

See the MyCompany Tutorial for details of creating a simple 2 screen user interface.

Users may specify how the individual pages of a webapp are created using the Page Architecture property. Note the 1st page of the webapp is ALWAYS generated as an HTML5 page. The linked pages can be generated as follows:

See attachment page-arch-options.png
1) Default Page Architecture
This is the default page architecture defined in Windows menu>Settings>HTML Generation dialog. Local HTML page is the initial default value.
See attachment html-gen-setting.png

2) Local HTML page (static)
This option indicates that the HTML code for this design page is to be generated into the same file as the startup page. Then when your startup webpage file is download, the content of this type of page is included in it and stored invisibly in the DOM (see screenshot below). When the user navigates to this page, since it is already in the DOM, it is simply made visible with any page transition effects applied. The benefits of this page architecture are that local pages are quick to access since no remote page loading is required and they work great in offline apps. The downside is that your main webapp page file can grow to be large and may impact startup performance as it contains the content of other Local HTML pages. Also development complexity may be increased if your app needs to fetch remote data that must be manually manipulated and bound into the user interface on the device using JavaScript rather than traditional server side technologies such as PHP or Java Server Pages (JSP).

See attachment myco-src-image.png

3) Remote HTML page (AJAX)
4) Remote ASP page (AJAX)
5) Remote JSP page (AJAX)
6) Remote PHP page (AJAX)
A Remote <type> page (AJAX) is a fragment of a web page containing the user interface content in a form that can be dynamically downloaded and merged into the DOM of your webapp. At this time these page architectures are basically the same less the file extension of the web content page generated. For example if your design page is named Contacts.mobi and the Remote PHP page architecture is chosen then when code is generated the user interface content for the design page will be in a file named Contacts.php. The benefits of Remote pages are that they are light weight and can be processed on the server using technologies such as PHP and ASP. Unlike Local (static) pages these pages are not loaded from the remote server into the DOM until they are needed by the user interface. The downside of such pages is that your device must have an internet connection in order to load the page at the time it is requested. Also other than HTML remote pages, scripted pages must be uploaded to a web server supporting the specific scripting language before they can be tested in the Test Center. The Test Center makes some approximation of some scripting tags but it can only do so much (which is very limited).

Additional notes and suggestions:
1) Complete your user interface design tasks before you begin customizing the generated code. This is because the Visual Designer does not recognize modification to the generated webapp code.

2) CSS files for remote pages are loaded by the initial HTML file. We plan to make it more modular in the near future.