DevBytes: Any Requests?

"What is it you wanna hear?"

- Lynyrd Skynyrd

In case you don't follow me on Google+, or you missed my recent G+ post about DevBytes requests, I'll reproduce it here. Comments are welcome either on the original G+ post or here; I'll see them in both places. Writing your suggestion on a nearby tree, probably not as helpful. Scribbling it on a piece of paper and putting it in a bottle that you toss in the ocean, not so much. Shouting it out to the wind to carry it to my ears, not really. Just stick to comments on these posts. Boring, but slightly more effective...

Hey #android developers:

Laundry list time. Now that I've started doing these DevBytes videos (something I've been planning on for a while now), it would be great to hear from you about tutorial topics that you would find helpful. I have a few more episodes in the can that will roll out over the next few weeks, but eventually I'll write some more apps and record shows around them, so I'm up for ideas on what you'd like to see.

Terribly important caveats:
- In general, I code/write/present around the topics of graphics and animation. These are the technology areas, and Android areas, that I'm most familiar with, and where I could be most helpful, because I might have some understanding of the issues to begin with. Having me do a tutorial on, say, location providers, or fragments, or activity lifecycle would take me more time to create something useful and probably would not result in something as useful to you.
- The whole idea of DevBytes (and most of the demos I ever write for presentations) is to be small and focused. If I have to explain, and you have to understand, unrelated bits about the application's architecture in order to understand the point I'm trying to make, I've lost. So rather than giving a tutorial on, say, the optimal architecture design for event processing in a photo viewing application, I'd rather write an app that shows how to display the photos quickly, or load them optimally, or filter them cool-ly. I've sat through presentations with huge impressive applications before, and walked away knowing nothing more than when I got there; I'd rather focus on the little things and build them up one by opne. Maybe it's just me, but that's the way I prefer to do these things.
- I'm not going to get to everything on this, or any, list. So I'm not necessarily going to get to your pet item (sorry!). The items I get to will be because of a combination of how I could contribute something useful, how I could incorporate it into an app and a show, how broadly applicable I thought the problem/solution was, what time of year it is, how warm it is, and whether I completely forgot that you requested it.
- Don't bet on this happening Immediately. It takes me a while to get to these apps, a while to set up a time to shoot the shows, a while to do the minimal post-processing that they take (mostly slapping a banner on each show and supplying a professional actor's voice, of course), and a while for them to roll out into the stream. So these are not short-term "how do you do this, I need it for my homework assignment next week?", but rather medium-term "I'd love to understand this eventually in case I have homework related to this next term" topics.

Enough constraints for you?

So, on with the ideas. Post something you'd like to see an explanation of below. If you like someone else's suggestion, +1 it to give me a [very] rough metric of its popularity (which I will use as a random filter in figuring out what to do in the future).

p.s. Don't worry if you don't have suggestions; I can always come up with some of my own, certainly enough to keep making these shows. I'm more wondering whether there are things that application developers would like to know about that I wouldn't have thought of all on my lonesome.

DevBytes: BitmapAllocation

This example shows how to speed up bitmap loading and reduce garbage collection by reusing existing bitmaps.

Note that the reused bitmap must be mutable and of the same size and configuration as the bitmap you load into it. Not sure if this is clear from the video, although it is documented in the API.

Code: http://developer.android.com/shareables/devbytes/BitmapAllocation.zip

Video: http://www.youtube.com/watch?v=rsQet4nBVi8

DevBytes: BitmapScaling

This example shows how the use of BitmapOptions affects the resulting size of a loaded bitmap. Sub-sampling can speed up load times and reduce the need for large bitmaps in memory if your target bitmap size is much smaller, although it's good to understand that you can't get specific Bitmap sizes, but rather power-of-two reductions in sizes.

Code: http://developer.android.com/shareables/devbytes/BitmapScaling.zip

Video: http://www.youtube.com/watch?v=12cB7gnL6po

DevBytes: Short, Focused Android Tutorials

The Android team has just rolled out the first four shows in a new series called DevBytes, which is intended to be very short, focused tutorials on specific developer topics. A quick explanation, maybe a demo, and a few lines of code to walk through and it's done. Taking a break from work? Want to learn something new? Or just wonder how a specific piece of technology works on the platform? Tune into one of the DevBytes episodes to get a quick deep dive into that exact topic (well, assuming we've done a show on that topic. Maybe we could interest you in one of the shows that we've actually filmed yet instead?)

The first few of these feature ... me! (Surprise, surprise!) I'll be doing many of these tutorials over time, especially in the areas of animation, graphics, and UI development, starting with this first set:


ViewAnimations:
This show covers the basics of creating and running pre-3.0 Animations on View objects.

PropertyAnimations:
This show parallels the ViewAnimations demo, but uses the new Animator classes introduced in Android 3.0.

WindowAnimations:
Ever want to use a custom window animation to transition between sub activities? Watch this show.

CrossFading:
TransitionDrawable can be used for very simple cross-fade effects between two different Drawable objects.

There will be other shows coming online in the future as well; we're just starting with some of the ones that I did. I wouldn't mind if everything were about animation, but that's just me...

There are code links in the video descriptions if you want to see the code I cover in the videos. I'll also be posting individual blogs with the video and code links to make this easier, I just wanted to get this introduction/overview out there to get it rolling.

These are just a start: we have more videos on the way in the coming weeks. So tune in and geek out.

Devoxx 2011 Recordings: Now Free on Parleys.com

All of the recordings of the technical sessions I gave with Romain Guy at Devoxx 2011 are now free on the Parleys.com site. This means that you'll have a chance to watch them all before we go to Antwerp next month and present several more sessions. Which means we'll need another five hours of new material. Dangit.

In the meantime:

Android Awesomeness (Part 1 and Part 2)
This vaguely-titled talk was in two parts. In the first half, Romain and I did a very quick introduction to the Android 4.0 release. The second half was more interactive, as we showed how we use the tools that ship with the SDK to debug performance, memory, and UI issues.
You can also download the slides for this talk here: Part 1 and Part 2.

Graphics Goodies
This session was an updated version of the Android Accelerated Rendering talk we did at Google I/O 2011.
Here are the slides.

Sticky GUIs
This presentation was a collection of techniques and principles for creating GUI applications that will make your users stick around: graphics, performance, animations, GUIs; they're all important.
Here are the slides.

There are many other good (and free!) technical talks from Devoxx 2011, including other Android talks on tools and application development and plenty of other geeky topics as well. Check them out on the Parleys Devoxx  '11 site. (Did I mention they're free?)

And hopefully see some of you in Antwerp in a month. After we've written a ton of new material.

Thanks for the Memories

(This tip and anecdote is specifically about Android, but the same technique applies to every platform I've ever worked on, which at this point is quite a few. In fact, it's a technique that Romain and I have stressed in our book and in most graphics/GUI talks that we've given over the years, such as this one from Devoxx in 2008) .
I was debugging an application recently (names withheld to protect the completely and utterly guilty) and discovered that the source of a serious performance bottleneck was simply the size of the bitmaps involved.

The application's job is to display lots of pictures, so using bitmaps is a given. And the size of the bitmaps being loaded and displayed is signficant, so there were going to be issues around memory and performance anyway. But it was the way in which the application was treating the source and destination sizes that was at the root of the problem.

In particular, the application was loading each image into a bitmap of size X x Y. Meanwhile, they wanted to draw that bitmap into a destination rectangle half that size, .5X x .5Y. This is easy to do; you just call the appropriate Canvas.drawBitmap() method with the relevant source/destination rectangles, or specify a scale on the Canvas object, and we'll take care of the details.

Simple.

But.

Wrong.

That is: Scaling on the fly is easy, and it works. But asking us to do your work for you on every frame in which you draw that bitmap might cost you significantly in performance and memory when there's a very easy way for you to do this once and simplify all future operations with that bitmap.

Here's the right thing to do: pre-scale the bitmap to exactly the size you need. Then when you need to copy it into the destination, you call Canvas.drawBitmap(left, top, Paint) (the version that doesn't take a dest rectangle) and then all that Android needs to do is copy the bitmap. Much simpler. And what's more: it requires potentially far less memory than downscaling to a smaller size.

This is probably (hopefully? please?) obvious when you're running in a software-rendering situation (e.g., all releases prior to 3.0, or any app targeting pre-4.0 releases and not specifying hardwareAccelerated="true" in the manifest); having the framework scale the image every time it's drawn means going through a much slower path than a simple 1-to-1 copy entails.

But what about on GPUs, with our wonderful new hardware-accelerated world of Android apps as of version 3.0+? Aren't GPUs supposed to be faster at stuff like this? What are we paying them for, anyway?

Yes.

But.

Here's the problem: the actual scaling operation is quite cheap on a GPU, even negligible. But that's not all that you should be concerned about as a mobile developer. Mobile developers should always worry about memory. You should profile your application. You should think about memory consumption at night when you can't sleep. You should bring it up on first dates*, and fester on it while on vacation.

If you're displaying several images per frame, you want to be very aware of how much memory those bitmaps are soaking up. This is true for the bitmaps in CPU memory, but also true for bitmaps that we upload to textures. Just because it's cheap for a GPU to scale a large texture into into a small space on the GPU doesn't mean it's fast to upload it into texture memory, or cheap for the GPU to have that large image sitting around in memory. Memory is a constrained resource and should be treated as such. I'm sure your date will tell you as much (possibly as they leave the date in search of more interesting prospects).

If you're going to scale from a 2k x 2k image into a 32x32 icon, wouldn't it make more sense to pre-scale it once, chuck the original one, and thenceforth deal with only the smaller version instead?

Of course, if you really need full-size images, then go ahead and do what you need to do. And if you're animating an image's size (such as zooming in on it), then pre-scaling to each intermediate size probably doesn't make much sense. But if you know that you're going to be using a smaller version for a while, then you should probably pre-scale to that size rather than drag around the memory and performance baggage associated with the original version, no matter what the hardware acceleration situation on the target device is like.

* The advantage of discussing memory consumption on first dates is not only that it will help you keep it in mind at all times, but also that this will inevitably lead to more first dates on which you can continue discussing it. Or it will at least result in less second dates.

Google I|O 2012 Presentations

The videos and slides are now posted for the presentations that I did with Romain Guy at Google I/O a couple of weeks ago.

What's New in Android: A developer's overview of some of the new features available in Android 4.1 Jelly Bean, including a deep dive into the enhanced Notifications capabilities (this part by Daniel Sandler, one of the engineers responsible).

For Butter or Worse: A very geeky look into how hardware accelerated rendering works on Android, what we did to make things smoother and faster in the latest release, and what Android developers can do to make their applications faster and smoother as well.

These videos were posted within a day of the talks, but the slides took a bit longer (possibly explained by the rush up to IO followed by everyone collapsing in fatuge when it was over).

There are tons of other great talks from the conference that are posted as well, both in the Google Developers channel on YouTube and (with slides) on the IO site itself.

Enjoy...