18 July: Android Developer Office Hours

Uploaded by androiddevelopers on 18.07.2012

>>Joe Malin: Hello, and welcome once again to Android Developer Office Hours. My name
is Joe Malin, and I have with me today DevRel people: Alexander Lucas, Reto Meier, Trevor
Johns, and from Google engineering, Francesco-- Sorry, I screwed up his first name.
>>Francesco Nerieri: Francesco Nerieri.
>>Malin: Thank you, Francesco. [laughter] The first thing we want to do is find out,
with a little intro from Francesco, about Google Cloud Messaging, which is a new service
that we introduced at Google IO. Go ahead.
>>Nerieri: Hi everyone. Google Cloud Messaging is a new service which is evolution from the
old C2DM service, which allows you to send messages from the Cloud to the device. This
is an important service if you want to avoid polling, which saves battery life because
your application doesn't have to work out the radio every X seconds or minutes due to
polling. But when the data is available on the Cloud, then the server can send it down
to the device. Improvement regards scalability, performance. There is a new set of features
for APIs that allows you to send multi-cast messages. With one request, you can send up
to 1000 messages. Up to one message to up to 1000 different devices. Time to leave,
so your messages can expire. And so on and so forth, a bit more. Other APIs.
>>Malin: Please send in or call in your questions. With that, we'll start now with the questions
from Moderator. The first question is: why doesn't Google provide developers with more
stats for the downloads, such as how users found the app, keywords, categories, related
apps, etcetera.
>>Trevor Johns: All right.
[electronic music playing]
>>Malin: Okay, thank you, Trevor. Next question, also about Google Play: how come selling apps
on Google Play is still impossible for most of the world because of country limitations?
Why is Google being so opaque on this matter?
>>Johns: Okay. We definitely do want to try and offer Google Play both for downloads and
as well for publishing in as many regions as possible. But different countries have
different legal climates. In some places, it's a bit easier for us to go and open up
shop than it is for others. We definitely do want to go to expand to, again, as many
regions as possible. It just takes a bit longer in some places compared to others. It would
take a very long time to go explain what these issues are for each country. Just in general,
we're working on it. We're trying to get there as fast as possible.
>>Malin: Great. Thank you again, Trevor. Here is a GCM question. GCM servers allow for a
maximum of four different collapse keys. Suppose the server's already received and stored messages
with four different collapse keys. What happens with the next message? If it's collapse key,
it's not among those four.
>>Nerieri: Okay. The collapse key concept comes from C2DM where every single message
needs to specify one collapse key. The limit of four was to avoid people to use infinite
collapse keys to flood the devices. We picked up four, which means that you have four main
topics for which you can update your device with messages. With GCM, we introduced a noncollapsible
message, so you don't have to specify the collapse key. If you need to send a big number
of messages, even if the devices are offline, you can use that [indistinct]. It's important
to note that it shouldn't be used for messages that you do want to collapse, like saying
the same news as the very same update, because we will deliver all those messages down. So
you can still use this four collapse keys. Now, we are thinking that this restriction
for GCM doesn't make much sense anymore, so we might consider to increase the number of
collapse keys. But to answer the question, what happens is that you should not use more
than four because the results are not definite. If you send messages with six different collapse
keys and the devices are offline, four of those messages will make the device, and you're
not guaranteed which one of those four.
>>Malin: Great. Thank you very much, Francesco. All right. Next question about GCM: I read
somewhere that GCM makes no guarantees regarding the time to delivery or order of delivery
of GCM messages. Okay. Could you give us a rough estimate or target? Any plans to provide
stats once the system is running smoothly?
>>Nerieri: Okay, one question at a time. [chuckles] The time of delivery. We do guarantee time
of delivery for multiple reasons. One is that we have no idea if the device is offline or
online when we receive your message. If the device is offline, we just store it and deliver
it when it comes back online. Two, we have no say on the latency introduced
by, for example, the mobile network between our server and the device. The numbers I gave
are the speech, when I had the speech at IO, was that roughly, we take 95 milliseconds
to process a message. This is the time the GCM takes from the moment it receives the
message to the moment it sends to the device. Another part of the question--
>>Johns: The short answer there is that it's pretty close to immediate.
>>Nerieri: Yes, it is.
>>Johns: Unless there's extenuating circumstances.
>>Malin: I would say in the best possible case, it's nearly immediate, but the estimate
or target, a lot of it depends on what's going on. Whether the device is offline or online.
>>Nerieri: Correct. But also, if your server sends a message in Germany, and the user that
receives the message is somewhere else in the world, like in Taiwan, we have quite a
bit of routing to do from that side of the world to the other one. The latency can go
out to 150 milliseconds. But it's definitely, if the device is connected, it's way below
one second.
>>Malin: Right.
>>Nerieri: The other part was the order of messages. The way we send messages downstream
is when we receive a message, we store it, unless the time to leave is zero. In that
case, we just send it down directly. But if we store a message and a second one comes,
we deliver in that order. But network, from your servers to our servers, does not guarantee
that if you send two messages in the same millisecond, that we will receive them in
that exact order. If we receive them swapped, then we'll deliver them swapped.
>>Alexander Lucas: So does that mean that it's guaranteed that we're sending them in
>>Nerieri: In the order in which we receive them.
>>Lucas: OK >>Malin: That may not be the order in which
you sent them to our servers.
>>Nerieri: Correct. Especially if you have a farm of servers that sends messages at the
very same time. It depends on the network location.
>>Malin: I think in the last question was: do we plan to provide stats on our--
>>Nerieri: We launched version 1 of Stats. If you, as a developer, log into Android Developer
Console, you can see stats for GCM and C2DM applications. We provide metrics of how many
messages are being sent, how many are stored, collapsed, or throttled. If you had any errors
in the request. And also metrics for the registrations that the user's device are connecting to our
servers for your application. You can already see those. We are working for providing a
version 2 in which you will be able to query the life of a message. [pause]
>>Malin: Okay, thank you.
>>Reto Meier: Just before we go to the next question, I'm getting a little bit of interference
from the two lavaliere mikes. If you guys maybe want to turn those off and just share
the hand-helds with the guys next to you.
>>Malin: All right. We'll have to do that.
>>Johns: Actually, I guess we didn't have to turn those off. We could have just muted
them, too, but-- Yes, we do have to share mikes now.
>>Malin: Right. So that's why I have this yellow thing in front of my face. Next question
from Moderator is for an app working with sensitive data. What solution would you recommend
if I need to show a login screen every time the app comes from the background? Related
to that, is there an easy way to determine if your app is currently in the background?
>>Johns: I think that this is actually a question that's come up at least once before. There's--
First off, to answer the question of how do you determine if your app is in the background,
all Android applications have a life cycle. When they start up, you get a on-start or
on-create callback. Then you'll get on-resume and so on and so forth. And finally, on-pause,
on-stop. These callbacks are what allows your app to know what its current state is. That's
pretty much the answer to your question as well, too. If you want to go display a login
dialog when your app comes back up from the background, if you just want to be on first
launch, you can put it in on-create. If you want to make it so it appears when it's coming
back after being in the background for a while, you can put it in on-resume. It's just a matter
of how you want to go and display this. Keep in mind that you don't want to display your
login dialog too frequently. Be a bit cautious about how you do use this.
Also, it's worth noting, as far as your login screen, don't go and launch that as a separate
activity. There's some security implications there that--. You can get it right if you're
careful, but it's very difficult to get right. My recommendation there would be just to go
swap out your layout for your login form without spawning a whole new activity. I think that
should answer your question.
>>Malin: I was going to add something, which is that I have used apps that have [pause]
encrypted data in them. They ask you for a login screen every time you switch away from
them and switch back, which is a little bit of an annoyance.
>>Johns: Oh, it's very annoying. To call out one app in particular, One Password. I love
the Mac version of it. The Android version drives me absolutely nuts because I log in
to get my password, I switch to the browser, I enter my password, I go back to One Password,
and it's locked again. It hasn't even been 30 seconds. The phone already has a lock screen,
so I'd say, at the very least, make this optional because it's going to drive a lot of your
users nuts to the point where they might switch to other apps. Definitely don't make it mandatory.
Consider that if the user really does want to keep their phone secure, they've probably
already set a passcode for the screen as well.
>>Malin: Right. And in fairness to One Pass, I'm aware of another password [clears throat]
app that I use which works exactly the same way. I think it was designed with the idea
that you might leave the phone around without locking it. But I think it's better to just
trust the user that the user will know when he or she wants to lock the phone itself.
Having to enter the password every time you go in to get a different password is a user
annoyance. That would be my comment.
>>Johns: Phones are much more personal devices than computers. Keep in mind, again, with
a lot of the security considerations you've made, you had to make on a computer that wouldn't
make sense in the context of a phone because it is something a user typically carries in
their pocket. And if you really, really do want to implement this, consider making it
a time delay and not just an on-background delay.
>>Malin: Okay. Any other comments? [pause] Our next question from Moderator is view.gettag
performance versus custom holder class for cells in a list view. Storing view references
using view.settag, find view by IB, and then retrieving via view.gettag. Simpler and less
static. I'm not really sure what that means. [pause]
>>Johns: All right. Well, I'll add you haven't used this for a gridview, which behaves pretty
much similar to listview. There's really no harm in using settag and gettag. It's there
for you to go and store your custom data, whatever that might be. If you find that's
an appropriate place to put metadata, references to objects using, etcetera, that's perfectly
fine. Just keep in mind, though, that your listview cells get reused. But as long as
you keep that in mind, where you decide to put your data doesn't really make a difference.
>>Lucas: I'm trying to figure out what he means by "versus custom holder." I'm assuming
that means something like external hash table, keyed off of the row ID or something like
that. One thing that you would run into in which where view.settag would be a much better
option is that, as Trevor was saying, these get recycled. If you were using an external
hash table or something like that, you could have 100 entries in there with the view stored
in there when you only really need, like, seven. That situation would take care of itself
if you just use the view.settag. [pause]
>>Johns: All right. Cool. Next question, then.
>>Malin: Thank you very much, Alex. The next question is from Moderator again: with GCM,
will there be any third party social servers available for us to use, as otherwise, stuff
like Twitter Push, which is difficult and pricey to implement. I'm not really sure what's
meant by third party social servers. I'll let Francesco--
>>Nerieri: The answer is no. Google Cloud Messaging is a messaging service, which means
that your server can send messages to the Cloud. We deliver it to the device, but we
don't provide any kind of extra feature like bringing down social messages or whatever.
If some developers could create a third party service that other users could use, but it's
not Google.
>>Johns: The one thing that might be worth mentioning there: one of the new features
we did add in GCM is that you can actually have multiple API keys associated with a single
application. As a completely hypothetical example, if Twitter wanted to go and push
messages directly to your app, they could go and give you their own API key. You could
add that as an authorized key for your app, and then Twitter would be authorized to send
directly in to your app. Right now, I'm not aware of any social services that do that,
but the functionality is there, so if anybody does want to go and build that out, the backend's
already in place for that. I got that right, right?
>>Nerieri: Yes.
>>Johns: Cool. [laughs]
>>Malin: Great. Thank you very much, Trevor.
>>Meier: We had a question on the hangouts from Matthew.
>>Malin: Okay, go ahead, Matthew. [buzzing noise] Hello? [pause]
>>Matthew: Hello, this is Matt. I had a question on the ADB tool. When installing devices onto
an emulator, we're using code that's either generated by ASM, not necessarily just compiled
in Java. You get errors like "Dexopt failed" or "Failed UID changed." I'm trying to find
if there's a way to find a general area that just lists where to go when you encounter
those types of errors. I know what they mean, but-- [laughs] Assuming Dexopt is kind of
like a Java lying verify error, but with much less details. [pause]
>>Johns: Yeah, I'd say-- I mean, our documentation there is somewhat sparse, partly because most
of the time, people don't interact with those tools directly. Anything that-- What causes
error is normally caught at an early level by the compiler and such. If you are going
and trying to do your own custom build, the chance of running into those are a bit greater.
Unfortunately, like I said, not much documentation there, at least on the Android Developer site.
Probably a good resource would be the Android Developer's mailing list. A lot of us are
on the Android team within Google. We do keep an eye on that. There's members of the framework
team, members of the build tools team. We all stop in there every now and then. If you
do run into any of the more complicated errors like that, you can just go ahead and ask us
directly. It's certainly not as good as having documentation, but it's probably the next
best thing.
>>Matthew: Okay, thank you.
>>Jones: Yep.
>>Malin: Thank you. Do we have anything else on-- Okay. My producer says, "No", so let's
move to Moderator: I implemented a simple app for push notifications to my phone, but
I ran into a problem. Boolean entries in the JSON sent to the GCM server were converted
into strings in the intent extras. Is that a bug or a technical limitation?
>>Nerieri: It's more like a technical limitation. GCM, we opened the JSON protocol in GCM only,
but we want to be able for you guys to use GCM on the very first release of push messaging,
which happened in Froyo devices. Froyo devices, when we used C2DM for them, they accepted
all the plain text, in which every parameter was string. So we send down to the device
only string parameters. It's a key-valued pair in which every single value is represented
as string. When we opened the GCM interface, we had to convert into string. What we are
thinking about is maybe force the JSON to have only parameters with strings.
>>Malin: Okay. Thank you very much, Francesco. Next question from Moderator: Is it possible
that daily device installs also counts existing devices that got a software update to a new
Android version? On a certain day, I had 80 user installs and 450 device installs. That
was a spike on 4.03-4.04 device installs that day.
>>Jones: Okay. Google Play does make a distinction between-- Actually, hey, Reto, don't you want
to switch cameras? Yeah. [laughs] Google Play does make a distinction between new installs
versus upgrades. As far as the data we're logging, we definitely do know the difference
between the two of them. I'm certainly not going to rule off the possibility that there
is a bug in our logging pipeline, but, to my knowledge, assuming everything is working
the way it was designed, those installs should be different. It's entirely-- It's possible,
too, that maybe you just got a bunch of traffic from some other source and your update may,
[indistinct], notice your app. If you [pause] maybe install something like
Google Analytics, which will get you a little bit more visibility into where your users
are coming from, how many unique users you have, that might help distinguish between
the two of those. I've certainly never heard of updates being counted as new installs,
so I'm really inclined to think that actually, those are new installs for some reason with
your app. Like I said, give Google Analytics a try, see if that helps. At least you'll
distinguish where those users are coming from. It'll tell you things like refers. Lots of
really GC stats there. All right.
>>Malin: Thank you, Trevor.
>>Jones: I just want to say, I stole Alex's thunder. He's the analytics guy. [laughter]
>>Lucas: It's all right. I'm just glad more people know on the scene know that I noticed.
I'm not the only one.
>>Malin: Great. Regarding GCM, what ports need to be opened on our server behind firewall?
Only HTTPS, which is 443, or 5228, 5229 and 5230, or all of them?
>>Nerieri: Okay, so if your server is the one that sends the messages and the only piece
that you want to use for GCM, in this case, then the port 43 is the only one you need.
But if you have devices that need to receive messages, then the port you want to open your
firewall is 5228, which is enough for now, but you might want to open as well 5229, 5230,
because we might use those in the future.
>>Malin: Okay. Great. Thank you very much. Next question off of Moderator: are there
docs coming up for using Create App Engine Backends option in GPE? There was a great
talk in Google IO about the same thing, but until now, no docs have been released. When
I click Google Create App Engine Backend, it exits with an error.
>>Lucas: I can take a shot at this. I'm assuming that you're referring to the Create App Engine
Backend for an Android application and you haven't just randomly put an App Engine question
in an unrelated Android talk. That plug-in, that particular function, uses C2DM to communicate
back down to the Android device. Given the C2DM is now deprecated, I'm not actually sure
what the future of that plug-in is off the top of my head. I can look into it. [buzzing
noise] But for the time being, I know that there are documents. If you already have a
C2DM account, there is documentation up. There is-- The GPE plug-in has its own page that
you can look at. There's also a page up on Android training. I can't really say anything
about the error you're seeing without knowing what the actual--
>>Jones: Yeah, as general guidelines, when you guys see an error and you want to ask
us, it helps if you actually tell us what the error is. [laughs] But more general, just
talking about the plug-in, I'm not aware of any plans to deprecate it. I think, if something
isn't working, I think that's just a legitimate bug. Please file a bug report and we'll look
into it. In general, b.android.com is the Android bug tracker. Or, of course, leave
a comment here with additional information. But again, we do need to know the actual error.
All right. Joe?
>>Malin: Great. Thank you very much, gentlemen. Next question is: are you planning on selling
the ADK 2012 at some point in time for those who couldn't make IO? If not, what would you
say is the next best alternative? Go ahead, Trevor.
>>Jones: All right. Right now, I'm not aware of any plans to have Google selling the ADK
version too directly. That being said, we have published all of the schematics and various
board layout files online. Anybody who does want to go and make one, everything is open
source. I want to say it's Creative Commons. Don't quote me on that. Check the license
associated with it, but it is released under permissive license. Anybody who does want
to actually go and manufacture more of these boards, just go ahead, download them from
our website. At some point in the future, I suspect you'll actually see some on the
market from somebody who's not Google who's actually gone and reproduced them. They do
take-- For those of you haven't seen it, it's actually a really cool design. They took the
ADK and built this really neat touch sensitive alarm clock around it. When you actually want
to go and build it, you actually pop it open, it has some magnets, and rip the ADK out of
it. It's really cool, but it's also a lot of work to build. I think it'll probably take
a little bit before people actually release the exact same ADK. That being said, I'm sure
you'll also see some non-alarm clock ADKs for sale as well, for somebody who just wants
a simpler, hardware platform to go and build on top of.
>>Lucas: I just want to add: the ADK that we gave away last year was followed up within
a couple months by several third parties writing their own ADKs and selling their own ADKs.
Many of them were more impressive than the one that we gave away. I wouldn't worry too
much about getting your hands on one of the ones that we gave away at IO. Just go to the
website and keep your ears open. Check out Maker Faire-type communities. More awesome
stuff that's better than what we gave away will probably be coming down the pipe.
>>Malin: Good answers. Thank you very much. Let's go down here to the next Moderator question.
This is going to be one that Francesco can answer: why are GCM multicast messages restricted
to 1000 registration IDs?
>>Nerieri: As opposed to 1001? [laughs] No. It's actually a good question. The API is
a multicast messaging, which means it's not broadcast, which means you don't want to send
the message to everybody. So we had to come up with a number. Now, the number is 1000.
It's the maximum we wanted to go at the beginning because we see spikes. Every time we receive
messages, we can have a QPS. In C2DM, we had a very nice curve with QPS. But now we can
have spikes of people sending 1000 messages in one request, which is very difficult to
allocate for our resources. We wanted to give this kind of API because it's good for our
developers to be able to, in one request, address multiple devices. But we had to come
up with a number, and this number was 1000.
>>Malin: Okay. That's a good enough answer, I think.
>>Nerieri: I hope.
>>Malin: Yeah. I hope that answers your question. If not, if you've got any other information
that causes you to ask this, we'd be interested in hearing it. Meanwhile, we'll move on to
the next question: I have knowledge of Android SDK, Android tools, Jenkins, Ant, Miavan,
XML, and JSON.
>>Lucas: I think they mean Maven.
>>Malin: Maven. Okay, yeah, that's probably true. Didn't think about that. What else does
an Android developer need to know to enhance his or her technical skills? [pause]
>>Lucas: Everything!
>>Jones: Yeah, that's quite the question there.
>>Lucas: Yeah. One thing I do notice missing from the list is SQL. For persistence storage,
we use a SQLite database. I would throw that on the list of things to cover. Other than
that, that is quite a broad question.
>>Jones: Yeah. Open GL would be a very good topic to learn, just because at some point,
you'll probably want to do something 3D. If not, a full-fledged 3D game, maybe you just
want to go and build some effects into your application. Open GL tends to be a very good
tool for that. In addition, just general computer graphics. If Open GL doesn't do what you need
to do, you're going to be stuck with something like a canvas. Knowing how to actually go
and do things efficiently in that context is a good skill. More broadly speaking, you're
going to want to know how to do things with web services, so understanding concepts like
rest, o/off, things like that, very useful to know. Really, it's a very broad question
here. [laughs] I could just go down the list all day. But yeah, I'd say you've already
got a pretty strong foundation there. It really depends on what it is you want to build. I
mentioned Open GL. Maybe that has no bearing in your-- I don't know. I don't know what
you want to do. But I'd say you already have a pretty strong technical foundation with
what you've listed.
>>Malin: I would certainly agree with that. I would also say that there's really no end
to the answer because you can't ever tell what you're going to need to know. A lot of
it, to my mind, depends on what you're trying to accomplish. If you are trying to get a
position someplace with a company that's doing something in particular, then I would look
at what that company is doing, what type of applications base it's in. If it's very data-oriented,
you probably want to look at something like SQL. Or, you may want to look at statistics
and learn something about how statistics and analytics are done in this base. On the other
hand, if you want to be a contractor and independent developer, one of the things you're probably
going to have to do is decide on what's most in demand and then focus on those areas. You
may have to pick up technical skills along the way as you're doing a contract. There's
no way to say that you're ever finished with learning stuff. That's certainly true. [pause]
>>Jones: I think that's a pretty good answer.
>>Malin: Yeah. I mean, Trevor covered a lot of the things that I would have covered, especially
Open GL. I think that's a really good answer. Let's move on: is there a rough estimate for
when C2DM will be turned off? I think we've got the expert here that maybe will give us
an answer.
>>Nerieri: C2DM is deprecated, which means we don't accept any more sign-ups, nor quota
requests. We do not want to break your applications, so we will give, if we will ever turn the
services down, we will give heads up way ahead of time. At least a year before we decide
to do so. This said, I would urge you to migrate to the new system before you run into quota
issues or if you need to use new APIs or the client login, which is being deprecated. It
will actually be deprecated.
>>Jones: Just to follow up on that. Whenever we deprecate an API, it is a good idea to
go and take a look for alternatives. The alternative in this case would be GCM and to move there
as quickly as you can. Again, we don't want to break your app. It's not going to disappear
any time in the near future. You do have time to do a nice, orderly migration. But please
don't wait to migrate until we actually say the servers are going away, because by then,
you'll be in a rush. Start your migration to GCM now, and then you'll be in good shape
for when they do eventually get turned off in the future. [pause]
>>Malin: Great, thank you. Next question. Okay, if we thought the one before was open
ended: I'm trying to learn Java. Can you recommend some books or videos, etcetera?
>>Lucas: I'm sure we're all going to have opinions on this one, but I'm going to take
a start. The part that you didn't give us that's really important is: are you an experienced
or intermediate programmer who just hasn't been exposed to Java yet, or are you not used
to programming? If you're already familiar with programming, I got a lot of value out
of a book called Core Java. Also one-- I'm blanking on the name, maybe you guys can help--
by Josh Bloch. It had a lot of really good design patterns.
>>Malin: Effective Java.
>>Lucas: Effective Java. Thank you, Joe. Really good book, but difficult to digest if you
are not already familiar with programming. If you're a new programmer, it's been pretty--
I'm pretty sure pretty close to a decade since any of us have been new to programming. If
we knew good resources a decade ago, they're out of date by now. Anyone else want to take
a crack at this?
>>Jones: Yeah, I'm actually going to take an opposing stance here and say that I've
hated every Java book I've ever read. [laughter] That being said, there's some amazing tutorials
online. What used to be the Sun website is now the Oracle website. They have a lot of
Java tutorials there. All of them are actually really well-written. I can't recommend them
highly enough. You go take a look at those, perhaps. They have-- Most of them are in tutorial
format. They're written by the guys who did a lot of the initial work on the Java language.
That'd be my recommendation. Also, if you are going to branch out into
Android, I can recommend a very good Android book, which would be the one written by the
guy sitting on the other end of the camera right now, Reto Meier. It's an Android for
application development. He's not on camera, so he can't really speak to it, but I'll give
him my recommendation from this side of the camera.
>>Malin: I would agree with Trevor's recommendation. I would also say that the books and videos
and everything is going to depend a lot on where you're coming from. If you've done programming
and you're coming from another language, you may want to take a look at books out there.
I'm sure there is some book that is like "Java programming for C programmers" or something
like that. If you just Google that, you may find something that will help you. If you
are not familiar with object-oriented programming, then you may want to look at something that's
a little bit more elementary that covers that as well as Java from the point of view of
somebody just starting out. I happen to have a book called Java in a Nutshell, which is
an O'Reilly book. The reason I have it is that it does cover-- It is a good introduction
in the sense that it takes you from very simple to very complex, but it's also a really great
reference. Since I can't claim to be a Java expert, I always have it sitting around in
case I need to look up something, which I find very easy to do in that particular book.
The only other thing I can think of is that a lot of things these days are discussed in
terms of general terminology for computer science related to programming languages.
You may want to look at books that are just in general about object-oriented programming
and design patterns. I sometimes read a book called Design Patterns, which is at least
a decade old, if not 20 years old at this point. But it's a good summary. Unfortunately
in C++ rather than Java. The standard algorithms and design patterns for creating things in
any programming language. That's worth having on your bookshelf.
>>Jones: Actually, Francesco, since you're a guest today, what's your opinion? Was there
any books or anything you found particularly good when you started out learning Java for
the first time?
>>Nerieri: You know, I learned Java when I was in Italy. The books there were different.
[laughter] My opinion is if you're new to a programming language, I would not start
with the language itself. I would start learning [mike gives out] like suggested, because you
can build up the foundation of programming skills, which will help you then pick up a
language, which is Java, C, or Python, or whatever, much quicker and faster. I have
a deeper understanding of the code [mike gives out] rather than having an approach of, "I
know this Java library, so I'm going to use that" without really understanding what's
>>Jones: Okay, thank you very much.
>>Malin: Since we're on this topic that is dear to my heart, I'll say one more thing
about this, which is-- sorry-- which is that the fastest way to learn any programming language
is to set yourself a project. I thought I knew Java really well until I started working
on Android. Then I really learned Java, because you learn something very fast if you have
to work in it every day and if you've got a target. At least, that's my way of learning.
Look at the ways you've learned other things, and follow that. If you learn out of a book,
then get a book. If you learn by doing, then I would say, "Go do something." [pause]
>>Jones: All right.
>>Malin: Okay, let's move on. The next question is: is Semantic Zoom, as implemented in ICS
Calendar, a recommended pattern to use in our own apps?
>>Jones: I actually don't know what Semantic Zoom is.
>>Malin: Yeah, I don't either. Sorry.
>>Lucas: It's this.
>>Malin: Ah, okay. I think what the question means is: is expanding with a two finger gesture
a recommended pattern to use in your own apps?
>>Jones: Unfortunately, we don't have our capture device hooked up, otherwise we'd actually
show you what Alex just showed us. He took two fingers and just was able to drag up and
down. The calendar view expanded and contracted as he did that.
>>Lucas: Specifically, one element of the view expanded and everything else stayed the
same, which I assume is what they mean by Semantic Zoom. A recommended pattern. I don't
think it's an official recommendation at this point. I would check the Android Design Guide
for that. But it looks neat. [laughter] I think it improves usability, at least for
the calendar app. It's definitely not a discouraged pattern, but I don't think it's an official
pattern yet, either. It's just a neat thing that's out there.
>>Malin: I can answer specifically for something I do know about: notifications. Jelly Bean
Notifications implement that feature as part of the API now. Notifications at least used
to be what we call one-u, which is a height of about, I think it's 64 DP. But now we feature
an expanded notification. If you do a gesture like stretching the boundaries of the notification
apart or some other gestures, you'll expand it to what's called a 4-U notification with
a lot more space. It's 256 DP. That's a zoom multi-- What I would call a multi-touch zoom.
That's an official part of Notification UI at this point. It's worth looking into.
>>Jones: On the broader topic of UI design patterns. There's certainly a lot of stuff
that we try that we think looks really cool or greatly improves the usability of the system.
Hopefully the two at the same time. We give those a try in our own apps. We're a bit more
conservative with the official design guidelines, because once we write something down there,
it's more or less set in stone. Developers go and they build up their apps using those
patterns. So we want to make sure that anything we actually go and write down is something
that we're really happy with. I think that this particular pattern that was mentioned
in the question has not actually been added to our UI guideline, as Alex mentioned. If
you want to go and be on the leading edge, by all means try to make your app work on
the system. I think it's a very good goal. I think you can't go wrong. That being said,
don't be surprised if, in the next release, some of these things change out from underneath
you. It's just like using undocumented API. That's right. These things are still in flux.
Actually, I take it back. It's not as bad as [mike gives out] in API, that's a horrible
thing. Don't ever do it. [laughs] But no. I don't think you can go wrong in this case
if you just want to make something that looks like the system. Just keep an eye out what
comes for you. When the K release comes out, whatever that happens to be called, make sure
that that behavior hasn't changed.
>>Lucas: I would also add that this is a shiny, visually appealing feature that doesn't necessarily
mean it's appropriate all the time. In general, I agree with Trevor, that if you want to look
like the system, you can't really go wrong. But we also put a lot of effort into making
visually appealing little effects like that, where appropriate.
>>Jones: That's true. There is a guideline that you want to have lots of playful visual
flourishes. It makes your app feel more alive. It makes your users happy. Even if things
aren't necessarily documented as official patterns, if it makes sense in the context
of your app and follows the spirit of the system-- The overarching goal there is something
we have written down.
>>Lucas: I was actually more referring to-- again, general, I agree-- I was more referring
to being cautious when using a feature like that. Don't set up a text view where you use
that feature and expand one word so it overlaps all the other words, because that would be--
>>Jones: Right, you have to make sure it's usable. You have to make sure it actually
makes sense.
>>Lucas: Exactly.
>>Jones: But at the same time, having something that is usable and makes sense, but is fun,
is a good thing. Case in point, Google+. When I get an event invitation, it folds out like
an actual event card, like a little piece of paper unraveling. It has no practical use,
but it looks cool and it makes people happy. It doesn't hurt usability, at the very least.
It actually might even help, because it helps explain what's going on.
>>Malin: Right. I would add that some of these things are sort of subtle, but they're force
multipliers. That means that you have immediate ability to look at information in depth and
take action without having to go to another activity or application. For instance, in
Notifications, you can click buttons and look at more than one email message. That's a force
multiplier because what it means is you're not forcing the user to go into email to look
at what's going on or go into a music player or a chat system. They can look at it right
from the notifications. They can look at a calendar event in detail without having to
switch to a separate activity to look at it. That's very powerful. It makes things look--
It's easy to use, but it means that there's less work for the user. I have to give credit
to Daniel Sandler for that. Yes, go ahead.
>>Audience member: I've got a question about the impact servers. Can you use content observers
>>Malin: The question was: can you use content observer instead of content provider to monitor
a database? If not, can you suggest another way of monitoring a database? This sounds
like a familiar question. I think we've discussed this before. If not officially in Developer
Office Hours, amongst ourselves. I'm not sure what the answer is. Anybody got an idea? [pause]
>>Jones: As far as content observer versus content provider, unfortunately, I don't know
the answer off the top of my head either. I'm drawing a blank. There's certainly more
than one way to go and read data out of a database. At the end, it's all going to boil
down to a SQL statement somewhere. It's just what design pattern do you use to go and retrieve
that data and make it accessible to everything else. Reto, you literally wrote the book on
this, so what's your thoughts?
>>Meier: I think the key here is what he's asking is, specifically-- A content observer
what you use when you want to be able to monitor a database with changes.
>>Malin: If you want a content observer that monitors a cursor.
>>Meier: Exactly.
>>Malin: Right.
>>Meier: Exactly. His question is: can you use it for a monitor a cursor from a database,
rather than from a content provider?
>>Malin: As far as I know, you should be able to.
>>Jones: Yeah, a cursor's a cursor.
>>Malin: Yeah, a cursor is a cursor. A content observer. There's an observer on cursors that
I think is independent of content providers.
>>Meier: That's my understanding as well, but--
>>Malin: Right. The easy answer is: look in cursor, and if cursor has a set content observer
method on it, then you can do it, because that's how you would do it, is set a content
observer for a cursor that comes from the database. Content provider, all that it really
does for SQL databases, is encapsulate an SQLite database. The SQLite database returns
the cursor and the content provider returns that cursor to the calling component. So really,
that's all the difference that there is. There's nothing magic about a content provider that
automatically does an observation. [pause] Anybody else? Okay.
>>Jones: It's actually probably a good time to mention that we have about 15 minutes left.
If anybody does want to go and ask us any live questions, please jump into our Hangout.
We'd be happy to have you on the air. Even if your mike doesn't work, feel free to hop
on anyway. You can go ahead and type your question out to us and we can go ahead and
ask our panel of experts here in the room. GCM questions or just Android questions in
general. We're happy to take any of them.
>>Malin: That's a good point.
>>Meier: I've been keeping an eye on the Google+ event livestream as well. If you have any
questions, you can talk to me [inaudible]
>>Malin: Right.
>>Meier: One of these is from Noulesh, who asks: is it a good idea to have two different
versions of the AAP plugin and FDK tools running two separate fields. Eg, SPN trunk could be
running on ADT 20 and SPK 20 tools, and Branch could be running ADT 15 and SDK 15. Are there
any issues with this?
>>Malin: Okay. The question is: is it a good idea to run separate versions of ADT on separate
builds? The answer is-- My answer would be you certainly can't do it in the same version
of Eclipse, because those are plug-ins. I don't think you can have more than one ADT
plug-in in the same version of Eclipse You certainly would run into problems. But if
you want to have more than one instance of Eclipse on your system, then you should be
able to do it.
>>Jones: There is one problem I can see with all this. The goal here is not only to have
different versions of ADT, but also different versions of the Android framework running,
too. Correct?
>>Malin: Right.
>>Jones: In that case, there are different versions of ADB server. The different versions
of the framework are going to try to launch different versions of ADB server. That's going
to cause conflicts. I think even if you're running your different versions of the SDK
inside of different versions of the ADT inside of different versions of Eclipse, at the end
of the day, you can only have one version of ADB server running. That's where you're
going to run into problems.
>>Malin: Yeah, that is a good point. You'd probably have to do a lot of fiddling around
with path variables and environment variables in order to get it to work correctly. It's
probably not worth doing. I would think that probably what you want to do, if you're just
trying to aim at different platforms, is set up for the highest level platform. Then you
can always aim to a lower API if you want to check for API compatibility.
>>Jones: Yeah, I'll add one additional data point here. Here in the Android team, we work
with a lot of different versions of the Android framework. I have never installed more than
one copy of ADT. I think that's not the right approach here. I think the right approach:
have one version of FDK tools, one version of ADT, and, like Joe said, just go ahead
and switch what your build targets are. That's a perfectly supported work flow. [pause]
>>Malin: Great. Thank you. Next question from Moderator: Google Maps home to work feature.
Is there an API available for developers to access this data? Intents or provider or something?
I'm researching location tracking for my app. I don't know exactly what the question means,
but I assume that the respondent means the thing that tells you how long it's going to
take you to get from your home to work and vice versa.
>>Jones: Right, I think so too, which I believe, actually, was something-- I think that's part
of the whole latitude umbrella, where it's actually going and keeping track of where
you are and reporting it to your friends and building a location service on top of that.
The answer, to my knowledge, is no, we don't have an API for that. We do have location
manager. You can get both fine-grained GPS location data as well as the coarser-grained
WiFi-based data as well. But we don't actually have the API say, "Where is my detect at home,
where is my detect at work, etcetera."
>>Lucas: I would say, actually, if there is an API for that, we're the wrong one's to
ask because we don't run-- or we don't write latitude or Google Maps. I believe Maps API
has their own office hours. That would be the right place to ask.
>>Malin: Yeah. I'm familiar with the current V1 version of the Maps API for Android, and
I don't think that it has anything like this in it.
>>Jones: No, it doesn't.
>>Malin: But there's also-- I think this is not a feature of that component. I think this
is more a feature of the Maps app and the latitude API-- the latitude app. I don't think
that they have APIs available. So. Go ahead.
>>Meier: There is a latitude API, I think.
>>Malin: Is there? Hmm.
>>Jones: There is a latitude API, but I think it's more for just reporting what your location
is. I don't think-- At least, the last time I looked at it, which admittedly was quite
a while ago, it didn't have anything "get your autodetected home and work locations."
>>Malin: Okay. Well, I stand corrected, which is pretty much par for the course today.
>>Jones: No, no. The answer is there's no API for this.
>>Malin: Right. The answer for this particular question is there is no API. Sorry. If you've
got any more particular questions, you can send them into us or call on-- get online
and talk to us about it. There may be something that we're missing that-- I feel like there's
more to this question that we haven't answered. I just want to leave that open.
Next question from Moderator is: I'm using the following function to get all view IBs
versus calling find view by IB multiple times, which does a very similar traversal. And he
has it in a link. I'm guessing this is faster if you have a high IB versus non IB view group.
Unfortunately, we don't-- I don't have off-hand the link available. Let me go look in the
link and see if it's-- [pause] I'm getting a redirect. It has something called a create
resource map. [pause]
>>Jones: Okay, he's literally just iterating through all the children inside a view group.
Then it creates this resource map, which is-- I'm not sure what data structure that is there.
>>Malin: I can't tell off-hand, but I think what's he's just--
>>Jones: Oh, here we go. He's actually-- If resource ID is not equal to view.noid, and
then he sets-- All right.
>>Malin: Oh, I see. Yeah. Mm-hmm.
>>Jones: Honestly, I think you're over-thinking things a bit. Find view by id is normally
the right way to do this. Unless you're seeing actual concrete performance problems, which
you can use-- You can find that out by using profiling tools. Things like Trace View. Unless
you're actually seeing a negative performant hit there, I'd say this is probably a case
of premature optimization. It seems like going a bit overboard to me. I've never seen anyone
go out of their way to go in and scan through all your childviews like that. Seems a little
off. But that being said, I'm not going to discount the possibility that it might be
more-- it might be faster in certain situations, which really just depend on how you're using
it. But again, unless you're seeing a performance impact, it seems like code you might not even
need to worry about.
>>Lucas: I would say that if you are seeing a performance impact and that's actually making
it faster, the only way I can see that being true is if your view IR key is so complicated
and nested that you have much bigger fish to fry.
>>Jones: Yeah, if you have hundreds and hundreds and hundreds of views that you're trying to
call find view by ID on, I'm really terrified to think what you're view hierarchy actually
looks like.
>>Lucas: If it's a--
>>Jones: You're going to spend more time rendering than you're going to spend searching.
>>Lucas: Right.
>>Malin: Right. Okay. Let's move on here. How does the Tablet layout of Google Play
manage to display two pages at once when you've scrolled over to the category section of the
view pager? Hmm.
>>Lucas: I don't have a Tablet on hand.
>>Jones: Yeah, I'm not sure what you mean by display two pages at once. I suspect they've
just gone and created a view that displays both sets of information at once. It could
be done using fragments. That's the sort of thing that they're designed to be very good
at. You can certainly stick fragments inside of a view pager. I think that's the answer:
the magic of fragments.
>>Malin: Okay. Thank you. Next question from Moderator: do you have any plans on integrating
Facebook or Twitter in Android as Apple did with Twitter? [buzzing noise] Hmm.
>>Jones: No comment. [laughs]
>>Malin: Yeah.
>>Lucas: Yeah. This falls under the category of "we don't disclose roadmap."
>>Malin: Right.
>>Lucas: This would be a huge roadmap question.
>>Jones: Yeah. Is our tardis fixed, by any chance?
>>Malin: Nope.
>>Jones: All right. Yeah, we can't--
>>Malin: Nothing we can do. The time machine is not working. we can't tell you about things
that we may or may not do in the future.
>>Jones: Yeah, it's stuck on the shelf, not moving anywhere.
>>Malin: Right.
>>Jones: Sometimes it has cookies inside, but--
>>Malin: Okay, next question: does the remote control client API only support the flag key
median next, flag key media pause, and flag key media previous controls? Other flags do
not seem to show up.
>>Jones: Without looking at that API, on the top of my head, I'm not sure any of us know
the answer. I'm not sure what you mean by "don't show up", either. Do you mean it doesn't
work or it's not in the documentation?
>>Meier: I think he probably means that it's not visible on the lock screen. So you just
have next, previous, and pause.
>>Jones: Ah. Well, if they don't show up, that's probably a good indication they don't
>>Malin: Yeah. Okay. Since we're getting low on time, we'll move on. I'm looking for a
way to overlay a drop shadow on a scroll view as described here, with a link. How can I
overlay a dropshot onto a scroll view? Is this possible? It looks as if the holo.lite
action bar does the same. [pause] Any answers? Are you waiting for--
>>Jones: I was waiting for the link. But I'm not sure I actually know the answer, having
never tried to overlay shadow on top of a scroll view.
>>Malin: I think that what he's trying-- It shows a layout, and he's trying to put a drop
shadow on top of something that's in the details. My intention that has another layout above
and outside the scroll view. It stays at the top whilst scrolling the content in the scroll
view. The scroll view should have a drop shadow overlay if the top, which appears to be from
the layout of--
>>Jones: Well, you certainly can place views on top of other views. There is an implied
Z order. I think, depending on which type of [indistinct] major you're using, sometimes
you can even specify the Z order, if I remember correctly. But if that's the case, then just
create a shadow as a drawable, with an alpha layer. Problem solved. Short of that, there
are other things you can do to try and fake that, but I'm not thinking of anything that
will work really well in the case of a scroll view. Actually, no. There is a-- what's the
word I'm looking for?-- a heading section on scroll views where you can actually go
and-- Normally, it's designed to go and have a title for your scroll view, but you could
put a drawable in there to put your shadow as well. That's a hack, but it'll work.
>>Malin: Yeah. It's not-- I mean, from what I'm looking at here, it's not really clear
to me whether he's trying to put the drop shadow on the scroll view or on the title
above the scroll view. I can't really tell.
>>Jones: If you're putting it on the title above the scroll view, that's even easier.
Then you just place a drawable at the bottom. The one thing that makes the scroll view difficult
is it's going to move. But I think-- To me, you're putting whatever your green box is
on top of your scroll view. Taking advantage of Z order is probably the easiest option.
>>Malin: I think that's a good answer. Okay, let's see if we can move on. Next question--
sorry. Okay. We're going to have to make this the last question, my producer tells me. So:
how can I notify each fragment in the view pager, which is linked to a tab-post to refresh
its view data, following the lotoor finishing in the main activity? [pause]
>>Lucas: A view pager is linked to a tab-post?
>>Malin: Yeah. How can I notify each fragment in a view pager linked to a tab-post to refresh
its view data following the lotoor finishing in the main activity?
>>Jones: Generally speaking, the way you want to go and communicate with fragments is using--
Define and interface and just make a call to all of your fragments. Then have your fragments
go and update what's inside of them. I usually recommend against reaching inside of fragments
to go and try to manipulate whatever view components are inside of it, because then
you're breaking encapsulation. The idea with a fragment is you can go and swap it out with
other fragments as needed. It is portable. Once you go and start modifying the content
of fragments, you've broken that portability. Short answer: send a message to your fragment
and have the fragment update itself. Anybody else have any insight on that?
>>Malin: No. He has posted a large set of code on Stack Overflow that we could go take
a look at in more detail, but--
>>Jones: Probably not in the 30 seconds that we have left.
>>Malin: Yeah, unfortunately. Sorry.
>>Lucas: I think we're out of time.
>>Malin: Sorry we're out of time. But we are out of time. We'll have to take a look at
it in Stack Overflow. Hopefully, somebody else can step in and take a look at it as
well. I encourage everybody else in the Android developer world to go to Stack Overflow, take
a look at this question, see if you've got any ideas about what's going on.
>>Jones: That's a lot of people.
>>Malin: Yes. [laughter] Crowd-sourcing the answer. And on that note, I think we're done
for today. I want to thank Francesco for showing up and answering GCM questions.
>>Nerieri: Thank you, guys.
>>Malin: And Trevor and Alex for supporting me, and Reto for running all the equipment
to bring this to you. On that note, goodbye.
>>Jones: See ya, everyone.