After we’ve looked into the range of input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, there is something more you can do. If you try the snippets as is you will find them working well and in tone, but rather lacking in terms of layout. So now that you have an idea how to provide content, let’s wrap it up in some proper containers and provide navigation.

For the record, it’s only fair to say that if you run a sample with just the controls defined you still get the entire page styled. Why is that? Well you can have a look at jQuery Mobile’s “Anatomy of a page”. As it says there the layout consists of conventions, rather than requirements. Wheat this means is that you are not forced to add a header, footer, content or page for that matter. What jQuery Mobile will do is to wrap your entire HTML in the body in a DIV with the page role. That while convenient is not optimal – if you have script tags in the body the process of wrapping the content will also load them again, so it is best advised to still have a properly defined mobile ‘page’ in your HTML. This is also absolutely necessary when two or mode pages are to be delivered in a single file, and yes, that is possible, but again not recommended way of design. So yeah, conventions and not requirements, however those conventions are there for a good reason and you are better off following them. So how about Ignite UI ASP.NET MVC wrappers? Will they help here? Sure!

Mobile pages 101

Let’s start with the most basic thing – the actual page. The helpers will  offer a way of defining it that is very similar to how you would go about a Form element. That is in the sense that there are separate methods to begin a page and to end it. However, unlike the form being a set of two methods, the page being Ignite UI means it can also be initialized with a Page Model passed to the view. Here’s how a simple definition with chaining syntax goes ( logically, any options should be in the page opening) :

And as I mentioned this can be done via Page Model:

How about that back button setting up there? What could that possibly do? Well it’s related to the next otherwise not required layout element – the header. For that setting to have any meaning, you will need a header on your pages as the button will appear just there). There’s another button that you can set text (for tooltip) to but you can’t customize, and that is the close button. Page with close button? Of course, that one is present when the page is opened as a dialog. We’ll talk about how that goes later or, but keep in mind it only makes sense to set one as the close is dialogs’ replacement for the back button.

Headers are used in much the same way as pages (begin and end) and among other things can be set to fixed position:

The ‘FixedOptions’ can also set behaviors like tap (or click) to show/hide the fixed header and transition animation for showing (the default is slide).  

Linking

One thing still is escaping – how did the user get here? Well he followed a link of course. jQuery mobile provides some enhancements to those as well. Links can be in three styling modes – the native for the browser, the link styling of the theme or as a button. Note that links inside headers and footers will always be styled as buttons whether you set them to or not. Also I mentioned dialog and you can tell the framework to load something as dialog when you specify an option on the link itself:

The above will produce:

As you can see you have the option to define a relation with the destination or the link, and this is how you create interactions to open up dialogs and popups. This is a similar page opened up by the dialog link above:

You can also specify relation to be ‘back’ so you can add back buttons not just in headers but anywhere in your content. Keep in mind automatic Back button on on pages only appears if there's actual history – as in when they have been navigated to by a link. This is somewhat important to know when using multiple pages in a single document (even thought it’s not a recommended practice) as you can force loading secondary pages by entering their URL but this way jQuery Mobile won’t add those to the history. Still, there’s a very minor chance someone will be entering links by hand, but you never know. Also for back buttons it’s good to still provide a meaningful link for browser compatibility.

More?

So far you can create basic pages and provide navigation. Also at your disposal is the content element – as the documentation describes it is helpful for “providing some basic formatting and structure”. But, hey, have you noticed the simulator screenshot in the previous blog? Does it seem odd items are stretched so far out it feels they are about to be cut off by the viewport edges? That’s because as direct page content they tend to spread to the maximum width… Wrapping those in a content element is at least the easiest way to provide proper formatting as the content will squeeze them a little. Also you can set separate theme to he content this way or apply classes to add custom styling and behavior with.

The same statement that describes the content is also true for the footer. But while it is not required for automatic page functionality like back/close buttons and it also serves the structural and potentially visual separation of content, it can much like the header be fixed, which can sometimes be really useful. So for that secondary page we have above we can add something like the following:

Enhanced Layout

Now that you can properly fill those pages comes yet another potential problem. While you have been refactoring your site’s experience into mobile pages to be properly consumed on mobile devices it still is too hard to fit relevant content together into a single page? Well you don’t have to, really.

You can separate content that is not for immediate consumption or instead of swapping pages on some event show content in a popup. It’s extremely useful for a range of cases – from simple tooltip to login forms and application menus. Keep in mind the popup is available from 1.2.0 version of jQuery Mobile! Like other content containers, the popup has begin and end methods and content between them is not displayed by default. To display a popup you can set up a link (on the same page) that navigates to the popup ID and has a relation of that type and inside you can add another link as close button:

The button class can be left and right and the contents of the popup can be any HTML. As seen options include positional settings like centering over the element that was clicked (origin) or the window. You can even pass a jQuery selector to position the popup over the matched element. And the tolerance sets up how much in the minimum spacing between the popup and the edge of the window. The MVC wrapper method has 3 overloads that let you put a single common value, just for top and left or for all sides. The transition has the usual jQuery animations available and another allows (or not) for jQuery Mobile to modify the page Url and add it to the history. This means you can let your users to close popups with the back button.

Another extremely useful layout trick is to organize things within collapsible container. They come in two varieties – a standalone  Collapsible and a Collapsible Set. While pretty self-explanatory the single version consists of a header and a content block that is either visible or collapsed. You have a number of options to control themes, header state icons and their position and more. For example the default icons are plus and minus, while we can use arrows instead:

The set version is essentially an accordion – only one out of a group of blocks can be expanded at a time and current collapses automatically when the user opens another. The model is pretty much identical – you have the set that is a container for single collapsibles and it even has the same general options (icons, themes) that you can apply for all child blocks:

A nicely packed navigation

Of course, it’s always nice when you can make the web page feel more like an application and provide nice buttons instead of links. It’s also nice if those are not spread all over the page, but rather grouped. Here is where the Navigation bar comes in play – it allows you provide up to 5 (after which it wraps them in multiline..) buttons with customizable themes, icons and exclusive selection (kinda like horizontal radio group but without the form input support). This toolbar is most common in headers or footers. The control itself has a collection of items, global icon positioning an theme options. Each item has Url and text as expected:

TL;DR | Summary

In this article we’ve looked into the basic ways to create structure in your mobile applications using the Ignite UI ASP.NET MVC wrappers/helpers. In addition, we saw how linking between pages can be done with different relations and styles. Furthermore, there were the mode advanced ways to enhance experience with your app by providing interactive content with popups and collapsible content. Lastly, a more neatly organized way to build your navigation in a toolbar that also provides a nice touch of ‘native’ feel to the mobile app.

Make sure you stop by the first part for some input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, check out our Ignite UI Mobile Documentation and visit our samples you can experience on your mobile device as well! I have packed all of the described examples in a very simple ASP.NET MVC solution for you to download and try and in order to run that you will need at least a Trial version of Ignite UI for the mobile assembly, but hey it’s free, grab one from here:

And as always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!