1 / 36

SD1230

SD1230. Unit 9 Mobile Applications. Course Objectives. During this unit, we will cover the following course objectives: Identify the characteristics of mobile applications. Describe the differences and similarities of mobile Web and mobile applications .

milek
Télécharger la présentation

SD1230

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SD1230 Unit 9Mobile Applications

  2. Course Objectives • During this unit, we will cover the following course objectives: • Identify the characteristics of mobile applications. • Describe the differences and similarities of mobile Web and mobile applications. • Describe the process used to build, test, and distribute a mobile application.

  3. Learning Outcomes • Completing this unit should help enable you to: • Describe the role of an emulator. • Identify the characteristics of mobile applications. • Describe the tools available for each of the three major mobile development platforms. • Create a simple mobile app. • Given a website or application, identify characteristics that affect its usability on a mobile device.

  4. Mobile Web App vs. Native App Mobile Web app Native app Device fragmentation Need to build or port for each platform Product short-term revenue for developers and operators Operators or platform makers have control • Better cross-device and cross-platform support • More difficult to monetize • You have control • Consumers expect it to “just work”

  5. When to Make a Native Application • You want to charge for it • Games • Historically required for location-aware apps, but now many popular browsers are location-aware • Using the camera • Using accelerometers • Accessing the file system • Offline users

  6. When to Make a Mobile Web Application

  7. Adapting to Multiple Devices

  8. Strategies for Multiserving • You can do nothing and wait for the mobile industry to become fully homogenized. • You can try to use a progressive enhancement technique to provide fallback experiences to a number of devices. • You can target only a handful of devices that support the standards you wish to support, knowing full well that this means making your mobile experience less accessible to your intended market. • You can adapt the experience based on the class of the requesting device, making many assumptions about its capabilities. • Provide an experience specific to each requesting device.

  9. Serving Multiple Contexts is Redundant and Expensive

  10. Multiserving from a Central Data Source

  11. Strategy #1: Do Nothing • Mobile Web Initiative (MWI) • One Web – the browser is the multiserver • It assumes that your content for multiple contexts will be the same, when it usually isn’t. • It assumes that cost per kilobyte to the user is minimal or nonexistent. In other words, it assumes that the user is willing to pay for content not designed for his or her context. • It assumes that a persistent and high-speed data network will always be available. • It assumes that mobile browsers are smart and will support the same standards consistently, which isn’t the case, at least today. • It assumes that a technology-based principle should come before the needs of the user.

  12. One-Web Approach with Media Queries • Add a line of code that points to a CSS file • Requires Web browser that supports CSS3 <link media="screen and (device-width: 320px)" rel="stylesheet“ href="320styles.css" type="text/css" />

  13. Strategy #2: Progressive Enhancement

  14. Implementing Progressive Enhancement • XHTML <link media="screen" rel="stylesheet" href="desktop.css" type="text/css" /> <link media="handheld" rel="stylesheet" href="mobile.css" type="text/css" /> • Within CSS @media handheld { * { font-family: sans-serif } }

  15. Implementing Progressive Enhancement • Class C and D <link media="handheld" rel="stylesheet" href="class-c.css" type="text/css" /> • Class B <link media="screen" rel="stylesheet" href="class-b.css" type="text/css" /> • Class A <link media="only screen and (max-device-width: 480px)" rel="stylesheet“ href="class-a.css" type="text/css" />

  16. Strategy #3: Device Targeting • Use the HTTP headers information to detect the device and browser • User-Agent string • Requires a device database on the server • Mobile Browser Detection scripts

  17. Strategy #4: Full Adaptation • Most expensive option to develop or maintain • Detect device browser • Dynamically render device-optimized content • Typically required for “on-deck” applications • Can be used for “off-deck” Web applications

  18. Reasons to Use Full Adaptation • You want to deliver the best possible experience to a number of Class B or lower devices, where other strategies don’t cut it. • You want to support users outside of the United States, where higher-end devices constitute the majority. • You want to do anything highly transactional, like billing or payments for content or services, for Class B or lower devices. • You want to do SMS campaigns that terminate with a mobile website. • You have a media-rich experience, such as images, video, or audio, and need it to render properly on several devices. • You want to support several nonphone mobile devices, like GPS units, e-book readers, portable gaming consoles, and so on. • You want to support a number of different devices and contexts, either now or in the future.

  19. Device Databases • Wireless Universal Resource File (WURFL) • Open-source database of device profiles • WALL and WNG • Adaptation libraries based on WURFL • dotMobi’s Device Atlas • Test suite • Web interface to the database • Standards-based API • Volantis • Content adaptation vendor

  20. Yahoo Blueprint

  21. Netbiscuits Web Service

  22. Mobile-Aware Web Service

  23. .mobi Domain • ICANN-approved top-level domain for mobile devices • Alternative to device detection, subdomains, or directors

  24. Device Plan • Deciding what to support: • View server logs to see which devices are accessing your site. • Use demographics to determine which devices are used by your site’s target audience. • Target the most profitable devices first. • Create a test plan.

  25. Devices by Market Segment

  26. Device PlanNumber Score System Support through progressive enhancement

  27. Device PlanActual Dollar Amounts

  28. Device Testing • Test on physical devices • Often cost-prohibitive • Sometimes required Accelerometer

  29. Device Testing • Other ways to get access to a physical device • Operator store • Mobile Monday device libraries

  30. Estimating Testing Effort • Device testing takes 2 to 4 times development effort

  31. Sprint-like Testing • Test the primary devices, then release • Test secondary devices after release

  32. Test Plan • Functional tests • Based on feature list • Context tests • How does the user experience render on the device? • Does it load quickly and correctly? • Can you use the physical features of the device as intended? • Does it terminate correctly? • What happens when the device loses connection? • Does the application work when hopping from cell tower to cell tower?

  33. Test Portal

  34. Desktop Testing • Frames • Opera Small Screen view • WebKit browser • Simulators and emulators

  35. dotMobi emulator

  36. Summary • In this unit, we covered the following topics: • Mobile Web app vs. native app • Native app creation • Multiple device support • Device plans • Testing

More Related