The App Clinic: Podcast Creators

The App Clinic: Podcast Creators


[MUSIC PLAYING] RETO MEIER: Today, we’re looking
at podcast creation apps Audioboo and
Spreaker Radio. IAN NI-LEWIS: And then we’ll dig
just a little bit deeper to learn some of the tricks for recording audio on Android. RETO MEIER: All that in a tight
30 minutes, today on “The App Clinic.” So what is a podcast
creation app? IAN NI-LEWIS: Yeah. I was wondering that myself,
because I know about podcast apps. And when I first saw that this
is what we were doing, I thought, oh, let me bring out
BeyondPod, and DoggCatcher, and all my favorites. RETO MEIER: It’s a
popular category. IAN NI-LEWIS: But this
is different. These apps often will let
you listen to a podcast. But they’re really geared
towards the creator of a podcast. RETO MEIER: Absolutely. So it’s an interesting idea. It’s this notion that
you have a phone. It has a microphone. A lot of times when you want to
be creating cool content to share with people, you’re going
to be out and about. Why not do that on your phone? IAN NI-LEWIS: Sure. RETO MEIER: So there’s actually
not a huge number of podcast creation apps out there,
or at least not that I could find. So we’re going to have a look
at a couple today which have been around for little while and
look at what they’ve done, what they’ve done right, what
they could have done better. And then dig a little bit deeper
and maybe share some of that knowledge as to how you can
create an app which does something similar, particularly
because it seems like it may be an under-served
market. So let’s have a look at the key
features for podcasting. So the essential things which
you’re going to need– record audio. IAN NI-LEWIS: Sure. RETO MEIER: That seems like a
fairly straightforward one. IAN NI-LEWIS: But not
just record audio. And this is really important,
because the way that these apps differ from a normal
recording app is that they need to record a lot of audio. They need to stay recording
for a very long period of time. RETO MEIER: Absolutely. And of course. you need
to be able to do that audio playback. And not just for the podcast
which you create but also for other podcasts from the
community which you’re generally belonging to. IAN NI-LEWIS: I wouldn’t say
that’s an absolute necessity. But it seems to be a really
popular feature. RETO MEIER: Yeah. I think it helps you become a
better part of that community if you understand some of the
things which other people are doing, help be inspired. IAN NI-LEWIS: Absolutely. I wouldn’t mind seeing a little
bit on playback in terms of effects and being
able to jump to different places in the podcast, being
able to mark times. There’s a big wish list
that I would have for one of these apps. RETO MEIER: And that’s some of
this stuff, which we’ve got covered here in Podcasting++. So it’s signing in with Google+,
because we’re from Google, and we like that. I use Google+ a lot, so that
would be kind of handy for me. IAN NI-LEWIS: And of course,
you can insert the social network of your choice here, as
long as it’s supported on the vast majority of
all Android phones. RETO MEIER: Precisely. IAN NI-LEWIS: Which Google+ is
because of the way we do login on Android. RETO MEIER: It would also
be interesting– the whole point of doing
podcasts on your phone, which is arguably not the best
platform for a recording audio, is that you can do it
while you’re on the go. So having some more integration
with geolocation, mapping, so that you can see
where these broadcasts are coming from, I think would
be really nice. IAN NI-LEWIS: Absolutely RETO MEIER: And finally– exactly what Ian was referring
to– some more device editing. So being able to trim the
beginning and endings off your podcast, being able to do some
audio manipulation, I think, would be a real win. IAN NI-LEWIS: Now, one
thing that a lot of people miss on this– now, I’ve worked in the
professional audio recording space for video games
for a long time. And one of the most important
features that consumer apps don’t have that pro apps
generally do is what we call punch-in punch-out. And the idea that you could just
hit a button and say, I’m recording now, and then hit
another button and either say, I’m not recording but
I’m going to again. Or what’s even more important
is to be able to press a button and say, I want to
remember this place. So either that’s someplace
where I messed up, and I wanted to edit that out. Or it’s something that I did
really well, and I want to be able to emphasize that. Or I want to be able to
put a bookmark there. That sort of functionality would
be really, really cool to see in these apps. And it wouldn’t be all that
difficult to deliver in a mobile form factor. RETO MEIER: Awesome. So we’re going to take a closer
look at two apps today, the beta version of Audioboo2,
sequel to Audioboo, and Spreaker Radio. IAN NI-LEWIS: Now, that’s
not Speaker Radio. RETO MEIER: No, but Spreaker. IAN NI-LEWIS: It’s
Spreaker Radio. RETO MEIER: That’s right. IAN NI-LEWIS: Exactly. Because Spreaker is a completely
different word and is not Pennsylvania Dutch,
as I had assumed. RETO MEIER: Indeed not. In fact, you probably just want
to look that up on your internets to find out the
exact definition. IAN NI-LEWIS: Yes. Because we can’t say it here. It’s unprintable. RETO MEIER: It’s just– yeah. We can’t do it. So Audioboo is an app that I
remember from my days as a developer advocate
back in London. And I got to know the team
behind Audioboo v1 pretty well as they were navigating the
waters of audio recording and processing on Android back
in the v1.1, which is a long way back now. So I know that they’re going to
be pretty happy to get some candid feedback on this
beta of version 2. Now, keep in mind that
this is a beta. So there’s likely be plenty
of rough edges, and [? spoilers, ?] there are. But generally speaking, that’s
the best time to give that sort of feedback. And I’m sure that they would
appreciate that feedback directly, if any of you guys
choose to check it out. Now first off, I’m not a
huge fan of the icon or the feature page. I know there’s a pretty good
chance that they’ve left it this way on purpose, because
they’re in beta, and they’re not ready to reveal their
new, modern branding. But even still, users are going
to form an early opinion of that app from the first time
that they use it, even if it is in beta. So it’s worth getting this
right straight away. IAN NI-LEWIS: Now, I do like
their featured graphic. I think that it’s actually kind
of nice and clean, and it pretty much says exactly
what the app is about. The problem is that they’ve
reused that feature graphic for the icon, which is
completely inappropriate. It’s tough, too, because they’re
using that generic microphone symbol, which says
“recording,” but it doesn’t say “Audioboo recording.” RETO MEIER: Exactly. And it’s interesting, because
they’ve used a lot of their own nomenclature and branding
throughout the app. The things that you record
aren’t podcasts, they aren’t anything else. They are “boos.” It
just makes sense. But if you’re going to have
that kind of branding, you want to make that rich right
from the outset to try and provide that consistency. Now personally, I would
love to see a richer feature graphic. Ian disagrees. But the icon, I think, we
can both agree could do with some work. IAN NI-LEWIS: It’d be great
to see an icon that’s a distinctive silhouette, maybe
building on the microphone icon but making it their own. RETO MEIER: Exactly. So let’s dive in and take a
bit of a look at the app. Now, the first time that you
start the app, you’re presented with a walkthrough. And you can see the first page
of the walkthrough here. And there’s a few issues
related to that. You can see straightaway that
the design language here is decidedly non-Android. We’ve got buttons which don’t
look like Android buttons. And in fact, we’ve got three
very similar but subtly different button styles all
on this front page. And to make things a little more
confusing, as a user, I’m presented with four options when
I open this app for the first time. Now, I’m not actually
in the app, but I already have to choose. Do I want to record a boo? I don’t know what that is yet,
but that’s an option. Do I want to listen to
the welcome message? Do I swipe to be able to read
through the walkthrough? Or skip the walkthrough? Now, that’s a lot of decisions
to have to make when I launch the app, before I’m actually
doing anything. So I’d recommend reducing
this to as close to zero as possible. So in my mind, the best apps
present you with a UI that lets you get started
straightaway. No interstitials, no
walkthroughs, no explanations. Walkthroughs are particularly
problematic, because it really suggests that your app needs
careful instructions to be able to understand how
it needs to be used. And I’m not sure that that’s the
case for an app like this. You would think if someone’s
gone to the trouble of downloading it, they get
the general idea. This is an app to be able
to record audio and share it online. And I’d like to think that you
could get to that process much more quickly than having to go
through all of these steps and walkthroughs beforehand. So here, I’ve skipped through
the walkthrough, and it’s asking me to sign in. And once again, I’ve
got 1,000 options. Do I log in? Do I register? Have I forgotten my password? Maybe I want to sign in with
Twitter, or maybe I want to browse without signing in. Now, all of these things
are on the page. Most of them have slightly
different UI elements. There’s four buttons,
but they’re in two different colors. Does that mean anything? Do the different colored buttons
represent a different kind of choice? If I’ve forgotten my password,
that’s a link. So there’s all of these
different ways of being able to proceed. And it can be quite confronting
to a new user to try and figure out. I just want to get to the app. And I should point out that both
the first screen and this screen both have a button that
will just let you skip forward to the actual app itself. But it’s buried amongst
all this other stuff. So again, here, I’d really
suggest that you try and cut that down as much as possible. Make it as simple as you can. Make that login process
as simple as you can. And possibly put that further
into your app, once you get to the point where they need to be
logged in to do something. Now again, in terms of UI,
you’ve some very non-standard Android controls on screen. And I noticed that even the
text views are custom. They don’t actually display
the cursor position when I have them selected. And it’s worth noting that the
buttons themselves don’t respond visibly to
being touched. So again, you press the button,
nothing happens until you let go, and you’re taken
to the next screen. And again, I’d like to see
Google+ sign in available as an option here. Now, once I get through all of
this, I get to an empty screen with a loading dialogue. I’ve already spent several
minutes clicking through logins, looking through
walkthroughs. So it seems that by
this point, I’ve spent a lot of time. It should have been enough time
to pre-fetch enough data so that these first screens can
pop up instantly and have the data that you want. So you want to take advantage
of that startup time, particularly if you have logins,
walkthroughs, or anything like that, to
pre-populate the data– at least the first page and
anything within a click of that first landing page. You can also probably notice
that, along the bottom here, there’s some buttons, and
they’re totally blank. I’m guessing that’s related to
some sort of custom control that they’ve built and it’s
not rendering properly. Again, one of the risks of
building things from scratch when there’s perfectly good
built-in framework components which do that same
thing for you. Along the top, they have tabs
that aren’t really tabs. I can’t swipe between them. There’s a bright pink Record
tab that’s in the middle, which makes me think that’s
what’s selected. It isn’t. It’s also not a tab. It’s a shortcut to the
Record screen. And I can see what they’re
doing here. It’s the most important
thing, so you make that big and bright. But again, it’s not obvious
what’s happening here. It’s not a button, it’s a tab. It looks like the tab is
selected, and so I’m confused. How do I get it to
record something? So again, you want to think
about that design language. Think about what a new user
is going to think. And an easy way to do this is
to give this app to someone who you’ve told nothing about
what it is, preferably someone who’s not very good with
computers or smartphones. And see how they react. Do they click the right
button to begin with? And use analytics to
see how this goes. Particularly in something like
beta, I’m hoping that the team here is using analytics to
find out which of their features are discoverable. Now, on the plus side, we’ve got
the ability to listen to community recordings, track
our own recordings. But again, you need to wait
for each of these lists to load before they
get displayed. So as I click through these
tabs, I get that same loading page. And every time I click, I get
the same loading page again. So you want to do some caching,
you want to do some pre-fetching to make sure that
all of this stuff happens in the background, without you
having to sit there and wait for it. Now, if we move on to the meat
of the app, the recording screen- or, as Ian christened
it earlier today, the “confidence screen”– same issues here. Nonstandard buttons, a
multitude of options. There’s three buttons
to press here. Really, I just want to record
and then finish recording. As it happens, only the Pause
and Record button is really relevant until I’m done,
unless you’re providing functionality like punch-in
punch-out that Ian was describing earlier. So it makes sense not to confuse
the UI with options that aren’t really relevant
or available to me yet. Now, I like the countdown clock combined with the counter. And the dot matrix view
to see the audio levels looks quite nice. But I’d love to see them
go a couple of steps further with this. Firstly, change the
bounce animation. So right now, as you’re
recording audio, it’s basically a triangle that’s
going to go up or down, depending on the audio level. I’d like to see something like
a spectral analyzer, so I can see which frequencies
are being recorded. It’s non-trivial to implement,
but it looks really awesome. So it’s something which may
be worth looking at. IAN NI-LEWIS: Well, do you want
to have a spectrum with more elements than 16? RETO MEIER: Not necessarily. IAN NI-LEWIS: I think you could
do a 16-element with– RETO MEIER: I think a 16-element
would be fine. You just want something
which gives you more than just volume. IAN NI-LEWIS: I actually
think that it might be a spectral analyzer. I was trying some different
frequencies. It’s hard to do with
your voice. But I noticed a few
differences. I think they actually might be
doing a Fourier transform on that RETO MEIER: That would
be kind of cool. IAN NI-LEWIS: It would be. RETO MEIER: We’ll have to
investigate further. Or perhaps the Audioboo guys can
reach out and let us know if I’m just being an idiot. IAN NI-LEWIS: Yeah, we’ll
talk about that later. RETO MEIER: It’s generally
the case. IAN NI-LEWIS: The idiot part. RETO MEIER: Yeah, clearly. Ian also pointed out how nice
it would be to see the audio levels over time, so I can
confirm the things that I’ve been recording have actually
been recording. So basically just that volume,
but over a period of time, to see how it all goes. And again, if you take it to
that next step and provide some ability to do edits, to do
punch-in punch-outs, it’s a really easy way for you to be
able to see where those different segments of
your audio are. Now, once I’m done, I have this
awesome button at the top, which is a Save/Delete
button, which is quite a dichotomy. And I’d really strongly
suggest that you separate these. It’s very unlikely that
anyone’s going to be particularly comfortable hitting
a button that says either Save or Delete. It’s a 50/50 chance! We’ll see what happens! That said, the recording
itself seemed to work pretty well. I didn’t notice any issues. I think Ian, you said that there
were some cut-outs when you were doing some testing? IAN NI-LEWIS: Well, I did get
a drop-out on playback. But I think that’s actually a
reported bug for JB 4.2.2, that there are some cases where
audio track or OpenSL can drop the last few
milliseconds of a track. RETO MEIER: That’s
interesting. So I didn’t notice
any problems. It could very well
be our fault. But in any case, that all seemed
to work pretty well. And I’d really love to see, like
I said, that ability to trim the start and ends of my
boos before I upload them and publish them online. So overall, it’s an
interesting app. It shows a lot of promise. But it also needs a lot of
work, particularly on the UI/UX to make it more
responsive, simpler, easier to get started. And overall, it really just
needs to take a close look at the Android design guidelines
and see if you can make it a little bit more consistent with
that way of interfacing with users. IAN NI-LEWIS: Spreaker fails
test one with a complete lack of a feature graphic. The icon is pretty
good, though. RETO MEIER: The icon
is pretty good. IAN NI-LEWIS: Love to see them
go the whole way, drop the box, and use the distinctive
silhouette exclusively. Because that is a very
distinctive silhouette. RETO MEIER: It’s kind
of nice, right? You can see it here. You’ve got that black silhouette
with the Sprooker– Speaker– there’s too many words which
sound like that but aren’t– logo built into the headphones, which is quite neat. So they’ve got a couple
of really neat branding elements here. And I’d love to see them
focus on that and it exclude the rest. IAN NI-LEWIS: Now of course,
we’ve done a great favor to the Spreaker team and previewed
the silhouette-only version of their icon
automatically on the bottom of our page here. Not right now, but– RETO MEIER: True. Yes, You will see it shortly. IAN NI-LEWIS: They did happen
to use the same color of chroma key green that we use
for the transparency here. RETO MEIER: So let’s take a look
at how that would look. IAN NI-LEWIS: There we go. RETO MEIER: So that’s exactly
the way which we think it should look, is just
like this. IAN NI-LEWIS: Right. With Reto’s hand behind it. RETO MEIER: Well, exactly. That can help to really
reinforce the branding, my hand. So we have a welcome screen
here, which tells us everything we probably already
knew before we downloaded it from Google Play. And unfortunately, there is
a Menu button of shame. The menu button does absolutely
nothing, which is unfortunate. Looking at the app once I’d
spent a bit of time in there, I realized this is probably an
app that hasn’t really been touched since probably
somewhere around the Gingerbread days. So I’m not going to dwell on
that too much, particularly as the developers here didn’t
self-nominate. They didn’t ask for
candid feedback. So I’m not going to
be too harsh. But it’s definitely an example
of where you’ve got an app which was launched much earlier
on in the life cycle. You don’t want to
abandon that. You don’t want to launch
and forget. Mobile phones, Android in
particular, the UX has really taken a step forward over
the last few releases. So it’s a good opportunity to
go back, update those apps. And we’re seeing several apps
that we’ve looked out on The App Clinic– Grocery iQ, I think,
being the most notable that I can recall– which have done a complete Holo-based UX redesign recently. And I think it really shows
how effective that can be. So once we get past that,
we can’t continue without signing in. Which is unfortunate, as it’s
going to alienate a lot of users who aren’t willing to
create yet another account or log in with the particular
social media option that you have available. So at the very least, again, I
would like to see Google+. Basically, just having
one social media network, it is a choice. But in this instance, it means
that I need to choose to either create a new account or
log in with a particular social media. As it happens, I really
struggled to actually get into the app. And most users won’t really have
the patience for that. It took a whole bunch of having
to jump through hoops, and then create the accounts,
and then it sent me an email, and then I had to have responded
to the email before I could actually log
in on the phone. It was kind of painful. So you want to avoid that kind
of pain wherever possible. Once we get into the app itself,
again, most of the features are very similar
to Audioboo. UX/UI issues, which are from an
older version of Android. Not going to dwell on that. The confidence recording screen
here, you can see that their UI is fairly non-standard
in a way that isn’t a bad thing. But for UI features like
buttons and drop-downs, there’s really a lot to gain by
sticking to the standard, rather than going your own way
or trying to implement your own versions of that. The recording experience is
actually pretty similar to what we saw in Audioboo. So I’d really offer a lot
of the same feedback. And again, here, we would like
to see more than just the amplification but something
which gives you an idea of how the recording is going over
time, the frequencies being recorded now. So that’s particularly important
for Spreaker, whose model is live broadcasts
rather than pre-recorded podcasts. The idea here is that it’s more
like a live radio station that you fire up, you do your
thing, and people tune in live, rather than downloading
podcasts to listen to. So I’m going to keep
that pretty short. I think we can probably turn
to Ian, our resident audio expert, who has some tips for
how you can ensure that your audio recording works and is
of the kind of quality that you really need it
to be on Android. IAN NI-LEWIS: You bet. Thanks, Reto. Let’s see if we can
get this working. Oh, look at me. Awesome. So on the surface, recording
on Android is dead simple. It hasn’t changed for years. You create an audio record
object, and then you call Read in a loop. And Read returns a buffer
full of audio samples. And you take those samples and
write them to some kind of persistent storage. At the same time, you probably
want to use those samples or some boiled-down version of them
to create that confidence UI, which is either the bouncing
LED type of thing, or maybe a little waveform,
or a spectral analyzer. Just something to let your user
know that something’s actually happening. But ti turns out that we have
the same problem that we have in audio in general when
we’re doing recording. And that’s the problem
of latency. Usually, when we talk about
latency in audio, we’re talking about the latency
in the audio drivers and hardware, which is usually
measured in a relatively small number of milliseconds. Now, for some devices, that
might be hundreds of milliseconds. But still, we’re talking about
a fraction of a second. But for recording, we actually
have a different problem, especially for the type of
recording that we’re doing, where the audio is not
going to fit into the RAM of the device. It’s not going to fit into the
heap allocated to your application. It’s going to need to go into
persistent storage or onto the network, somewhere other than
where it is right now. So in that case, we’re talking
about a latency number that can get very, very large, up
into the multiple seconds. So I actually sat down with
Jean-Michel Trivi and Glenn Kasten, two of our audio
engineers, this morning. And we had a yap about the old
times and talked about recording on Android. And this is one of the things
that I hadn’t realized. But Glenn said on the Nexus 7,
he could actually measure three to four seconds of latency
going from memory to persistent storage, in that
case, to flash memory. So we’re actually talking
about a very long period of time. Now, once things get started,
the flash memory is capable of writing just as fast as the
microphone is producing data– much faster, actually. But it takes a while
to get started. So of course, we need to fix
this with our old friend, threads and extra buffers. That’s the way we fix every
audio problem, is with a little bit of extra buffering. So here’s how we do it. We want to have one
thread that is dedicated to recording. The way that the audio record
API is set up, you really don’t have a choice on this,
because audio record, first, is a blocking API. When you call Read, it
will block until the data has been read. Second, it’s not a guaranteed
delivery API. In other words, if you don’t
call Read often enough, you simply will miss data. The data will just go off to
some other app or into the bit bucket, and you won’t
read it at all. So you get a dropout. So you want one thread that’s
doing nothing but call Read over and over and over again. That’s the Record thread
in this diagram. So every time it gets a buffer,
it does two things. First, it’s going to pass it off
to a write buffer, which is going to be a very, very long
buffer that’s being read by another thread, the
storage thread. And the second thing it’s
going to do is pass some version of that audio data off
to the UI thread so that it can create the confidence UI. And usually, this is going to
either be RMS level, or it’s going to be a spectral analysis,
or just something to let us know that things
are still happening. Of course, if the latency on the
SD card is very high, then you’re going to end up with an
awful lot of data stacked up in the write buffer. And software being what it is,
sooner or later, you’re going to get into a situation where
it won’t all fit. Now, if you’re running into
this condition a lot, that means you probably made your
write buffer too small. You’re going to need
to enlarge it. But even with the biggest write
buffer in the world, someone, somewhere, on some
device is going to end up running out of space. Maybe they’re running too much
in the background, or maybe the SD card is filling up. Or maybe there’s an abundance
of cosmic rays in their neck of the woods, and all their
devices are beginning to inexplicably fail. Whatever the condition, you need
to be prepared for it. So how do you do that? Well, when you run out of record
thread space– so in other words, when the Record
thread can’t write to the write buffer anymore, that’s
when you need to signal a dropout to the UI thread. So there’s two lessons here. First is that you need to make
sure that whatever you’re using for a write buffer, it
has the ability to handle a single-writer, single-reader,
multi-threaded case. And it has some size that it can
signal back when it’s full to the write thread so
that you can detect these dropout cases. And then you just want to turn
your UI red, or whatever it is that’s going to let your
user know that some audio is going to miss. That way, they can either stop
the recording and try again or whatever action they
want to take. Now, there’s a number of other
things that you can do to make this sort of app better. And we don’t have time to go
over all of them in depth. But let’s talk about
just a couple. For instance, Reto already
mentioned that running a simple Fourier transform, even
just an 8- or 16-element transform, over your audio will
let you do a little bit of spectral analysis. Doing a larger Fourier
transform, with maybe 256 elements, would let you do
things like show whether there is excessive noise in the input
signal, which could be really useful in a mobile app. Or you might want to use the new
MediaCodec API that came out in Jelly Bean. And you could use that to access
the FLAC encoder or the MP3 encoder so that
what you write to persistent storage is smaller. You don’t have to do as much
processing, because that’s possibly a hardware-accelerated
stage. I don’t actually think
that for audio it is. But it could be. In any case, we’re talking about
things that take a lot of processing power, not just
spectrum analysis but perhaps multiband compression or
automatic gain control. All of these things will make
your audio recording sound significantly more
professional. We don’t have any samples
ourselves in the Android group that would show you how to
take advantage of the processing power on a mobile
device for this type of audio. But before the show, I Googled
“renderscript” and “audio,” and came up with a bunch of
GitHub projects from people who have done this exact thing,
using renderscript. Now, renderscript has the
benefit that it works on pretty much all Android
platforms now. It doesn’t require you to know
anything about the underlying architecture. And it’s really, super fast for
doing the sorts of things that you’re likely to do
when you’re trying to process a podcast. So I’d encourage you to take
a look into that if you’re looking for professional
audio features. With that, back to Reto. RETO MEIER: So our next step
is to take a closer look at today’s apps and see
how close they are to being pure Android. Now, I think given the place
that each of them are, particularly Audioboo being in
beta and Spreaker being, I think, an app which hasn’t
been updated particularly recently in terms of UI and UX,
that they’re probably a little distance from that. But we would suggest to those
developers to start by going through each of these
checklists, particularly while you’re still in beta, to find
out how much closer you can get to being pure Android,
and really make that launch a success. Until then, you can find our
pure Android collection at bit.ly/PureAndroid. And you can nominate your app
for consideration by adding it to our Trello page,
by searching for App Clinic Trello. And you’ll see there exactly
what topics we have planned for the next few weeks. In fact, tomorrow– not tomorrow, next week, we are
going to be experimenting with the app clinic by holding
a special session for the members of the Prague Google
Developers group. So we’re going to be recording
that early next week and putting it online for you
guys to check out some time after that. This is a new initiative that
we’re going to try out to try and get some of these
GDGs more involved with the process here. So it you are part of a GDG or
run a GDG, let us know, and we’ll see if we can include
you in the schedule. IAN NI-LEWIS: All right. We’ll be back later in
the week to look at– what is later in the week? RETO MEIER: Weather. I think we’re looking at
weather apps next week. IAN NI-LEWIS: We’re looking
at weather apps. And the Android Design
in Action is also? RETO MEIER: I’m not sure. I think so. I think the Design in Action
team should also be looking at weather. I’m not sure if Roman’s going to
be available, so it may be Nick and Adam taking a
look at weather apps. But we’ll check in with
them and find out. IAN NI-LEWIS: Sounds good. RETO MEIER: So until next
week, I’m Reto Meier. IAN NI-LEWIS: And I’m
Ian Ni-Lewis. RETO MEIER: And this has
been The App Clinic. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *