The App Clinic: Travel: On the go

Uploaded by androiddevelopers on 02.11.2012


IAN NI-LEWIS: Hello, everyone.
My name is Ian Ni-Lewis.
RETO MEIER: And I'm Reto Meier.
And on today's "App Clinic," we'll be looking at apps
people while they're traveling.
That's an excellent idea.
And I just swallowed coffee down my lungs.
Why don't you take the next line.
RETO MEIER: That is the wrong place to be
drinking your coffee.
Gone are the days of badly folded maps, guidebooks, and
laminated holiday itineraries.
Today you can keep everything you need in the
palm of your hand.
IAN NI-LEWIS: That's right.
No longer will you look like a bumbling tourist standing on
the corner of Oxford Street and Charing Cross Road with
your London street map unfolded before you,
fruitlessly trying to figure out which direction is--
you know, I never even do that.
What's your plan?
IAN NI-LEWIS: My plan is, I'm always looking
at the curb in London.
Because it tells me which way the traffic is flowing.
RETO MEIER: That is very true.
Keeping your eye on the road is probably wise for an
American in London if you don't want to be
murdered by a black cab.
IAN NI-LEWIS: In any case, let's face it.
When you're in a foreign city, foreign country, there's a lot
to keep in your mind.
And I don't think my mind is big enough to
encompass it all.
RETO MEIER: Well, you want to be able to use your mind for
things like appreciating the sights and sounds of the new
city that you're visiting, not trying to remember exactly
where you need to be and how you're going to get there.
IAN NI-LEWIS: And you certainly do not want to be
unfolding a paper map because that's just like a sign that
says "mug me."
RETO MEIER: Yeah, please steal my stuff.
I have stuff.
I probably have three weeks' worth of money in my pocket.
Please, rob me.
And that is not the message you want to be sending out.
IAN NI-LEWIS: It's funny, because you do get different
reactions in every city.
For instance, in London, I think they just try and sell
you a three-card Monte.
In New York, they kill you.
In Beijing, they want to take you to tea, and
then you pay for it.
And in Shanghai, they want to introduce you to your sister--
their sister.
RETO MEIER: Well, introducing them to my sister would be
IAN NI-LEWIS: Eh, that too.
RETO MEIER: Particularly as I don't have a sister.
Anyway, so today we're going to be looking at four apps
that the viewers have nominated as must-have travel
assistance apps.
So we're going to be looking at social venue discovery
classic Foursquare--
IAN NI-LEWIS: The ultimate in travel management--
RETO MEIER: --and one-click location-sharing widget, Share
Where location widget.
IAN NI-LEWIS: Excellent.
We'll be taking a closer look at each of these apps and
using them as a kicking off point to explore the
technologies and the best practices that you need in
order to create a must-have travel app.
RETO MEIER: All that and more on--
IAN NI-LEWIS: "The App Clinic."
RETO MEIER: So a travel assistant is a pretty broad
category, and that's being reflected in the three apps
that we'll be looking at today.
IAN NI-LEWIS: As part of the Developer Relations team at
Google, travel is a big part of our job-- or it used to be
before we got this boss video studio, the video studio that
puts that thing in back of us.
So this is a category that we are intimately familiar with.
I've been traveling for work for what?
10 years now, and it can be a nightmare.
RETO MEIER: It's also one of the more popular groups of
apps in Google Play.
And the popular apps in this category tend to have very
loyal and passionate uses.
Take, for example, Foursquare.

So let's have a look.
Boy, look at that.
IAN NI-LEWIS: Beautiful.
Now this isn't a travel app per se, but it's definitely
useful as a travel app.
I think you had some insights into that recently.
RETO MEIER: Absolutely.
Let's see.
We want to put that in front.
In fact, yeah.
I remember how this was supposed to work now.
IAN NI-LEWIS: Yes, indeed.
RETO MEIER: Excellent.
So when I was growing up in Australia, Foursquare was the
name of an independent group of supermarkets whose TV ads
implored me to come in for a square deal.
So every time I look at this app, I hear the jingle playing
in my head.
Leaving that aside, I'm a big fan of Foursquare, both for
the service and the features that they offer as well as
their passion for creating a really great user experience,
which is a really important thing.
We can see that over the course of the years, the
Foursquare app has really progressed.
As each version of Android has come out, they've
refreshed the UI.
They've taken advantage of some of our best practices.
So this is an app that I'm a really big fan of.
Now, strictly speaking, you don't need to be traveling for
Foursquare to be useful.
In a lot of ways, it's most useful when you're close to
home, doing your daily routine.
I know a lot of people whose coffee shop loyalty is based
around fierce competition to maintain their status as mayor
of Pete's Coffee Shop on the corner of El Camino and San
Antonio roads.
Now, a big part of Foursquare's success is also
around the social elements of its use, as indicated by this
It's a way to share where you are, let you know where your
friends are hanging out, and all those sorts of things.
But for today, we're going to be focusing on its use while
you're on the road.
And that's where I found it to be the most compelling.
When I'm away from home on a trip, there's really no chance
I'm going to become the mayor of anything except for maybe
the hotel that I'm saying at.
So the app's primary use case switches is from consistent
use of the same venues to discovery and exploration.
IAN NI-LEWIS: Now, this is the part that I really wanted to
hear about because I have avoided Foursquare forever.
First, because it was a hipster app, and second,
because I just couldn't see the use in being a mayor.
I'm the kind of person who's so ultra-competitive that I
avoid competition just so I don't have to lose.
RETO MEIER: That's pretty hard core.
RETO MEIER: I like it.
So when I lived in London, I'd visit the mother ship here at
Google every three months or so.
And as soon as I landed in SFO and checked in to the
terminal, it was game on--
coffee shops, hotels, restaurants, hot dog stands,
pretty much anything.
I used to travel with--
well, I think only once or twice with Nick and Richard.
And those guys would be on the Cal train checking into each
Cal train stop as they went past it.
So as far as competition goes, those guys
are pretty hard core.
So the thrill of rocketing up the leaderboard is a
short-term gain, although what really makes this app a travel
assistance powerhouse is its discoverability features.
So back in--
I can't even remember when it was--
2009, 2010, whenever the Nexus One came out I went on a
10-day European road show where we hit something like
nine cities in 10 days, stayed in each one just long enough
to get a good night's sleep, hand out a couple Nexus Ones,
and grab a meal.
So suddenly--
IAN NI-LEWIS: We don't do that anymore, by the way.
We do not hand out phones anymore.
RETO MEIER: Which is sad.
That was a lot of fun.
It was an easy way to make friends in foreign cities.
It's like being those GIs in World War II with their
chocolate and cigarettes.
RETO MEIER: Exactly.
They loved me.
Everywhere I went, they loved me.
I'm sure it had nothing to do with the giveaways.
So suddenly, having an app that tells you where you can
get a good meal and rewards you with points for doing so
really becomes very appealing.
So I'm going to go into more detail as to how the social
discovery service on Foursquare works a
little later on.
But first, let's take a look at TripIt.
Oh wow.
It's totally covered up.
Oh, right.
We're supposed to do it this way.
RETO MEIER: Yeah, clever, huh?
IAN NI-LEWIS: I love TripIt.
By the way, I should mention that Reto
fracking loves TripIt.
I love it a lot.
IAN NI-LEWIS: But I don't fracking love it, because it's
not 2008 anymore.
IAN NI-LEWIS: When I started going on business trips, I
didn't even have a cell phone, much less a smartphone.
I had to manually create my own version of TripIt with
printouts of bookings, and receipts, and flight
itineraries, and maps to my apartment,
and maps to the train.
And I kept doing this for years.
When I worked for Microsoft, I tried to do it with a Windows
mobile phone.
That didn't work out so well.
Nothing against--
well, OK.
Anyway, later on, I switched to an iPhone, and then when I
came here, I switched to an Android phone.
But honestly, the experience was still unsatisfying.
And the most important problem was that my itineraries would
be in my email.
And I'd have to make sure, A, that it was synced to the
right folder in my email, and B, that it synced and remain
synced and didn't get tossed out by the time I needed it.
So I would frequently find myself in line for, let's say,
a rental car, frantically charging my phone off of my
laptop battery pack, just so I could bring up an email that
told me where and when I was supposed to be
at a certain place.
At this point, though, I don't have to do any of that.
With TripIt, I can just set it up to go through my email and
find all of the travel-related stuff, although it turns out
that the security guys at Google don't like that.
So I had to stop that.
But fortunately, what you can do is set up an email
forwarding rule.
Just take everything that you get from Expedia or Carlson
Wagonlit or the other places that we use to book travel and
just forward it on to TripIt.
And TripIt will actually figure out
what the email means.
It'll pull out all of the details about you hotel and
about your flights.
And then it will store that and send you reminders
whenever you need them.
So by the time I'm sitting in the taxi to go to the airport,
I've got my entire trip right in front of me-- hotels,
weather, cars, directions, even information about what
friends of mine that use TripIt are going to be in the
same place at the same time.
But for me, the most exciting part about TripIt is just the
way it seems to work like magic.
Everything just appears.
It comes up when it should.
It lets me know what time I need to be where.
It figures out where I am and where I need to be.
And it works offline without having to connect up to an
internet, which is really, really important as you're
traveling, because a lot of times, internet access is
either unavailable or incredibly expensive.
It also does some clever things with intents.
And Reto's going to be going over that a little bit later.
But before we do that, it's time to take a quick look at--

RETO MEIER: We're going to take a look
at Share Where widget.
IAN NI-LEWIS: Nice handoff.
That was beautiful.
RETO MEIER: I thought it was really clean.
So I'm going to start to move over to this side, because I
know that we're going to be in frame.
Now, I just want to take a moment to comment on the
Google Play landing page for Share Where location widget.
I really love the icon here.
It's got that distinctive shape that provides really
strong branding and even a hint as to what the app does
without resorting to that square with rounded corners
that you see so much.
They have a great icon, and it doesn't have a background.
Love it.
RETO MEIER: Exactly.
It's also great to see that they've got a feature graphic.
But here I think they could take another pass at this.
The feature graphics are really used in a lot of
different places, including on the phone, not always at this
massive size and resolution that you can see here.
So a graphic like this that includes a lot of text is
going to be pretty illegible when it gets shrunk down into
the smaller sizes.
So I'd suggest it you rely on the description field, which
is just below it, to detail the functionality of the app,
and really make the feature graphic
a little more stylized.
In the same that you've got this great logo icon, make it
more like that so that you're giving an idea of the app
rather than trying to explain everything within a small
feature graphic.
IAN NI-LEWIS: You know what this feature
graphic says to me?
RETO MEIER: What does it say?
IAN NI-LEWIS: It says, they hired a great designer, and he
made a great icon.
And then the CEO put together the feature graphic.
RETO MEIER: We've got everything we need.
We don't need to pay another guy a couple of grand to
create the feature graphic.
IAN NI-LEWIS: Exactly.
I've got Photoshop.
RETO MEIER: Exactly.
So yeah, maybe make it look like a designer did the
feature graphic as well.
I think that's really going to help you out.
It just gives you that much more professional feel.
And now if we actually look at the app itself, in terms of
functionality, this is a much simpler--
maybe you would even say tighter focus than either of
the other apps we're looking at today.
So the idea here is a pretty simple one.
It lets you create a home screen widget or a number of
home screen widgets which will send preset messages to one or
more recipients.
And those messages can go out via SMS, email, or actually
using any app that you like using intents.
It's a simple concept, and one which I actually considered
writing a while back, an app I called one-click SMS, which
had a very similar idea.
So if I just wanted to always tell my wife I'm on my way
home when I was on my way home without having to try and do
all the swipey stuff, just press a button.
And that's exactly what this app does.
So I love the idea of having a one-touch emergency widget on
my home screen to let friends and family know that I've
survived the inevitable San Francisco
earthquake, or that I'm--
I'll try that again.
And that I'm OK.
Or that I'm not OK and having my location embedded within
that message so that they know where in the rubble to dig
through I think would be really useful, as well as
things like I've arrived safely, my flight's just
landed, I'm on my way home, any of those sorts of things.
So being able to do all of that really quickly without
having to scroll through contacts lists or try and type
in a keyboard while I'm walking, half-asleep with jet
lag, is really a plus.
There's some UI work that could be done
to improve the UX.
And I'll go into a little bit more detail on that later.
But they've done some great work in terms of keeping the
functionality simple and using intents to make the app even
powerful without having to do much extra work.
So the best thing that they've done is keep it simple in an
app that does one thing, and it does it very well.
IAN NI-LEWIS: Love it.
So each of these apps offers some valuable features to help
you when you're traveling.
Taking a step back, let's take a look at the key features
we're looking for in a pure Android travel assistance app.

RETO MEIER: OK, so the feature set of each of these apps are
kind of orthogonal.
They're all really useful for travelers.
But there's very little overlap.
So that's handy, because it helps focus on how they're
achieving some of that magical feature set rather than
debating the relative merits of each feature.
RETO MEIER: Exactly.
So each of these apps needs to work when I'm away from home,
because they're travel apps.
That's whole point.
And so that means that I'm likely to be charging my phone
less often.
So battery life and battery consumption
becomes really important.
Data transfer is likely to be slower.
It's probably going to be roaming.
So it's probably going to be expensive.
So back home, I may not care.
Suddenly, I'm in Italy.
I'm paying a lot more for my roaming costs.
So I care about that data transfer.
And frankly, I'm probably going to be turning it on and
off, depending on when I need stuff.
IAN NI-LEWIS: At the same time, a lot of times when
you're traveling, you will get great data every now and then,
like when you've got Wi-Fi.
RETO MEIER: Exactly.
IAN NI-LEWIS: So in Italy, for instance, they have Wi-Fi on
the trains.
If you can hook up to that--
RETO MEIER: No, no-- they have "wiffy" on the trains.
IAN NI-LEWIS: Oh, I'm sorry.
RETO MEIER: In Italy, it's all "wiffy."
(AUSTRALIAN ACCENT) Shrimp on the barbie.
RETO MEIER: Exactly.
IAN NI-LEWIS: Anyway, the point is that you're not just
having nonexistent data or expensive data, you're having
very intermittent data.
So when you do have Wi-Fi, or "wiffy," or "wah-foe," or
whatever it is, you probably want to take the most
advantage of that.
RETO MEIER: Exactly.
And of course, location is key.
It's particularly important because you want to
know where you are.
But this has to balanced around the fact that you don't
want to be draining the battery getting those location
updates all the time.
So it's really a balancing act of wanting to have fresh data,
having constant data, working offline, accurate location,
without draining the battery when, chances are, you're
going to have your phone.
You're going to be using it a lot, but you're only going to
be charging it at the end of every day.
RETO MEIER: So the final result really does emphasize
the efficiency of apps serving this market.
IAN NI-LEWIS: So at last year's I/O, Reto spent a bunch
of time talking about how to ensure your app is always
fresh, which is extremely important for apps.
Is that an Android using deodorant?
RETO MEIER: It is, to maintain freshness.
IAN NI-LEWIS: Silly person.
Androids don't smell.
RETO MEIER: I'm just going to put that in front so everyone
can see the link to the presentation as well.
RETO MEIER: Yeah, so it was all about freshness, not just
about Androids using deodorant, but also--
this is really important for apps like
Foursquare and TripIt.
In these sorts of situations, latency is your enemy,
particularly if you're late for a train, or you're just
tired after a long day of sightseeing, and you just want
to find somewhere to eat.
What you don't want to do is spend a lot of time waiting
for your phone to refresh, to find a connection, to download
You just want to have everything at your fingertips
so that you can glance at it and keep running, basically.

So Let's take a look at Foursquare in
a little more detail.
All right, so let me bring up the giant phone.
IAN NI-LEWIS: Giant fake phone, wooo!
RETO MEIER: Perfect.
So you can see that Foursquare has done a fantastic job on
pretty much everything.
They've created something that's really engaging, really
interesting, really great to look at.
They've got a modern-looking UI.
You can look at it straightaway, and you can see
that it feels like a modern Android phone.
It's all using Holo theming, all of that good stuff.
And what's really useful here is that what Ian is
experimenting with here is the local search feature, which we
were discussing beforehand.
And that's kind of the key here.
So you can see as we go through here,
it's got the map.
It's showing where your friends are.
So if you're traveling in a group, which is something we
used to do a lot of for things like Google Developer Days and
DevFests, you can see where other people that you're
traveling with are at.
Where's everyone going out for a drink after the conference
is finished?
You can track them all down.
You can find places that other people have rated, perhaps on
previous trips.
So it's really a way for you to be able to get some idea of
confidence as to where should I go?
I just want to grab a meal.
I'm in a place that I'm not familiar with.
What's a good place?
Is there anywhere where it's recommending in the nearby
neighborhood that you would agree or disagree with?
IAN NI-LEWIS: Oh, absolutely, Cafe Blaze.
RETO MEIER: Blaze is great.
IAN NI-LEWIS: Excellent cafe.
RETO MEIER: So that's a good choice that they've selected
there, actually.
And you can go through, and this sort of consistent, clean
UI is pervasive throughout the entire app.
It shows you the information that you want--
address, details, who's checked in, photos, all of
that sort of information, and does it in a really clean,
natural way.
Again, what I really like about this is the simplicity.
It keeps everything really simple.
It shows you the information that you need without making
an overly complicated UI.
So it really is something that's easy to use and quite
addictive, I think.
You don't have this mountain of information.
I think that's a challenge for a lot of apps like this is
that there are a lot of venues around.
So there's this tendency to just drop 1,000 pins on the
screen at any given time.
And that's not actually really useful.
What you want to know is, where do I want to go?
And this is somewhere where choice can be a problem.
If I'm standing on Castro Street, I know there's a bunch
of restaurants around.
I want to know which one I should go to based on the
things that I like, that my friends have checked in to,
and those sorts of things.
And that's something which I think they do a
really good job of.
IAN NI-LEWIS: Absolutely.
And just as a side note, you can see that the design here
is really beautiful.
And they've done some of the things that
we've talked about--
putting your media front and center, making sure that you
make good use of space.
Every time something is blank, it's for a reason, but mostly,
just bringing up these beautiful, beautiful pictures.
RETO MEIER: Absolutely.
I mean, that's what this is all about.
I mean, what Foursquare has , which a lot of other apps
which are offering similar services don't, is a huge
community of people which are contributing to the
information here.
So we have lots of pictures contributed by users which you
can trust, because it's not the picture that the owner has
taken on the day where he's cleared out everyone and given
everything a spic-and-span clean.
It's pictures which people have taken while they've been
hanging out there.
So they've done a really good job.
So what I want to talk about a little bit is use this as an
excuse to talk a little bit about how Foursquare have done
the job that they have done.
It's simple enough to get location updates for Android.
But what Foursquare have done a really good job of is making
sure that location updates are as low latency as possible.
So there's a few tricks you can use to maintain your
location freshness without draining the battery
So you can significantly reduce the battery--
sorry, you can significantly reduce the latency for getting
your first location fix by retrieving the last known
location from the location manager each
time the app is resumed.
So if you have a look at this code snippet--
I'll just pop that in front as well so you can perhaps read
that a little bit more easily.
So in this snippet, we're going to iterate through each
location provider on the device, including those that
aren't currently available.
And we're going to seek out the most timely and most
accurate last known location.
So if there's one or more locations available from
within the allowed time frame, then we can return the one
which has the most accurate result.
And if there isn't, then we return
the most recent results.
Though if we're just doing that-- the most recent result,
but it's kind of beyond our latency window--
it's pretty good practice to request a single location
update from every available provider to try and get a more
recent result.
At this point, it doesn't even matter which is the more
accurate result.
You just want to get something that's a little more timely so
that you get something which is in the
vaguely correct location.
And then obviously, you can continue to do your location
updates to try and get something even more useful.
IAN NI-LEWIS: So one thing that I've always wanted to ask
you, Reto, about location, because I know you're kind of
the location guy.
IAN NI-LEWIS: So I remember when I first started
traveling, and this was way back in the Dark Ages when we
didn't have offline maps and we didn't have really good
location providers.
And I found out an app called Maverick that was mostly for
And so they made it work in the wilderness.
IAN NI-LEWIS: And it turned out that for me, anyway,
coming from the US, London was the wilderness.
RETO MEIER: Effectively.
IAN NI-LEWIS: So what it did was it allowed me to download
a bunch of map tiles, which may or may not
actually been legal.
RETO MEIER: It downloaded them regardless.
And then it would find GPS, but it also kept track of my
location through dead reckoning.
Do any of the phones we have now do that automatically?
Is that part of the location provider?
RETO MEIER: Not that I'm aware of, no.
I think the location providers that we're using at the moment
are fairly simplistic in that it's just
GPS or network location--
what do we call it?
NLP, Network Location Provider.
So using cell ID and Wi-Fi rather than momentum and dead
reckoning and those sorts of things, although I think
that's something which the industry is heading towards.
RETO MEIER: So it would be fantastic to see more and more
of those sorts of features become part of the location
providers available.
IAN NI-LEWIS: Wouldn't that be great?
Now, what implications does that have for power, though?
RETO MEIER: Well, I guess that's kind of the question.
And that's one of the important reasons why within
Android, you shouldn't be specifying a particular
location provider.
So at the moment, it's just assumed that GPS is going to
drain your battery, and the network location provider is
going to be relatively low-power.
But these days, it's actually becoming a point where a lot
of the GPS chips are becoming more and more power efficient
and getting built into the hardware itself so that the
actual location drain is significantly lower.
By comparison, the network location providers are using a
lot more features, things like gyroscopes, things like
momentum, all of those things which can comparatively
increase its battery drain.
So what it then means is it's kind of up to the system to
figure out how to balance those things and provide you
with as accurate a result as you can without
draining the battery.
And so for us right now, that means using things like
criteria to specify a location provider based on the power
drain or the accuracy you need rather than saying, hey, I
think that this implies that, so I'm going to use that
particular provider.
IAN NI-LEWIS: So as with many things Android, you really
don't want to go too low-level yourself, because you know
that things are going to get better.
And they're going to get better in a very unpredictable
way, where on some devices they're much better in terms
of power, for instance.
And other devices, they haven't made those changes.
So you're always safest going with the basic system.
And then if you absolutely have to tweak things for
specific classes of devices, maybe you want to do that.
RETO MEIER: Exactly.
A good example is if you're creating a device which lets
you understand how many GPS satellites you've got in
view-- and we looked at a couple of these apps a little
while ago, some of these GPS apps.
Clearly they want the GPS provider, whether it's
accurate or draining the battery or whatever, they
don't really care.
That's not the point.
For everything else, you want to be as
high-level as possible.
And then trust that as the framework team are able to
make improvements to these APIs, that suddenly your app
will get better and more efficient and more accurate
without you actually having to do anything.
Yeah, I think this is a good area.
If you're doing a location app, stay tuned and make sure
you follow not only Android, but the different chipset
vendors and see what kind of changes they're making,
because I know there's a lot of active
research in this area.
RETO MEIER: Absolutely.
I think we've been hearing a lot about things like passive
background location updates.
And you can see apps like Google Now, in fact, being
able to give you these really cool hints about how far
you've walked or suggesting things based on your location
and those sorts of stuff.
So that's kind of cool.
I'm going to talk a little bit about how you can do some of
those things in just a minute.
Let's do that.
RETO MEIER: So generally, I prefer to use pending intents
rather than location listeners when I'm
making my location requests.
And that's because it offers the flexibility of registering
receivers in multiple activities or services or even
directly in a manifest.
In fact, by doing that, you can make your app silently
update your location, just like what we mentioned, and
potentially even update the list of nearby venues.
So an app like Foursquare can passively listen for these
location changes, and then in the background every once in a
while actually pull down nearby locations.
So when you open the app, you're not waiting for that
feeling like it's interminable.
Come on.
Yeah, I was there half an hour ago.
I'm here now.
Just give me something more reasonable.
IAN NI-LEWIS: And let's remember, too, that while
you're doing this, it's very, very important to persist that
Because you're pending intents and any listener of this type
is going to be running in the background, which means that
if the user, let's say, boots up a game or starts to run out
of battery, you're going to be on the list to be killed.
And if you're keeping that information in memory, then
it's just going to go away.
And essentially, you've just wasted a bunch
of power for nothing.
So make absolutely sure that that gets persisted out to
either a content provider or your own file system database
or whatever.
RETO MEIER: Share preferences can be a good
one for that as well.
IAN NI-LEWIS: There you go, exactly.
RETO MEIER: Exactly.
So now requesting locations updates, particularly if
you're using something like GPS, anything which is high
power while your app isn't in the foreground, is
kind of a bad idea.
It's going to drain the battery.
It's going to make people angry.
So what you're going to do instead is use a passive
location provider to piggyback your location updates when
other apps are requesting them.
So again, I'm going to pop the code in front.
So you can see in this code snippet, we request location
updates using a passive provider, this thing in a
broadcast, of pending intent whenever it receives any of
those changes.
And it includes a receiver definition as well down at the
bottom, which is what you put in your manifest, which is
then going to listen for those broadcast intents in order so
that you can then do something with them.
So within our receiver definition, we can choose what
to do when those new locations coming in, which may be store
the location for later use, though often, that's going to
be duplicating the work that you can do just by querying
the get last known location.
Or you can do other things like pre-fetching nearby
locations when certain conditions are met.
So you may want to do that much less frequently than the
updates that you are receiving.
IAN NI-LEWIS: Exactly.
Now, the door has just opened, and Billy is sticking is head
in, so there's something wrong with the show.
What's wrong, Billy?
BILLY: All good.
RETO MEIER: Outstanding.
IAN NI-LEWIS: Beautiful.
RETO MEIER: He's just making sure we're
actually doing work.
We're not just sitting in here drinking.
IAN NI-LEWIS: Exactly.
RETO MEIER: I respect his confidence in us.
IAN NI-LEWIS: Absolutely.
RETO MEIER: Let's move on.
That's an entirely blank screen, very disconcerting.
IAN NI-LEWIS: Mike Winton, don't ever stick
your head in again.
You screwed up everything.
RETO MEIER: So this technique of pre-fetching
can be really powerful.
But it's also inherently risky, as you're introducing
battery and bandwidth cost by downloading data that may
never actually be necessary.
So if you're looking at a travel assistance app, that
can be kind of touch and go.
And that's something which I think Foursquare are
really aware of.
And this is an app, where again, that balance between
being an app that you use a lot at home and an app that's
really useful when you're away becomes an interesting balance
of how do you maintain that freshness without draining the
battery and becoming something which people don't want to
have running when they're overseas.
IAN NI-LEWIS: Well, I think this actually starts to get
into the secret sauce of what makes an app truly amazing and
what it means--
for instance, we've talked about this with the video
apps, where everybody and their brother uses some form
of media player on any platform, Flash player on the
web, for instance.
But where the secret sauce comes in is how do you make
something start really fast and play at a good bandwidth
and switch bandwidth easily.
And in location apps, it's really, how do you know when a
person's going to try and use it?
If you look at what we've done with Google Now, it really
tries to predict based on your past behavior, what you're
going to need at a particular point.
And I think that when you look at Foursquare, you're seeing
some of the smarts and some of those intelligences.
You could probably even go further and make it into
something where you kind of know when the
app's going to be needed.
Because you can see where the user is, and even how fast
they're going and what time of day it is, and predict what
kind of information they're going to need.
RETO MEIER: Absolutely.
So another useful best practice is monitoring the
state of your providers.
So this is kind of important.
When you make a location update request, even when
you're using criteria, the location manager is just going
to choose one of those providers whose updates it's
going to monitor.
So whatever provider happens to be active, whether the user
has GPS ticked or the network location provided ticked, it's
going to try make a determination
based on what's available.
But that can change in real time.
So again, I'm going to stick this code--
yeah, I'm going to stick this in front.
Then I can move around a little bit more.
So this snippet is monitoring two conditions.
It's checking to find out the location provider that we're
using to see if it's being deactivated.
So a user can turn these on and off.
So it's checking to make sure that, OK, we've decided to use
GPS, and the user goes and turns off GPS.
We're going to be able to then find another provider.
And likewise, we're going to check to see if there is
another provider that becomes available.
So maybe we would have used GPS, but it was disabled, and
then it gets turned on.
We want to switch without the user having to exit the app
and come back in or manually do something that way.
It should all happen dynamically.
In either case, we're just going to re-run the process
used to determine which provider that is currently
available is best for our current needs.
And this technique ensures that we can continue to
receive location updates without interruption even if
the user is totaling GPS and network
location provider details.

That's interesting.
I'm sure that there was a picture behind us.
Nonetheless, you can find all of these tips in great detail
in the "Deep Dive into Location" blog post that is
actually on the next page.
IAN NI-LEWIS: I am so sorry.
I fixed almost all of those typography errors.
And this one, I guess I didn't see it.
RETO MEIER: That's OK, but nonetheless, so this is a blog
post I wrote mid-last year, I think.
I even created a sample project that includes the
basic Foursquare functionality--
let's see, I have to do two jumps.
There we go--
for finding nearby venues.
So this is displaying them in a list that allows you to
check in using Google Places API, which you can find here.
Basically, its all of the sorts of things that we were
talking about, all those best practices around using passive
location provider, monitoring location provider changes, and
being able to make sure that you're doing everything in the
background in an intelligent way that hopefully isn't going
to drain your battery.

IAN NI-LEWIS: Now with TripIt, the need for freshness is a
little more different.

The important thing about TripIt is--
and let's bring up the giant fake phone, shall we?
RETO MEIER: Oh, of course.
IAN NI-LEWIS: So with TripIt, you're going to have--
you don't have any actual plans in here, but I notice
that some of your friends do.
RETO MEIER: I was going to go back to a trip that I did.
I think that's probably going to be the easiest.
In fact, let me navigate through that.
Let me go to past trips.
IAN NI-LEWIS: The idea with TripIt is that it's all of
your travel information in one place.
And it's going to show you the most relevant thing first and
try and remove all the irrelevant nonsense.
So it needs to know what time it is, and it needs to know
where you are.
So in this particular case, for instance, knowing that
we're going from Melbourne to Perth is only important if we
are not in Perth.
IAN NI-LEWIS: And you could find that in
two different ways.
You could find that out either through location or by time.
But probably location is a little safer because the
flight may have been delayed.
RETO MEIER: Or I may have missed the flight.
Same thing with the hotel, same thing with everything.
The idea is, once you've got there, you don't need to see
it anymore.
So it doesn't need to be updated perhaps as frequently
as Foursquare does.
But it does need to update at least in time to be able to
show and hide this information.
RETO MEIER: And one of the other things which I think is
really important is it needs to be able to update--
there's sort of this balance.
Because if something does change, if my flight time
changes or my hotel booking changes, I need to see that
updated straightaway.
And that needs to be as low latency as possible.
But the frequency of that is pretty rare.
Once the travel is booked, you're going to be lucky if
there's a change once a day, if that.
You certainly don't want to be checking every five minutes to
see if your flight's delayed.
Instead, what you really want is to know exactly when your
flight's delayed and then never worry
about it again, right?
So if I was doing this with just my airline, my airline is
going to send me an SMS to let me know that
the flight's delayed.
Now I don't want TripIt to send me an SMS because there's
a better way to do that, right?
RETO MEIER: Absolutely.
You would want to--
yeah, exactly.
IAN NI-LEWIS: In fact, I think what we want is to--
hopefully what it does is use GCM.
RETO MEIER: Exactly.
So let's have a look at some of the things which you should
be able to do and do really well.
So knowing where we are is important.
But it's much more important that I get my itinerary
changes as quickly as possible.
And as I mentioned--
let me see if I can drop this behind us.
It's neater.
Ah, that looks a bit weird.
Nonetheless, but this does set up a conflict.
And like we said, it's that idea of we want things to
happen straightaway, but we don't want to have to do these
manual updates.
And so what that does is that we--
IAN NI-LEWIS: I love these graphs that you make.
Because they're complete nonsense, but they do get the
idea across.
RETO MEIER: It goes up and to the right,
up and to the right.
So it's a good graph.
Do the obvious graphs, people.
So again, it's this how do we reduce the latency but not
have that increase in battery life?
And that's genuinely what happens, is that the fresher
the data is, the more battery cost.
And where you actually want to be is somewhere down here,
where you zero latency and maximum battery life.
I think that was my microphone.
You have to dance while I fix this.

IAN NI-LEWIS: Dance, monkey, dance.
The reason I'm dancing instead of sharing technical
information is because I was sick yesterday.
So Reto had to script this whole show himself.
And he's only been a little bit bitter about it.
RETO MEIER: Only a little.
So even if you're not downloading anything every
time you do the poll, you're still potentially
draining the battery.
And that's because of the way that the battery life cycle
model works-- or I should say the cell network life cycle.
Or the cell radio, which is going to say on high power for
around 10 seconds and around low power for up to a minute
every time you ping a server.
Even if the server is going, it's cool,
nothing you need to do.
It's still going to drain the battery.
So if you're doing these updates every minute, then
you're just leaving the cell radio on permanently, which is
going to destroy your battery life.
And so this is compounded by the typical update rates of
apps like TripIt, where if my itinerary changes, I want that
update, like, now, like as soon as it happens.
But it's not going to happen that often.
So how can we optimize those updates and
minimize the latency?
Well, in fact--
and the most important the answer is to use
Google Cloud Messaging.
Like, seriously, use Google Cloud Messaging.
It is going to solve most of these problems.
It's something which TripIt, as far as I
can tell, has done.
Because there is that option to choose manual slash push.
And I had a look in their manifest, and they are using
those things.
But they still have the options for those more
frequent updates.
So I want to hear from the guys at TripIt and find out,
are you using it exclusively?
If not, why not?
And is there a reason for still having that option to do
the manual polling, which is just going
to drain the battery.
IAN NI-LEWIS: Well, there was a time when Google Cloud
Messaging was C2DM, and there was a cap.
You could only send so many messages a day.
Now, that's not in place anymore.
RETO MEIER: That's true.
IAN NI-LEWIS: So it may be that in the past it was
difficult for them to guarantee that they wouldn't
hit their C2DM limit.
RETO MEIER: That could well be the case.
IAN NI-LEWIS: Now, of course, Google Cloud Messaging isn't
doing anything magical.
It's just taking advantage of the fact that a lot of apps
want to do this sort of thing.
So it makes a lot more sense to coalesce that into one ping
that's done intelligently with battery life in mind rather
than having everyone ping their servers at whatever time
they feel like.
RETO MEIER: Exactly.
So it's a way that you can send a message to a particular
device or set of devices used by a particular user,
informing the app running on that device that there's
updates which they need to retrieve.
So the result is near-instant updates with none of the
battery drain.
Or at least your app doesn't get blamed for any of the
battery drain caused by--
which you would normally get with regular poling.
So you get to blame it all on Google, which is much cooler.
If anyone's going to get blamed for battery drain, it
may as well be the system rather than
your app, if you can.
So that's kind of a no-brainer.
Similarly, you'll want to pre-fetch as
much data as possible.
And it's particularly important
for an app like TripIt.
And it's something that they do really well, in that I had
to think about whether or not they did, which made me
realize that they must.
Because otherwise, I would have thrown
it through a window.
RETO MEIER: Offline access here is absolutely vital.
For a lot of travel, particularly when we were
jumping from country to country, you don't have the
opportunity to buy a local SIM just for the data, which you
often do if you're going to be there for a week or so.
If you're going to spend 12 hours, you're just going to
have your core global roaming SIM, and you're going to
disable data a lot.
it often takes a long time once you get out of flight
mode for the data connection to start back up.
And I want to know where to tell the taxi driver to go
without having to wait half an hour for my phone to turn on
or to find Wi-Fi in order to be able to get those updates.
So for apps like Foursquare, though,
pre-fetching can be tricky.
Because there's no knowing which places a user is going
to want to check into, or what areas, what categories they're
going to want to explore.
And you can't pre-fetch everything because that would
just be a huge battery drain and a huge bandwidth drain,
particularly if you're roaming.
So pre-fetching can be kind of a cat and mouse game between
trying to get the right details without wasting too
much bandwidth.
So for apps like TripIt, where the information users want is
relatively small, well-encapsulated around a
trip, and entirely predictable--
you even know when they're going traveling.
So you can wait to do the pre-fetching until the day
before, pull it all down, stick it on the device, and
then it's just there, and it's just working.
So you can go into offline airplane mode, and it all
still works.
So in that instance, I think pre-fetching can be really,
really powerful.
On the same lines, it's really important that you limit
bandwidth as much as possible.
And that means caching results, particularly images,
or anything that's likely to remain static.
Better still, your server should specify the lifetime
and update time stamps of its responses.
And that's what you can see in this piece of code, which I'm
just going to step back from it rather than go full screen.
So in this code snippet, we're just checking the server
response headers to see if we actually need to bother
downloading the rest of response body.
So this is still going to cost you in terms of hitting the
server to see whether there's anything to get.
But at least you're not then downloading extra data that
you already have or that hasn't changed since the last
time you pinged the server.
IAN NI-LEWIS: If it's possible to look ahead, too, and
determine how fresh each piece of data is,
that's really useful.
Because in a lot of apps, I would much rather know that a
piece of data is stale than to not see it all and see a
loading bar or a progress bar instead.
RETO MEIER: Absolutely.
So it's probably also worth mentioning that network state
and the type of network that you're connected to you can
also be really important in determining the frequency of
your data transfers and the aggressiveness of your
So you can actually monitor all of that.
As you can see in this code snippet, where we're checking
the server response headers, that doesn't seem true.
So in this snippet, what we're doing is modifying the size of
the pre-fetching cache depending
on the network speed.
So we're going to increase it when we're on Wi-Fi or on 4G,
or we're going to drop it down when we're on slower networks.
And so again, what we're doing here is trying to find a
better balance between battery drain and latency reduction.

I do go into much more detail on this, on how to create apps
that are more efficient in my I/O talk from earlier this
year, which is the link here.
And there are more details on creating efficient download
patterns in this Android training class as well.
IAN NI-LEWIS: I love that pro tips picture, by the way.
Did JJ Abrams make that for you?
RETO MEIER: He did, yeah.
RETO MEIER: Yeah, yeah.
I know a guy.
So finally, let's take a closer look at Share Where,
which is our third app.
IAN NI-LEWIS: That's Share Aware, of
course, not just Shareware.
It could be Shareware.
RETO MEIER: I think it's just Share Where.
IAN NI-LEWIS: Oh, it is Share Where.
RETO MEIER: Because it's "where" with, like, "where."
Homonyms for the win.
IAN NI-LEWIS: It's Share, Where, not shareware.
RETO MEIER: Not shareware.
Don't share this app.
That would be piracy.
And that would be bad.
IAN NI-LEWIS: Wonderful.
RETO MEIER: Now unlike Fes--
unlike Fairsquare?
Unlike Foursquare and TripIt, Share Where, which is what
I've written there, was self-nominated and isn't yet
an editor's choice on Google Play.
And so we're going to try and be a little bit more--
IAN NI-LEWIS: We can go nuts on this.
RETO MEIER: So we were going to try and be a little more
Let's say constructive.
IAN NI-LEWIS: There you go.
RETO MEIER: Exactly.
Because you know, you put your app up here.
I'm going to assume that you want to have our feedback, or
you wouldn't have asked for it.
But our goal is to still set it up-- to bring it up to a
standard where we can show it off to everyone else in our
pure Android collection.
So that's pretty much the goal for any app that we look here.
We want to bring it up to something which we can show
off to everyone else as a great example of an app
IAN NI-LEWIS: Like you said earlier in your morbid
preamble, this is an app that has great functionality.
RETO MEIER: Absolutely.
IAN NI-LEWIS: It's something that we really want to own,
but maybe not in this exact form.
RETO MEIER: Yeah, exactly.
So we're going to give the developer a chance to share
their experiences in implementing some of our
suggestions and even explaining some of the choices
that they've made in later episodes of "Developers Strike
Back." So stay tuned for that.
But let's have a look at the app.
IAN NI-LEWIS: Let's do.
RETO MEIER: So thinking behind this app is pretty
Let's just bring the giant phone up.
So the idea here is that you're going to create a bunch
of home screen widgets, which all have predefined messages
which you can set to a predefined audience.
So in case of emergency, or I've just come home, I've just
landed, any of those things, you can do it
all ahead of time.
Now, what happens when you load the app up the first time
is you get this massive screen of options.
Now, it is a widget app.
And there is a challenge associated with widget apps in
that you can't just have the main launcher icon launch the
app widget selector.
So you have to find a way to add meaningful value in that
when you first open up the app.
And that's a challenge that we see a lot of widget apps do.
And so a lot of them will do this, go straight into the
configuration screen, which isn't a bad idea.
Except as you can see, it's kind of a
complicated options menu.
There's a huge number of options.
There's some information in there as well
as some actual settings.
There's Help, About, Contact Us, little tech fields which
just explain what the app does.
It becomes a little bit overwhelming for
a first-time user.
IAN NI-LEWIS: You know what it feels like this needs more
than anything is a tutorial.
RETO MEIER: Sure, yeah.
IAN NI-LEWIS: It really does need a little animated
tutorial with little Back and Next
buttons and a Skip button.
IAN NI-LEWIS: You know, little pictures of fingers
and things like that.
Because you need to help people understand.
This is an incredibly useful piece of functionality that a
lot of people are going to want, especially people who
are not particularly computer literate.
So they may or may not know where to
find widgets in Android.
But they certainly know how to--
they'll certainly know what they want the app to do.
RETO MEIER: Absolutely.
IAN NI-LEWIS: And they just need to be told how to do it.
RETO MEIER: That's right.
And so what you can see on the home screen here is the end
result of placing these widgets.
So you can see that we've got a--
we've got different-sized widgets.
So this is a one by one.
And we've got a two by one here as well.
If we click on--
IAN NI-LEWIS: So these aren't resizable widgets?
RETO MEIER: They do have a resizable one as well.
So there's a third option, which I actually thought I'd
dropped on here, but maybe I hadn't, which lets you do a
resizable one.
In fact, we can bring it up on widgets here.
IAN NI-LEWIS: I just smelled another business opportunity.
I could do home screen launcher widgets like this and
go full metro.
RETO MEIER: Absolutely.
So you can see here actually, so this is the four by one,
which is actually resizable.
And you can see, again, this is the configuration screen
for each of the widgets.
Now, straightaway, the UI is a little--
it could use a little work, let's say.
It looks kind of gingerbready.
It's got the black theme, which I think in this
instance, doesn't really work.
Because you've kind of-- it just feels like it's blending
into the background.
Because it is--
and it isn't full screen either.
And I can kind of see why they haven't gone full screen.
Because they want it to look like it's a
configuration dialog.
But I think in this instance, you could actually benefit
from actually launching a full activity, which just, you go
into, you set things up, you hit save, or OK, or whatever,
and your configuration is complete.
IAN NI-LEWIS: And even if you are going to do a full screen
or not full-screen dialog, it should be prettier than this.
You know, part of this is on us, right?
Orange on black was cool for like five months back in 2010.
RETO MEIER: So it's claimed.
IAN NI-LEWIS: It's over.
RETO MEIER: We all like blue now.
RETO MEIER: And you can see, I mean--
IAN NI-LEWIS: We liked blue before, actually, too.
RETO MEIER: That's true.
IAN NI-LEWIS: Nobody likes orange.
RETO MEIER: No one likes orange.
You can see straightaway why this kind of creates issues.
Straightaway, it looks kind of weird.
And then if I click this-- so they've done the right thing
here in that it does launch the contact picker to let you
choose which contact you want to include.
But this is all Holo themed.
IAN NI-LEWIS: I love how Reto has two friends.
RETO MEIER: Well, this is Daniel's phone.
One of Daniel's friends is Daniel.
So you can get this cognitive dissonance of like, well, I'm
definitely not in the same app anymore.
So I don't know what's going on here.
But if you click through, then--
and again, you're bringing up this kind of weird non-Holo,
non-modern UI.
IAN NI-LEWIS: It's a really strange mix of styles.
RETO MEIER: Exactly.
So you really want to try and find a way to use the default
themes so that you're keeping up with whatever style is
prevalent at the time on
whichever device it's installed.
IAN NI-LEWIS: It also feels like this just
could use more graphics.
It could use something that's sort of explanatory, like--
I would even imagine maybe a little view pager or something
that chooses different types of widgets with graphics that
represent each of them.
RETO MEIER: The thing that you're going to want to do.
Maybe even have a bunch of presets.
That could be interesting.
There are certain use cases which you've
probably got in mind.
And whether or not anyone will ever actually use them, it
gives you that, like-- because this is the first screen
you're going to see, basically, when
you open this app.
If you know how widgets work, you're not going to click the
launcher icon.
You're just going to go Add Widget, drop your
two by one on there.
And this is the screen you're going to get.
So this really needs to welcome users, tell them what
the app does, how they're supposed to use it, which
check box they're supposed to have checked by default, and
make it as simple as possible.
IAN NI-LEWIS: I have to reemphasize
what you just said.
Widgets should have presets, and this one, in particular.
I mean, I think you'd cover 99% of all possible cases for
this widget by just providing five or 10 presets.
RETO MEIER: Absolutely.
From here, basically everything works
as you would expect.
If you hit any of these problems, it brings up a
confirmation dialog, which you can skip.
So you can say, you know what?
If I want to send an emergency message, I don't want to have
to do two clicks.
I just want to do one.
IAN NI-LEWIS: Well, and once again, this
is a confusing dialogue.
I've just gone out of something that's beautiful,
which is the Android home screen with the very nice
widget, and now I'm looking at this thing that--
it almost looks like, oops, some pirated app just took
over my screen.
RETO MEIER: Exactly.
And so you want this to be small as well.
We've got a whole bunch of empty space here.
So if you're not going full screen, go as small as you can
and make this-- it is just a confirmation dialog.
I've already selected all this stuff.
So you almost want to be able to have a big Send button and
then maybe an ability to edit as well if you want to.
You want the Send button to be big.
You want the information to be there, but not editable.
Then you want to have a way to go edit it.
Because by bringing up the edit boxes as it is now, A,
you're introducing possible error, where somebody
accidentally hits a key that they didn't intend to.
And B, you're making it seem like I have to edit it, like
that's my job now is to edit this.
But no, I'm just trying to tell Lassie where to dig to
get me out from underneath the rubble.
RETO MEIER: Precisely.
IAN NI-LEWIS: I don't need all this.
RETO MEIER: And again, what I really like here is this
ability to set a timer.
So you can say, set it five minutes into the future.
IAN NI-LEWIS: That would be great if they had used the new
control for that, though.
RETO MEIER: It kind of would.
IAN NI-LEWIS: That's intensely horrible.
And it's a really useful function, so I would actually
want to have that as the main thing.
So the two main things here are I want send it now, send
in a few minutes, and edit also, maybe.
So you almost want to flip the importance of those things, so
that the editing functionality is up on the top right, and
the being able to set a timer is right there.
Also note that there's no way to cancel here as well, which
is interesting.
So I'm done, but I changed my mind.
Do I just want to send it now?
I kind of can't, which is again--
it's just that user flow.
You want to make everything as simple and easy as possible,
and make it impossible for a user to do it wrong.
It's never the right answer to say, oh, you're
using the app wrong.
That should never even be an option.
They should only ever be able to use it right.
One thing that they have done nicely here is that one of the
recipients you can set is, share with other app, which is
what we've got ticked now.
So if we do that, we can see it's set up an ongoing
notification, which is--
time is set to an hour.
I'm going to cancel that one and set off
another one really quickly.
Now, what it's going to do is find my current location.
So now, all that information we have it earlier on about
being able to find a location really quickly
becomes really important.
Because I don't want to sit here waiting for it to find my
GPS signal.
Anything is good enough right now.
So you can by all means check to see whether you can get
something really accurate.
If it doesn't happen within 5 seconds, screw it.
Go with what you had last and send that.
Maybe send a second message.
Maybe make that an option.
So that's going to keep doing its thing, retrieving current
location, for a while.
Interestingly, the app comes up when that happens as well.
So I think you've probably done something weird with your
intent receivers there.
So this shouldn't be getting triggered from
clicking on the widget.
That's not a great user experience.
So you want to make sure that doesn't end up on the activity
stack associated with your activity when you're entering
it from the widget.
So once that's happened, it will actually then let you
send that message via any of the other apps that you've got
on the system, which is a nice way of doing things.
And in fact, I guess, maybe take that as an opportunity to
talk a little bit about exactly what
they're doing there.
Oh, there it is.
It's now got the location.
And we can share it using any of the apps which are capable
of sharing text, which is nice.

As we were saying, perhaps even more so than Foursquare,
low-latency location detection is absolutely
critical for this app.
So I'd be interested to know from the developers what
techniques they're using to get that quick and accurate
location fix, particularly because it's not that quick.
So I'd like to see them doing some work to improve that.
But one of the things they have done well is this sharing
using any app dialog, which I really like, and which is
something that TripIt has done pretty well as well, making
use of intents to add more functionality to their apps
without having to do any extra work.
IAN NI-LEWIS: We're running out of time.
But let's quickly go over what you'd need to do to add the
sort of share intent to your app.
RETO MEIER: Absolutely.
Let's see.
So the details for what I'm describing here are all on
this Android training class on sharing content.
But the basics are actually pretty straightforward.
You can create--
IAN NI-LEWIS: You know, all that typography looked right
on my laptop.
RETO MEIER: That's they all say.
IAN NI-LEWIS: Yes, I know.
RETO MEIER: It was fine on my machine.
So you create a new intent.
You set the action to send and then populate the text extra
with the text you want to transmit.
Then you just start an activity using that intent.
Now, in this example here, I'm actually forcing the activity
chooser to be displayed every time.
That's because users will often choose a default app for
handling a lot of content.
And for an app like this, you actually want to give the user
a chance to say, well, which specific thing do you want?
Because you've actually ticked a box to say, send using
another app.
It kind of makes sense to give them an opportunity to say
which app that they want.
So given that we are just about out of time, I think
happily, we're just onto the prescriptions for each of the
apps that we want to look at.
So let me pop all of this behind us, and we'll bring
each of these up.
So I think this is the--
these are the prescriptions for Foursquare.
RETO MEIER: We didn't have a lot because they've done a
pretty good job.
IAN NI-LEWIS: No, they really have, yeah.
RETO MEIER: I'm pretty impressed.
I mean, the Foursquare team have spent a lot time really
refining and honing their app to try and make
it as good as possible.
They're really passionate about creating a pure Android
experience, something that is really user friendly, that
makes the phone work better, that is always a positive and
not a negative, so hats off to them.
But as with any app that was designed almost exclusively in
the Bay Area, it simply assumes too much about your
network connection.
It needs to be better offline and also better during
changing network conditions.
RETO MEIER: And so for me, I guess the key thing-- and I
have brought this up with the Foursquare team.
And I know they have good reasons for not doing this,
but I'm going to mention it anyway for anyone else who's
doing an app which does something similar, is support
for being able to check in when I'm offline.
So in the Bay Area, going inside ends up having better
network access because everyone has free Wi-Fi.
Not the case in London, and A lot of the good venues are all
three stories underground so that they don't get bombed in
the Second World War, but it also means they have really
bad network coverage and no free Wi-Fi, because nothing is
free in London.
So being able to check in, and then just have all of that get
cached in a queue that then will check me into all these
places once I do get network access would be
a really nice feature.
So I'm going to take this opportunity to ask the
Foursquare guys to do that.
IAN NI-LEWIS: I would love that.
we had a couple more suggestions for them.
Again, this is an app that we really love.
And this is one of those apps which does everything right in
terms of the service that it provides.
Absolutely love it, totally indispensable, would use it
even if it was a terminal prompt.
So that means that a lot of what we're actually saying
here is-- in a way, it's nit picky.
But it's also something which can make the app that much
more appealing, that much more fun to use.
And I think the key thing here is it would be great to see
them take another pass at the design, another pass at the
UI, now that we've had these changes to Holo, so kind of a
UI overhaul would be kind of nice to see.
So we've got all the details there--
things like getting rid of the menu button; not having to
click to load more lists, just having that automatically fill
as we scroll; more use of C2DM; better copying and
pasting; and overall cleaner navigation.
And our third contender, the Share Where location widget.
Again, I think the key here is really a simplified workflow.
Everything should be easier, particularly the first time.
It should just be click, click, that's my wife's
contact, done.
IAN NI-LEWIS: We have talked about this many times, that a
lot of apps are just difficult to get into.
And what you need do is just figure out what the most
common use case is, and Just fill that
stuff in for the user.
RETO MEIER: Exactly.
It seems kind of counterintuitive in a lot of
ways to say, we want you to remove some of the options
from your app.
But it kind of works, particularly for something
like this, which is really focused, is figure out what is
it that people are downloading this app to do.
And you can use analytics for that to find out what are the
most common settings that they're choosing?
What are the most common options that they're clicking?
And make that not only the default, but maybe the only
thing that you can do.
And then worry about expanding those features in a way that's
consistent with the app usage and easier to use
as time goes on.
IAN NI-LEWIS: And definitely ditch the gingerbread.
We're sorry.
We're sorry we ever put it out.
Go to Holo.
RETO MEIER: It happens.
But yeah, make a UI that's consistent with the rest of
the framework, preferably something that's Holo, but
definitely something which doesn't feel like it's been
yanked out of an earlier phone and stuck in the
middle of your app.
And that's, again, particularly important for
anything which is widget-based.
Because users aren't going to be in your app much.
But when they are, you don't want to make it feel jarring.
So that's kind of an important step.
And also the widget, the widget is what you're doing.
So make sure the widgets are really beautiful.
They look kind of jaggy and blurred on the Galaxy Nexus.
So make sure you've got the right assets, nice scalable
assets, so that everything looks really beautiful.
Because if it's going to live on the home screen, it needs
to look nice.
People want their home screens to look nice.
So I think that just about takes us to the end of today's
"App Clinic." So two, both Foursquare and TripIt of the
apps that we looked at, are already featured in Google
Play's Editor's Choice category, which makes them a
good chance to join the pure Android collection,
particularly Foursquare, which, having looked at again
today, just continues to impress.
So wherever possible in the future, we're going to
prioritize reviewing apps by people who
self-nominated them.
So to be sure, please be sure to head over to Trello to
nominate your apps.
And in fact I'll stick that in the background as well.
I don't know if you can read that.
I don't think that I can.
IAN NI-LEWIS: You might want to bring that to the
RETO MEIER: Why not?
Let's bring it to the front.
RETO MEIER: So that's
That's where you going to go to nominate the categories
that you'd like us to review and to nominate your apps in
particular for us to take a look at.
So next week, what are we looking at next week?
IAN NI-LEWIS: Oh, if I knew, I'd be a genius.
What are we looking at next week, Dan?
RETO MEIER: I'm going to read off the screen and say--
DAN: You guys are going instant messenger.
IAN NI-LEWIS: Oh, it's on the screen.
RETO MEIER: I wouldn't have asked you if I hadn't given
you the answer.
IAN NI-LEWIS: Oh, dear.
RETO MEIER: So we're going to be choosing
that later this afternoon.
So if you have an instant messaging app that you would
like us to check out, please make sure that you've got it
nominated there so that we can bring it up and talk
about it next week.
So, instant messaging, should we narrow that down at all?
RETO MEIER: If you like.
IAN NI-LEWIS: So these are apps like
Google Talk, or like--
I don't know.
Is AOL Instant Messenger still a thing?
Or like Skype--
RETO MEIER: You're going to go old school?
So something that's going to allow you to type and/or voice
to each other.
RETO MEIER: Exactly.
IAN NI-LEWIS: I'm particularly interested in looking at what
they call the push-to-talk apps.
RETO MEIER: Absolutely So that'll be interesting one, an
interesting one to try and demo the apps as well.
So we may need to get someone in another
room to help us out.
Oh, that will be interesting.
RETO MEIER: So that's it for today's episode of "The App
Clinic." But be sure to tune in next Tuesday for "Android
Design in Action" with Roman, Nick, and Adam, live from our
New York studios.
Now, before we sign off, I do want to ask our producer Dan
if we have any questions which we should answer in the
negative 13 seconds that we have?
DAN: I didn't see anything that is worth your time.
We just have the normal quality YouTube
comments going on.
IAN NI-LEWIS: Awesome.
DAN: Maybe better luck next week.
IAN NI-LEWIS: Keep it up, haters.
RETO MEIER: So yeah, we would love to answer any questions
you guys have during the show about the apps or about any of
the technical content, or indeed, just the structure of
the show, given that we're trying things a little bit
So do be sure to send your comments through on Google+,
in particular.
If you happen to be looking at this later on, remember, we've
got comments open on Google+ that you can take a look at.
And all you need do is mention one of our names, and we'll
see it and look at it.
RETO MEIER: Absolutely.
So we'll be back again next week at the same time.
And in the meantime, we're going to be taking a look at
some of our past "App Clinic" patients to see if any of them
have attained the status of pure Android.
So if you have had your app reviewed and you've made some
changes and you'd love for us to take a look at those
improvements, do let us know.
My name is Reto Meier.
IAN NI-LEWIS: I'm Ian Ni-Lewis.
RETO MEIER: And thank you for watching.