}w!"#$%&'()+,-./012345<ya

Transcription

1 MASARYK UNIVERSITY FACULTY OF INFORMATICS }w!"#$%&'()+,-./012345<ya Analysis of NFC Technology On Most Popular Mobile Platforms BACHELOR S THESIS Michael Ruml Brno, 2013

2

3 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Mgr. Ivan Bradáč, Dr. ii

4 Acknowledgement I would like to thank to my advisor Ivan Bradáč for a valuable assistance and to Mautilus s.r.o. for providing technology needed for this paper. But mainly, I would like to thank my family and girlfriend for their unconditional support during the work on this thesis. iii

5 Abstract This thesis deals with NFC technology, its usage, features, and implementation on mobile devices. The first part describes the technology as such, its principles and used data formats. Second part introduces the four most popular mobile platforms (ios, Android, Windows Phone 8 and BlackBerry 10), describes how NFC is implemented on each platform, and shows how a simple prototype application defined in this chapter can be implemented. In the end of the chapter we evaluate NFC implementation of each platform. iv

6 Keywords NFC, NDEF, ios, Android, Windows Phone, BlackBerry v

7 Contents 1 Introduction NFC Analysis Description of the Technology Development of the Technology NFC Data Exchange Format NDEF Record Header Well-known Types External Types Usage of the Technology Basic Use Cases Connection Handover Smart Card Emulation Other Similar Technologies Barcodes Bluetooth Wi-Fi Chapter Summary Mobile Platforms Analysis Composition Demo Application specification ios Android API Analysis Tag Handling Data Exchange Implementation Windows Phone API Analysis vi

8 3.5.2 Prototype Implementation BlackBerry API Analysis Cascades API Core Native API Prototype Implementation Platform Comparison Chapter Summary Conclusion vii

9 Chapter 1 Introduction Since the spread of personal computer to general public, there has been an effort to integrate tools and devices together. That effort gradually resulted in one pocket device capable of satisfying most of the needs, for that one had to own a dedicated device. For instance, we can observe this phenomenon on dedicated portable multimedia players. As smartphones and other mobile devices have become more sophisticated, they are now more than capable to substitute for dedicated devices. Moreover, they offer features dedicated devices are incapable of offering, such as integration with other services (e.g. online multimedia markets). Adoption of a wireless technology, such as NFC, is just a logical step in an integration process. NFC technology can substitute, enhance, or simplify many daily needs. One of the main selling points for this technology is of course RFID and smartcard substitute, but we should not forget about other aspects a substitution of regular business card for NFC tags, seamless connection establishment and so on. Also, competition in the mobile market is fierce and in order for mobile vendor to succeed, it must offer high-end devices with all the latest technologies. Moreover, highend devices buyers are mostly also early adopters, so device support for latest technologies is a must, despite the cost of the risk that a newly adopted technology will not succeed. However, technology such as NFC cannot succeed without support from available software and services. We can demonstrate this on spread of front-facing cameras on mobile devices: for a long time, their usage was very sporadic as there was not sufficient mobile internet connectivity available. However, that did not stop vendors from including this functionality to their devices and once the connectivity have developed 1

10 and more software services have become available, front camera have become important feature for a mobile device. Software support for NFC technology is the main reason for this thesis. Mobile platforms, even the popular ones, do not share same development platform. Additionally, the development processes are rarely even similar and so development for multiple platforms can be a nearly impossible task for one person. This thesis s main goal is to offer a basic understanding needed for development of NFC technology, introduce the main mobile platforms that implement NFC, describe how each platform adopts it and how NFC use cases can be developed. The description part will be supported by an implementation of a simple prototype for each platform that supports NFC. We will also evaluate how well each platform implements NFC support and whether all of the features of NFC are supported. In the first chapter, we describe NFC technology as such. We define its main features, how various types of data transfer are handled and how the connection participants are categorized. We also mention the development of the technology. After we introduce NFC Data Exchange Format as a main format for NFC data exchange and we mention some possible use cases of the technology and similar technologies at the end of the chapter. The second part of this thesis introduces four main mobile platforms (ios, Android, Windows Phone 8 and BlackBerry 10), and describes NFC implementation on each of them. As a support for this chapter, we develop prototype applications that demonstrate how NFC can be implemented and used. At the end of the chapter, we evaluate each platform. 2

11 Chapter 2 NFC Analysis In this chapter, we will introduce NFC technology and define it s main principles. We will describe the specifics of standard implementation, it s energy efficiency, and security. After that, we will mention why the technology was developed, how and by whom it was performed. We will also describe the main features and standard use cases of NFC. At the end of the chapter, we will mention the data structure used by NFC standard and we will introduce a short comparison of NFC with other established wireless technologies (namely Bluetooth and Wi-fi). 2.1 Description of the Technology Near Field Communication (NFC) is an open standard mainly for smartphones and portable devices defining radio communication at a close proximity. The technology is based on RFID standard 1 and in order to maintain compatibility with RFID cards and readers, it operates on the frequency MHz. As we mentioned, data transmission is effective only within a distance of a few centimetres. It is recommended to touch the devices during transmission. The close proximity needed for the connection brings several benefits. First, it enhances security it is more difficult to eavesdrop on the connection when it has such a limited range. Second, it doesn t need much power. Thanks to that, the NFC system can stay powered for a long period of time and it will not drain the device s battery. This feature is actually quite important: the device with NFC on can always, for example, act as an access card

12 seamlessly. Also, the device can open a particular application according to the data received from a tag. We distinguish two main types of connection participants: an active device and a passive device. An active device provides power for the connection, in contrast, the passive one feeds on the power provided by the active one. Based on this, we distinguish three types of devices according to their functionality[15] NFC reader an electronic device capable of receiving data through NFC. Active device an active electronic device capable both of reading and writing through an NFC stack (e.g. smartphone, contactless payment terminal) NFC Tag a passive device powered by an electromagnetic field. Tags typically contain an antenna and a small amount of memory. A memory module can be read only, writeable once or fully re-writeable. We distinguish three types of operating modes: Reader/writer mode This mode is used by active device and passive NFC tag pair. An active device adopts reader or writer mode. In reader mode, the active device reads the data from a tag, in writer mode, the active device writes the data. Peer-to-peer mode This mode is used by two active devices. One must adopt an active role and provide power for the data transmission. Also, the reader/writer roles are decided and the data transfer works in a similar fashion as in reader/writer mode. The reader/writer role can be changed multiple times. This way, bidirectional half duplex communication can be performed. Card emulation mode The device supporting this mode can mimic a contactless smart card. This way one can use an NFC-enabled device as an ordinary credit / debit card or a ticket. The device can store multiple cards or tickets. It is one of the major features of the NFC standard. 4

13 2.1.1 Development of the Technology NFC was developed by Philips and Sony at the end of After it s successful development, ECMA 2 and ISO 3 adopted the technology and defined it as a standard. In 2004, NFC Forum was founded by Nokia, Philips and Sony in order to promote the technology and to provide needed resources for adoption by other companies. NFC Forum is now the main organization responsible for NFC and related technology standards. Also, one of the main tasks of the organization is to promote the technology in consumer electronics and to maintain and develop documentation. NFC Forum standardized both data exchange modes: reader/writer and peer-topeer mode. Also, the organization brought standardized data formats for NFC devices and data exchange, namely the NDEF standard (described in Section 2.2). 2.2 NFC Data Exchange Format NFC Data Exchange Format (NDEF) is a specification for exchanging data between two devices. Each one message consists of one or more NDEF records. Each record contains a record header and one or more data payloads NDEF Record Header An NDEF header describes the data delivered in a payload as well as some information about message itself. A description of a header data structure follows: First byte of a header in question consists of several data (see Figure 2.1).[13]: After the first byte, several bytes follow: TYPE_LENGTH Defines the data length (in octets) of the TYPE field 2. European Computer Manufacturers Association 3. International Organization for Standardization 5

14 Name size Description MB 1 b Indicates whether this record is first in a message ME 1 b Indicates whether this record is last in a message CF 1 b Indicates whether this message is partitioned into more payloads SR 1 b If true, this is a short record the payload fits only one octet IL 1 b If true, the header consists a length identification TNF 3 b Stands for Type Name Format, indicates the structure of the TYPE field Table 2.1: NDEF Record Flags PAYLOAD_LENGTH Specifies the length of the payload in octets. If the record consists of more than one payload, more PAYLOAD_LENGTH bytes are included in a header. TYPE Identifies the payload type (for instance, 0x55, or U identifies the URI type) ID URI identifier (for example PAYLOAD the rest of the transmitted data The shortest possible message consists of one record. In that case, the MB and ME flags are set to 1, indicating this record is both first and a last one in a message. An important attribute is a TNF. As was said, it describes the structure of the TYPE field. In other words, TNF defines whether the type of a payload is one of the wellknown and, if yes, which one. There are several defined values (described in Table 2.2) Well-known Types NFC Forum provides several defined record types. These are identified by TNF value 0x01 and have well-defined TYPE format urn:nfc:wkt:type, where urn 5 is nfc 5. Uniform resource name 6

15 TNF Empty NFC Forum Well-Known Type Media Type Absolute URI 4 NFC Forum External Type Unknown Unchanged Reserved Value 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 Table 2.2: TNF Field Values TYPE Content Sp T U Sig Description Smart Poster Text URI Signature Table 2.3: Well-known Record Types Namespace Identifier. After wkt: prefix the well-known record identifier follows. In this case, it is the type. This is the absolute format of the used URIs. When these are used in an NDEF record, the URN and wkt: are omitted, so the content of the TYPE field would be only type. There are several defined well-known types these are mentioned in Table External Types User can also define an own type. These can be used for example for identifying the record by a custom software, launching and application when read by a device etc. TNF record has value 0x04 and TYPE format is very similar to the well-known ones: urn:nfc:ext:example.com, where all the segments have the same meaning as in the well-known record case, except ext: identifier, which is specific for external record types. 7

16 2.3 Usage of the Technology In essence, NFC technology is a basic radio-base data transmitting system. However, because it offers some unique features, it is possible to think of the use cases, which were not possible before Basic Use Cases A typical NFC use case is a simple data transmit. NFC itself is not suitable for transmitting a large amount of data because of limited speed. On the other hand, thanks to the limited range, the technology does not need a complex authentication protocol and it is suitable for exchanging small chunks of data with as little effort as possible, i.e. business information, hyperlinks etc. It is also possible to use NFC for establishing the communication and, once both sides are paired and ready to exchange data, hand over the session to some faster technology available. Bluetooth or wifi-direct is typically used. As was described in 2.1, usage of passive devices (also known as tags or tokens) is possible. The typical use case can be distribution of hyperlinks through smart posters Connection Handover As was mentioned, NFC can serve as an initiator of a connection and when it is established, the session can be handed over to some other technology programmatically. This way, the connection participants don t have to be in the vicinity during whole data transfer. Also, the data transmission is typically faster. A simple bluetooth connection could be established instead, but when NFC is used for initialization, the authentication procedure can be simplified, so that the whole process is more user-friendly and seamless than using bluetooth only.[14]. 8

17 2.3.3 Smart Card Emulation In many use cases, an NFC-enabled device can substitute for a legacy RFID card. In combination with other device features, such as custom application, internet connection etc., an application using NFC technology can not only substitute for standard access or credit cards, it can enhance the use case as such. An example can be a public transport ticketing system. Through a dedicated application, one could buy a ticket. Once he or she chose one and decides to buy it, it can be paid for through various payment systems, e.g. PayPal 6. Right after the ticketing backend receives payment confirmation, an electronic ticket is sent to the user s device. After, the ticket is accessible through an application. The application also implements RFID card emulation mode. When the user enters the bus, he or she can verify the ticket by touching the mobile device with a dedicated reader. The reader confirms the ticket and also sends the information to the system s backend. The backend now marks the ticket as used or active (depends on a nature of the ticket) and sends the information to the mobile application. Once the application receives the message, it also marks the ticket. 2.4 Other Similar Technologies There are several technologies capable of delivering similar functionality as NFC Barcodes Generally, barcode is a machine-readable image representation of data. There are many standards designed for various uses. Among others, the QR Code standard is one of the most popular. QR Code is a two-dimensional barcode (example on Figure 2.1) originally de

18 Figure 2.1: QR Code example veloped in Japan by Toyota for identifying various commodities. It s design enables fast scanning by standard optical sensors, typically cameras. After camera-enabled mobile phones wide-spread the QR Codes became popular mainly because of use in marketing. Nowadays, most of the mobile platforms offer a QR Code reader functionality, either built-in or downloadable. Generally, QR Code use cases are similar to NFC passive tags usage they also can be used as a simple data distribution channel. It s main advantage is in it s production: as a simple image representation, they can be printed right on a poster, a business card, etc. However, the data capacity QR Codes offer is quite small only a small amount of data can be distributed on one code.[7] Bluetooth Bluetooth is a wireless data transfer standard developed in 1994 by Ericsson as a substitute for RS-232 serial port 7. Since the first versions of the standards, it was designed for personal, small-distance networking. The first versions (up to Bluetooth 2.0 standard) suffered from a fairly complex authentication system. Version 2.1 brought a simplified authentication process, making the whole pairing and connection routine seamless. In comparison to NFC, Bluetooth can offer much faster data transfer speed (up to

19 24 MBps 8 ) and a longer range (up to 100 m, 10 m for mobile devices typically). However, NFC can offer faster connection establishment.[17] Wi-Fi Wi-fi is a wireless technology designed for networking, standardised as IEEE Networks based on Wi-fi typically follow star-like topology 10. Over the years, Wi-fi became a standard for wireless networking. However, because of the need for a control element, basic Wi-fi is not suitable for mobile device networking. In this case, Wi-fi Direct technology can be used. Wi-fi direct is an ad-hoc 11 network based on original Wi-fi technology. Wi-fi Direct enabled device can connect and exchange data directly, thus it is usable in mobile networking. Use cases are similar as with Bluetooth. However, Wi-fi modules are often more complex and require more power than Bluetooth, but they offer faster data transfer speed. Because of that, Wi-fi Direct is more suitable for simple data exchange. 2.5 Chapter Summary In this chapter, we introduced NFC wireless technology. We described the fundamentals of the technology, how it operates, and we mentioned basic use cases. We also showed how NFC is usable in the modern world of mobile devices, what the pros and cons of the technology are and how the data exchange works. We also mentioned technologies similar to NFC. 8. Megabytes per second Meaning it does not rely on a preexisting infrastructure, each node participates in routing by forwarding data for other nodes instead. 11

20 Chapter 3 Mobile Platforms Analysis In this chapter, we will show how the NFC standard is implemented on chosen mobile platforms, namely on ios, Android, Windows Phone 8 and Blackberry Composition For each platform, we describe how one can implement NFC support using resources provided by platform s vendor. We look into the structure of provided tools and describe what is possible and what is not. Further on, we implement an application described in Section 3.2. At the end of the chapter, we compare the platforms capabilities and their convenience for an NFC application. 3.2 Demo Application specification A simple proof-of-concept application will be developed, which will demonstrate the following capabilities of NFC-enabled smartphones. Data read: The application will be capable of reading a text message stored on a NFC-enabled tag and display it on a device s display. The message will follow NDEF standard (see Section 2.2), so the TNF value will be set on 0x01 (Table 2.2) and TYPE will have a value of T, which stands for text in NFC Well-known Record Types (see Table 2.3). 12

21 Data write: The application will offer the possibility of writing the text to an NFCenabled tag. The message will also follow NDEF format and header values will be set exactly the same way as in the Data read case. Application launch: The application will be registered to the device s system for launch when the message with the specific TNF will be read. For the purposes of testing and demonstration, we will be using the Mifare Ultralight NFC Tag 1. The application will implement three possible use cases: 1. User puts the tag with a specific NDEF record close to a device. The system recognizes a type of a NDEF record on a tag and launches the application 2. User launches the application by our NFC tag or by a standard method. Afterward, she puts the device near the tag. The application reads the data and if the type of the record follows the application s specification, it displays the recorded content. 3. User launches the application by our NFC tag or by a standard way. The User types a text of her choice into an input text field. Afterward, she taps on the Write Data button. When she is prompted by the application, she puts the the NFC tag near the device. The application writes an NFC record to the tag. If the tag contained any record, it will be deleted. The input field can stay empty in this case, an empty string will be written to the tag. 3.3 ios ios is a mobile operating system developed by Apple Inc. The system was introduced in 2007 along with the iphone Apple s first mobile phone at that time[1]. The system

22 introduced a user interface designed to be controlled by touch only. Along with capacitive touchscreen 2, they introduced a new way of controlling mobile devices. At this time (4th April), ios is in version Applications for ios can be developed using Cocoa Touch Framework, a framework provided by Apple Inc., based on Objective-C 3 language. At this point in time, no device running ios supports NFC directly. Partial functionality can be achieved by using icarte frame by Mifare 4. However, these are not available for the public, therefore implementation will not be covered in this thesis. 3.4 Android Android is a mobile open-source operating system originally developed by Android Inc. In 2005, after a short term of funding, Android Inc. was acquired by Google Inc.[3] Google continued in work and in 2007 they introduced a new operating system and founded Open Handset Alliance a consortium of companies interested in an open standard for mobile devices.[4] The first Android device was introduced in October The system is based on the Linux kernel (version 2.6, version 3 since Android 4). However, despite the open-source nature of the project and the usage of a Linux kernel, Android is not considered a Linux distribution, because of some GNU tools missing[16]. Since the first versions of the project, many device vendors are trying to differentiate their device by modifying the system. Many of them (e.g. Samsung, HTC) provide handsets with an already modified system. The user interface is typically enhanced. Because of that fact, it is not possible to release an update for all Android devices at the same time the device vendors must first modify the system and thus delay the update. Also, many (typically older) devices do not receive an update at all, despite the fact that 2. Capacitive sensors detect a touch of a conductive element, such as human finger 3. An object oriented programming language developed in early 1980s. It was created by adding Smalltalk objective funcionality to C

23 % 39.7 % 4 % 0.1% 4 % Other 23 % x Figure 3.1: Android version usage (source: about/dashboards/index.html ) they are capable of running it. This also causes significant granularity in Android versions running on some devices. Nowadays (April 2013), the most widespread is still version 2.3.6, despite that latest Android version is version 4.2 (See Figure 3.1) Applications for Android are developed in Java with the support of the Android software development kit. These are converted to standard Java bytecode, which is then translated into the Dalvik compatible files. Such application run on Dalvik virtual machine, which is a process virtual machine developed by Google Inc. for mobile devices. It is also possible to develop parts of application using C or C++ and native tools (Native Development Kit), which is convenient for high-performance tasks[11] API Analysis Android offers a complex API for work with NFC, a developer can choose between various levels of assistance from the system. Android offers two methods of NFC processing data from an NFC tag and data exchange between two devices. 15

24 Tag Handling The backbone of NFC tag reading is Android s tag dipatch system. Once a device receives an incoming tag, it tries to parse the data and map the message to one of the following entities: ACTION_NDEF_DISCOVERED when incoming data complaints to a NDEF wellformed message and the system recognizes its MIME 5 type, the message is recognized as an NDEF message. The recognition also depends on particular TNF of the message (see 2.2), meaning some of the types are not considered as ACTION_NDEF_DISCOVERED, namely: Empty, Unchanged, and Unknown. ACTION_TECH_DISCOVERED when the system fails to recognize incoming data as an NDEF well-formed message, it encapsulates the message as the ACTION_TECH_DISCOVERED entity. It can happen when NDEF data cannot be mapped to MIME type or when the data a message begins with is not NDEF formatted. Also, messages with mentioned TNFs (Empty, Unchanged and Unknown) fall to this subcategory. ACTION_TAG_DISCOVERED this entity encapsulates both previous types. An application can subscribe to one of the mentioned intents. The intents are subsets of each other, so a developer can decide what kind of message an application will process. For instance: the developer knows an application will be used only for reading tags which were created by the same application, so the content format is clear and the application subscribes to the highest ACTION_NDEF_DISCOVERED entity. On the other hand, there can be an application designed for reading various other tags (e.g. to analyze them) and it would be convenient to receive all the messages the system receives. Because of that, the application subscribes to ACTION_TAG_DISCOVERED. When system receives a message and finishes creating the intent, the tag intent system dispatches intents from their highest priority. For instance: when 5. Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of . 16

25 the system receives NDEF well-formed message, it begins with dispatching an ACTION_NDEF_DISCOVERED. When no application receives the intent, the intent system dispatches the message as a lower entity ACTION_TECH_DISCOVERED and ACTION_TAG_DISCOVERED after that. This way all the applications have the opportunity to receive all the intents they subscribed for. Intent subscription can be further filtered. When an application subscribes for ACTION_NDEF_DISCOVERED, it can filter messages according to their MIME type or URI format. For ACTION_TECH_DISCOVERED intent, messages can be filtered for particular technologies, i.e. NFC tag types. Subscription can be specified by adding a node to AndroidManifest.xml in the following format: <intent-filter> <action android:name="android.nfc.action.ndef_discovered" /> <category android:name="android.intent.category.default" /> <data android:mimetype="text/plain" /> </intent-filter> to a node of the activity which is to be invoked. When a tag arrives, onnewintent(intent) overriding method is called. From the given parameter one can obtain data from an incoming intent by calling getparcelableextra(nfcadapter.extra_ndef_messages) to obtain NDEF message or getparcelableextra(nfcadapter.extra_tag) to obtaing the Tag object, from which desired data can be extracted later. The message can be written simply by creating an Ndef instance with Ndef.get(Tag) enabling I/O 6 operation by Ndef.connect() and writing a message by writendefmessage(ndefmessage).[5] 6. Input / Output 17

26 Data Exchange A peer-to-peer data exchange can be performed using Android Beam service. An application can transfer data by calling setndefpushmessage(ndefmessage), where attached NdefMessage contains information about data to transfer (e.g. URI for the file to transfer) or the data itself. It is also possible to initiate Beam by calling setndefpushmessagecallback(), which accepts a callback, when an NDEF message can be created. This way it is guaranteed that the message is created once it is needed. Once the message is set, user can put two devices near each other and confirm data transfer. After that, a transfer is initiated and, if needed, a connection is handed over to bluetooth Implementation All the application logic is implemented in activity MainActivity.java. When the activity is created, the intent subscription is set accordingly and established. When a message from the tag dispatch system is received, an overloaded onnewintent(intent intent) method is called. The method processes the intent, extracts data and displays the payload content to the user. When user taps the Write Data button, a boolean property shoudwrite is set to true and after a tag is received, onnewintent(intent intent) method is called again, but this time it calls write() and passes on the content of an EditText component and a tag on which the method should write. Once it is done, it instantiates an Ndef class and writes the message. Subscription for well-known text type messages is achieved as described earlier an intent-filter record for ACTION_NDEF_DISCOVERED intent with filter for text/plain MIME type was added to a MainActivity in AndroidManifest.xml file. This way once the user taps the tag with the right message, the application is offered to launch. 18

27 3.5 Windows Phone 8 Windows Phone is a mobile operating system developed by Microsoft Corporation. It is a successor of the Windows Mobile operating system. Windows Mobile was introduced in April It featured full multitasking, support of various devices and a user interface that was designed mainly for stylus control. In 2007, when the first iphone was introduced, there were efforts to enhance an interface and optimize it for touch control[18]. In 2008, Microsoft started development of a new version of their mobile operating system Windows Phone. It should have been released in 2009, but because of several delays it was introduced in February November 8th, Windows Phone 7 was publicly released[9]. While Windows Mobile was aimed mainly at enterprises, Windows Phone is focused mainly on the consumer sector. However, in order to keep the system simple and usable for a wide range of customers, many advanced features were not supported in the first release (e.g. multitasking). Some of them were added in next versions. In addition, Windows Phone is not backward compatible with applications developed for previous versions of the OS[18]. In October 2011, Windows Phone 8 was introduced. It featured support for multicore processors, multiple screen resolutions, etc. Also, it brought NFC standard support. Windows Phone 8 adopted many components from Windows 8 (mainly NT kernel) in order to provide simple porting between these two platforms. Due to this, devices equipped with Windows Phone 7 are not able to upgrade the operating system. The official development platform for Windows Phone applications is.net 7 with the C# programming language. Windows Phone does not support the whole.net, only some parts can be used. User interface can be developed using XAML 8. Since Windows Phone 8, C++ or a JavaScript/HTML combination can be used for development as well. Also, all three methods can be combined[12]. 7. Software framework developed by Microsoft Corporation 8. A declarative XML-based language created by Microsoft Corporation 19

28 3.5.1 API Analysis Most of the types of close range wireless connection are implemented using Proximity API. It is a set of classes offering support for connection management, its establishment, subscribtion and handling. Proximity also offer out-of-the-box support for connection handover and data exchange between two instances of one application. Concerning NFC, Proximity offers an easy way to implement NFC use cases. However, some aspects are limited. Proximity limits NFC only to usage of data in NDEF format. However, the system does not offer tools to manipulate NDEF messages directly. Several predefined data types are offered instead. For instance: Windows a message containing unspecified binary data WindowsUri a message containing an URI WindowsMime a message containing data given a specific MIME type (e.g. WindowsMime.image/jpeg for a JPEG image) LaunchApp a message, which, when read on a Windows Phone device, triggers a specific application launch NDEF an NDEF formatted message. There are several subtypes, e.g. NDEF:URI (formatted NDEF URI message) or NDEF:wkt.T (NFC Forum well-known type formatted message) For Windows, WindowsUri, WindowsMime and LaunchApp, there also exists the :WriteTag subtype, which has to be used when the message is to be written to a writable NFC tag. Although Proximity API does offer NDEF types, its further handling is not supported. An external library NDEF Library for Proximity APIs 9 can be used for such purposes. The library provides classes for working with NDEF messages on top of Proximity API. Using this library, one can read all the data contained in an NDEF

29 message, including record headers, and easily create new messages and records, which can be sent via Proximity later. Subscribing for incoming messages can be done easily through Proximity API by calling ProximityDevice.GetDefault();, which returns a reference for ProximityDevice, on which we perform subscription by calling SubscribeForMessage(Stringˆ messagetype, MessageReceivedHandlerˆ messagereceivedhandler) where messagetype is a type of a message, which we want to receive (e.g. "Windows.SampleMessageType") and messagereceivedhandler is a callback for a function, which should be called once such a message is received. Publishing message is performed by calling PublishMessage(String messagetype, String message, MessageTransmittedHandler messagetransmittedhandler) where all parameters are similar to the previous method description. As was mentioned, although usage of Proximity API is simple, there are some severe limitations. For instance, because the system offers NFC API only on the NDEF level, it is not possible to format an unformatted NFC tag. Also, it is not possible for application to register for receiving specific type of massages, as we show on the prototype implementation.[6] Prototype Implementation For a development platform, we chose a combination of.net and XAML for the user interface. All the application logic is implemented in MainPage.xaml and its source file, MainPage.xaml.cs. During an object creation, a subscription for well-known Text type messages is performed and MessageReceiverHandler is registered as a handle for incoming messages. Once the user scans the tag, this method enumerates all the records and if a NDEF Text record is found, it prints the payload content. A tag write procedure is initiated by clicking the Write Data button. 21

30 BtnWriteText_Click method is registered for this event. Once it is invoked, an NDEF Text message is created using the method provided by NDEF Library for Proximity and PublishBinaryMessage is called. Once the user taps the tag, the message is written and, once it is done, the user is prompted by a message. Due to system limitations, it is not possible to register the application for receiving specific messages (in this case, well-known text type messages). It is possible to write a specific record instead. Such a record is of an internal windows.com/launchapp type. Inside a record s payload there is an application s name and its unique identifier. When such a record is received by Windows Phone 8 device, it tries to launch the specified application. The record in question has to be the first record in an NDEF message, otherwise it will not trigger application launch. Because of that limitation, we implemented the possibility to write a LaunchApp record to the NDEF message. This can be done by checking Write application launch record checkbox. 3.6 BlackBerry 10 BlackBerry 10 is a mobile operating system developed by BlackBerry Inc. (formerly Research In Motion). The first BlackBerry device was introduced in Since that, BlackBerry has become famous for their handsets featuring full keyboards and the capability of pushing , calendar and contacts to the device. Since the first device, all the BlackBerry products were aimed on the entreprise market. However, with ios and Android-enabled devices gaining market share, BlackBerry started to lose its customers. In November 2012 a new operating system version, BlackBerry 10, was announced. The new version brought a whole new user interface focused on finger gestures. It also featured full multitasking and connectivity with many services and social networks. Development for BlackBerry 10 is possible using native C++ or Qt 10 framework with Cascades 11 for UI development. One can also use JavaScript and HTML combinations 10. Cross-platform aplication framework built on C A set of visual components written on top of the Qt framework. Cascades components can be used 22

31 to develop a BlackBerry WebWorks application. The developer can use standard JavaScript libraries or take advantage of existing tools and frameworks for developing mobile applications by web technologies, e.g. Sencha Touch 12. Also, an existing Android application can be ported for BlackBerry 10. Currently (April 20, 2013) only Android applications can be ported. Support for Android 4 is planned[8] API Analysis BlackBerry offers two ways for NFC use case implementation. For the more basic needs, one can use tools and libraries included in Cascades framework. If the capabilities offered by the framework are inadequate, one can make use of Core Native libraries for NFC[10]. Cascades API Cascades framework offers support for sending and receiving content between two devices or between a device and a NFC tag. It also provides out-of-the box support for Bluetooth handover (See 2.3.2) and application registration for specific NFC content. All the communication takes advantage of Invocation Framework. It is a mediator between installed application and selected services. When an application is able to work with some kind of a content, it registers for it through the Invocation Framework. The content can be a specific file format, an event or a message from the system, NFC in our case. When an application or a system receives such a message, it notifies the Invocation Framework, which hands the message over to the application registered for the given type. This way a user can e.g. tap on an attachment received through an e- mail. An client invokes the application registered for the right type, which opens the attachment after receiving the invocation. Invocation Framework is also used for receiving NDEF messages, so it plays a major role in NFC implementation. from C++ code as well as from QML (Qt Modeling Language)

32 In order to register an application for specified content, a developer adds a record to a bar-descriptor.xml 13 But invoking an application causes only its launch. In order to work with received content, an application must connect to the invocation framework and handle the received invocation accordingly. This can be done by calling: QObject::connect(const QObject *asender, const char *asignal, const char *amember, Qt::ConnectionType atype) where asender is a pointer where a returned invoke manager will be stored, asignal is a signal, for which we are subscribing (e.g. invoked(bb::system::invokerequest)), amember is an originating object, and finally atype is a slot, which should be called when invoked signal emits a message. When implemented, a slot method receives an invoke request, which can be processed accordingly. As for sending content, one can implement such functionality in two ways, either with the use of NFC Share Cards or without. NFC Share Cards are one of the possible cards that can be invoked through Incovation Framework. By a card, we mean a system interface, which offers sharing given content with registered applications. This can be done by setting an InvokeRequest to bb.action.share, and set the message type, uri and data, and sending it to the invocation manager. A system responds by presenting a screen with share choices and, if the user chooses one, handles the connection. A system also decides how the data will be transferred if the amount of data is low (below 1 kb), it will be transferred through NFC. If the amount of data is larger and the other device supports it, a connection handover from NFC to Bluetooth is performed. Since using Share Cards is simplistic, its usage is fairly limited to sending and receiving data. Also, the logic of presenting sharing options can be inappropriate for some use cases. The same use cases (and more) can also be achieved without using NFC Share Cards. When a developer decides not to use them, it is necessary for the app to make sure it supports NFC functionality. If so, an application initiates NfcShareDataContent or 13. A file containing basic info about an application, like a name, supported display orientation etc. For more information, see com.qnx.doc.ide.userguide/topic/capabilities_editor_options_base.html 24

33 NfcShareFilesContent (depending on the nature of the data), sets uri and data type accordingly, and registers the object with NfcShareManager. After, the app waits for an NFC tag or device and transfers the data. As with NFC Share Cards, the system decides whether the content should be transferred by bluetooth handover or directly by NFC.[10] Core Native API Native libraries offer low-level access to the NFC system. At the cost of more responsibility being given to the application itself, one can take advantage of the large amount of capabilities NFC can offer. Beyond the capabilities of Cascades API, native libraries offer: Logical Link Protocol connection NFC tag emulation Secure Element control card emulation (e.g. ticketing, credit card emulation) A straightforward approach to start receiving NFC events is initializing Black- Berry Platform Services 14 by calling bps_initialize(); and waiting in cycle for an event. The Native library also offers bb::abstractbpseventhandler for inheritance, which allows the subscription of for specified events and, when one is received, an reimplemented event(bps_event_t *event) method is called. In this method, one can further process the received content, read or write data etc.[2] 14. A library, which provides interface for various system services 25

34 <invoke-target id="com.example.nfcbb"> <type>application</type> <filter> <action>bb.action.open</action> <mime-type>application/vnd.rim.nfc.ndef</mime-type> <property value="ndef://1/t" var="uris"/> </filter> </invoke-target> Figure 3.2: bar-descriptor.xml tag registration record Prototype Implementation The base of our prototype application uses Cascades framework. For demonstration purposes, reading an NFC tag is implemented using Cascades libraries and Invocation framework, and writing takes advantage of BlackBerry Platform Services and Core Native libraries. Additionally, a user interface is implemented in QML. An application logic is implemented in a single MsgReceiver class, which interacts with UI through Q_PROPERTY macros 15. After an application starts, an instance of MsgReceiver is created. The object automatically connects the application to Invocation Framework and listens for the incoming action specified in bar-descriptor.xml (see Figure 3.2) accordingly. When such an action occurs, an invokereceived slot is called, where the received data is parsed to an NDEF message, the first record from message is extracted, and a payload of a record is displayed. Because the application subscribes only to well-known type text messages (see Section 2.3), there is no need to check whether the incoming message has the right type. The writing procedure is triggered by tapping on the Write Data button. When this occurs, the content of an input field is handed over to the MsgReceiver instance. As a result, a subscription for invocation is terminated and Blackberry Platform Services handler is initialized. The application also registers for tags and prompts the user to provide a tag for writing the message. If the user does, the identifier of an incoming 15. a Qt framework provided, which specifies read, write, and signal methods for given variables and enables to use them in QML code 26

35 tag is received. Afterward, the application creates an NDEF record. After the message is written, the user is again prompted that the message was written successfully, and the application unsubscribes from NFC events, shuts down BPS and resumes subscription for invocations, so the user can again read tags. Application launch after a tag a with specific NDEF message is received was achieved by the same approach as was described in Platform Comparison Leaving the platform analysis and implementation of the demo applications, we can now compare the platforms in question. Each of the three further analyses of these platforms offer an easy way to use NFC. However, comparing with Android and Blackberry 10, Windows Phone 8 suffers from severe gaps in implementation: It is not possible to access NFC tag on a low level. A developer can only work with a tag through NDEF format, so it is not possible to work with tag whose content is not a NDEF well-formed message, or even format a new tag to NDEF. It is true that NDEF became a standard for NFC data exchange, but constraining NFC to this format limits the usability of NFC. Also, Proximity API for Windows Phone 8 offers only some types of NDEF content. These types are mostly platform-specific, although they matches the NDEF when written on a tag. However, when one needs to work with NDEF formatted messages more deeply than only specifying its content, an external library is needed. Thankfully, there is a library that offers NDEF message creation and maintenance tools (mentioned in 3.5.1). Windows Phone 8 is also limited by its inability to subscribe to specific messages. It can be substituted by writing a LaunchApp record, but this solution has some flaws. For instance, the LaunchApp record cannot be used by other platforms and it takes up space on a tag. Overall, NFC implementation on Windows Phone 8 is the worst of all three platforms. Its usage is in many ways limited to the platform only and some use cases simply 27

36 cannot be implemented due to lack of support from the system. Also, the official documentation does not always contain all the information needed, and a developer must often search for the info because there is no main document, that contains a summary of NFC implementation in the system. Android and BlackBerry 10 offer more or less separated API for use cases of various complexity. For instance, when implementing an NFC use case in BlackBerry, one can use Core Native libraries for a simple task, but it is more convenient to take advantage of Invocation Framework as it offers more straightforward access. On the other hand, when a developer needs more detailed control over an implementation or the use case is just more complex (Secure Element usage for instance), Core Native libraries can be used. Android also offer such scalability in API. It is neccesary to mention that Black- Berry also offers limited NFC API for other development platforms WebWorks and Adobe Air. Considering documentation, both Android and BlackBerry offer extensive documentation of their APIs. Android published a document containing all the basic information for NFC development for the platform. Knowledge contained in this document should be sufficient for a developer to implement most of the basic use cases. Overall, we found Android NFC API the best implementation of NFC standard of all three platforms. It offers all the tools needed to interact with NFC on a low level, working with specific parts of NFC (e.g. Secure Element), but on the other hand, it is also possible for a developer without knowledge of the API to read basic documentation and start programming right away. 3.8 Chapter Summary In this chapter, we defined the methodics of platform analysis and described a demo application, its features and main use cases. Afterward, we introduced four mobile platforms, namely ios, Andrdoid, Windows Phone 8 and Blackberry 10. For those platforms, we described how NFC is implemented and what each platform supports. We also described how we proceeded in demo application implementation (source codes 28