[music playing] [inaudible] reto meier: or you can post yourthoughts in the g+ event or the youtube comments. and producer dan is going toread those out for you, if you
Android quit App, are too shy to join us liveon the telly box. while we give folks a chance toget their thoughts together and join us on the hangouts,i'm going to cover a few points that have already beenraised by some of the
developer audience onthe google+ page. those of you who have joined uson the hangout, thank you for joining us. we'll get daniel in touch withyou via text on that, so that we can queue you upand get you ready to share your thoughts. so dan: sorry about that. i cut out the first 10 secondsof your intro, the welcome,
and if you're watching[inaudible] and all that stuff. sorry about that. reto meier: that's all right. not a problem. just so everyone knows, this isafter the table flip, talk radio style, chance for everyoneto tell me how right i was, or how wrong i was. i somehow suspect we'llget more of the
latter than the former. just because, if you agree thenthere's not a lot to say. so we're going to get somefolks on hangout as well. i'm going to start off byanswering some of the questions from people onthe g+ event and the youtube live streams. so if you do have questions andyou prefer not to be on video, do throw them in there. and producer dan will respondon your behalf.
so on g+, developer jacob[? nordfolk ?] represented probably the mostcommon argument against what i was presenting in today'stable flip. and that is, that there's alot of user pressure or dissatisfaction. because users, quote, "don'tknow how to quit the program." and i think i coveredthe argument against that pretty well. but let's be a little bit morespecific in two examples.
so in jacob's case, he's talkingabout two internet radio apps that he has built. and in his experience, usershave failed to find the stop button to stop the music. now he's pointed out that in hisparticular use case, he's not allowed to make the stopbutton more prominent. and so this is a genuineproblem. so what i would say is, have alook at the way that google music actually solves this.
and so really it's aboutmaking sure that stop-- stopping the music, stoppingthe resource consumption-- is really, reallyeasy to find. so google music does this byhaving the stop controls along the bottom of every activity,whenever the app is running. or if the app isn't running butthe music is playing, then there's an ongoing notification,which has rich notifications. which again allows youto stop the music.
and in addition to that, there'salso the lock screen, which you can then configure--and which google music does-- to allow you to stopplayback as well. and so the solution here,particularly for music playing apps, is that all of thosethings i've just described are totally available to anythird-party app. and so by doing things likethis, it makes it really, really easy. even if the stop button doesn'thave to be half the
screen, it's just everywherethey look there's a really obvious place to find it. and that's going to be much morereliable than having an exit button, which alot of users aren't going to find anyway. user demands for an exit buttonalmost always correlate to an app that has confusingnavigation, or hard to find controls, or is aresource hog. so adding an exit button isgoing to stop users from
asking you to addan exit button. but it's kind of like givingan aspirin to a patient complaining of chronicabdominal pains. they will stop askingfor the painkillers. but that doesn't actually getrid of their problem. so you're better off trying totreat the underlying cause rather than the symptom. and similarly, daniel [? drew ?]asks, how would you implement the browser featuredof ditching all cookies on
exit, if you don't havean exit button? and that's actually a reallygood question. in practice i think there's anassumption that mobile devices are inherently more personalthan computers. so privacy features likethe removal of cookies when you exit-- which were really designedaround ensuring the credentials used by differentusers on the same computer-- don't leak, when your wife,girlfriend, husband, whoever,
uses your computer. so those sorts of featuresaren't quite as important for a phone, with the implicitassumption is that there's only going to be oneperson using it. and in fact, it even almost goesthe other way, where the pain associated with having toput in your credentials or into the same informationmultiple times, is actually significantly more annoyingon a phone than it is on a computer.
so there's even more reason tohang on to some of this stuff. so that said, if you did want todo something like that, the suggestion i would have isprobably to have a menu option, probably a settingsoption to clear all cookies. or better still, maybe a menuitem, which says something like "close all windows andclear all cookies." or it just says "close all windows andclear all cookies" is one of the option that you have. so that's answer to twoof those questions.
what should we goto next, dan? have we got folks on the hangoutwhich would like to vent their spleen? dan: we don't haveanyone explicitly asking for time on camera. but if any of you guys in thehangout right now want to comment, we can definitelyput you air. so just let us now. reto meier: i think we shouldput people on the spot.
if they're joining the hangout,we're going to assume that they've got somethingto say. so pick someone who looks likethey're enjoying themselves. the guy in the red shirt. let's pop him online andsee what he's got to share with us all. dan: all right. the guy in the red shirt wouldbe jay [? mcgill. ?] i'm not going to sayhis whole name.
reto meier: he can introducehimself. you want to pop himup on the screen. and let him know. and unmute him. because i suspect he's muted. reto meier: i thinkhe's still muted. dan: hey, how are you doing? can you hear us? reto meier: we can't hear him.
have you got dan: here we go. reto meier: now wecan hear you. so what do you think? am i full of it? or am onto something? audience: you're absolutelyright. and i was curious if thereare any other options? i mean, are there people thatthink that the exit button
makes any sense? reto meier: there are. there are a surprisingly largenumber people which disagree with the basic premise. i think it's usuallyaround users. that seems to be the feedback iget from most developers, is that they're like, yeah,we don't want to do it. but our users keepasking for them. and so i think a big part ofit is trying to explain.
and a lot of the timewhat they're saying is, well that's fine. but you need to explain to userswhy they don't need an exit button. but what i've actually found isthat it's easier to explain to developers how to build appsthat people aren't asking for those exit buttons. that kind of tends to bethe most common thing. they're like, i didn'twant to do it.
but people kept asking for it,so i had to build it in. so it's really about trying toexplain to devs how you can build apps which don't havepeople asking those questions. audience: in the end, if theclient does ask for it-- [laughter] audience: they'repaying for it. they get it. reto meier: absolutely. of course, i guess that's theother case which i haven't
really talked much about is,what happens when you're building an app for someone. and they say, we wantan exit button. well, you have to do whatthe client says. but really it's about trying tocreate an atmosphere where people feel comfortable at leasttelling their clients that, this is an anti-pattern. this is not what android usersare going to expect. and being able to say thatwith some authority.
and that's a big part of whatthe design guidelines on developeratandroid.com/designare really about, is helping to create sort of an expectationof, this is what android apps are. so if you're asking forsomething different, then it's counter to what peopleare expecting. i think there's a lot ofbackground which we have to get past, of people being usedto old feature phone j2me apps, which havean exit button.
because they were sortof single tasking. or even iphone, which uses aslightly different model for the way that they do things. and so a lot of it is education,both the developers and users, and clients,which seem to somehow fit in between. dan: anyone elseon the hangout? i'm going to put you guys onthe spot and just select someone at random ifno one volunteers.
audience: i just want to jumpin real quick before i have to head out. reto meier: hi ryan. audience how're you doing? reto meier: good mate. dan: all right, ryan. go ahead. you're live. audience: cool.
so i just want to agree withreto with the whole activity life cycle thing. a lot of people say that youneed that exit button to exit that app and get itout of their mind. i guess a lot of people probablyjust don't fully understand that life cycle,where it goes in the background, stays in thebackground for a little bit. you have to adjust for thatwhole life cycle pattern of going through on pause, and thenon stop, and making sure
you clear up the things thatyou're appropriately doing with your app in thoselife cycles. reto meier: yeah, i thinkthe life cycle stuff-- it's kind of the most fundamental thing about android. which makes it really differentto anything i've ever done before. i was a windows programmerbefore android. you're not really thinking inthose sorts of terms, of the
os telling you what's happeningto your app. you capture some of thosethings, like on-form leave, and on-control focusand stuff. but it's never to controlyour resource usage. it's just to decidewhether your app should be doing something. and i always think that's kindof the big challenge. once you really get the lifecycle stuff in your head, everything else justkind of makes
sense and kind of follows. is that similar toyour experience? audience: yeah. i definitely agreein that aspect. a lot of people probablyjust don't see that. us being developers, youknow that life cycle. you know it's happening inthe background, what is supposed to happen. maybe the users just don'tsee that, right?
in the foreground of, oh there'sa life cycle going on and this is what needsto happen. and so maybe they'refeeling like there should be an exit button. when in reality, you reallydon't need one. so you're definitelynot crazy. i see where you'recoming from. so i just wanted tolet you know that. reto meier: cool, thanks ryan.
i appreciate that. all right. cool. do we have any other questionson either the livestream or on g+ or youtube? oh someone's got hishand up in the-- dan: all right, yeah. let's put him on. this is dave.
reto meier: hey dave. dan: go ahead, dave. audience: yeah i just want aquick comment about what the previous speaker said. i think it's going to take alittle while for people to get used to that. i think we're so-- even a few years ago, or acouple years ago maybe with vista or something like that--
we're so used to closing downstuff and making sure ram is available and all that stuff. that we need to really get usedto knowing that if an app is done properly, sitting in thebackground, not consuming resources, not pinging theserver and so on and so forth. i think that's really going totake a couple of years before people understand and areaware of that, and are comfortable just leaving appsopen just by hitting the back button and back tothe home screen.
i think there's a big challengethere for us as developers as well. it's making sure thatusers feel really comfortable doing that. and this is the thing, if youhave a whole bunch of apps, and then you go back to the homescreen and your device starts running real slow, that'sa terrible experience. it's no wonder users are goingto be like, i just want to know how to exit allof these apps.
and so i think the frameworkteam here at google have done a lot of work in that direction,to try and make the blame more visible. so things like battery drainand those sorts of things-- you can see which appsare doing it. and so the blame goes to them,rather than to the system. and if you're doing thesethings right-- if you're suspending all of yourlisteners, turning off your updates, not doing backgroundrefreshes
or any of that stuff-- then your app will never getblamed for anything. and no one's ever going to callinto question as to, how can i get rid of this. because it's just there. and it just works. but yeah. i think that's the challenge. you've got reach that criticalmass where most apps are doing
the right thing. and then users are going to belike, why would i exit it? that's just going toslow stuff down. audience: mm hmm. dan: cool. so ali, hey, i notice that youhave a question in the chat? do you want to ask reto live? you're on air. audience: i just askedwhat i could do--
i'm actually just starting tostart to develop and whatnot. so i want to know, are thereany resources that you can actually provide, or thatgoogle provides, about learning more aboutthe life cycle? so i posted a link. so links to all of the stuffthat i showed in the intro video there, on the youtubesite, i'll post it into g+ event as well. but to answer your question morespecifically, if you go
todeveloper.android.com/training, we have a bunch of intro levelclasses to help explain the basic building blocksof android. and i think the life cyclestuff is lesson one. it's kind of that fundamental. so if you want to get a betterunderstanding of what it means, how does it work,what's the right way of dealing with it, then definitelycheck that out. and that should helpyou get started.
audience: thank you. reto meier: no worries. and good luck with everything. it should be a lot of fun. we look forward to seeingwhat you come up with. audience: thanks. dan: all right guys. who's up next? just go ahead, raise your hand,and i'm on the hangout,
and i'll put you guys live. anyone? here we go. sorry, i'm not quite sure howto pronounce your name. why don't you go ahead andintroduce yourself. reto meier: oh yossi. [interposing voices] from google+. nicely done, man.
how you doing? i think you muted yourself. dan: yeah. still nothing. why don't you go aheadand check your mic. reto meier: we're not hearingyou unfortunately, yossi. audience: can you hear me now? reto meier: we canhear you now. thank you.
audience: ok. sorry. a couple of mics overhere, so i needed to choose the correct one. first of all, hi reto. i don't know if you rememberme from the google i/o? reto meier: vaguely. i meet a lot of people at i/o. audience: i know.
basically what i wanted to referto was the exit button. in our app, we use video-socialcommunication, chat and im messagingand so on. and basically we have userswanting to exit the application in fully, not justdoing a signout and leaving the service running orsomething like that. basically they want to exitthe application, so our service will die at thesame point they want. so i'm referring to itas a bad pattern.
because that's more like asingle task device and not the android system. but basically, if we need toimplement such behavior, then the exit button should be a partof the android pattern. although the android system iskilling tasks by itself. reto meier: i think thechallenge in a situation like that is similar to what you'regoing to see things like googletalk or any ongoingmessaging thing where-- the user wants the ability tobasically say, disconnect from
your server. and stop consuming everything. so in that case, the culminationof hitting logout or signout from the service,and then listening for on-pause should be enough. so that once they saydisconnect, that should be the equivalent of hittingexit, basically. audience: that's whatwe implemented. we have both features.
we have the featureof signout. so we'll show the user thehome screen to log in via facebook or his usernameand password. and we also have the exit buttonthat keeps the user logged into the system, butbasically exits all the applications and kills theservice and everything. and then all messaging ornotifications comes via gcm or t2dm to all the devices. reto meier: so that'sinteresting.
that brings up a reallygood point. kind of what i was alluding toearlier-- like, if you hadn't told me that, if i just openedyour app and saw logout and exit as two separate options, iwould have no idea what the exit button would do. i certainly wouldn't expect thatif i hit exit, that i'd still get messages from gcm. i would expect that if you hitexit, everything turns off. so i log out, and i stopgetting messages.
if you introduce something likeexit, which doesn't have a clear semantic meaning, thendifferent users are going to interpret it in differentways. and so, logout totallymakes sense. disconnect me fromyour services. i don't want to getany more messages. 100% makes sense. exit-- it doesn't.
basically what you're describingwhat the exit button does, it sounds to melike what should happen when i hit back or home fromwithin your app audience: that's whati'm saying. but because we're doing crossplatform, so we want our users to know that the device orapplication handles the same situations all overthe platforms. so basically if you have an exitbutton on iphone, or you have an exit button on windows,or on windows phone
tablets and so on, or even onmac-- you press command q, you exit the app. and on android, the ecosystem isjust, hit the home button, and let android deal with allthe memory and all the tasks ongoing, and so on. so what is the best option tohandle the situation for us and also give the user the sameatmosphere, or the same experience, when movingfrom device to device? because basically the userconnects from an ipod, an
iphone, an ipad, a nexus 7,nexus 10, google tv-- you name the device,we have it. so basically we want the usersto know that [? uvu ?] connects people allover the world. no matter what, the sameexperience, the same features are available on all devices. so that's the main issue here. reto meier: ok. that's a good question.
and it's actually aninteresting one. because i hear this a lot fromdevelopers who are building these cross platform solutions,where they want to have something really consistentacross all the different devices. now the thing is, there's sortof two different ways that i would approach this. and the first is that it'sactually fairly unlikely that you're going to have asignificant number of users
which have multiple differentdevices from different manufacturers. so you're not going to have alot of people which have an iphone and an android phone. there will be some-- and this leads me to my secondpoint, which is that people expect their devices tobehave consistently. they don't necessarily expectapps to work exactly the same across different devices.
so if i've got an ipad, then iexpect all of the apps to work in a way that's consistent withthe way all of the other ipad apps work. and if i have android,then i expect them to all work with android. so what you don't have is aniphone user expecting their android phone to work in thesame way as their iphone. because it's a differentdevice, right? they don't have thesame expectations.
if they did, they get reallyconfused when they started using things like mail and mapsand music and twitter and everything else. because they just inherentlybehave differently. and it's the samewith computers. you expect your computer towork in a certain way. expect to have that command qto get out of an app in mac. if you've got windows,you expect to be able to hit alt-f4.
but what you're notexpecting is-- a good example is, if you'rebuilding an app for both windows and mac, you're notgoing to build the command q shortcut into the windows app. so that people who areusing it on mac understand how to quit. you're going to build in thesame user patterns that they're expecting for windows. and it's the sameacross mobile.
like, i wouldn't tell you tobuild your iphone apps so that they work and look the sameas your android apps. you want to have a consistentexperience between the platform because that'swhat they're doing within a given context. so for your app in particular,what you want to do, what your users are going to expect isthat if you're signed in but your app is not in theforeground, then it shouldn't be consuming any resources.
and that's just going tobe their expectation. some may look to findan exit button. but if you're not doinganything, if you're not consuming any resources, if thephone's not going slower, if you're not doing backgroundpolling, you're not waking up the phone-- you're just receivingthose updates using google cloud messaging. then they're goingto be happy.
they're not going to be lookingfor something if there's no reasonto look for it. so that would be my bigpiece of advice. don't try to over simplifyacross devices. because in my experiencethat tends to be what bosses, what ceos do. they look at all of your appsacross all the different phones audience: that'sour issue here.
the designers or product guysbasically want the same features to be on all devices. and my main concern or my mainissue as an android developer is to show them the androidsystem is not the same as the ios system. or is not the same-- so you have the basicconventions in android, such as the home key or not showingthe exit option. i agree that you don't needan exit button on your
application. but basically i want you tosay it so i can have up a judge overrulingon the matter. so i can show it to ourdesigners and let them know that basically what they'redoing is not is not native to android. reto meier: sure. and that's the sort of thingwe're trying to do a lot more of these days.
i think the thing about android,particularly when we got started is, it's open. you can do anything. but now we're trying to get tothe point where it's like, you can do anything. but we'd really like people todo things in a consistent way to make it easier for users. and so we're trying to becomea little bit more aggressive about telling people whatare the best practices.
you don't have to follow them. no-one's going to take your appout of google play if you do things differently. but at least something you canshow your design team and your management team and say look,this is the way that things work on android. and if you want to do itdifferently, you're going to have to come up with somethingvery different. oh, i see what'shappened here.
dan: [? i think ?]your keynote. reto meier: yeah. so let me just jump over hereand i'll fix that problem. wonderful. boom. yeah, so it sounds like you'reon the same page as me. so it sounds like we'rein good shape. the challenge is explaining toother people exactly why that's the case.
and hopefully you can share withthem some of the stuff that we talked about today. and that may help changetheir minds. thanks for your time, yossi. it's been a pleasuretalking to you. dan: i'm going to put luke on. luke has a quick questionfor you. reto meier: cool. hey, luke.
audience: hey. i was just wondering aboutsomething that i've seen that's similar to what you'retalking about, but not exactly the same. where someone hits the backbutton from an application dan: i love it. hangouts. reto meier: hangouts. doing us a favor.
dan: one second, guys. reto meier: we'llbe right back. i love the technologyaround here. it never screws us over. so, while we're waiting forluke to come back-- cool. i think you're back. so we missed some of thatbecause our hangout crashed. i'm going to go and assume thatsentence finished with, you hit a back buttonthat says, are you
sure you want to exit? audience: yes. reto meier: right. yeah, i hate that too. that makes me very,very angry. there are very few exceptionsto that rule. so navigation is actuallya good one. where if i hit the back buttonon google navigation, it says do you want to endall [inaudible]?
then you can eithersay yes or no. and that's reasonable. because i think it stillbacks out of the app. it just either does or doesn'tturn off the ongoing service. and that's because, if iaccidentally hit back while i'm driving, i don't want tothen have to faff around with maps and navigation to tryand get it back up. so i like that, where it'ssort of a disruptive, distracting behavior.
but it's just a normalapp, that's like-- it shouldn't be a difference,right? for most apps, if they don'thave an ongoing service, hitting back and then going,oh whoops, and then starting it again-- it should be the same asstarting it from scratch. or hitting home andgoing back. so yeah, that's definitely ananti-pattern that i really hope dies a death.
audience: that's kind ofwhat i was expecting. nothing too controversialthere. thanks for bringing it up. we've got another hand wave. i think fourth from the left. dan: is that you again, dave? reto meier: i think so. i don't think that's it again. audience: that was justmy son waving.
reto meier: excellent. say hi to your son. dan: who's up next? unfortunately, since the hangoutcrashed, i lost some of the comments. so if you guys were interestedin joining in live, just let me know. wave your hand. i'll put you guys on air.
reto meier: do we have anycomments on g+ or on youtube which may requiresome responding? dan: there are actually alot of great comments. i'm actually having a hardtime picking a good one. they all seem to be replying toeach other about this very debatable topic. reto meier: oh, ok. excellent. dan: so let me go ahead and lookthrough a couple of them
and pick a great one for you. i did see one down here. let me scroll down. reto meier: so while daniel'slooking that up, i just want to as well point out to you guysthat i'm going to try and do this semi-regularly. so if there are particulartopics which make you want to flip a table, let me knowon g+, twitter, wherever you like.
and i'll see if i can puttogether some argument. yes, dave? audience: i actually havea quick question. maybe we all have thesame question. are you going to flip thattable before you leave? reto meier: i was thinkingabout it. but my laptop is on it. so i'm going to choosenot to and maybe save that up for next week.
i will also take suggestions ondifferent kinds of tables. i know that there were somepeople who were disappointed that i used a table which hada cylindrical bottom, rather than a more traditionalfour-legged table, which the emoticon would seemto require. but it's a learningexperience. it's iterate and launch earlyand iterate often. so that's what we're going to dohere at table flip as well. i'd really love to hear whatare some of the things that
drive you guys crazy. as justin was sort ofsuggesting earlier-- a lot of the time, we asdevelopers all know how we think apps should work. and we get overruled bydesigners or pms who perhaps aren't as familiar withandroid as we are. so if you're looking for a wayto be able to present a justification, do let me know. and perhaps a six-minutevideo will help.
i don't know how much so, butit's probably worth a try. did you find a good questionor comment for us to respond to? dan: i found a simple one whichis not too far beyond my understanding. it's about de-bouncingthe back button. for example, if you're headingback multiple times and quickly try to escape an app,which most users tend to do, it'll take you back a lotfurther than you intended to.
so what are your thoughts ongiving some feedback to users when they're hitting back ina short amount of time? reto meier: so i think i'm goingto answer that question by answering a slightlydifferent question, which is really about navigation. and i think that's anothervector into which people are like, i want an exit button,because otherwise i'm in a browser or in an app that ihave to hit exit like a million times before iget out of the app.
if that's happening, that tellsme that the navigation of your app is probablyoverly complex. it shouldn't require 15, 20 backbutton hits to get back to the home screenof your app. so that's using the[? app affordance ?] or using a logo click to takeyou back to the main screen of your app, you really want tobe able to make it easy for users to navigate, particularlyon phones and i think still on tablets.
you really don't want to forceyour users down a rabbit hole of navigation. you want to keep it assimple as possible. so rather than figuring out howdo i deal with the fact that a user may hit the backbutton seven times instead of six times to get to the homescreen, think about how to make it easier for a user toget to the home screen to begin with. i think that's probably a betterway to invest your time
than figuring out howto do de-bounce too many back button clicks. dan: so we've got another goodcomment from paul w here. he says that users traditionallyhave grown up being taught what the exitbutton does throughout their entire lives. and so you're on windowsor you're on some other operating system. and everyone kind of feelsfamiliar with the exit button.
and it's kind of part ofthe foundation of how we do things already. reto meier: yes. dan: so maybe he's sort ofdisagreeing with you. reto meier: i'll take that. i mean, i think that's what iwas kind of talking about right at the beginning. so you may have missed the we'llhave just the video of the [? rant ?] posted.
in fact, there's a link to itin the g+ stream if you did miss the very beginning. but it's a good point right? like, old school, exitmeant something. like if you have asingle-tasking operating system, you need to have an exitin order to be able to do something else. and so, yeah, users havegotten used to it. particularly us.
like, i'm guessing peoplewatching this have been using computers since shortly afterexiting the womb. and so those patterns reallygetting ingrained with us. but new users-- they're not thinkingof it that way. particularly phone users whodon't really think of their phone as being a computerthat runs apps. they just think of itas a device that lets them do stuff.
i mean, i remember readinga survey-- i think it was late last yearor early this year-- which asked people, do you usethe internet on your phone? and most said, no, i don't usethe internet on my phone. and the follow-up questionis like, well, do you check your email? do you update facebook? do you use twitter? and they're like, yeah,definitely do
all of those things. and it's like-- the internet, howdoes it work? that's what's making allof these things work. but people don't thinkof it that way. all of the implementationdetails about how these apps work-- the fact that thereare apps running in a multi-tasking operating systemconnecting to the internet over ethernet or a cell network,tcp/ip connection.
they don't know any of that. they don't care aboutany of that. they just want to do something,like order a taxi, or check their email, or update twitter, or take a photo. and how it all works meansnothing to them. and so in that context, exitdoesn't make any sense. like, i just want toupdate twitter. and then i want totake a photo.
i don't want to have to thinkabout exiting one app to start up another. so it's really about changingthose paradigms. and getting people thinkingin a different way. i mean, you can say anythingis old school. like, i remember when i was inhigh school thinking, i can't believe it. this new computer i'm goingto buy doesn't have a 5 and 1/4 inch disk.
that's ridiculous. i mean i know i mainly use the3 and 1/2 inch floppies now. but the 5 and 1/4 isnever going away. yeah, it went away. and then the 3 and 1/2 inch wentaway not too long enough afterwards. and then hard drives startedto end up in the terabytes. my point is thatthings change. and i think as developers,we need to adapt to that.
and the trend is really to tryand make things easier and easier for users, so they don'thave to think about how do i use a computer? they just do stuff. and then the os doesall the hard work. it's the same when we startedswitching to garbage collected programming languages. like a lot of folks back in theday were like, oh that's ridiculous.
you don't have to manageyour own memory. but you know what? it's easier. it makes our job easier. and it lets us focus onfeatures, rather than on the bits and pieces that go intomaking an app work. i think we're just aboutout of time. we've already gone15 minutes later than i initially proposed.
but we've had a lot of goodcomments and conversations. so i didn't want tocut anyone off. but is there anyone on thehangouts which would like to throw in a few final thoughts,comments, disagreements? could you speak up? reto meier: oh, you'revery welcome. audience: i had a question. and i was wonderingif you could do a session on unit testing?
yeah, unit testingis a good one. i think testing is somethingwhich we probably don't have as much information out therefor android as we should do, considering how importantit is. so yeah, we'll definitely feedthat back into the team. and see if we can get anoffice hours hangout or something around unit testingbest practices, those sorts of things. it's a great idea.
dan: cool man. i think that's it. reto meier: all right. thank you very much everyone. let's see. yes, so that's it for today. i'll be back next time foranother android anti-pattern that makes me wantflip a table. i don't know what it is yet.
so if you've got suggestions,let me know.
and i will throw the furnitureon your behalf. until then, my nameis reto meier. we were ably assistedby daniel [? fan. ?] and thank you for watching.
