Kony Empowering Everywhere. 10 KEY CRITERIA FOR MOBILE PLATFORM SELECTION A Must-have Checklist for Mobile Application Development

Transcription

1 Kony Empowering Everywhere 10 KEY CRITERIA FOR MOBILE PLATFORM SELECTION A Must-have Checklist for Mobile Application Development WHITE PAPER NOVEMBER 2012

2 Introduction Support for Multi-Channel Service Level Agreements Developer Productivity Developer Creativity Open and Standards-based Platform Server Capabilities B2E Capabilities Total Cost of Ownership Mobility Track Record Platform Maturity and the Developer Ecosystem...13 TOC

3 Introduction There are many technologies available for organizations facing the imperative of creating a mobile solution for customers or employees (or both). By now, most companies have already tried a few approaches developing on Native SDKs, employing industry-focused application providers (like Mfoundry, UsableNet, etc.), using frameworks/libraries (like PhoneGap, JQuery, Sencha, etc.) or toolkits (like Appcelerator) or developing in-house on HTML5. For those who know hands-on or through references the limitations of the approaches mentioned above, the need has come down to a true enterprise-grade technology a mobile application development platform (MADP). Why Choose a Single Platform? A platform is the ultimate end-to-end solution with an integrated development environment, middleware, and a seamlessly-integrated console to address the organization s entire set of mobility needs including: Developing for multiple channels (mobile, tablet, desktop web) Deploying in multiple modes (HTML5, hybrid, mixed-mode, Native) Enterprise connectivity/back-end integration Robust security features Mobile app, data, and device management Analytics and reporting Platforms provide a holistic approach that gives organizations more control and predictability in the constantly changing mobile landscape, enabling swifter development, more robust and simplified integration, and easier maintenance of mobile apps. Platforms utilize the concept of write once, deploy everywhere in which the same code can function across a variety of devices. However, not all platforms offer all of these capabilities in a seamless, complete fashion. There is a set of key business and technology criteria for evaluating a mobile application development platform. Overlooking these criteria can result in compromised user experience, app performance, connectivity, scalability and user base coverage. It can also surface a series of unanticipated costs and implementation and maintenance failures. The top 10 criteria for mobile application development platform selection are outlined below. These are the key criteria that will ensure success of your mobile projects and future-proof your mobility choice. Ultimately, avoiding development and maintenance costs (typical for mobile projects) and risks is what organizations need to focus on. 1

4 1. Support for Multi-Channel Is Multi-Channel Development Supported? Is It Really Supported? Channel A channel is the device/platform + the mode of application that the customer accesses. E.g. iphone Native, Android Native, iphone Mobile Web, Desktop Web, etc. Your users must be able to access your app from desktop as well as any mobile device native or mobile web and have consistent experience across all channels. Why supporting all channels is important: Multi-channel coverage is pivotal for organizations approaching mobility with the diversity of devices their users have in mind. With the true multi-channel support, a developer can write once and deploy across mobile devices, tablets and desktop. Consequently, this centralized approach and connectedness results in efficiencies for the organization s mobile development team and consistency of experience across all channels for their users. Why supporting all output modes is important: Users have different devices and different preferences for accessing their apps. According to a recent survey, the market share for apps vs mobile web is 50/50. Also, whether to create native or HTML5 or hybrid apps depends on the purpose of that app, e.g. for enterprise apps Native is a more suitable mode due to large off-line storage and higher security capabilities, while for some consumer facing e-commerce apps, hybrid apps may make more sense. 1. Is multi-channel truly supported from the single code-base, requiring single skill-set? 2. How is Native supported from a single code base or through leveraging native SDKs? (Figure 1 - comparison table) 3. How is desktop supported from a single code base or through other products e.g. Lotus? 4. How many steps are required to generate Hybrid Apps? 5. How much of the code is generated (human readable!) and how much do the developers need to hand-code? (Figure 1 - comparison table) 6. Are non-html5 browsers and CSS 1.0/2.0 supported? 7. Ask for the list of all platform OS versions, devices and form factors supported and compare for the best coverage. (Figure 2 comparison table) OUTPUTS Kony Competitor Who is Write in One Place and in One Language, Write Very Little, and Run in Every Mode? <HTML4 HTML5 Hybrid Mixed-Mode Native Out-of-the-box Out-of-the-box Out-of-the box Out-of-the-box Out-of-the-box Older XHTML-MP, CSS 1.0/2.0 HTML5 and HTML5 SPA (Single Page App). 90% Humanreadable generated Minimal coding to transfer state/data from native forms to HTML5 forms. Bottom-line: Single code base, 1 skillset None Partial and Manual Manual Not integrated None Not supported No SPA. Only HTML5 Dynamic. 90% Handcoded 5 Steps to generate All native components have to be written using Native SDKs and languages. E.g. iphone - Objective C with Xcode; Android - Java with SDK. Bottom-line: 5 code bases, 5 skillsets Leveraging native SDKs only Figure 1 Kony vs Other Platforms Comparison Table: Supporting Multiple Modes 2

5 CHANNELS Kony Competitor Who has you covered better? Platforms Mobile Phones Tablets Other Desktop ios, Android (all versions), RIM (BlackBerry ), Windows Phone (6,7, Mango), Symbian, MeeGo/ Harmattan, J2ME, Palm ios, Android, RIM (BlackBerry), Windows Phone, No Symbian, J2ME or others ios, Android (all major form factors), Blackberry (5.0+), Windows (6,7,Mango), J2ME (All major versions of Nokia, Samsung,, LG, Sony Ericsson, Panasonic, Orange, Alcatel), Symian (All major versions of Nokia, Samsung, Sony Ericsson, MeeGo) iphone, Android (60% of form factors), BlackBerry (30% of devices), Windows Phone (7 only), No J2ME and Symbian phones ipad, ipad 2, ipad 3, Google Nexus One, Samsung Galaxy Tab, Motorola Xoom Only ipad and some Android tablets Kiosk, ipod 3G, ipod 3GS X 32 bit rich client, Desktop Web 32 bit rich client, no Desktop Web Figure 2 Kony vs Other Platforms Comparison Table: Supporting Multiple Channels 2. Service Level Agreements Does the Vendor Provide SLAs to cover new releases of devices an OSs? A Case in Point: Kony s readiness for ios6 release. 1. Plug-ins to ensure that apps continue to work flawlessly 2. New features: Maps, invoking Siri, Passbook support through FFI and more. Kony s SLA: To provide updates of the programs to function with new releases (GA): OSs within 30 days Devices within 90 days Why SLAs are important In a rapidly evolving mobile landscape, a service level agreement (SLA) guarantees that your customers will be covered within a certain amount of time as new devices and operating systems are released in the market. Without SLAs, the future of your application is uncertain. As certain toolkits rely on 3rd party frameworks (such as the open-source Phone Gap framework), the upgrade path of your applications is unclear. Without these SLAs, it is possible that your users will be alienated and left in the dark upon upgrading their OS or device. Don t penalize early-mover users. Stick with a platform option with a clear SLA. 1. What exactly is covered by the SLA? Look for the specific language to identify any ambiguities 2. Are new operating system releases covered? What is the committed SLA in terms of days? 3. Are new device releases covered? What is the committed SLA? 4. What is the provider s track record for complying with SLAs? When reading an SLA from any platform, framework, or toolkit provider, it is necessary to look out for specific language so that you ensure continuity of an application. For instance, be careful to note the amount of time after each OS and each device are released to market. Users have come to expect applications to be promptly updated and function not only as they did with previous OS releases, but to include relevant integration of new OS or device features. 3

6 3. Developer Productivity What is the platform s tooling support and how is developer efficiency achieved? Why robust platform tooling support is important The key advantage of the Studio/Designer component of a platform for a developer is the ability to use multiple tools to minimize the lines of code and repetitive effort. While a product bake-off or a POC (Proof of Concept) will help you understand these capabilities better, it is important to analyze the step-by-step effort. See Figure 4 for analysis of a day-in-the-life of the developer as well as the ultimate number of days/hours required to build an app. 1. How is the UI created? Is there drag and drop capability? 2. How is a service connection defined, created and tested? Is there a visual editor available to create a J2EE service connection? 3. How is the app logic defined? Is there tooling like mapping editor, action sequence editor, logic editor, etc., available? 4. Is it possible to directly import 3rd party libraries? Summary of Steps Involved per Task Task Items Define, connect, and test a service connection Develop App User Interface (UI) Competitor task effort (a) Start by defining an adapter connectivity (b) Define service invocation logic separately that captures the method, type and parameters for each service adapter. (c) Define service transformation logic (a) Start by defining the app screen User Interface (UI) layout (b) Define UI form factor variations and screen sizes/resolutions from one platform to another (c) Design and develop look and feel (branding & style) for each screen size and resolution (d) Ability to quickly preview app UI during development for productivity? Competitor skills, artifacts XML based adapter definition file is created using the Adapter Editor. (See Figure 1, 2, 3) Service invocation logic is developed in JavaScript as a separate artifact (Figure 4) Developer defines XSL files for each service transformation logic where XPATH and XSLT both need to be defined Develop HTML code to build UI layout (div, tablet, etc.) Create UI resources (including variations of different screen sizes and resolutions) Configure app menus using Competitor APIs in JavaScript. Develop separate HTML code for each UI form factor. Please see figure (5, 6, 7) Develop CSS styles for each mobile screen size and resolution. Leverage basic HTML preview capabilities provided by Eclipse. Kony Task effort (a) Define, connect and test services using Service Definition Editor provided by Kony Studio (See Figure 1a, 2a, 3a) NOT A REQUIRED STEP (b) Define service transformation logic (optional) (a) Create app screen User Interface (UI) layout using visual drag-n-drop editor provided by Kony Studio (See Figure 5a) NOT A REQUIRED STEP (c) Design and develop look and feel (branding & style) for each app UI (d) Ability to quickly preview app UI during development for productivity? Kony skills, artifacts Visual Editor provided to develop J2EE service definition (saved as XML) NOT A REQUIRED STEP Develop XPATH in the Service Definition Editor to develop and test service transformation. Developer uses Visual Form Designer to rapidly create app UI. Optionally, developer selects platform specific properties to leverage platform specific UI differences. --- NOT A REQUIRED STEP Developer Skins & Themes Editor to define look & feel Developer uses Quick Preview to preview app UI on device emulators. 4

7 Define App business logic (a) Define app logic for each screen & associated service invocations to map the response data to the app UI or variables. (b) Define app navigation logic to capture each event and screen transition. (c) Define core app logic (decisions, rules, technical and business validations, etc.) (d) Integrate with 3rd party libraries such as JQuery, Sencha, or Dojo. This is optional. Developer needs to define JavaScript function code. Optionally, you may develop XSL code as well. (See Figure 8, 9) Developer needs to define JavaScript function code. (See Figure 10) Developer needs to define JavaScript function code. Developer needs to define JavaScript function code for 3rd party invocations. Developer uses Mapping Editor (See Figure 8a) Developer uses Action Sequence Editor (See Figure 9a, 10a, 11a) Developer uses Action Sequence Editor and Logic Editor with content assist Developer uses Integrate 3rd Party Libraries wizard Figure 3 Step by Step Effort Comparison Effort Analysis Case Study Results Task items Kony Competitor a. Defining services (total 2 services) 2hours 1-2 days per service b. Developing application UI 2hours per app screen 1-5 days per app screen c. Developing application business logic ½ day 2 days d. Test & QA ½ day 1 day Total time required to build the simple banking application* days 2 weeks 4. Developer Creativity Figure 4 Effort Analysis Case Study Results: What are the platform s capabilities to create pixel-perfect, advanced-ui apps with no limitations? Foreign Function Interface (FFI) An Extensible API to take advantage of native device capabilities Why platforms shouldn t compromise the UI: Besides giving the developer necessary tools to create apps efficiently, a key criteria to consider is whether the platform allows developers to build pixel-perfect apps with advanced UI features and flows. Because a MADP s key premise is to enable the creation of apps across many platforms and form factors, developers are often left with an impression that there are tradeoffs to creating a great user experience because they are limited by the platform s common denominator approach. While it is true that many development platforms in the market have this limitation, there are ways to identify the platforms that do not. Creating a great UI is achieved by leveraging cross-platform and platform-specific APIs. Also, allowing the import of any type of 3rd party libraries is key. Simply review and compare the number and types of APIs as well as openness to integrate any 3rd party libraries. Also, identifying whether the write once, deploy to multiple channels is achieved through cross-compilation could help you anticipate the limitations for advanced UI creation. Make sure the platform doesn t utilize this approach. See Figure 6 Cross Compilation Explained. 5

8 1. What are the APIs and libraries provided by the platform? 2. How is leveraging platform-specific properties achieved? 3. What kind of 3rd party libraries can be integrated? Can Native libraries be imported as well? 4. Is Foreign Function Interface capability provided within the platform? 5. Is the platform s approach to write once, run everywhere different from cross-compilation? Number of APIs APIs Kony Competitor Cross-Platform APIs String Library 22 0 Math Library 8 0 Table Library 16 0 Application Level APIs Window Library 5 10 Widget APIs 11 5 Inline Browser Navigational APIs 6 3 Datastore Library 14 0 Internationalization 13 2 Timer APIs 3 0 Push Notification 14 5 Phone APIs 12 0 OS APIs 30 4 Live Tile APIs 3 0 Accelerometer 5 0 Streaming APIs 3 0 Gesture APIs 2 0 Cryptography APIs 8 1 Network APIs 5 1 Badge APIs 6 1 Hybrid APIs 3 1 Themes 5 0 Geolocation 3 1 Server-side APIs UI Widgets Total Import JavaScript Libraries Import Native 3rd Party Libraries X Foreign Function Interface X Figure 5 API Comparison Table 13 0 How Kony is NOT a Cross-Compilation Technology What Cross-compiler is: You write it in one language, e.g. C And compile it into another executable e.g. Java Binary directly No Interpreter No Libraries in between A cross-compiler is usually proprietary. What Kony is: An interpreted model Kony generates JS code for App logic It leverages an interpreter/vm to interpret the App logic The interpreter leverages natively-written cross-platform libraries The JavaScript interpreter that Kony provides is all standards based. C Language Java Binary App Logic Interpreter/VM Libraries Examples: Compiling native code for emulators for obsolete platforms like Commodore 64 or Apple II Examples: Any browser in the world Figure 6 Cross-Compilation Explained 6

9 5. Open and Standards-based Platform How open is the platform and what are the standards supported? Why an Open and Standards-based Platform is Important: Simply put, open and standards-based products give companies flexibility to integrate any products and peace of mind that they are not heavily dependent on, and limited by, the platform vendor s proprietary technologies. It is important to thoroughly review the standards supported for each component of the platform like studio/designer, server, etc, to ensure the minimum dependency on proprietary elements. See Figure 7 for an open/standards comparison table. Open Defined: A product is NOT open when a customer is limited to choosing a particular path for its product that the vendor provides, or if a customer cannot buy 3rd party components and add them in. Proprietary Defined: A product is proprietary when a customer is buying some IP from the vendor and is dependent on that vendor for the service. 1. What development language is supported? 2. What standard is the server based on? 3. What application servers are supported? 4. How is importing 3rd party products supported? 5. Are standard connectors supported? 6. How are HTML5, HTML4 and older standards supported? Who is Open, who is Proprietary and who works on more Standards? Studio Kony Competitor Develop within 3rd Party Libraries FFI (Extensible API to take advantage of native device capabilities) FFI (Extensible API to take advantage of native device capabilities) FFI (Extensible API to take advantage of native device capabilities) FFI (Extensible API to take advantage of native device capabilities) Figure 7 for Open/Standards Comparison table Eclipse (Open) or another Proprietary tool Only JavaScript Libraries can be integrated Not Supported Server Kony Competitor Server Based On J2EE Standard (Open) J2EE (Open) or the Company's own Application Server (Proprietary) Application Servers Supported* Tomcat (Open), JBOS, Weblogic (Open) and Websphere Websphere Only Server Operating Systems Linux, Unix, Windows Windows Only Server Operating Systems Kony Competitor REST/JSON X REST/XML SOAP Web Services Java Services X Java Datavase Connectivity (JDBC) Other Standards Supported Kony Competitor HTML5 and CSS 3.0 HTML4 (CSS 1.0/2.0) X Service-Oriented Architecture X 7

10 6. Server Capabilities What are the platform s server capabilities? Why having a robust application server is important: In a platform, the middleware server plays a key role in providing enterprise-grade functionalities like integration and security. Therefore, ensuring that the server of the platform is robust enough to provide reliable performance and scalability is crucial. See Figure 8 for a Server Components Comparison table. 1. What are the key components of the server? 2. Is there a device database available? How are new devices detected and added to the database? 3. What components of the server are distributable? 4. What are the connectivity/integration capabilities of the server? What kind of custom, proprietary and standard connectors are supported? 5. How is usage reporting handled? Are there built-in reporting capabilities available? Server Components Kony Competitor Sync Server X Version Management Server-side Web Runtime Memcache/built-in J2EE Session Native App Downloader X Distributable Server Components X Device Database X Push Notification Anroid ios Blackberry X Other platforms X Android C2DM push Android GCM push X Integration Standard Connectors (Web Services, SOAP, XML, REST) Proprietary Connectors Custom Connectors Mobilizing SAP without Middleware X Security PCI/PII Compliance X Addressing OWASP Top 10 Vulnerabilities SSO Support On-Device Encryption Support Security Implementation for Critical Businesses Certificates and Client Side Authentication Design Time Security Compliance 8

11 Server Components Kony Competitor Reporting engine Mobile data collection Built-in reporting X Adobe Omniture X Others Coremetrics X Google Analytics X Webtrends Analytics X 7. B2E Capabilities Figure 8 Server Components Comparison table What are the platform s Business to Enterprise (B2E) capabilities? A Seamlessly Integrated B2E Solution: When evaluating B2E capabilities it is key that the entire B2E product set (MAM/MDM, Connectors and Sync) is tightly integrated with the platform and has actually been built in concert. A hodgepodge of separate products brought together by acquisitions present risk of scalability and integration issues. Why having strong B2E support is important: A true MADP should offer end-to-end B2E capabilities consisting of mobile application management (MAM), mobile device management (MDM), enterprise connectors and sync server. Without these, deploying mobile apps in an enterprise environment will pose numerous challenges, especially when Bring Your Own Device (BYOD) is being embraced by the organization. Simply having an enterprise app store, and incomplete MDM capabilities, will not serve as a true enterprise-grade platform to create and manage apps. For all the other components, you would need to employ other vendors. 1. What are the key components of the B2E offering? 2. Are both standard and custom connectors supported? 3. How is the server handling sync? 4. What is the approach to mobilizing SAP? 5. Does the provider offer any pre-built B2E solutions? Overview Key Components Kony Competitor Mobilizing SAP w/out Middleware X Standard Connectors Custom Connectors Proprietory Connectors Sync Server X MAM with Secure App Container X Enterprise App Store MDM MCM X Figure 9 B2E Checklist 9

12 Sync Server Capabilities APIs Kony Competitor Enterprise Application Features Over The Air (OTA) synchronization X Bi-directional synchronization X Incremental download X Incremental upload X Conflict resolution X Device Detection and Security Intelligent Device Detection X Encrypted data transaction X SSL X Multi-factor Autentication X One-time password X OFX X PKI X Symmetric Cipher X Device and Server-side components KonySync Libs (embedded in Application) Persistence Logic X Change Tracking X Sync Protocol (OData) X Delta Determination X Merge data with backend X Change Tracking X Expandable on-device SQlite DB unique to an application Figure 10 Sync Server Capabilities X X Mobilizing SAP Kony Competitor Build Enterprise Explorer to disover SAP objects X Build SAP-optimized Apps X Bind SAP-objects at design time X SAP-optimized Sync API X Integrate Connecting to SAP with no Middleware X Interface manager w/throttling, routing, queueing, load balancing capabilities Integration with SAP security infrastructure X Manage KonySync Libs (embedded in Application) X Description of Others integration with SAP: No prebuilt SAP support have to use other adapter objects. All mobile SAP interactions are transactional with no builtin capabilities to synchronize and build offline apps out of the box. Separate appliance to install, configure and manage, separately outside of SAP. Figure 11 Mobilizing SAP without Middleware X 10

13 8. Total Cost of Ownership What will the total cost of ownership (TCO) for my app project be? Why it is important to ask for a detailed TCO study? Mobile app development has a lot of hidden costs. Even with a platform, app maintenance, upgrades and development efforts can vary significantly from vendor to vendor. Besides, TCO analysis will give you a good idea on the overall scope and timeline of the project. 1. How detailed is the TCO model? 2. Does it include various complexities of screens and integration capabilities? 3. Does it take into consideration my team s size and learning curve and/or optional services (i.e. vendor, partner, off-shore, etc)? 4. Does it include estimates for maintenance and upgrades? 5. Does it include detailed descriptions of each and every task? IT Savings with Kony Development Licenses Maintenance & Suport Enhancements & OS changes Year 1 Year 2 Year 3 Competitor $676,512 $0 $0 Kony $219,510 $0 $0 Competitor $150,000 $150,000 $150,000 Kony $250,000 $250,000 $250,000 Competitor $3,950 $223,249 $357,198 Kony $32,916 $60,800 $60,800 Competitor $0 $405,907 $405,907 Kony $0 $87,804 $87,804 Competitor $0 $0 $0 Dedicated team costs Kony $0 $0 $0 Hosting $0 $0 $0 Net difference with & Competitor $830,462 $779,156 $913,106 without Kony Kony $502,426 $398,604 $398,604 IT Savings NPB over 3 years with Kony $1,102,033 Figure 12 TCO Comparison Example 11

14 9. Mobility Track Record What is the platform vendor s mobility track record? Why customer footprint and number of deployments is important: Mobile is a relatively new and dynamic space and you cannot rely on a vendor only because it is a large software/technology enterprise that, in line with many other core products, offers mobility solutions. When evaluating a vendor, you have to make sure you are looking to a platform/product that is best-of-breed in mobility. And there is no better proof than the number of customers and live apps segmented by deployment size, geography and industries. The more diverse the vendor s customer portfolio is, the better. 1. How many live deployments has the vendor had? 2. How many industries do the vendor s products serve? The more diverse, the better. 3. Has the vendor done multi-country, large-scale deployments? 4. How many months does it usually take the vendor to take the app live after the execution of the contract? Mobility Track Record metrics comparison Kony Competitor Number of Global 2000 customers Number of application sessions web+native >1 Billion/yr <70 Million/yr Number of B2E users >100,00 0 Number of apps in production Number of apps for F Figure 13 Mobility Track Record metrics comparison 12

15 10. Platform Maturity and the Developer Ecosystem What is the maturity of the platform and strength of the developer ecosystem? Why platform maturity is important: Platform maturity can be gauged by the number of man-months invested in the development of the platform (core platform engineering work). Simply put, the more man-months invested in the platform, the more advanced/superior you can expect it to be. Why a strong developer ecosystem is important: A developer ecosystem includes the vendor s own engineering and delivery team plus system integrator (SI) partners and other developers trained on the platform. The larger the ecosystem, the more streamlined implementation and delivery of your project. Also, the sheer size of the ecosystem speaks to the degree of innovation the core engineering team is able to deliver due to the feedback and interaction received from the larger developer community. 1. How many man-months have been invested in the platform? 2. How many in-house developers does the company have? 3. How many partner SIs have been trained on the platform? 4. How extensive is the developer support and documentation? Mobility Track Record metrics comparison Kony Competitor Number of Global 2000 customers Number of application sessions web+native >1 Billion/yr <70 Million/yr Number of B2E users >100,00 0 Number of apps in production Number of apps for F Figure 14 Platform Maturity and Developer Ecosystem metrics comparison 13

16 About Kony Solutions Kony is the industry s leading mobile and multichannel application platform provider. Kony develops a suite of customizable pre-built apps and the KonyOne Platform, which give companies the confidence and control to quickly build apps once and deploy everywhere across all smartphones, feature phones, tablets, kiosks and desktops, seven operating systems and multiple deployment modes, including HTML5 and mobile web, hybrid, native, and mixed-mode. The company also delivers a comprehensive mobile application management (MAM) solution for provisioning, deploying, managing and analyzing mobile and multi-channel apps. Kony s customers include more than 70 Fortune 500 companies, the largest global bank, and global brands such as Toyota, Capital One, Hyatt, and Huntington National Bank. Kony customers have generated hundreds of millions of dollars through apps such as mobile ticketing and reservations (hospitality), mobile remote deposit capture (banking), and mobile claims processing (insurance). In 2012 Kony was named a Visionary in the Gartner Magic Quadrant for Mobile Application Development Platforms (MADP) report. For more information, please visit or connect with Kony on Twitter, Facebook and LinkedIn Kony Solutions, Inc. All rights reserved. Kony and the Kony Mobile Application Platform are trademarks of Kony Solutions. Apple and iphone are trademarks of Apple Inc., registered in the U.S. and other countries. BlackBerry is a registered trademark of Research In Motion. Android is a trademark of Google Inc. Other product names mentioned are the property of their respective holders.