2012-11-01 Android Developer Lab+ NFC


Uploaded by androiddevelopers on 31.10.2012

Transcript:

TONY CHAN: Hi, everyone.
Sorry again for the technical difficulty earlier.
So I hope now everyone can see everything OK and no echo.
So let's jump straight to the news.

So the news of this week, so we have new devices.
So we just announced this week, the Nexus 4.
It's a Quad core Snapdragon S4 with a Snapdragon processor
with the largest 4.7 inch screen.
And it has NFC, actually, which is what we are going to
talk about today.
We have also another new device.
It's a 10 inch device.
It has a super high resolution--
it's 2560.
And so I'm sure you guys can read more about these two
devices on the internet.
And of course, the new version of Android 4.2, we just
announced it.
And along with that, we have also pretty good guidelines of
how to build high quality tablet applications, and also
in general high quality applications.
So we added some more documentation guidelines to
help developers to build high quality applications.

Another major news we have, we now have
seller support in India.
You can read more about that in the blog post, but just
want to clarify something.
The seller support also includes in-app billing.
And subscriptions are also included.

The Google+ experiment we announced earlier.
So we still need to gather all the submissions.
And we will follow up with you guys next week.
So stay tuned.

So now back to our presentation this
week, which is NFC.
So let's take a look at what NFC is.
Just before we dive into the implementation details, so
let's take a high-level overview of what NFC is.
So NFC stands for Near Field Communication.
It's really based on the RFID technology.
It's a short-range technology.
So usually when the device to the NFC tech card is between 4
centimeters or less,
communication will start happening.
You can also share a small payload, usually in kilobytes,
between NFC tags and an Android device, or between
Android devices.

So the most common data format people use for NFC is NDEF.
Also, we will talk a little bit more about
that in future slides.
So what is NFC for?
Actually, you can use NFC for a couple of things.
The first one is social.
I mean, you can share contact information using NFC, which
is one of the most common use cases.
And also, you can use NFC to do bootstrapping for Bluetooth
and Wi-Fi connections.
So Anirudh will talk a little bit more about that, and also
the Android technology, Android Beam.
So Anirudh will cover that later on.
And the third use case of NFC is in commerce--
so for example, contact-less payment like Google Wallet.
But that is a little bit outside of our topic today
because Google Wallet requires the access
to the secure element.
And if you are interested in becoming a partner of Google
Wallet, you can go to the link below here to send us
information.
But that's not something we're going to cover
today, Google Wallet.
We're going to focus on the technology today.
So for NFC, there are a few communication protocols.
So these are the protocols.
So I'm not going to spell out all of these
ISO standards here.
But the key thing here is we have Android classes to talk
to these protocols.
and so I kind of highlight that with the bullets here.

And besides the protocol, we have different
types of NFC tags.
So the standard ones defined in the NFC forum, there are
four major types.
And there are products, actually, implementing these
different types.
So some of the more common ones, probably that you guys
see most, are the MIFARE ones and the Sony FeliCa one.
But there are four major types of tags in NFC.

I have actually a very nice table to summarize all these,
to put things together.
So stay tuned.
And besides the NFC forum standards, there are also
other types of tags.
So the MIFARE Classic one is one of them.
And it's also very popular--
NXP is using this type of tag.
And there's additional operation you can do with
these tags.
And we have a special class, actually, for these also,
called MifareClassic.

So what is NDEF?
So we talked about formats of data we use in NFC, and I
mentioned NDEF is the most common standard.
So NDEF actually stands for NFC Data Exchange Format.
It's really a lightweight binary message format.
And one thing about NDEF is an NDEF message can have many
NDEF records.
And for data with an application-defined payload
can be actually encapsulated in one or more NDEF records.

So let's take a look at the NDEF record, talk a bit more
about that in detail.
So an NDEF record is composed of a header and a payload.
So in the header, it has a 3-bit Type Name Format.
And it also has the type itself--
it's in variable length.
It's from 0 to 255 bytes.
And the same thing for the ID.
It's optional and not very often used.
And then the payload.
The payload can actually have data up to 2 to the power of
32 minus 1 byte.
So that's the structure of the NDEF record.

So here's the big picture side, a summary of all the
relationship between all the classes.
So if you look at the NFC stack, so you have the analog
things at the bottom.
And then you have the different
communication protocols.
And there are two major types of
applications people can build.
So one is using the standard NDEF message format.
And within that, you have the NFC forum standard Type 1 to
Type 4 tag and also have the MIFARE Classic tag.
And the stuff in blue is actually the Android classes
we have to the implementation for those
particular types of tags.
And for non-NDEF format applications, we also have the
corresponding classes to allow a developer to talk directly
through the protocol.
So we have all these NFCA class, which corresponds to
the ISO 14443-3A protocol, and et cetera.
So it's mapping these route protocols if the application
is not using the NDEF data format.
So that's a nice summary of all these things together.

So now let's start to talk about how Android actually
reads these tags and then how to dispatch these tags to your
applications.
So again, the two major categories, one is the tag
using the NDEF format, and the other one is using the
non-NDEF format.
So we have different action types, essentially
following the order.
We first try to see whether something matched the NDEF
data format first.
So we have an action called NDEF discover.
So if there is an activity that matched that action, we
will route the intent to that application.
So we will see some example of how to set up these
[INAUDIBLE]
in your application later.

So back to the picture, if the NDEF discover action, we don't
see any NDEF-format tag, we will fall back to the tag
discover actions and then to the tag discover actions.
So this is how the Android decision tree to decide how to
dispatch all the NFC tag it reads from the fail.
So now, how to request NFC access in the application?
So as you guys probably can imagine, this definitely has
something to do with the manifest.
So the first thing you need to do is to add a special
permission.
It's android.permission.nfc.
And for filtering application in Google Play, you want to
use the feature use_feature tag specifying the hardware.
So if NFC is really an optional feature in your
application, you can consider setting the required
attribute to false.
And you can also check NFC runtime availability by using
the getDefaultAdapter() method.
If it equals null, that means NFC is not available in that
particular device.

So another thing is you have to set the minimum SDK version
in your application.
So the minimum SDK version that will have NFC support is
API level nine.
So in this level, we will support the
ACTION_TAG_DISCOVERED action, but we recommend developers to
at least specify level 10, because it has a much more
comprehensive read/write support in level 10.
And also you can do foreground NDEF pushing.
In API level 14, we added Android Beam support and also
some extra convenience methods to create NDEF records.
So at least use API level 10.
That's our recommendation.

So filtering--
let's take a look at how you set up your activity to
capture these NFC intents.

So one of the actions you can filter by is the
NDEF_DISCOVERED action.
In this example here, you can filter by MIME type.
So you can specify if the MIME type is plain text, you have a
data tag and specify the MIME type, that's how you filter
NFC message--
by MIME type.
And if you want to do filtering by URI,
you can also do that.
So it has a different data tag, specifying the host or
prefix of your URI.

And the next actions--

after the dispatch system couldn't find a match on the
NDEF_DISCOVERED action, we'll fall back to this
TECH_DISCOVERED action.
And in order for this to work, your application has to
specify an XML resource file to specify the list of
technology the NFC tag you're reading--
your application--
the list of NFC technology has to support before your
application can process the NFC tag information.
So in this case here, what you are trying to say here is your
application will only take NFC tag that can support the
entire list of NFC technology.
So it's a pretty long list of things.
I think in reality, you only want to specify a field,
because this is really end cases.
So you're trying to find something that supports all of
these technologies--
it's not all.
So how to do an all in the tag lists--
so if you specify multiple resources, like this example
here, so you're trying to filter something.
If the NFC tag is supporting NFCA and NDEF and all is
supporting NFCB or NDEF, both of them will match, and your
applications can serve both of these NFC cards.
So if you need to use the all semantics, this is the way how
you define the tech list.

So another fallback is using the TECH_DISCOVERED in your
activity, you pretty much just filter by the TECH_DISCOVERED
tech actions.
And then you add the metadata tag, pointing to the
resource XML file.
So this is how you include the filter in your manifest.

So did I miss--
OK.

So how to obtain information from the intent.
So it's pretty straightforward.
There are two ways you can do it.

If you want to have the NFC tag, you can always do the
getParcelable data extra, calling the EXTRA_TAG.
And it will return you a tag, and you can just look through
and get them to find out the list of technology.
But there's also a very convenient way.
If you know you are only processing NFC tech using the
NDEF data format, you can use the NDEF_MESSAGES extra to get
a list of NDEF messages.
So the [INAUDIBLE]
here is really an example of how you get the NDEF messages.
So you pretty much get a list of parcelable, and then you
[? cast ?] these raw messages to the NDEF message to just
look through it.

So the next session, Anirudh is going to talk
about Android Beam.
So I pass it to Anirudh.

ANIRUDH DEWANI: All right.
Thanks, Tony.
So to begin with, what's Android Beam?
It's something that's based on something called NFC NDEF
Message Push.
So this is about pushing messages from an app that's
running on the foreground, an activity that's running on the
foreground to another activity running on another phone.
So that's the push part aspect--
TONY CHAN: By the way, can you guys see the slide when
Anirudh talks?
MALE SPEAKER 3: I can, Tony.
TONY CHAN: Andrew, you can?
How about Andrew?
Andrew, can you see the slide when Anirudh talks?

Andrew, can you see the slide?

ANIRUDH DEWANI: He has a [INAUDIBLE]
message, but he can highlight it to see.
So it's probably not getting recorded.
Tony, let me do something.
I will share my desktop instead.
TONY CHAN: OK.

ANIRUDH DEWANI: All right, I think we've got my slides on
the screen now.
So as I was mentioning, NFC is based on NDEF
message push format.
And it's basically NDEF message, like Tony explained,
it's something that contains zero or more NDEF records, the
first record being something that contains the URI or the
MIME type of the content that your NDEF message contains.
For example, if it's an image, you would have something with
the image MIME type.
Or if you have text, you would set ASCII as the MIME type.
So that's your zero position NDEF
record in the NDEF message.
Now, this message with these records is pushed from one
device when in close proximity.
And that's the basic concept of NFC.
When you bring devices in close proximity and when your
app is running in foreground, that's when NFC beam is
activated, and it tries to push the message from one
device onto the other one.

So as a programmer, how do you enable your app or make your
app Android Beam capable?
It's quite simple.
There are two options of how you can do that.
The first one is, you basically invoke the method
setNdefMessagePush().
So when your app is running, your activity is in the
foreground, you call this method, and this method is
usually used if you have a static data to be pushed.
For example, you may want to push the link
of your app to download.
And this is something static, and this is the method you
would use when you have to push that kind of data.
The other option is that you can have your activity
implement something called CreateNdefMessageCallback.
And so as soon as your activity then comes into
foreground, the system invokes this method, calls your
activity back using this interface.
And the only method that you have to implement from this
interface is the createNdefMessage method.
So this method is where you have to provide the
implementation of how you create the message and return
a message from the method.
So the framework would invoke the callback, and
this method is called.
And at this point, you should return the
created NDEF message.
So this is more useful when you want to add some context
to your NDEF message.
So depending on what state your activity is, or maybe,
for example, if you're on YouTube and you have some URL
that you're watching right now which you want to push to the
other guy so there is some context here.
So you would use this implementation of using a
callback and create the NDEF message appropriately by using
the context from your activity and embedding that data onto
the message and parcelling that message through.
And when this is done, what you get is a callback called
setNdefPushCompleteCallback.

This is the callback that's invoked when the system is
able to reliably beam the message to the other device.
So what we've discussed here, there's a short snippet of
code on how it's implemented--
very simple code.
OnCreate we set the NDEF message push callback.
And this is the other implementation, which is the
implementation of implementing an interface callback.
So we have a method implemented here called
createNdefMessage, which comes from the create
NDEF message callback.
At this point, what we do is we construct an NDEF message.
So like we said, NDEF message is basically an array of zero
or more NDEF records.
So in this case, what we do is, we have this method called
createMimeRecord, and this is a custom method.
So what createMimeRecord does is basically creates the first
NDEF record as the MIME type of the data.
In this case, ASCII is the MIME type because we are
sending some text across.
So what it does is puts the MIME type as the first NDEF
record and then uses the rest of the message--
in this case, it's just a text that says "beam me up." And it
uses this to add to the payload of the NDEF message,
which is the records falling from index one, two, three,
and as long as your data is.
But the first record is always the MIME type.

And how do you receive this Beam message?
So what we've done till now is we've
created the NDEF message.
And when our activity's in foreground, the system will
try to beam this message.
So on the other device, which is in close proximity, you
have to filter your NFC intent ACTION_NDEF_DISCOVERED.
This will make sure that the system knows that you have a
component or you have an activity that's interested in
this intent.
And when you declare this intent, you declare it with a
URL or MIME type of interest to you, which means--
so for example, a code that we just saw in the last slide was
trying to send you some ASCII text.
So when you declare this in your manifest, you may say
that I am only interested in text.
If there's an NFC intent with a message that's carrying
text, I'm interested.
Or if there's an NFC message carrying some image data, I am
interested.
So you declare also your MIME type of interest.
So again, like we said, it should be the same as the
first NDEF record of the incoming message.
Because that's where we kept the MIME type of the message.
So once you do that, and let's look at some simple code--

here it is.
This is the method that's invoked on new intent, which
is what we'll get called when--
[INAUDIBLE].

So this method is what we're invoking on new intent.
And so that means there is an incoming message now that we
are ready to process.
So what we do now is using the GET_EXTRAS of the intent, we
try to obtain the raw message, which is the NDEF message.
And the NDEF message is the 0th or the beginning element
of the raw message array.
And this is the only element right now.
So once we get the NDEF message, what
we want to do is--
the actual message, because the 0th element is the MIME
type or the URL type, what we want to do is get the payload
starting from the 0th message.
So we say, ndefMessage.getRecords.
And we use the method getPayload, which will give us
the following records from the MIME type, following the MIME
type record.
And this is basically the text message that we had, which
said "beam me up." And this is how you obtain the message.
So as you can see, it's just 10 lines of code on both sides
on both devices.
And sending the intent as well as receiving the intent, and
your app is now NFC Beam capable.
You have some more use cases like Tony discussed-- how to
set up a handshake for Bluetooth with NFC.
And then in this case, you might want to exchange some
more data of different MIME types between the two devices
if you want to initiate a Bluetooth connection or if you
want to send across images or some other text data.
But in general, this is how NFC works.
Move the MIME type under the first record, create the other
records with the payload, and push the payload across.
Declare the intent NFC discovered.
And then once you have the intent in your activity on new
intent, you try to process this message by obtaining the
raw record and then getting the payload from the record.
And all this happens on foreground.
And that's how NFC Beam works.
Your app has to be on foreground.
So just a use case here.
What may happen sometimes is that there may be multiple
applications on the device that may be interested in
listening to NFC incoming messages of a
certain MIME type.
This could be very common for something like a contact or
image or text-- there will be multiple applications.
So if your application is beaming that message and you
want to guarantee the delivery of the message back to your
app on the other phone, what you can do is use something
called Application Record, and this is
Android Application Record--
AAR.
This is very simple implementation.
What it does is just puts the package name of your app in
the NDEF message.
Which basically means inside the NDEF message, everything
is an NDEF record.
So this basically means that we are creating an NDEF record
which contains the package name of our app.
So this is to specifically target your app at the
receiving end of the message.
This increases the probability that your app will be the
first app to pick up the message.
Or your app is the intended receiver of the message.
So just to summarize what we saw in terms of a graphical
illustration, on the top you see a device that has the Beam
foreground UI activated, which means the device is ready to
beam a message.
At this point, we use the createNdefMessage method from
the createNdefMessage callback interface to create our
message and send it to the system
adapter, the NFC adapter.
So once you create the message, this message is
beamed to the other device using NFC technology.
And if you have the intent ACTION_NDEF_DISCOVERED on your
app, this message will be delivered to your app.
And the format of the NDEF message would indicate what is
the MIME type or the nature of the data in your message.
And based on this, you will have your intent [? filter ?]
declaring those MIME types.
And once you receive the data, you're able to pass it getting
the raw record and then looking to the
record for the payload.
So this pretty much summarizes what we have to offer for
Android Beam right now.

Yeah, that wraps up our live presentation for today.
So Tony, we can move to Q&A?
TONY CHAN: Yeah, sure.

So Let's take a look at the
questions we have on moderator.
So the first one I see is from Anatole from Ukraine.
So I need to authorize users, but I don't want them to fill
in some data manually.
So after receiving a confirmation email, I want
Excel in my app to be started.
Can you use URI like this?
My app colon-slash-slash some data in Gmail client because
it knows the URI.

So we talked about intent filter.
And I believe in the Gmail client, actually, the standard
HTTP URI is actually working.
And so in your applications, one suggestion I can think of
is you can have an intent filter actually filter by some
specific URL.
So if you have some URL only your application can
understand, so you can use that to filter by that.
So you don't need to use a different kind of scheme.
So that would be my suggestion.
Anirudh, do you have anything to add on top of that?
ANIRUDH DEWANI: Yeah, I think that's the easiest way-- to go
through something that the framework already understands.
And what the Gmail understands is the HTTP URI.
The other thing I could think of is maybe your confirmation
could come as a file which is off your application type.
And once the user downloads the file, maybe a patch, an
unlock patch or something.
When the user downloads that file, your app is registered
to open the file of that type.
That may be another way of handling this.
TONY CHAN: Cool.
So the second question we have here is, anything new about
NFC in 4.2 API level 17 that you are allowed to talk about?
So I haven't seen actually anything I am aware of that's
super-new on 4.2.
So I need to double check that.
And if we have something that we can talk about, maybe we
can talk about that in future [INAUDIBLE]
class.
So yeah.
So why don't you take the next question?

ANIRUDH DEWANI: So the question is from Flight
Engineer, Austin, Texas.
And the question is, I would like to replace the incoming
call screen with a small overlay.
But it appears that there is no way to disable the default
incoming call screen in [INAUDIBLE]
app.
Any creative ways of achieving the desired result?
Requiring root is a possibility.
So I would not comment on what you can achieve by rooting
because I'm not really familiar.
And it's not something we recommend anyway to our users.
So yes, you are right.
The phone application is the standard application.
And you can't put textual or graphical canvas
overlays over top of it.

TONY CHAN: This is really for security reasons.
ANIRUDH DEWANI: Yeah, pretty much.
TONY CHAN: Yeah, the fourth question is coming from
Russia, from [INAUDIBLE].
So I have a positive experience on Android platform
for porting application built on frameworks like Spring,
Hibernate, AOP, et cetera.
I would like help to continue development in cooperation in
this field with you.
So that doesn't really seem like a question.
But we are glad, actually, that you have good experience
with porting applications.
Feel free to leave us some more comments or some specific
questions in G+ in the future if you have anything.
ANIRUDH DEWANI: Yeah.
Just add something to it.
I think there are some open source projects that are
catering to these frameworks or applications of these
frameworks on Android.
I surely know there is something
called Spring Android.
And definitely [INAUDIBLE].
So there is [INAUDIBLE]
or something like that available for Android.
And these are open source.
So I think a good avenue for you would be to work with
these guys.
Spring Android is a project where you can go and
contribute.
And yeah, so this is how you can work with
community that's one idea.

TONY CHAN: Anirudh, want to take the next one?
ANIRUDH DEWANI: Yes.
So the next question is from Shoshanka, Hyderabad, India.
The question is, I need the process of changing the bite
rate of an audio file which should be used on Android SDK.
So the question is not really clear to me.
So I get the first part, the process of changing the bit
rate of an audio file.
So we have media codecs where you can have an input buffer
and an output buffer.
And you can specify the media properties there.
But I don't get the part where you say which should be used
on Android SDK.

Do you mean what should work on the Android OS?

See, I'm not really clear.
Maybe if you can drop us a comment on what you want to
say with the second part of your question [INAUDIBLE].
But just in case, for handling the audio and video pipelines,
you can use a media codec, which is available on the
Android SDK.

TONY CHAN: So the next question is from
Sweden, from Mac 10.
So random users of my apps, maybe one user a day out of
200,000, get a Java I/O [INAUDIBLE]
exception permission denied when calling contacts open
file input.
A few seconds later, the file reading works.
So Mac and I actually took a look at the links you have.
And if doesn't actually give us too much information.
Maybe we really need to look at some code before we can
fully answer this.
But one idea I can think of may be, is it possible to have
some sort of raising conditions?
Like, the file it's actually reading doesn't exist in
certain cases?
So that's my guess.
How about you, Anirudh?
Anything you can think of?
ANIRUDH DEWANI: Not really.
I saw the [? stack list ?] there.
Maybe if you can obtain a buttress from the device which
will capture more information on what's happening there.
I can see there is a permission denied by the Unix
APIs there.
But yeah, a buttress would probably help narrow in on
what's happening, if you can grab one from your users.

Maybe even random failure of flash drive or storage.

TONY CHAN: So how about the last question?
Anirudh, do you want to take that?
ANIRUDH DEWANI: All right.
So the question is, what are the various best approaches to
develop static pages?
Each page contains text--
TONY CHAN: Oh, I think you skipped one.
ANIRUDH DEWANI: So that's the second to last.
Is card emulation supported?
If yes, then how do we do card emulation of Android devices?
Google Wallet is able to do.
Why not others?

I don't know the answer to this one.
So Google Wallet--
I don't know.
Tony, do you have any insights on how NFC is working?
TONY CHAN: I believe, actually,
emulation is supported.
Because I heard developer has done that before.
And also, when one Android device is talking to another
Android device, it's really some sort of emulations.
But I'm not 100% sure, is it really the true emulation?

I don't have a direct answer.
So maybe we can take a look at that and get
back to you next week?
Follow up with you?
ANIRUDH DEWANI: Also, I believe Google Wallet is
probably not using stable interfaces right now to work
against NFC, in the sense which can be published as part
of SDK [? enabled ?].
Everyone's sort of experimented
in what it's doing.
And once we have some kind of stable interface, that may
become a public SDK [? facing the API. ?]
AUDIENCE: [INAUDIBLE]

The APIs that we are talking about, I'm referring to seek
interface, which has been provided already, has been
implemented in many of the devices, such as the Samsung
and Sony devices--
The seek interface.
What we find is that it is not getting implemented in the OS.
That's why it's not a standard [INAUDIBLE].
Just hoping to get some kind of info if it is going to be
standardized in the future anywhere.
Is it there in the roadmap or not-- something like that?
Because people want to do something
with the seek interface.
They want to access the SIM card for certain reasons--
because a secure element has the [INAUDIBLE].
They want to access the secure element.
And being not able to do it is a limitation for many of the
applications.
So looking forward, is there any plan like that that you
guys are having?
ANIRUDH DEWANI: Yeah.
I mean, definitely there's work in progress--
even [INAUDIBLE]
when it was launched.
And even now, it was under specific devices.
Because like you said, it's not a stable
interface right now.
There are different
implementations that cross renders.
And so this is something that is being worked at.
And I don't know the timelines on when we'll have something
stable to be exposed as a backward
compatibility for our time.
But there's work in progress, and I can try to find out more
from the teams and update you on what progress is
[INAUDIBLE].
AUDIENCE: Also a small question.
Google Nexus S used to have
compatibility with the [? SWP ?]
chip, so it was able to have a communication over there.

The previous one, the Nexus 3, which [INAUDIBLE], there is a
[INAUDIBLE]
having it.
Are we expecting this to be there in Nexus 4?
ANIRUDH DEWANI: Sorry, can you repeat the first part?
I didn't really catch with the audio breaking.
AUDIENCE: I'm saying Galaxy Nexus was not having it, yet
Nexus S, the previous one was having the seek interface.
It was having the SWP chip, by which the SIM can communicate
on the NFC level.
Is there any possibility that Nexus 4 will be having it?
Is there any chance--
do you have it on the roadmap?
ANIRUDH DEWANI: I can find out.
I can find out.
I don't know the answer.
AUDIENCE: Thank you.
ANIRUDH DEWANI: So maybe you can join us next
week for the answers.
Or we'll try to post it to G+ on the [INAUDIBLE].
TONY CHAN: Yeah, try to post the question in G+ to us so
that we have a record.
And we can follow up easier.
So thanks.
ANIRUDH DEWANI: My ID is Anirudh Dewani.
And that's Tony Chan.
So you can find us on G+.
And maybe you can just tag us to post a question, and we'll
[INAUDIBLE].

TONY CHAN: So let's take a look at the last question.
So what is the best approach to develop static pages?
Each page contained text and optional images.
I'm thinking to use one activity ViewPager use as your
[INAUDIBLE]
pages of a real book while the user flips left and right
through pages of data.

ANIRUDH DEWANI: So depending on the size of the book that
you're talking about, 200 pages, maybe, you don't want
200 fragments sitting in a ViewPager with
data flipping across.
So what you probably want to do is instantiate something
with five fragments and try to buffer or cycle through your
content of the book so keeping some pages in the buffer so
user can go up and back.
And then maybe use just animations on a given fragment
or a view to have the content of the fragment being
replaced, the text and the image being replaced from your
data source again.
I mean, the strategy of using an activity of a fragment and
some animations would be good.
So Google Books itself was written within the script.
And the script is a low-level graphics and mathematical
computation library that we introduced.
So I'm not sure what the kind of development you see on it
going ahead.
But that's what Google Books was using at
that point of time.
But again, you have the options using Java, OpenGL 3-D
interfaces and to give those effects and animations.
And even the framework object animated properties can give
you animation to give the effect.
But yeah, I would look at a fragment with a view
containing text and images and some animations there.
TONY CHAN: Well, I guess that's all we
have in terms of questions.
And so thank you very much for watching.
And I hope you learned something about NFC today.
So we will be back next week.
Hopefully Ankur will be back too.
Anyway, anything else you want to add before we--
ANIRUDH DEWANI: Just a reminder that we are running
the Android experiments.
And the first one was about connectivity API.
So if you have some last minute
submissions, please go on.
And if you want to showcase your call of have us review it
or showcase what you've done, please submit it to the
Android Experiments page.
We're looking forward to it.
TONY CHAN: Cool.
All right.
I think that's it.
Thank you very much for watching.
And we'll see you next week.
All right.
Bye.