MyMobileWeb Certification Part III
Upcoming SlideShare
Loading in...5
×
 

MyMobileWeb Certification Part III

on

  • 1,418 views

Advanced MyMobileWeb

Advanced MyMobileWeb
http://mymobileweb.morfeo-project.org/

Statistics

Views

Total Views
1,418
Views on SlideShare
1,417
Embed Views
1

Actions

Likes
2
Downloads
23
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MyMobileWeb Certification Part III MyMobileWeb Certification Part III Presentation Transcript

  • MyMobileWeb “Authoring adaptive Mobile Web Applications with MyMobileWeb” FIT-350405-2007-1 FIT-350401-2006-2
  • Part III Advanced MyMobileWeb
  • Contents
    • Exploiting the Delivery Context
      • Device Description Repositories
      • DDR Simple API
      • DevInfo Simple API
      • The MyMobileWeb DDR REST Service
      • Device Clustering
      • Convenience Functions for the Delivery Context
    • Internationalization
    • Media Sets and Content Selection
    • The Mobile Web Client Runtime
  • Device Description Repositories
    • In the desktop Delivery Context, the number of different Properties that affect the usability is limited but in mobile Delivery Context this number is higher and affect the usability of the resulting content
    • Historically, it has been difficult or impossible to upgrade Web browser software on mobile devices or to add support for features not present in the Web browser originally shipped with de device
    • DDRs have become essential components of development of content targeted at the mobile Delivery Context
    • Screen size, markup language support or image format support information is stored in “ Device Description Repositories ” (DDRs)
  • DDR Simple API (I)
    • Minimal API for retrieving device properties needed for content and application adaptation.
      • http://www.w3.org/TR/DDR-Simple-API/
    • Promote the development of Web content that adapts to its Delivery Context.
    • From the point of view of the DDR Simple API
      • Aspect: represents a category of hardware or software that participates in delivering a Web experience.
      • Property : characteristic of an aspect that can affect the Web experience.
      • Vocabulary: set of properties and the aspects with which the properties are associated
  • DDR Simple API (II)
    • Interfaces :
      • Evidence : information to determine the Delivery Context.
      • PropertyName : the name of a Property together with its namespace.
      • PropertyRef : the name of a Property together with its Aspect together with the namespace they are in.
      • PropertyValue : models a PropertyRef together with its value.
      • PropertyValues : a set of PropertyValues.
      • Service : the core of the DDR Simple API .
      • ServiceFactory : factory for instantiating Service with the supplied default namespace and configuration.
      • Several exceptions together with its codes ( DDRException , SystemException ,…)
  • DDR Simple API (III)
  • DDR Core Vocabulary
    • Essential vocabulary of properties for adaptation in the Mobile Web environment
      • http://www.w3.org/TR/2008/NOTE-ddr-core-vocabulary-20080414/
      • Not intended to represent an exhaustive set of properties for content adaptation
      • DDR Implementations might require additional properties and vocabularies
    • This vocabulary defines two aspects:
      • device : apparatus through which user can interact with de Web (default aspect)
      • webBrowser : a User Agent for Web pages
    • Properties: vendor, model, version, displayWidth, inputDevices , …
  • DevInfo Simple API
    • Early implementation of W3C’s DDR Simple API Specification
    • The implementation is based on WURFL and UAProf
    • Supported vocabularies :
      • W3C’s Core Vocabulary
      • MyMobileWeb’s Vocabulary (used by MyMobileWeb to adapt content and applications)
      • WURFL Vocabulary
    • It is flexible enough to incorporate other data sources if available (e.g. DeviceAtlas)
    • MyMobileWeb is integrated with this API implementation
      • The first open source adaptation tool that use this new API
    • User Manual:
      • http://forge.morfeo-project.org/wiki_en/index.php/DDR-RI_User_Manual_1.1
  • Architecture Overview
  • Vocabulary Descriptors
  • Vocabulary Sources
  • Vocabulary Mappings
  • DDR REST Service
    • Available a REST Service to access to DDR Repositories
      • So thirds can know dynamically properties values
        • E.g. from Javascript code
    • The REST Service is consisted of
      • Meta Service
        • It lists the combination of all known Properties and Aspects in all Vocabularies, and furthermore it provides the data type and default Aspect for each property
      • Query Service
        • It provides the property values passed as parameter property, aspect and vocabulary
    • MORFEO provides the following service:
      • http://195.235.93.83:8081/DDRService
    http://forge.morfeo-project.org/wiki_en/index.php/DDR_REST_Service
  • Meta Service
    • URI Meta Service: http://195.235.93.83:8081/DDRService/LIST
    • The format of interchange can be JSON or XML
      • View syntax: http://forge.morfeo-project.org/wiki_en/index.php/DDR_REST_Service#Meta_Service
      • If the client supports JSON (' application/json ' in Accept HTTP Header), the Meta Service will send a JSON object as response
  • Query Service
    • URI Query Service: http://195.235.93.83:8081/DDRService/GET
      • The request parameter is called request
    • The format of interchange can be JSON or XML
      • View syntax: http://forge.morfeo-project.org/wiki_en/index.php/DDR_REST_Service#Query_Service
  • DDR REST Service Installation
    • Developers can install their own DDR REST Service
      • Download from: http://forge.morfeo-project.org/frs/download.php/521/DevInfo-Simple-1.1.tar.gz
      • Uncompress the tar.gz
      • Copy the DDR Service application in your server
      • Configure the Installation_Path property ( web.xml )
      • If you want use WURFL as data source you have to append to JVM parameters ' -Xms512m -Xmx512m '
    http://forge.morfeo-project.org/wiki_en/index.php/DDR_REST_Service#Install_your_own_DDR_REST_Service
  • MyMobileWeb - DevInfo Integration
    • MyMobileWeb provides two ways to access to Device Description Repositories
      • Local DDR
        • Embedded DevInfo Simple API (previous MyMobileWeb versions)
      • Remote DDR (DevInfo Simple API Connector - Based)
        • Platform retrieves property values asking to the DDR REST Service
    • The DevInfo Simple Connector Library is licensed under LGPL 3.0 and the DevInfo Simple API is licensed under GPL 2
      • The LGPL does not propagate itself in the same way that the GPL does so if you need a commercial development you should user a remote DDR option
  • Local DDR - Architecture
  • Local DDR - Configuration
    • If you choose the local DDR option you should download the current DevInfo Simple API RI and copy the rest of libraries and configuration/descriptor files in your MyMobileWeb application
      • Libraries
        • DevInfo-Simple-1.1/build/*.jar (except devinfo-simple-connector-1.1.jar )
        • DevInfo-Simple-1.1/lib/*.jar (except backport-util-concurrent-3.0.jar & ehcache-1.5.0.jar )
      • Configuration and descriptor files
        • DevInfo-Simple-1.1/resources/**/*
  • Remote DDR - Architecture
  • Remote DDR - Configuration
    • MyMobileWeb uses this option by default so distributes all needed libraries and configuration files
      • Property data: absolute path to resources (ehcache configuration and device clustering)
      • Property url: remote DDR URI
  • Device Clustering (I)
    • DevInfo Simple API provides the device grouping proposes in the following W3C Working Draft
      • http://www.w3.org/TR/2008/WD-dd-structures-20081205/
    • The majority of handsets share common characteristics and can be grouped into families
      • For example, all the devices made by a manufacturer or all the devices that provide certain functionalities
    • Device Grouping is useful as it provides a higher level of abstraction avoiding to work with specific device instances or models
      • This working draft proposes an XML format, a syntax for group expressions based on boolean conditions over the properties
  • Device Clustering (II)
    • MyMobileWeb describes a set of predefined device groups or families in the devinfo/device_groups_1.xml file
      • Developers can add their groups in devinfo/device_groups.xml
  • Delivery Context Management APIs
    • Device (DDR Simple API Wrapper)
      • getPropertyValues()
        • Returns all property values
      • getCapabilityValue (String property)
        • Returns the value of the property for the caller device (only for DDR Core & MyMobileWeb Vocabularies)
      • getCapabilityGroupValues (String property)
        • Returns the value of the enumerated property for the caller device (only for DDR Core & MyMobileWeb Vocabularies)
      • belongsTo (String family)
        • Returns true if the device belongs to the device passed as parameter
  • Convenience Functions – Java API
    • DeliveryContextFunctions is an utility class provides access to properties of DC
      • deviceWidth(Context context)
        • Physical width of the display associated with the device as a integer number
      • deviceHeight(Context context)
        • Physical height of the display associated with the device as a integer number
      • width(Context context)
        • Usable width of the display associated with the device as a integer number
      • height(Context context)
        • Usable height of the display associated with the device as a integer number
      • charactersColumns(Context context)
        • Number of columns
      • charactersRows(Context context)
        • Number of rows
      • currentOrientation(Context context)
        • Current orientation (0, 90, -90, 180) according to default orientation
      • currentPosition(Context context)
        • Current position as a string
          • Eg: "40.5143,-3.6637", latitude = '40.5143' and longitude = '-3.6637'
      • colors(Context context)
        • Number of colors
  • Convenience Functions – E.L (I)
    • Invoking convenience functions from authoring language
    • Asking to the DDR Service from authoring language
      • namespace:propertyValue (String property, String localAspectName)
        • Value of a specific property in the aspect and vocabulary specified by namespace and localAspectName respectively
      • namespace:propertyValue (String property)
        • Value of a specific property in its default aspect in the vocabulary specified by namespace
      • propertyValue (String property, String localAspectName)
        • Value of a specific property in the aspect specified by localAspectName (by default vocabulary, xmlns="")
      • propertyValue (String property)
        • Value of a specific property in its default aspect (default vocabulary, xmlns="")
    http://forge.morfeo-project.org/wiki_en/index.php/EL_Functions_(DDR_%26_Convenience_functions)
  • Convenience Functions – E.L (II)
    • Examples
    http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_Convenience_Functions_DC
  • Internationalization
    • Two concepts are handled
      • Literal . It is a "tag" information that appears in a presentation and that can be formed by more than one word
        • Examples: “Type of Company", "Enter", "Search"
      • Message . It is a sentence with subject and predicate used to indicate something to the user.
        • Usually the sentence is parameterized
          • Example: "We have found {0} products“
        • The messages have a type
          • Information, Warning, Error, Question, ....
        • They appear in presentations of the pseudo-OP 'Messages‘
        • The platform solves the multilanguage
    • The platform handles the internationalization for both: literal and messages
  • Internationalization - Literals
    • The platform makes possible to develop applications that are multilanguage “by definition”
    • Traditionally: An application designed for a single language, requires an effort of "adaptation" when it is translated into several languages
      • All views should be modified to incorporate a indirection mechanism for resolving literals
      • Unnatural
    • It is possible to do things in other way
      • Each developer in their mother tongue
      • The multilanguage is transparent to developers
      • The tools of the platform, if the application is decided to deploy in several languages, are responsible for extracting the literal and outsourcing, by language, in XML files, which included translations
      • The platform runtime will make the translation at runtime
      • The literal in the mother tongue programming is the key translation
  • Internationalization - Literals - Tools
    • Literal Extractor
      • Takes all presentations of an application and extracts the literals, leaving them in translation XML files, the same number as languages specified.
      • The translations for the language in which was development are left in place (they are the identity)
      • For all other languages they are leave prepared for sending to the translation department
      • It is managed the cleanup, updates, etc.
    • There are application literal and platform literal
      • Next, Previous, Select
  • Internationalization -Literals -Redefinition
    • Using the same translation mechanism we can redefine literals for different families of devices
    • Example: a literal too long destroying the layout in a terminal or family of terminals
    • Redefinition Mechanism
      • A new translation will be created and it will be applied in runtime when a user connects with a terminal or family of devices that matches the specified
  • Internationalization – Literals – Example
    • Hierarchy of multilanguage literals files
    AppName_literals_en_US.xml AppName_literals_es_ES.xml
  • Internationalization - Messages
    • Each message has an identifier, a type and the text message
    • It supports variable substitution involving both parameters 'local', and context variables (specified by EL)
    • Example
      • "The user ${ _MYMW_LOGIN} has {0} associated clients"
        • {_MYMW_LOGIN} refers to a context variable and {0} refers to a local parameter
    • The messages are displayed requesting the execution of an action showMessage in the flow
    • There are messages of the own application and messages of the platform
      • Example: Error messages for automated validations
  • Internationalization-Messages-Example
    • Hierarchy of multilanguage messages files
  • Internationalization - Configuration
    • Default language and the available languages
    • Language identifier: <LanguageCode>_<CountryCode> (ISO)
    • Literals directory configuration ( MyMobileWeb.Global.xml )
    • Messages directory configuration ( MyMobileWeb.Global.xml )
    • XML files should have this suffix:
      • < LanguageCode>_<CountryCode>.xml (ISO)
  • Internationalization - Runtime
    • Each user has in its session a variable that indicates the language code
    • You can specify the language of a user in the object that represents the user's profile
    • For multilanguage portals provides a language changeover operation using the parameter _MYMW_LANG
    • The language of the user is stored in a cookie
    • In running time there are two components
      • MessagesManager
        • Given a message ID it solves for the user's language and replaces the variables
        • If it does not find the identifier the result is the identifier itself
      • LiteralManager
        • Given a literal it translates to the user language
        • If it does not find a translation the result is the literal itself
    http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_Internationalization
  • Media Sets & Content Selection (I)
    • There are resources in applications, typically images, videos or audios, which rely heavily on the capabilities of devices
    • To meet the requirement of displaying or supporting the most appropriate resource for each terminal, it is handled the concept of abstract identifier of resource which has different instances
      • Example: a ‘home’ resource, which it is available in jpg, gif and wbmp and with different sizes.
    • It is responsibility of the developer provides resources for each of these instances, so MyMobileWeb can send the best resort to each terminal
  • Media Sets & Content Selection (II)
    • Relative paths of media resources are configured in MyMobileWeb.Global.xml file
      • Content selection on CMS is also implemented
    • Multi-device instances are stored into resource directory or generic subdirectory
    • Redefined instances per markup, technology or family of devices are stored into directory whose name is the same as the technology or family name
  • Media Sets & Content Selection (III)
    • MyMobileWeb supports content selection according to the language
    • For that it is needed to add a folder level with the concatenation of the country code and code language (ISO)
    • If there is a definition of family or technology:
      • If within this subfolder are defined instances for the current language, the system will select only between them
      • Otherwise, it will be selected from the ones that hangs directly from the family and not language
    • If there is no a definition of family or technology:
      • With language definition (folder with country code) under the generic folder is chosen only by these instances
      • Without defining language select among all instances except from which are defined for other languages
  • Media Sets & Content Selection (IV)
  • The Mobile Web Client Runtime (I)
    • Common
      • mymw-common
    • AJAX
      • mymw-ajax
    • UI
      • mymw-ui
      • mymw-tabview
      • Much more to come (sliders, calendar…)
    • Other Modules
      • XForms
      • DCCI, Context
      • Recommendation
      • Autocompletion
    mymw-common mymw-ajax mymw-ui
  • The Mobile Web Client Runtime (II)
    • The platform handles different device behaviours (including Windows Mobile 5)
    • The platform offers a minimized version of the scripts to reduce load times.
    • Scripts are located under script/ISO-8859-1/All/*.js
  • Common Module
    • Source “script/ISO-8859-1/All/mymw-common_min.js”
    • Element $ (<String> elementId)
    • Gets an element by id
    • boolean isDefined (<Object> o)
    • Validates if an object is defined or not
    • boolean isFloat (<Object> str)
    • Validates if an string has a float format
    • boolean isInteger (<Object> str)
    • Validates whether an string has an integer format
    • String trim (<String> str)
    • Trims a String, removing every leading or tailing whitespace.
  • The Mobile AJAX Framework
    • Source “script/ISO-8859-1/All/mymw-ajax_min.js”
    • Object mymw.ajax
    • void submit (<String> method, <String> url, <Object> params, <Object> callbacks)
    • Sends an HTTP request to the server.
    • method : HTTP method (“POST”, “GET”…)
    • url : remote URL
    • params : parameters to be sent
    • callbacks : “onerror” and “onsuccess” functions
    • String encode (<Object> params)
    • Encodes a list of parameters to be appended to the URL.
  • User Interface Module (I)
    • Source “script/ISO-8859-1/All/mymw-ui_min.js”
    • Object mymw.ui
    • Modify page contents
      • void addFragment (<String> id, <String> htmlContent)
      • Appends some content to a given element
      • void setFragment (<String> id, <String> htmlContent)
      • Modifies the inner contents of a given element
  • User Interface Module (II)
    • Modify styles
      • void setClass (<String> id, <String> className)
      • Sets the class name for a given element, removing any previously assigned class names.
      • void addClass (<String> id, <String> className)
      • Adds the class name for a given element, not removing any previously assigned class names, if existing.
      • void removeClass (<String> id, <String> className)
      • Removes a class name for a given element
      • boolean hasClass (<String> id, <String> className)
      • Verifies whether an element has a given style class name
      • void setStyle (<String> id, <String> property, <String> value)
      • Modifies a style property in a given element
      • void show (<String> id)
      • Shows (toggles display on) the element with a given id
      • void hide (<String> id)
      • Hides (toggles display off) the element with a given id
  • User Interface Module (III)
    • Utilities
      • void addOptions (<String> id, <Object> options)
      • Adds a set of options to a select element
      • void removeOptions (<String> id)
      • Removes all the options present in a select element
  • How to use them in your POs (I)
    • Add the required platform scripts
    • Add a reference to your script files
    • Add the listeners you need
    http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb_Certification_Examples_WebClientRuntime
  • How to use them in your POs (II)
  • Consortium