Profile

Cover photo
Chet Haase
Works at Google
Attended Carleton College
17,476 followers|13,257,025 views
AboutPostsPhotosYouTube+1's

Stream

Chet Haase

Shared publicly  - 
 
ADB 49: What's New in Android N

This time, +Tor Norbye and I talk with the one (l'une), the only (la seule), +Romain Guy about some of the new features in the Android N preview release. At least until Tor had to ditch and run for some "important" thing.

http://androidbackstage.blogspot.com/2016/05/episode-49-whats-new-in-n.html
Chet, Romain, and Tor (mysteriously shadowed) In this episode, Chet and Tor talk with Romain Guy about some of the new features in the Android N preview release. Favorite feature: "San Jose French" Subscribe to the podcast fe...
55
11
Add a comment...

Chet Haase

Shared publicly  - 
47
1
Marty Ballard's profile photoAmit Jayant's profile photoStaffan Thomén (duck)'s profile photoRobert Wallis's profile photo
6 comments
 
" Eleven thousand people follow him on Twitter, and 2,000 on Medium .. "

That bit made me laugh.
Add a comment...

Chet Haase

Shared publicly  - 
 
They just posted Speechless on the Google I/O schedule.

This sh*t just got very real.

Android developers: I hope to see you next week at the conference.
Everyone else: I don't know why you read this far.

https://events.google.com/io2016/schedule?sid=32d50c09-0cef-e511-a517-00155d5066d7#day2/32d50c09-0cef-e511-a517-00155d5066d7
Speechless is back at I/O for the third year in a row! You've seen them present. You've even seen them present at I/O. But you've never seen them do it quite like this. Watch Google speakers as they give totally new presentations in totally unpredictable ways. Based on the SF-based comedy show Speechless, this session will bring new meaning to the phrase "slide show". Armed only with a laser pointer and a deck of random slides, the presenters w...
78
4
Constantin A.'s profile photoRonaldo Pace's profile photoAkshay Dave's profile photoChet Haase's profile photo
10 comments
 
+Akshay Dave Indeed, it shouldn't be streamed. Improv comedy can be unpredictable, and I really like my job.
Add a comment...

Chet Haase

Shared publicly  - 
 
+Tor Norbye and I have an open podcasting relationship in which we're free to explore recording with other co-hosts or even, as in this case, no co-host at all.

I had fun talking about ExoPlayer with Oliver Woodman while I was in London recently.

Back to a Tor-filled episode next time.
 
Android Developers Backstage episode 48 is now available. Listen in to learn about the ExoPlayer, an application level media player for Android.

http://androidbackstage.blogspot.com/2016/05/episode-48-exoplayer.html
Oliver and Chet In this episode, Chet visits the Google's Android office in London and chats with Oliver Woodman about ExoPlayer, an application level media player for Android. Subscribe to the podcast feed or download the au...
3 comments on original post
31
1
Lisa Borel's profile photoTimothy Kist's profile photo
2 comments
 
Very helpful! Nice one!
Add a comment...

Chet Haase

Shared publicly  - 
 
Inedible Arrangements™: my favorite!

20
Christopher Tate's profile photoTyson Kemp's profile photoMarty Ballard's profile photo
7 comments
 
I'll take my chances with a banana instead.
Add a comment...

Chet Haase

Shared publicly  - 
 
As I suffered through a new, and therefore excruciatingly exhausting, workout in the gym this morning, I was reminded of Jim Fixx, herald of the new age of running back in the 70s, and dead of a heart attack (while jogging!) in the early 80s:
"He died of a heart attack while jogging at 52 years of age"

It struck me, much like the floor would have done if I'd gotten any closer to passing out, that nobody has died while eating a donut. Or if they have, at least they were enjoying it more than I enjoy working out.



https://en.wikipedia.org/wiki/Jim_Fixx
25
3
Chet Haase's profile photoJorge Castro's profile photobryce hendrix's profile photoJim Andreas's profile photo
7 comments
 
Seems like you could add a plugin to Studio that monitors the performance of your coronary arteries. You could call it the "Open Tor" plugin :-)
Add a comment...
Have him in circles
17,476 people
Jay Dellinger's profile photo
Garrett Valiant's profile photo
Natalia Dragun's profile photo
Android Al dia's profile photo
Long Nguyen's profile photo
Eric Villiers's profile photo
Shakura X's profile photo
杨树森's profile photo
Suwing Ben's profile photo

Chet Haase

Shared publicly  - 
 
The best advertisement for a hamburger is a veggie burger.
43
1
Ricky Solorio's profile photo
 
With a side of celery to replace the fries. 
Add a comment...

Chet Haase

Shared publicly  - 
 
They've already posted our What's New in Android talk. They're getting so fast at posting the session videos, next year they'll probably post it before it happens. Then we can just show the video instead.

https://www.youtube.com/watch?v=B08iLAtS3AQ&list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&index=1
128
11
Marc Poppleton's profile photoRonaldo Pace's profile photoStaffan Thomén (duck)'s profile photoRicky Solorio's profile photo
10 comments
 
Or you could just do What's new in Android '17 the same day next week and have it ready for 2018 for all Non Nexus phones so they can catch up. Lol
Add a comment...

Chet Haase

Shared publicly  - 
 
+Dianne Hackborn doesn't post about Android often, but when she does, it's a doozy.

I've been asked before which application architecture we recommend, from the perspective of the toolkit team. I've tried to explain, with little success, that I have no opinions on this, that the toolkit is pattern/architecture/design-agnostic, and app developers should do whatever works for them.

But Dianne's post provides a much more complete and eloquent explanation. Maybe I'll just print business cards with a link to this post and hand these out when people ask me about their favorite design-pattern-TLA from now on. Then while they're reading the URL, I'll make my escape.
 
"How should I design my Android application? What kind of MVC pattern should I use? What should I use for an event bus?"

We often see questions from developers that are asking from the Android platform engineers about the kinds of design patterns and architectures they use in their apps. But the answer, maybe surprisingly, is we often don't have a strong opinion or really an opinion at all.

Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here.

This may be surprising, because Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not.

It is probably better to call the core Android APIs a "system framework." For the most part, the platform APIs we provide are there to define how an application interacts with the operating system; but for anything going on purely within the app, these APIs are often just not relevant.

That said, the Android APIs can often look different (or higher level) from what one typically expects in an operating system, which may easily lead to confusion about how they should be used.

For an example of this, let's consider how an operating system defines "how to run an app." In a classic system, this is basically the contract it has with an application about when it should run:

int main(...) {
// My app goes here!
}

So the operating system starts the app, calls its main() function, and the app goes off and runs and does what it wants until it decides it is done. And clearly it is not saying anything here about what the app should be doing or how it should be designed within that main function -- it's a pretty pure blank slate.

In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them... so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn't running.

To accomplish this, we decomposed the typical main entry point of an app into a few different types of interactions the system can have with it. And these are the Activity, BroadcastReceiver, Service, and ContentProvider APIs that Android developers quickly become familiar with.

These classes may look like they are telling you how the internals of your app should work, but they are not! In fact, they are all about how your app needs to interact with the system (and how the system can coordinate its interaction with other apps). As long as that interaction with the system happens, we don't really care what goes on inside of the app.

To illustrate, let's briefly look at these different APIs and what they really mean to the Android system.

Activity

This is the entry into an application for interacting with the user. From the system's perspective, the key interactions it provides with the app are:

• Keep track of what the user currently cares about (what is on screen) to ensure the process hosting that is kept running.
• Know that previously used processes contain things the user may return to (stopped activities), and thus more highly prioritize keeping those processes around.
• Help the application deal with the situation where its process is killed so the user can return to activities with their previous state restored.
• Provide a way for applications to implement user flows between each other, coordinated by the system. (The most classic example here being share.)

What we don't care about:

Once we have gotten in to this entry-point to your UI, we really don't care how you organize the flow inside. Make it all one activity with manual changes to its views, use fragments (a convenience framework we provide) or some other framework, or split it into additional internal activities. Or do all three as needed. As long as you are following the high-level contact of activity (it launches in the proper state, and saves/restores in the current state), it doesn't matter to the system.

BroadcastReceiver

This is a mechanism for the system to deliver events to the application that may be outside of a regular user flow. Most importantly, because this is another well-defined entry into the app, the system can deliver broadcasts to apps even if they aren't currently running. So, for example, an app can schedule an alarm to post a notification to tell the user about an upcoming event... and by delivering that alarm to a BroadcastReceiver of the app, there is no need for the app to remain running until the alarm goes off.

What we don't care about:

Dispatching events within an app is an entirely different thing. Whether you use some event bus framework, implement your own callback system, whatever... there is no reason to use the system's broadcasting mechanism, since you aren't dispatching events across apps. (In fact there is good reason not to -- there is a lot of unnecessary overhead and many potential security issues if using a global broadcast mechanism for the internal implementation of an app.) We do provide the LocalBroadcastManager convenience class that implements a purely in-process intent dispatching system with a similar API to the system's APIs, if you happen to like them. But again, there is no reason to use that over something else for things going on purely within your app.

Service

A general-purpose entry point for keeping an app running in the background for all kinds of reasons. There are actually two very distinct semantics services tell the system about how to manage an app:

Started services are simply telling the system to, for some reason, "keep me running until I say I am done." This could be to sync some data in the background or play music even after the user leaves the app. Those also represent two different types of started services that modify how the system handles them:

• Music playback is something the user is directly aware of, so the app tells the system this by saying it wants to be foreground with a notification to tell the user about it; in this case the system knows that it should try really hard to keep that service's process running, because the user will be unhappy if it goes away.

• A regular background service is not something the user is directly aware as running, so the system has more freedom in managing its process. It may allow it to be killed (and then restarting the service sometime later) if it needs RAM for things that are of more immediate concern to the user.

Bound services are running because some other app (or the system) has said that it wants to make use of the service. This is basically the service providing an API to another process. The system thus knows there is a dependency between these processes, so if process A is bound to a service in process B, it knows that it needs to keep process B (and its service) running for A. Further, if process A is something the user cares about, than it also knows to treat process B as something the user also cares about.

Because of their flexibility (for better or worse), services have turned out to be a really useful building block for all kinds of higher-level system concepts. Live wallpapers, notification listeners, screen savers, input methods, accessibility services, and many other core system features are all built as services that applications implement and the system binds to when they should be running.

What we don't care about:

Android doesn't care about things going on within your app that don't have any impact on how it should manage your process, so there is no reason to use services in these cases. For example, if you want to start some background operation to download data for your UI, you should not use a service for this -- it is actually important to not be telling the system to keep your process running while doing this, because it really doesn't need to be and the system would be better off having more freedom in managing it with other things the user is doing.

If you just make a simple background thread (or whatever non-service mechanism you want) to do the downloading, you will get the semantics you want: while the user is in your UI, the system will keep your process running for that, so the download will never be interrupted. When they leave your UI, your process will still be kept around (cached) and able to continue downloading, as long as its RAM isn't needed elsewhere.

Likewise for connecting different parts of your app together, there is no reason to bind to a service that is running in the same process as the one binding to it. Doing so is not actively harmful -- the system just sees a dependency from the process to itself so doesn't try to keep it around any more than usual -- but it is a bunch of unnecessary work for both you and the system. Instead, you can just use singletons or other normal in-process patterns for connecting pieces of your app together.

ContentProvider

Finally, the ContentProvider is a fairly specialized facility for publishing data from an app to other places. People generally think of them as an abstraction on a database, because there is a lot of API and support built in to them for that common case... but from the system design perspective, that isn't their point.

What these are to the system is an entry-point into an app for publishing named data items, identified by a URI scheme. Thus an app can decide how it wants to map the data it contains to a URI namespace, handing out those URIs to other entities which can in turn use them to access the data. There are a few particular things this allows the system to do in managing an app:

• Handing out a URI doesn't require the app remain running, so these can go all over the place with the owning app being dead. Only at the point where someone tells the system, "hey give me the data for this URI" does it need to make sure the app owning that data is running, so it can ask the app to retrieve and return the data.

• These URIs also provide an important fine-grained security model. For example, an application can place the URI for an image it has on the clipboard, but leave its content provider locked up so nobody can freely access it. When another app pulls that URI off the clipboard, the system can give it a temporary "URI permission grant" so that it is allowed to access the data only behind that URI, but nothing else in the app.

What we don't care about:

It doesn't really matter how you implement the data management behind a content provider; if you don't need structured data in a SQLite database, don't use SQLite. For example, the FileProvider helper class is an easy way to make raw files in your app available through a content provider.

Also, if you are not publishing data from your app for others to use, there is no need to use a content provider at all. It is true, because of the various helpers built around content providers, this can be an easy way to put data in a SQLite database and use it to populate UI elements like a ListView. But if any of this stuff makes what you are trying to do more difficult, then feel free to not use it and instead use a more appropriate data model for your app.
65 comments on original post
77
10
Russell Collins's profile photoBjörn Lundén (blunden)'s profile photoSigurður Rafn Gunnarsson's profile photo
3 comments
 
It's a great post, but "business card" level? Doesn't fully close the "Opinionnatedness of Android" question for me.
Add a comment...

Chet Haase

Shared publicly  - 
 
I think Hollywood could save a lot of money on remakes by automating the process, at least for movies from the 80s.

Just take the original movie, speed it up 2x, cut out the long, ponderous pauses, have some image recognition software detect and fix big hair, and replace the synth soundtracks with anything but.
I'd pay to see those movies again.
41
Andrew Kelly's profile photoLuke Wallace's profile photoMark S's profile photoGrayson Wendell's profile photo
9 comments
 
+Chet Haase​ I think you would enjoy http://ifdb.fanedit.org
Add a comment...

Chet Haase

Shared publicly  - 
 
#TravelDiaries : Santa Monica

It's often said of Southern California that, "Everything about this place is made up, even this quote." But I didn't realize that this adage applied to actual makeup. And I certainly didn't expect that it was about the plant life.

Imagine my surprise when I saw that even the trees in L.A. get their hair done.

But the results are probably worth it - Santa Monica might eventually be an attractive city when it’s done with its current construction projects (“face lifts”, as they say). Sure, the roads and sidewalks are torn up, and there’s nothing but concrete and outdoor shopping malls until you get to the beach, which is overshadowed by the Santa Monica Pier (America’s great invention for extending parking lots and streets out onto the water).

But I’m sure it will be beautiful some day, just as old people are when they’ve had so much plastic surgery that their lips touch their ear lobes. It’s all about removing the wrinkles. And making sure the trees have nice hair.
33
Mark Leznik's profile photoDavid Belliveau's profile photoLisa Borel's profile photo
3 comments
 
Come to Pasadena, it's much nicer.
Add a comment...

Chet Haase

Shared publicly  - 
 
I'm not as disturbed by the fact that I'm getting letters about cremation as I am that my wife is opening and considering them.

42
Nugroho Latifolia's profile photoJoe Posillico's profile photoDave Sparks's profile photoMichael Leibman's profile photo
9 comments
 
Being disturbed by mortality is a great opportunity to turn toward looking for or appreciating the whole meaning and greatness of life. Like, what is this really all about? Can I have the fullest possible realization of the truth of the nature of being now? At least that is fulfilling to me. (I just noticed this post because I'm listening to a really helpful and interesting and alive interview about interaction design, hopefully it designed me to interact and reply here in the most perfect way.) 
Add a comment...
People
Have him in circles
17,476 people
Jay Dellinger's profile photo
Garrett Valiant's profile photo
Natalia Dragun's profile photo
Android Al dia's profile photo
Long Nguyen's profile photo
Eric Villiers's profile photo
Shakura X's profile photo
杨树森's profile photo
Suwing Ben's profile photo
Work
Occupation
Graphics geek: graphics and animation software for the Android group at Google.
Employment
  • Google
    Senior Software Engineer, 2010 - present
  • Adobe Systems
    Senior Computer Scientist, 2008 - 2010
  • Sun Microsystems
    Senior Staff Engineer, 1999 - 2008
  • Micron Technology
    DirectX Drivers Mgr, 1998 - 1999
Basic Information
Gender
Male
Apps with Google+ Sign-in
  • AlphaBear
  • Wordiest
Story
Tagline
Graphics geek, comedy nerd
Introduction
I'm a software geek, working at Google, making Android graphics and animation more excellent. In previous lives I've worked at Sun on the JDK, at Adobe on Flex, and various other places in Silicon Valley, always working on graphics software.

In my copious spare time, I write. I write humor on my blog Enough About You... along with my G+ stream at google.com/+ChetHaase and on Twitter via @chethaase. I also occasionally post technical articles on CodeDependent. I co-wrote the book Filthy Rich Clients with Romain Guy, wrote another programming book Flex 4 Fun about Flex graphics and animation, and wrote humor books Round and HolyWhen I am King.... and the long-anticipated sequel, When I am King... II. Like women and childbirth, I eventually forget the pain of the process of writing a book, and will probably make the mistake of writing another one eventually. As soon as the scars from the last one heal.

I also have developed a strange and disturbing attraction to the microphone. Any microphone. You may find me giving a technical talk at a developer conference or user group, or doing some standup or improv in a comedy show. I've also been seen in videos ("You may know me from such hits as DevBytes..."), either work-related or posted on my comedy blog and YouTube channel.

None of what I write in my blogs, on Google+, or anywhere else has anything to do with my employer; they're just my thoughts, my jokes, my mistakes.
Bragging rights
4, no 5, books published so far. If I lose my mind, I may write more.
Education
  • Carleton College
    Math, CS, 1983 - 1987
Chet Haase's +1's are the things they like, agree with, or want to recommend.
Wordiest
market.android.com

Two words are better than one! Wordiest challenges you to make two words from 14 letters (some with bonuses attached), competing with other

Google I/O 2012
market.android.com

The official Google I/O 2012 conference companion app supports devices running Android 2.2+, and is optimized for phones and tablets of all

The Wind Through the Keyhole: A Dark Tower Novel
market.android.com

In The Wind Through the Keyhole, Stephen King returns to the rich landscape of Mid-World, the spectacular territory of the Dark Tower fantas

Lake Tahoe – Romain Guy
www.curious-creature.org

Lake Tahoe. Saturday, February 18th, 2012 at 7:23 pm, Photos. Written by Romain Guy · Bonzai Rock Sunset. A Song of Ice and Fire · Tweet · ←

Codedependent: September 2011
graphics-geek.blogspot.com - written by Chet Haase

One of the app developers here on Android asked me about the best way to animate adding and removing items from a UI Specifically he wanted to fade items in

Codedependent: Old Views Don't Die; They Just Fade Away
graphics-geek.blogspot.com - written by Chet Haase

Old Views Dont Die They Just Fade Away. One of the app developers here on Android asked me about the best way to animate adding and removing items from a UI