pg电子游艺麻将怎么玩

書名： Building Mobile Applications Using Kendo UI Mobile and ASP.NET Web API
作者名： Nishanth Nair Ragini Kumbhat Bhandari
本章字數(shù)： 2000字
更新時間： 2021-08-06 16:59:07

A real-world mobile app – Movie Tickets

Now let's get to the real deal and develop a fully functional mobile app using Kendo UI Mobile and see how it can be integrated with a RESTful service (ASP.NET Web API in our case which will be introduced in Chapter 3, Service Layer with ASP.NET Web API).

Before we start building our Movie Tickets application, let's quickly go through the screens and functionalities that will be implemented in the app at a high-level:

User can search for a particular movie and then select a theater for a show.
Once user selects a show time, application asks the user for number of tickets and displays the rate. The total amount will be automatically updated once the number of tickets is entered.
After booking, user can see completed bookings in the booking history view.
In the user account screen, user can update name, e-mail ID, address, and so on.
In the trailers tab, video trailers are displayed which can be navigated using the swipe gesture.

The Home screen

Now let's build the home screen of our mobile application using the single screen application that we've developed. We will add a tab strip in the footer of the screen, so that the contents in the middle can scroll and the tab strip remains static. In the tab strip we will add tabs such as Movies, Trailers, My Account, and About. We will then create views for these screens and navigate to the respective view when the link on the tab strip is clicked.

The completed Movie Tickets application will look like this:

You can see the booking and trailers page in the following screenshot:

The TabStrip widget

The Kendo UI Mobile framework ships with lots of useful widgets which helps to build great looking apps quickly. We will take a quick look at the TabStrip widget here, as it is one of the most important widgets in the framework, and we will explore other widgets in Chapter 5, Exploring Mobile Widgets in detail.

The TabStrip widget is used to display a group of navigation buttons usually in a layout footer element. On the click of the navigation buttons, respective views will be loaded.

When navigated to another view, it updates the TabStrip's currently selected tab, based on the current view's URL. The TabStrip comes with built-in tab icons which can be used by setting the data-icon attribute to the anchor element or we can add other images by adding an img tag inside the anchor element.

Here is the list of all built-in icons provide by Kendo:

Let's open up the view that we created before and add the following code to the footer after replacing the current footer contents:

<footer data-role="footer">
  <div data-role="tabstrip">
    <a href="#mt-home-main-view">
      <img src="images/movies.ico"
      height="40" width="40" /><br />
      Movies
    </a>

    <a href="#mt-about-view" data-icon="about">
      <br />
      About
    </a>
  </div>
</footer>

Now copy the images folder from the source code folder of the book to your workspace's root so that all the images we are using will be visible to you.

Here we have used a custom icon and a built-in icon as the navigation buttons. The href attribute has the values of view IDs prepended with #. This tells the application that when this button is clicked, we need to navigate to a particular view.

Navigation between views in the same file is the basic level of navigation and soon we will see how navigation to external URLs, remote views (views in external files), and data transfer in query string can be done.

Clicking on the Movies navigation button will take you to the home page of the app and a click on the About icon will take you to the About view which we will add as shown just after the closing div of the first view:

<!-- about view -->
<div data-role="view" id="mt-about-view" data-title="About" data-layout="mt-main-layout">
  <div style="padding: 15px">
    This is a sample application developed for the book            
    Building Mobile Applications using Kendo UI Mobile and ASP.NET Web API
  </div>
</div>

The code is pretty self-explanatory. A new view with the same layout is added for the About view in the same file.

The two screens will look like this when viewed using Ripple Emulator or an iPhone:

Transitions

Kendo offers different transition effects while navigating through views and if you need a single type of transition across the application, we can configure it in the app initialization script as shown here:

var application = new kendo.mobile.Application(document.body, {
  transition: 'fade'
});

Different transition effects supported by Kendo UI Mobile are:

zoom: Current view fades out and the new view along with the header and footer zooms from the center of the screen.
slide: This is the default transition. Transition direction can be specified by using slide :(direction).Value of direction parameter can be left or right. Current view slides to the direction specified and the new view takes its place sliding in. If no direction parameter is specified, left is taken as the default direction parameter.
overlay: The new view slides on top of the current view without transitioning the header and footer. The overlay:(direction) parameter can be used to specify transition direction and possible values are left, right, up and down. For example, transition: 'overlay:up'.
fade: The new view along with its header and footer content fades in on the top of the current view content.

The parameter reverse can be specified along with the transition effect to play the transition in reverse. If we specify slide:right reverse in a view and try to navigate to the previous view, the previous view will slide in from the left.

Navigation

In the previous example, we have seen how navigation happens between local views (views within the same file) using the href attribute in the anchor tag. Now let's explore the navigation framework of Kendo UI Mobile in detail.

The Remote view

To keep all the views of an application within the same physical file is not practical while developing a big application with lots of screens. Almost always, developers will want to have each screen/module in its own HTML file, which will help in code maintenance and ease of development when a team of programmers are working on the application.

Handling this scenario is straightforward in Kendo UI Mobile. If we need to load a remote/external view, it is only required to specify the filename of the external view for navigation instead of the view's ID. When navigated to a remote view, Kendo UI Mobile loads the view using an Ajax call, caches the contents of the file, and displays the first view encountered in the file. If there are additional views in the file, they will be appended to the Document Object Model (DOM), but will not be initialized or displayed. Any inline style/script elements and mobile layout definitions will also be evaluated and appended to the application.

To see this in action, let's create a file called Trailers.html in the root directory with the following contents:

<div data-role="view" data-title="Trailers" data-layout="mt-main-layout" id="mt-trailers-view">

</div>

As you can see, there is no need to add the Kendo reference files as these are already referred from the index.html file.

Now that we have an external view, let's navigate to this external view using our TabStrip widget. Open up index.html and a new navigation element between the Search and Movies buttons appears, as shown in the following code snippet:

<a href="Trailers.html">
  <img src="images/trailers.ico" height="40" width="40" /><br />
  Trailers
</a>

Now reload index.html in your emulator or on your mobile device and click on the Trailers icon and you can see that the view is loaded just like our local view:

When a remote view is loaded, styles/scripts from the <head> element, if any, will not be evaluated.

Tip

There could be use cases where you need to navigate to an external URL and for this, just add the data-rel="external" attribute to the navigation element. Keep in mind that this will load the external URL on the browser by unloading your app and you will be at the mercy of your device or the browser's back button to return to your application.

The Back button

The back button is one of the most widely used UI elements of a mobile application and is typically added to the top navigation bar. Kendo UI Mobile provides us with a back button widget which is very easy to use; just add data-role="backbutton" on an anchor tag and our back button is ready! Kendo UI Mobile handles back page navigation automatically, which is in-built with the back button widget.

Adding the markup for the back button to our application's NavBar widget will display the back button on the top-left corner of all the three views we have built till now:

<header data-role="header">
  <div data-role="navbar">
    <a data-align="left" data-role="backbutton">Back</a>
    <span data-role="view-title">Movie Tickets</span>
  </div>
</header>

Now we have a problem to fix. The back button is displayed in all the views including the home view too, which is not required. Some mobile development frameworks such as jQuery Mobile automatically hide the back button on home screens, but in Kendo UI Mobile, we will have to handle it ourselves.

Again, this is very straightforward to implement. We need to update the home view definition and add a CSS class:

<div data-role="view" id="mt-home-main-view" data-show="homeViewInit" data-layout="mt-main-layout" class="no-backbutton">
  Home Page View
</div>

Let's add this CSS snippet to the <head> tag:

<style>
  .no-backbutton .km-back { visibility: hidden; }    
</style>

Now if we run the application, we can see that the back button is not visible on the home page. The rendered back button will have a CSS class km-back added to it automatically by Kendo UI Mobile. The previous CSS snippet will hide the elements with the km-back CSS class inside the element with the CSS class no-backbutton, which is our home view.

Looking into the rendered HTML

One interesting fact to note here is that the layout header is rendered inside the view div and the rest of the contents in the view div are displayed after the header, inside the content element, and after that the footer elements are appended.

The rendered HTML can be investigated using Chrome/Safari developer tools:

View loading and HTML element IDs

Now that we are comfortable creating multiple views and navigating to each other, it is important to understand how the views are loaded into the DOM, displayed, and how it is related to the HTML element IDs in views.

Let's consider the following navigation scenario in our sample application:

The user loads the application, views the home page, navigates to Trailers screen and then navigates back to the home page.

This is what happens in the DOM when the user does the earlier mentioned navigation:

Layout and view for the home page is loaded.
When the user navigates to the Trailers view, the view for the home page is made invisible using style="z-index: 0; display: none;". Now the Trailers screen's view is loaded into the DOM and made visible. Then z-index of the view is set to 1.
Now when the user navigates to the Home screen, the view of the Trailers screen is made invisible and the view of the Home screen is made visible and z-index is set to 1.

The important point to be noted is that once a view is loaded into the DOM, it is never removed; it's just made visible and invisible every time the user visits the view.

Let's inspect the DOM of our application after the user does the earlier mentioned navigation:

We can see that the Home screen view's z-index is set to 1, the About screen view is made invisible (this view is loaded as it is defined in index.html) and the Trailers view is made invisible with z-index set to 0.

Tip

Since the views, once initialized, always remain in the DOM and are just made visible and invisible, programmers must be careful with naming the HTML elements within views. If two views have elements with the same ID, and if any client-side code tries to access one of these elements using the same ID, it may cause unintended consequences. So it's advised to have proper naming convention for IDs, so that a conflict may not arise when multiple programmers are working on the code base. Prefixing all the element IDs with three or four characters of its view's name is one way of staying out of trouble!

官术网_书友最值得收藏!

Building Mobile Applications Using Kendo UI Mobile and ASP.NET Web API