Video: Android Developer Office Hours (EMEA)
[clink] >>Sparky: OK. I see that Nick and Rich are getting seated, so I will start by saying good afternoon, everybody. And welcome once again to the Android Developers Office Hours EMEA edition. We are the EMEA-based Android developer relations team. I'm Sparky. I'm coming to you from Munich, Germany. And I'm also joined by my colleagues, Nick and Rich, who are visiting in–where. Are you in Tel Aviv? Is that where you are? >>Rich: We're coming slightly blurry from Tel Aviv. Please don't clean your webcam or screens or anything. We just have a slightly lower quality internet connection today.
Hopefully the audio comes through OK. We're also joined by, here's Nick. This blur here is Nick's blur. And this one's mine, Rich. And we're joined by a blur on the far left, or far right to you guys, Yossi from ooVoo, who has been joining us at the GDG meeting in Israel here. >>Sparky: Hi, Yossi, wow. Imagine being in the same building with him. >>Rich: Yeah, this week he's live with us. He was gonna join anyway, right? Just need more bandwidth, so we might as well do it from the same room. >>Sparky: That's terrific. Well, I can see you guys pretty well as long as you hold stock still. So, lean back on those support braces that you got yourselves built and don't move a muscle and your picture will be just fine. Oh. And Matt is asking to be invited into the Hangout. How do I do that? You got it? >>Rich: I'll take care of that. >>Sparky: All right.
So, I see that we're already joined by several people live in the Hangout. We got Al. We got Archbrum. We got Ravi. Who else has just joined us? Ravi, Dami, and Richard. So that rounds out who's live in the Hangout right now. Do any of have anything Android related that you would like to talk about this week? >>Rich: Can I just check with you, Sparky? Where was Matt asking? Is he on the G Plus thread? >>Sparky: No, he just pinged me. Oh, he just joined the group chat. He must be in. >>Rich: He joined us. OK. >>Sparky: Matt, welcome. >>Rich: There he is. >>Sparky: Some pretty posh digs you got there, Matt. >>Rich: [inaudible] >>Sparky: That, where are you–? >>Rich: Please feel free to go ahead and ask your question. [pause] You gonna ask it live or ask it in the chat? >>Sparky: I want you people to be bold–bold and assertive. Ask your questions because I've only got five questions queued up in the Moderator.
So, if you crawl back on the Moderator, we're going to exhaust our prepared material quite quickly. >>Rich: We have a plan. If we run out of planned material, we can go around. We've got a Hackathon running here at the moment in Israel. We can go around with our shoddy internet connection and see what people are up to at the Android [inaudible] Hackathon. >>Sparky: That's pretty cool. >>Rich: So, Harry has typed through the window. Maybe he has no microphone? Has Al got a lower third? What is going on? [laughter] >>Al: I thought I'd give it a try this week. I can turn it off if you guys want. >>Rich: No, no. You go for it. >>Sparky: I want one of those. >>Al: I'll tell you how to get it in chat, Sparky. >>Sparky: [laughs] >>Rich: Are you using one of the Hangout plugins for that? The lower third plugin? >>Al: Yeah, I am. I only just discovered it a couple of days ago. >>Rich: Sweet. Nice.
Everyone should start doing that. We'll know who you are more easily. Harry is asking "I want to play a sound when a user clicks on a button using the sound form. It was working well except on my HTC. It works well except on your own device. It doesn't create a sound after the act. with visible for more than three seconds." >>Sparky: I presume that's "activity." >>Rich: Yeah. >>Sparky: Hmm. >>Rich: So it works unless the activity's been visible for more than three seconds, or the other way around. It doesn't–. >>Nick: Sounds like some sort of race. >>Rich: Playback to audio hardware, log cast audio hardware ACM. Playback is going to standby. So it works when you hit the button within the first three seconds and after that it doesn't work anymore. Are you pretty much using the example code for SoundPool? I've only used it a couple of times myself, but I just used the sample code, put it in and used it.
And it was fine. Have you checked StackOverflow for this particular issue with your bit of log cat there? >>Sparky: Hmm. >>Rich: Sorry. I'm talking to a chat window live on air right now. I'm reading the chats back. Harry says, "Yes I've checked Stack Overflow" and yes, he's talking about activity. Which one is [inaudible]? >>Sparky: Yeah, I don't know anything about it. >>Rich: He's got a StackOverflow issue. [pause] >>Sparky: Yeah. Alright. Well, it's great that we have the StackOverflow case. I don't know if we're gonna be able to really sort through it live. >>Rich: [inaudible]. [pause] >>Sparky: Let's see.
Taking a look. It doesn't–. >>Al: It does seem to indicate that it's device specific and that's a StackOverflow question. So maybe it's a problem with HTC's implementation or some of the binary packages they're using on some of their devices. >>Rich: The SoundPool's a pretty oft used class. I would've thought if HTC had buggered up the implementation SoundPool, we'd know about it. >>Sparky: It does say that he's using Ogg Vorbis. So, that's Open Source. You can't trust that stuff. [Rich laughs] >>Yossi: Has he tried to use the media player object and see if after [inaudible] you'll still have the object ready for you? [feedback sound] >>Rich: Same result with the media player, Harry says. It looks like we have another third now.
Now, we'll waste the lower thirds across the whole of the bottom screen. I don't think I can have one being a, a live Hangout host. >>Sparky: Yeah, I'm drawing a blank on this one. I don't know. This is not exactly my forte. >>Rich: The notification of the sounds work. But that's clearly a hack. I'm just gonna take a look. Sorry about that. >>Sparky: It does sound pretty hacky. On the other hand, it sounds like a pretty clever hack. >>Rich: OK. We don't have an answer for you for that right now, Harry. Sorry. I haven't had issues like that with SoundPool myself, but then again, I haven't tested on that device. So, I'll have a quick look around whilst we go to our Moderator question. Go and read out the first Moderator question with your better internet connection, Sparky. >>Sparky: Sure. First question on Moderator is, "Now that Google Cloud Messaging is in place, is there any recommended way of benchmarking how an app behaves for large numbers of receivers before going live?" That's an interesting question because it's only peripherally Android related, right? I think what he's, if you're talking about load testing, really what you're looking for is your testing out the web app via the server-based application, not the Android client.
And yeah. It's a web service, so I would say test it out the way you would test out any web service. Probably abstract out the Android clients and maybe just use some kind of a web-based load testing tool or an Expect script or a Python script or something. And hammer at it purely with network-based requests. That's my answer to that one. And as far as the Google Cloud Messaging part goes, that's, the Google Cloud Messaging is a service that we are providing more or less as is and either it can handle your load or it can't. And we think it can. So, GCM, at least as far as its load testing part, isn't really part of your system under test. It's really our system under test. So, all that you need to worry about is your Android client and your server app. And the server app you can basically test using traditional network testing utilities. >>Al: It's also probably worth mentioning that with GCM, it's not worth assuming that if you send a message out a user is gonna receive it quickly because people can be out of service areas, can have their devices turned off.
So, bulk load testing like that's not really the best way to go. It's probably better to test the logic on the client side for discarding messages, which have either expired or out-of-date or no longer relevant. >>Sparky: Right. >>Al: You might see, you know, a series of messages that have been patched up waiting to be delivered to you. >>Sparky: Yeah. And of course, Google Cloud Messaging is designed to not be a reliable protocol, meaning we make no guarantees at all that every message will be delivered, or that messages will be delivered in a timely manner or in order. I like to just tell people, think of it more like UDP rather than TCP. Packets can arrive in any order. Some of them can be lost. And you should design the information that you're packing into the data to take into account the possibility that not everything will get through. For instance, rather than sending a GCM message that says, here is the content of your mail, you send a GCM message saying since the last time you contacted the server, you have 27 new messages.
Here's a little URL so that you can get your 27 new messages. If that one gets lost and number 28, 29, and 30 come in, you send another one that says, since the last time you contacted the server, you now have 30 new messages. And that way your messages can be cumulative and you aren't reliant on every single one getting through. >>Nick: The other thing to think about is if you're worried about sending a GCM [inaudible] that goes to thousands and thousands of people and you're worried about them harrying the server, you can build in some jitter code. Like, don't let it all go at once, but time phase it so you're calling GCM at specific times. Or, in your client code, you can put a broadcast task over one and add some jitter in your new client code so maybe, bound to be over a minute, you'll call and get it [inaudible]. Ten thousand get requests all at once, so that's something to consider. >>Rich: And also, one of the new features of GCM over cloud to cloud device messaging is you can now specify a time to deliver the messages, so make sure you put that, make it relevant to your application. So, messages that would've expired don't actually end up getting delivered and you'll reduce the load that way as well.
And people who turn on their handsets later on in the morning. OK. I think that covers that one. Does anyone else have a question from inside the Hangout? >>Sparky: Alright. We got Ravi. Ravi, what's up? >>Ravi: Hi, guys. How are you doing? >>Sparky: Good. Thank you very much. >>Ravi: Yeah. I've been part of Google Hangouts the week before and yeah, I'm really excited to join you guys back again. Not to waste any more time, but I just had a quick question. I don't know if this sounds really stupid, but pardon me if it does. [laughs] I have an application which we're extending into a tablet edition and I don't know. What's really haunting us is the screen resolutions where as for the developer guide, given in developer.android.com, the actual screen sizes were differentiated or general sizes were small, normal, large, and extra-large. And as for the density, there's LDPI, MDPI, HDPI, and XHDPI. In this instance, I see some of the seven-inch tablet devices, or some of the devices which has a seven-inch screen taking HDPI assets, whereas some devices which are having a four point seven inch screen, such as S3 is taking XHDPI assets.
I'm not quite sure what strategy I just need to lay in order to fit the best layout with the best assets. >>Rich: Yeah, that's exactly right. Devices [inaudible]. Have you seen any support in multiple screens page in android developer.com? It gives a good outline of which device [inaudible]. [pause] >>Sparky: Is Ravi still–? >>Ravi: I have seen the developer's Android site and I've also seen the supporting multiple screens and stuff. But I mean, when I am actually doing some development and it's OK when we are doing it via an emulator and checking it over some part of your test devices, but when we send the app over the market, Android devices are being in thousands of numbers and we are not, we are unable to figure the way where we need to strategize the way. So, in some cases, we just need to specifically set some standards for a specific device and release the APK to the consumer and send it to air, which is taking hundreds of business, I mean, developer hours.
So, how am I think if you would help on this? >>Nick: So, what's the issue you're facing? >>Al: I get the impression from Ravi that one of the things that's providing a bit of confusion is the difference between densities of assets and screen sizes. It's best if you think of those as two different things. So, the density of assets is about how much detail you want. And the screen size is your layout that you want to incorporate. So that way, when you come across something like an S3, it's using the high-density assets but it's still using the right layout for its size screen. >>Ravi: Right. >>Sparky: Yeah, exactly. So, to sort of riff on what Al is saying, basically, you have say a visual thing like a button background or an icon. And you say, "I want this thing to be about two centimeters across." And then, you design a bitmap that measures about two centimeters across in each of say, three or four bitmap or pixel densities.
So, you say this thing is at 300 dots per inch or 200 dots per inch or 160 dots per inch. This is how many pixels across the image needs to be in order to measure say, two centimeters in real distances. And so, you just have different versions of every visual asset and let the Android device know its own screen density and say, OK, I am an XDPI, XHDPI device. I will pick this one. Or, I am an NDPI device. I'll pick that one. And you can then trust that when that thing has gone on screen, that is approximately two centimeters across, subject to minor variations because of the different size buckets. And then, so you size your assets for the density and you size your layouts for the actual size. So you say, I want, this is the layout I want to use and this screen actually physically measures seven inches across, or ten inches across, or whatever. And then rely on the device to pick and choose the right combination of layout per its screen size and the individual asset elements based on its pixel density.
Did that make sense? >>Nick: An easier way to do that is whenever you're doing your layouts, make sure you're working in DIPS 'cause that lets you not think about density, just think about size when you do your screen layout. And make sure you're working in density independent pixels for all the layouts. >>Ravi: Uhh, yeah. But when I'm doing the assets, the screen resolution which I use for the assets says like, as specified in developer.android.com, which is a normal screen has 470 by 320. And that screen has 640 by 480. And using this aspect ratio, we are designing the assets where you cannot expect all MDPI devices would be having this same screen resolution. So, I think this is where I am making a mistake. >>Al: Yeah. I mean, for the sizes you've quoted are the screen sizes, not the densities. So, that would define your layout. The densities are if you look on the same page, it'll say MDPI and the range is about 150 to 200 dots per inch. >>Ravi: Right.
>>Al: And that's what you use to determine your asset sizes and how much detail you wanna put in those assets. The sizes you're talking about, the 640, 480, the 470, 320, that's for designing the actual whole layout of the screen rather than designing your assets and how much detail you want to appear in those assets. >>Ravi: Right. I got it now. Yeah. >>Nick: The raw pixel dimensions as well, like something about normalcy. I guess the most common thing out there, it's a normal high-density screen. And I wouldn't ever think about it, the dimensions, so it's always, always, always think about how big that is in DIPS. And when you're doing your design, use the value, the DIPS value, as the pixel dimensions. >>Al: Fortunately, the screen support document does talk about DPs rather than actual pixels. So, hopefully that's reinforcing Nick's message. >>Nick: Yeah, there's a great training class as well.
So, that should probably give more background as well. >>Ravi: Alright. That's brilliant, guys. >>Sparky: And of course if you have further questions, feel free to look us up on Google+ and send a little message to Google+ or something like that. Or, take your question to StackOverflow or to the Android Developers Forum, where people will be happy to help answer your questions for you there as well. >>Ravi: Thank you. >>Sparky: Alright. Does anyone else want to ask us a question in the forum before we tune in to the Moderator again? >>Al: I've got one to throw across to Matt. I saw the announcement yesterday about Google TV rolling out to Germany, France, and The Netherlands. Do you know if that's going to be the same Android version as is currently available on the Sony player in the UK and the States? >>Matt: So, it'll be a different version. The versions being released in the UK, Germany, the Netherlands is gonna be different from the one in the States.
There's a couple of bits they've got over there that we haven't got quite yet over here. Yeah, it will be different, but only slightly. >>Al: Cool. Is there somewhere gonna be put out that says what the differences will be so that people coating for global Google TV can tweak their apps accordingly? >>Matt: I will make sure that that happens, but ultimately it'll be things like the EPG content supplier that's not gonna be there and things like that. Yeah, and we'll eventually bring it out. Yeah, but I'll make sure it ends up somewhere. >>Al: Cool, thanks. >>Matt: No worries. What are you working on? Can I ask? >>Al: I was looking at working on some social backed applications with Google TV. So, chatting about TV shows but using second screen on a phone and things like that. But if the EPG stuff isn't around, it makes it a little difficult to determine which programs on and therefore, get hash tags and stuff relating to that program. But I can tweak it.
There's other ways of approaching it. And it was a bit of a shock to see that there's no Google+ app for Google TV yet. >>Matt: Yes, I know. >>Sparky: I suppose you could code source that, couldn't you Al? You could just monitor which tags are out there and when a whole bunch in one particular theme start appearing, you can guess that that show has begun. >>Al: Yeah. The only issue with that comes when you got people that are watching the less popular channels 'cause you get the popular TV program, like "X Factor" or some talent show. You get someone who's watching it–. [pause] >>Matt: I think there's a number of ways you can kind of let go with it. I think e-pop is the main one that's, that they really target specific shows in their apps. So, yeah, it'll be really interesting to see what you come up with. >>Al: I'll put you on the beta list.
>>Matt: I look forward to that. >>Sparky: And when you peddle the idea, remember that you heard it here first so you can't sue us. [laughter] >>Al: I'm sure in the States it's patented already somewhere. >>Sparky: So, I wanted to ask Matt, since you were talking about Google TV a little bit, you wanna just give us like the quick, the 10,000 foot overview of what is in the new Google TV platform and how does it relate to Android? What version is it based on? And what new capabilities does it give us? >>Matt: So, at the moment, Google TV is running three point two, so it's still Honeycomb. But essentially, added a load of extra work for media codecs, so it means that we've gotten a load of extra hooks for people with [inaudible] media, so you can actually work out what the quality of the stream is.
We're also adding in support for like, PlayReady DRM as well as allowing content suppliers to create their own DRM solutions. We've also got libraries to help you set your screen applications, so you can easily integrate it with phones, tablets, and then you can either communicate over a socket or use intents. Essentially you can [inaudible] on the TV or on the mobile phone. And we're just developing a load of extra tools so it can actually help develop the tablet UI. We're desperate to make sure they're not just getting tablet UIs ported across without focus states being enabled, which obviously, for the TV that relies on [inaudible] is quite important. So, yeah. And we're at the moment, I mean, our focus is just getting international launch going in Paris, Germany, Netherlands, and the UK. I've just come from IFA in Berlin where we've just had Samsung announce the [inaudible] will be launching in the UK and hopefully other countries soon.
My sense is we'll actually be going international I hope. So, yeah. There's lots of stuff going on at the moment. Lots and lots of devices coming out, so lots of interest all over the place. >>Sparky: That's fantastic. Now, a couple of minutes ago when you mentioned content providers choosing their own DRM solutions, I assume that you're talking about people who provide TV shows and stuff, not services that say, front databases, right? Is that right? Different kind of content provider? >>Matt: Yeah. Yeah, yeah. Definitely. My apologies. Yeah, definitely. Anyone who's got video or audio content and they've got their own DRM solution. Ultimately, it's a neat area, but you'd be surprised at the number of people that have niche content that they're publishing. Like, we've got a company that's in the US that distributes Korean TV shows and we had them at Google IO and their main demonstration show was "Sex in the City" but with guys instead of women.
The other thing is, I suppose, yeah, sure. You could tie it into, for example, the license verification library, but where you gonna say something Al? >>Nick: I heard the question slight differently. I heard it more like with some device. So, you can actually implement let's say, some kind of launcher, I think, to, it's the launcher which opens up the shortcuts to launch all the apps. So, if you wanted to provide a customized experience, which requires a password to do that, you can open it out of the launcher. >>Rich: But at the same time, you'd have to be very careful because we do have a clause in the developer distribution agreement which means, which states you're not allowed to interfere with the other applications, the way they work, or the data that they use. So, when you're trying to lock this application behind a password, just be quite careful that maybe it's still impossible to run the application other manners so it shouldn't muck about with the application data or anything to do with the way the application itself is stored.
If any complaints come in saying that your application is affecting their application, then you could get taken down for it. So, do it in a safe, family friendly manner. >>Matt: See, I think I read this question a third way, which was essentially detecting before the application is actually launched and then essentially throwing up a password screen before that and then preventing it from launching otherwise, if the password isn't entered. >>Rich: Yeah. That would be a function of an [inaudible], right? >>Al: I mean, I read it a fourth way, which is along the lines of using a password to get access to content provider data. So, is there a way of requiring one application to provide a password before it can get access to data from a content provider from a second application? >>Rich: OK. Well, Vmail, you've divided us four ways somehow.
[laughter] >>Yossi: I think what he means is there used to be a way to see the ActivityManager log file, see the system logs and see the events being brought against result to see if it's being launched. And when the activity was being launched, we used to send the intent and show your log screen. And when there was interest, the logcat is now blocked. So, no one can really see the system log even if they have permission. So, application locker won't work and they have the same issue. Basically, you just look for the package after you set the lock feature, then you set the package name and the logcat. And then when the intent is broadcasted, then you show your own screen instead of the app screen. >>Nick: So it sits on top of it? >>Yossi: Yeah. >>Rich: It sits on top of it. So if you don't get the password right, you kill the application? >>Yossi: Yeah. You don't kill the application, you just send a cancel intent or send a home intent, so the apps won't get actually the wrong time. >>Nick: So, you can't do that anymore. So, I guess if you were gonna go the launcher route, I'd look at the source for launcher two, which is in AOSP and use that as a starting point. And beyond that, I guess we need some more details on what you're exactly trying to achieve.
>>Rich: Yeah. That's fair enough. >>Nick: Thanks. >>Rich: Next. >>Sparky: Anybody else? >>Al: I've got one for Nick and Rich. Can we see what's going on in the Hackathon? >>Rich: Yeah, I'll try and get a mobile device through there in a minute. >>Al: Cool. >>Rich: Nick's laptop, I'll see if I can join. We've got one, two, three, four, five, six, seven, eight, nine, ten. We're already fully booked. We got all ten users in the stream right now. So, I might just take this device with me and hope this doesn't–. No, there's already ten people in the Hangout. >>Yossi: OK. >>Rich: So, if you leave the Hangout, you'll be able to see. [laughter] >>Al: If you tell me that you need the space, I'm quite happy to drop out.
>>Rich: No, it's fine. We'll leave it to the last five or ten minutes of the Hangout 'cause there's a good chance we'll drop out while talking around the building. And then I'll take this laptop and go into the Hackathon space and you'll be able to see it that way. >>Al: Cool. Thanks. >>Rich: We'll jump out of there and see what's going on. >>Yossi: You can see a few pictures on my Google+ page. >>Rich: If you follow Yossi on Google+. [laughter] OK, so we'll just go to the next question. Have you got on lined up there, Sparky? >>Sparky: I do. Let's see. How to manage the ICS incremental use of memory for high density graphics? My apps are using up to 20 mgs pre-ICS, but with ICS it goes up to 60 mgs plus.
That's too much. Heavy opps crashes due to memory, etc. Is there not something that you can put into your manifest that says "I want to use an extra big system heap," that you probably shouldn't use? But–. >>Rich: Yeah. >>Sparky: Otherwise–. >>Rich: It sounds like he might be storing more tif files or something in your XHTPI folder. What, 60 megabytes of graphics? >>Nick: So, on this question let's see how many ways it divides us. So, he thinks something's changed in ICS with memory handling, or is he just saying like, the ICS era with HD graphic, higher resolution, how do you guys interpret it? >>Rich: I interpret it as the latter one, but now we're going for HD graphics. >>Nick: Yeah, so each of these devices with the higher resolution screens don't really have a higher per app memory that you can get, can't you, by the memory info class? I can't remember the name of the class.
Physical attribution query and say what's my limit. It's a good way to do this kind of thing, is to use empty caches so that there's a first level where you're caching it to in memory cache. If that cache gets full, you're putting it out to disk and so on. And there's a bunch of great implementations of that, most of them based on LIU caches. So, there's a good talk at Google IO by Jeff Sharky about writing apps which go through such a cache mutation. And that talks about how you would size it based on memory available, right? So, that's one strategy behind a clever caching system. Any other advice you guys? >>Rich: Al Sutton's just put a link to memory [ unintelligible ] memory class. >>Nick: Get memory class, that's it. >>Rich: Oh, is that–? >>Al: That one will give you all the details about what you got available.
>>Nick: Yeah. And I think Jeff's talk says about using the memory available to apps to size your cache. So you might wanna keep, say, half of your memory available for images. But it depends what your app is doing. >>Al: There's also the recycling bitmap information, which might be useful if there are a lot of bitmaps being held around in memory. >>Rich: Yes. They have a good blog post on that at Android developer's blog. >>Nick: Yeah. Reuse bit map objects and recycle it as soon as you can. I think Chris Baynes also has a great recycling bitmap cache implementation on GitHub if anyone would be bored with their internet and find a link to Chris Baynes', uh, GitHub. That would be most appreciated. I think that's it. A nice solution. [pause] >>Matt: I was saying there's 60 megabytes sounds a lot.
>>Nick: Yeah. My original worry with that as well, that you're just opening large sized bitmaps and porting the large sized bitmap in memory and then resizing it when you're setting it. So, I definitely don't do that. Definitely only open, do the thing where you get the bitmap bounds and only open it for a certain size at which you want to present it. So, never, keep it [unintelligible] and resize it, especially if you're doing a custom drawing where you're actually resizing it in your own drawing and things like that. Don't forget about doing that. >>Matt: Another thing to consider, I think it was in the Greendroid bitmap recycling, it's got a listener for memory warnings. And then the minute they receive that, they clear out their bitmap cache.
And I don't know whether that's good as an absolute last resort or whether you just should be avoiding that situation at all costs and not try and account for, I don't know. >>Nick: And as the new callback's introduced in ICS, right, on trim memory, which will get the full on load memory. So this is all covered in that talk from Jeff Sharky in IO. So, I strongly encourage you to check that out. Yeah, which talks about that's the point at which you trim out your cache. >>Rich: Yeah. Sounds good. Yeah, the app should never get to the point where it crashes anyway. >>Sparky: I could get behind that. >>Rich: What was that, Sparky? >>Sparky: Just saying, I think I could definitely get behind that last comment of yours, the app shouldn't get to the point where it crashes. I like that. I think I can live with that advice.
>>Nick: Thanks. >>Rich: The link? Oh, it's a YouTube link for the Jeff Sharky's IO talk. You can also find the IO– >>Yossi: I also posted on the thread, the memory–. >>Nick: Cool. Any more live questions? Silence. >>Rich: We've gotten loads more appearing in the Moderator, though. Let's go have a look. Offline documentation for Android four point one so we can share it with other developers. He's downloaded it three times, but each time the Android training is still lots of Android [inaudible]. I think this is more likely because–. >>Sparky: It probably hasn't changed. >>Rich: Haven't had new classes added to Android training for four point one. But maybe you already, maybe you've spotted a class that is online that isn't offline. But it is most likely that we just haven't added any new classes since the package was built.
>>Sparky: My understanding is that each time we push an SDK release, the Docs team rolls up the documentation site and they put that in the SDK as well. I think that's what's, I think that's what they told me. >>Al: There's also partly Android Open Source Project, there's some training documentation all the development pulls are in there as well. So, if it does look like there's a problem, there's the ability to contribute back to the AOSP and make tweaks in that that hopeful get rolled into the next release. [pause] >>Sparky: Cool. >>Nick: The SDK is updated. You'll get the latest cut then. [pause] >>Sparky: So, in light of that, I would guess that if he's not seeing any new classes, it may just be that there aren't any, unless he can identify something that's missing. I would go with that. >>Rich: Yeah.
>>Sparky: Rich, you're right. The questions are flowing in here. RobM wants to know, looking for tips on developing on lock screen widget. There isn't a lot of documentation on that. However, I did find some information about it on StackOverflow. I just found it by searching for it, so you probably can, too. Or if you look back in the archives of these Hangouts. Go back maybe two or three months. I think you may find it there. So, we had a–. >>Nick: [ inaudible ] widget, then I think most of the app posts which tend to work with standard widget APIs they use, it should be exactly the same as creating a fresh, new widget, right? >>Sparky: Yeah, now that you mention it, I think the question was that we have some information about lock screen widgets that are officially supported for Honeycomb and beyond. And one of the objections that people have is they say, "Oh, I want my lock screen to work on Gingerbread and before as well.
" And that's where you have to get into the unofficial stuff and look at what the people have done on StackOverflow. So, one of the authors of one of the leading lock screen packages basically posted to StackOverflow and said, "This is how I did it." >>Yossi: Why not try and use the AOC code. Try to see how it's built on the version you want to implement. Just extend it to what you want to change. Maybe the views and basically have the base class already implemented on your application. [pause] >>Sparky: That's a pretty good idea. Should we move on to the next one? Let's see. >>Rich: Oh, but Ravi was trying to ask a question when I was talking about, started asking the thing from the Moderator. Do you want to ask your question, Ravi? >>Ravi: Yeah. I've been posting it on chat, actually. That's fine. I can ask here.
I heard it from Google IO that Android would be strictly monitoring the applications that were paid on Google Play. And someone would be downloading and instantly the APKs will be having some strict reinforcements and considering a downloaded application. So, what has happened with it, I mean, I haven't seen any restrictions of people downloading applications from third-party sites and just installing them on their phones. >>Al: I think that's related to the encryption that was coming in Jellybean for paid APKs. >>Sparky: Well, the encryption is in, I think. >>Al: There were some issues that had it that it was backed out for a bit, but I think it is back again. >>Ravi: Oh, right. So, the devices which are supporting four point one and less than four point one will not be having any kind of restrictions over these stuff if I am true. >>Sparky: I don't think that there's much that we can do for devices that are running a release of the OS that comes before it knows about the encryption because how would it? I mean, I guess, I don't know. I suppose if we updated the market client or the Google Play client, maybe you could.
>>Nick: Changes to packet manager involved as well. >>Sparky: OK. >>Nick: You can't [inaudible] >>Rich: It's through Jellybean only and upwards. >>Sparky: Yeah, that's the problem with those darn legacy devices. Screw up all your wonderful new technology. >>Nick: I'll be interested to hear, so, what is it that you heard at Google IO? Was it about the bad encryptions, is that what you're asking about? The install from unsecure sources. >>Ravi: Umm, no. When I just watched the launch of Nexus 7, which is about the Jellybean, yeah. That's where it is. [pause] >>Rich: Next. >>Sparky: Next. OK. Houdini has a couple of questions following up from previous discussions. He was talking about the one-by-one settings widgets saying isn't that really a shortcut because it can be placed in a folder, which I thought was exclusive to shortcuts? Back to your original question, how do you create a config activity for a shortcut? And then he asks a related question, which is, he says, my main use case for creating shortcuts is replicating place on hold screen that is on the overflow menu for the people app.
How can you do that without the widget so he can skip shortcuts altogether? >>Al: There is actually a StackOverflow answer for creating shortcuts there. >>Rich: Yeah, the key is to get the create shortcuts permission, isn't it? >>Al: Yeah. >>Rich: So, just look for, go for search for create shortcut permission. >>Al: Install shorts. >>Rich: They have a widget which creates shortcuts, I think. >>Nick: [ inaudible ] widget right between [ inaudible ]. >>Rich: Is there a way to do the same widget so it can skip shortcuts? No. There's no way inside your application of having a button that you press which [inaudible]. >>Nick: [inaudible]. >>Sparky: The user has to install the widget, right? Is that right? >>Rich: Yeah. I think we actually agreed on that one, that that's the question he asking. Yeah, he's been trying to ask this question since we got here, I think. Trying to find the buttons that add widgets to the home screen.
>>Nick: So, there is an API for adding shortcuts or not? >>Rich: Yeah. Plenty of widgets. Interesting, though. [buzzing] OK. We had a little bit of interference. >>Sparky: [inaudible]. So, just say the app won't do anything unless you install a widget. And then, he'll have his widgets. >>Rich: Or just a lot of uninstalled apps without ratings. But yeah, I think we got to the bottom of it in the end and no, it's not possible. Next. [laughs] >>Sparky: Joined by a couple of new people live on the Hangout. We got Prakash. We got Quint. You guys have anything you wanna talk about here on the Hangout? [pause] OK. We'll let them think about that. Maybe take another question from the Moderator. So, Sebastian says, "I want to make a custom calendar view wherein I can show events match fixtures in date cells. How should I go about it? Thanks." >>Nick: Probably start from the calendar view widget in AOSP.
>>Sparky: So, are you thinking like take that in subclasses and, or–? >>Nick: Yeah. >>Sparky: Can you just override layouts, maybe? Like how much customization do you think is necessary to do something with that? >>Nick: It depends what you're trying to do. You might even be better off going from the calendar app itself. It depends what you're trying to achieve. I don't, I'm not quite clear on exactly what he's trying to achieve. >>Yossi: He's trying to show calendar–. >>Matt: And what about the Google for IO app as well? That might be a good one if that's sort of what you wanted to implement. >>Sparky: OK. So, a couple of good sources. Look at the AOSP calendar app or the Google IO app. >>Nick: Yeah, I'd probably start with calendar which is something similar, but the actual calendar, if you go to that month view, it sounds like what you want, which draws the month and has little dots marking events.
I'd see what I could learn, borrow, steal from that. >>Sparky: We had a question not too long ago, a month or two, where somebody wanted basically wanted to take their own private calendar data and mash it up with Android calendar data and display it in a calendar. And I seem to recall that what we came up with at the time was more or less, they would have to create their own UI for it. That we didn't have a way to just enhance the existing UI of the existing app. So, it's the case that the way to do this is gonna be to look at the source code of one of these already published date-viewing apps, IO calendar, whatever and actually get, really get down in there into the UI and basically copy slash reinvent the UI. [pause] OK. "Can I make an Android app for just three people to have without putting it in the store?" Yes, absolutely.
We call that side-loading, which basically is installing by a means other than Google Play. And in order to support side-loading, your users have to go into settings and from settings, go into security and select the checkbox that says "unknown sources." In this case, unknown sources is pretty much anything but the Google Play store. Once they do that, the easiest way to give just three people your APK is to attach it to an email and email it to them. When they read the email on their device, then the package manager will offer to install it. Clear? I think? >>Nick: And as you get increasingly sophisticated there's other things you can do. So, if it's just small, like something like Google Drive or drop boxes, it's great for all your sharing-related tools, but if you get more requirements, like have more tested, more people you want to distribute it out to, there's other solutions out there like there's one called Floppy App, which is, I've heard a lot of people using. So you can use that to distribute your apps to other people. It's kind of like a private store.
>>Sparky: Hmm. When you said that, what I immediately thought of was Hoccer, which I seem to recall was popular a couple years ago as a way of sharing things with people. Are those guys still around? >>Nick: I don't know. I haven't heard from them in a while. >>Sparky: That was the other thing. It was a little bit like Bump, only it worked over a distance, where you had your accelerometer and you took your device and you kind of went "foop", like that, almost like you're throwing a Frisbee and they could catch it. And the devices would talk to the server and correlate the accelerometer readings and figure out who threw what to whom. Doesn't ring a bell with anyone? H-O-C-C-E-R. >>Al: It doesn't with me, but a quick thought is if you're developing an Android app, you can use NFCB to send a URL between devices. So, if you wanted a quick way to do it, host the APK on the web server and update the app so that NFCB sends a URL across the other device should be able to woken it up and install it.
>>Sparky: I thought about that. I also thought that a small developer who's gonna get an APTK to a couple of friends quickly is more likely to have email than a web server. >>Al: True. True. >>Nick: I think the [ inaudible ] drive is the way to go here. >>Rich: Yeah. >>Sparky: Google Drive. Good one. I hadn't think, you know, that one even slipped my mind. That's a great answer, too. >>Nick: Yeah, I like Google Drive 'cause then you can even update it and make sure everyone has the latest version and all that good stuff. >>Sparky: OK. All these questions that keep on splitting our opinion in multiple different ways. >>Al: There's never one right answer, just a whole series of suggestions, which is the way it should be. >>Sparky: Right.
Let's see. You people have to stop voting on these questions. New questions are coming in and they're getting voted up and filtering to the top of my list on the Moderator. Maybe in the future, I'll, maybe in the future I'll lock the Moderator just before we start the Hangout. So, a word to the wary, get your questions in before the Hangout begins if you want an informed answer. "I just switched from C2M to GCM, but sometimes my messages don't get delivered to all devices when sending them as a batch. The devices are all linked to the same Google account. Does that mean it will only deliver them to one?" >>Al: No, GCM doesn't guarantee delivery of any message. So–. >>Sparky: I am not aware that it restricts multiple devices on the same account from each receiving the message. I hadn't heard anything about that. So, I would guess that's probably not the case. It may just be vagaries of delivery. >>Rich: Lots of applications that you have installed, you'll get notifications across all your devices at the same time with GCM. As long as you've got the ID right as the device sets up and registers your server.
You may have issues that you're not correctly supporting the C2DM and GCM at the same time. Some devices are still on the C2DM version of your client and some devices have upgraded to the GCM version of your client. Maybe one or the other aren't getting the messages–. >>Nick: [ inaudible ]. >>Rich: Yeah. Boy, you've got to support both C2DM and GCM and both end points on our server so we can send the right message to the right clients. So, you'll be sending two sets of messages if you're still doing the upgrade, especially if you've just switched over. It's likely to fall into that bucket. So, make sure you've got an old client that's still on C2DM and a new client that's on GCM when you're doing the test, I would say. If it's not that, then yeah, what Al said that we don't guarantee delivery. But it's definitely not down to us excluding devices because they're on the same Google account. Andrew Kenny has one other question.
He also asks, "If I have a grid view, how can I get the last rows recentered if I have an odd number of items to the grid?" Apparently it's in the left-hand column of the other items. I don't actually have an answer. In the left-hand column unless you can add a footer to grid view like you can on list views. Maybe you can add a footer item if you've got an odd number of items, you can put it in the footer. Any suggestions from the Hangout? >>Nick: Add a spacer item? >>Yossi: Yeah. Maybe [ inaudible ]. Just as a filler? >>Rich: Just as a filler? So, you'd be in the right-hand column, yeah. But he wants it centered in the middle. >>Nick: But I'm saying it's just like three columns and then you could add one. >>Rich: Oh, there's three columns? Yeah, that's not bad. Yeah. I was imagining two and then left and right and swap. >>Nick: Yeah, right. Yeah.
>>Yossi: He wants it centered, so it has–. >>Nick: I would say this sounds like a custom layout. You probably want to extend grid view and change some of its layout attributes and center the last little line. >>Sparky: I haven't done this with grid view, but I had a question a little while back where somebody wanted to center an even number of, well, a mix of even, odd numbers of elements–in this case, buttons–in a relative layout. And what I suggested was creating an invisible, or a non-visible, text view. Center that and then place all the other elements relative to that. So, a spacer item or an invisible view of some kind, may be a way to go here. >>Nick: I like the idea of extending grid view. [inaudible]. I think that fills that. >>Rich: Extend the grid view.
>>Nick: Yeah. Plus it will work nicely with the adapter as well, [inaudible] background of the [inaudible]. There we go. Announced. >>Rich: I was thinking, yeah. That's fine. Well, that was the last question from the Moderator unless someone else has snuck one in whilst–. >>Sparky: I got a bunch more, actually. >>Rich: No. Well, we've only got three minutes left of the Hangout and I was gonna do a quick run round to the–. >>Nick: Yeah, do it. >>Sparky: Well, why don't I through some of these questions while you take a walk maybe? >>Rich: OK. I'm unplugging from the Ethernet, so that might drop me off for a start, but I'll just re–. [laughter] >>Sparky: He is frozen. So we've got another question on the Moderator here. It says, we "described how to make use of a drawer but didn't document it or provide any implementation advice." Well, that's true.
It's so new that basically the Android team had not, or the framework team had not yet caught up with the practice. So, look ion Stack Overflow. There's some Stack Overflow threads that give links to projects that implement various versions of the left-hand drawer. And look–. >>Al: And then obviously–. >>Sparky: Look to the YouTube application as the way that we recommend that it be implemented in terms of behavior. Oh, I see some motion there from, is that Rich? >>Rich: Yeah, I'm sure you can see that it's a beautiful day here in Tel Aviv. I just thought I'd stop on the balcony for a second to make you all kind of jealous. When was the last time you saw a sky like that in London? >>Sparky: It's been a while since I saw one in–. >>Rich: And the palm trees. OK. >>Sparky: Let's see. I'll take another question from the Moderator while he's walking. "In my UI thread, I started a task to do some long time calculations.
How can I weight properly in the UI thread to get info about finishing the task without handlers?" You can post progress updates from you async task. And you can also complete the task by doing something on post execute. >>Al: We have a cardboard Android. >>Sparky: Cardboard Android. Rich, what are we looking at? >>Al: I have a feeling they've just frozen. >>Sparky: Uh-oh. Well, they stepped into a, they stepped into a lion's den of developers there. They're probably using every wi-fi channel. [pause] Got a couple of new people in the call. We got Falco Richter. Any news from Falco? OK. [pause] Do we recommend creating a library Android project to validate–? [pause] Is always a good idea. Maybe not for something like a spinner or a drop-down list, but if you're taking anything from a text view or a text edit, definitely validate your– >>Al: And they're back in Israel. >>Rich: OK, we are back. Here's the Hackathon happening in the college right now with [ inaudible ].
[background chatter] This is, this is the Android developer Office Hours. Hey guys. What projects are you working on? >>Male #1: I'm working on–. Hi. I working on, it's a kind of application that integrates Google Drive API to distribute files with [unintelligible] events. If you're attending a Google IO, then you don't have to download the application, it will drop inside your Google Drive. >>Rich: Thanks very much. Does anyone want to see what other project bits are going on? Or, do you wanna finish it off there? >>Al: No, keep going round the room. It sounds interesting. >>Rich: OK. Would anyone else like to tell the world what project they're working on at the moment? [background chatter] Yeah? Yeah. What project's you working on? >>Male #2: [inaudible]. We're doing dog feeding. >>Rich: Dog feeding? >>Male #2: Yeah. Poor dogs. No, it's basically an application that once installed in all your device, will choose whatever products you want to subscribe to. Every time the machine builds a new version, it uploads everything to your drive and then has it installed on your devices, beta users, [inaudible].
[background chatter] >>Rich: Excellent. That's actually guests Google Drive slash Android Hackathon. So, lots of projects going on. Google Drive projects as well. It's an excellent addition to your build system, will upload your files as you're building them straight to Google Drive and that way users test them, the latest version of the apps as they're being built. We'll leave it at that. We're way over time already. But–. >>Al: Thanks for the tour. >>Male #3: Only a few people? >>Rich: Yeah, it's all right. Well, thank you all very much. We're gonna leave you there and we'll catch you again next Wednesday. >>Al: Thanks, guys. >>Sparky: Alright. Thanks everyone for showing up. Once again, giving us another great excuse to fill your heads with lots of ideas about Android development. And we'll join you again at the same two o'clock UK time, three o'clock Central European time next Wednesday. Take care everyone. >>Rich: Until next week.
See ya. >>Al: Bye..