Fragmented Podcast - Material Design using the Support Libraries
/I recently had the opportunity to be on the Fragmented Podcast. I was pleased with how it turned out. I got the content transcribed, so I could post it. I added links to the content, relating to the subjects we we were discussing, and hope this additional context adds value.
Participants:
Donn Felker
Kaushik Gopal
Mike Wolfson
[Audio Length: 43:32]
RECORDING COMMENCES:
Donn Felker:
Welcome to Fragmented, and Android developed podcast where we talk about building good software and becoming better Android developers. I’m Donn Felker.
Kaushik Gopal:
And I’m Kaushik Gopal.
Donn Felker:
Kaushik, I’ve been trying to get my apps, I don’t know, been trying to make them look a little bit better, like material and so forth. You know what I mean?
Kaushik Gopal:
Mm-hmm.
Donn Felker:
Have you done anything like this before and do you know anyone that might be able to help us out here.
Kaushik Gopal:
Sure, so we’ve never touched on the topic of Material Design from the developer’s point of view, so I thought it would make sense because we both are definitely curious about Material Design and I’m sure both of us have like dabbled with it at the levels that we need to. But we thought let’s really deep dive into this. And for that we got our mutual friend of the show and Material Design master, Mike Wolfson. So without any further ado, let’s get Mike on. Welcome to the show, Mike.
Donn Felker:
Welcome.
Mike Wolfson:
Thanks so much for having me.
Donn Felker:
So Mike, can you explain a little bit about who you are and maybe your background in software development and in particular Android?
Mike Wolfson:
Sure. Well, like most current Android developers, I started in the world doing Java development, enterprise job development and the company I was working at needed an Android app back in the day and I had been dabbling and actually created an app in the play store just to learn about Android. I was able to kind of turn my hobby into a career. This was right when Android was getting started and I kind of saw the writing on the wall that Android is going to be awesome and big and so I kind of dedicated my career to learning and doing Android.
Donn Felker:
Awesome. Where exactly are you located? Are you in the states? Are you overseas? Where are you at?
Mike Wolfson:
As you know, as well as I do, I live in Phoenix, Arizona, I am now the top Android developer in Phoenix. I used to be the second best but, I ran the top guy out of town. That’s Donn. Donn moved away from Phoenix. I live in Phoenix, Arizona and I am a freelance guy, so I do general different things for a lot of different companies. Right now I am working for a company called The Medical Memory. They are a startup in Phoenix and we are creating a framework to allow physicians to record video interactions with their patients and then the patients can review them later and view them offline. So, that’s what I’m working on now, but I’m constantly on the hunt for the next contract and interested in doing design and design-focused development.
One last thing that’s kind of worth noting, I ama Google Developer Expert as you are Donn, and so it allows me to kind of leverage my passion for Android and kind of help the community, so that’s kind of a really important part of my identity.
Donn Felker:
Definitely.
Kaushik Gopal:
We have a lot to talk about today so let’s hop right into the discussion. Let’s start off with the very basics. What exactly is Material Design? I know there are Material Design specs that are laid out. Let’s just try to give a quick intro into what this whole thing is about.
Mike Wolfson:
Sure, so I think it’s really great context to kind of talk about what Material Design is. Material Design is a design language that Google created. So, it’s both a design language to describe how user interfaces should look and feel and then it’s also a specification that defines exactly how you’re supposed to accomplish these various things. There is a really great document at design.google.com that’s kind of like Google’s main landing page for this stuff. On that page is something called Material Design specification. Inside of that is more information than you could ever hope to learn. Interaction guidelines, style guidelines, animation, layout components.
But the important thing is the design spec is just a spec. It just tells you what you’re supposed to do. It doesn’t have any information about how you’re actually supposed to accomplish that. The design spec includes all sorts of fancy animations and all sorts of really interesting language about paper morphing into other paper, things like that. However, to actually develop this stuff is incredibly, or can be, incredibly difficult. But I think that’s what we’re here to talk about is how the second half of this equation, and that’s kind of the support libraries are designed to kind of work within this specification and help us get there.
Donn Felker:
Now, Material Design as a spec, I guess the big thing is why, as developers that we are, why should we care about that? Isn’t that the designer’s job? Or, if we were to flip that on its head, why would designers care about this spec in general?
Mike Wolfson:
Okay, so there’s kind of a few different reasons that we care and I think designers and developers should care for these same reasons. So, the first one is we’re creating apps that work on Android and we want to make sure that they fit on Android, meaning the app itself has the same sort of dimensions and layouts and parameters as every other app on the phone. That means when you’re going between apps and different functionality, the app itself feels like it is designed to fit within the Android framework. It’s amazing how that fit really subconsciously effects the user experience.
By just having different margins or button sizes or different icons, it really takes the user out of the Android experience, right? And the most important thing is we’re creating Android apps that live within the Android ecosystem, so really important that we’re meeting the fit and finish that Android has specified for us.
Kaushik Gopal:
That’s a very subtle point that you mentioned and it’s so true. I was having a talk with the designer some time back, and just these small things, you may think it’s not really going to lead to anything different, like just having the margins and padding, because the concern is always how do you add character to your application. You don’t want it to look like a stock Material Design, because then if you are a company or if you’re building this new app, you want it to be memorable in some ways, right? But you can still adhere to the spec and have this, and those small things that you mentioned, it’s just a fantastic point. Like just keeping the margin, the key line, the padding, just having all that, it makes you feel like you’re a member of the ecosystem.
Mike Wolfson:
Just to kind of piggyback on your point, so we want to make sure our apps fit and look right, okay? And so that’s kind of the general stuff that we talked about, sizing and dimensions, but we also want to kind of create some unique opportunities that make our app kind of different and not like you said, just kind of vanilla material. The thing is, you want to concentrate on creating those unique UI experiences in the places that it counts. So, you don’t mess with the dimensions and padding and stuff like that because that may make your app look unique and different, but not in a good way, right? Where you want to concentrate is on specific animations or user icons, specific icons. Things that you can really differentiate your app on a very important level, but not in the way that your app just doesn’t feel right.
Donn Felker:
You know, the app, and we actually interviewed one of the developers that did this app, but the app that always rings total material but done very well in my mind, is a Pocket Cast app. I mean, what do you think about that?
Mike Wolfson:
You know, I was just looking at that yesterday. One of our mutual friends was showing it to me and I think it’s great. They use the collapsible app bar and they use activity view transitions I noticed. But it feels like a material app and it feels like an Android app, yet they take the opportunities to create some really nice UI flourishes in important places.
Donn Felker:
Yeah, it’s awesome. It’s one of those things like when it first came out, they had these small little animations and I remember the talk that you gave at the Phoenix Android group, and I think, correct me if I’m wrong, you said something like you shouldn’t have animations unless there’s a user interaction. Is there something like that you had said?
Mike Wolfson:
That’s interesting. This is actually a key point of the Material Design spec, and that is, and I’m holding up my fingers in quotes, “the user drives interactions.” So, Material Design, motion is one of the key criteria or important characteristics of Material Design and the whole kind of factor of it is that the user drives that motion to happen. You see this in ripple effects or when buttons raise to touch your finger, as they call it. All these different motion effects are an important part of material, but they don’t happen superfluously or just kind of for the sake of things flashing or things moving. They happen when the user causes some action and then that motion effects themselves are actually useful and key feedback to the user. The user does something, they see some motion that reinforces what they did is correct and fun, and delightful.
Donn Felker:
I learned a lot from just that simple tip, because for the last many years, I would create animations in my app and be like that’s a cool animation, let me throw it all over the place. It was just like back in the early 2000s when the gradients and page flips were the thing in graphic design. It’s like animations are that way in Android. Once I heard that exact statement that you just recapped there, I now question myself every time I want to create an animation for something, I think like all right is this like a user initiated action? Is it going to add anything to the user experience? Is it going to look like a nice polish? And if the answer is usually no, then at that point I don’t include it.
Mike Wolfson:
Of course animations can be problematic for memory, and they’re difficult to develop and things too, so concentrate on doing them when they matter most.
Kaushik Gopal:
The other huge advantage as developers, especially with these things, sometimes it’s hard. Personally, as a developer, sometimes it’s hard for me. Well, should this value be 16 dp, should it be 12 dp, should it be a large font, should it be a small font? These decisions are just alleviated. Having the spec basically makes it easy. Sometimes I don’t want to think about these things. I want someone to have put a lot of thought into this and come up with the perfect guideline or styles and I can just go look and refer to them, and that’s also a huge benefit that I’ve found with the Google design guidelines.
Sometimes even designers come back. Because we like have designers who crisscross between different platforms, and when they come back and say “Oh, what does that value? Like how should this be?” Just having those guidelines is so convenient because then also it makes you feel that “Oh yeah, this is how it ideally should be and this is where we can take inspiration from.” I don’t have to like go searching, spending time thinking about it. It’s just there for us to use, right?
Mike Wolfson:
Wow, super important point, the one thing that I find really empowering about these specifications is that it eliminates kind of all the new onsets that the designers dealt with previously. So, I’ve spent a lot of time dealing specifically with designers and forever I would get a spec for a particular screen that has unique dps for every margin. Generally, defined in pixels, right? Because they are coming from an iOS world. Generally, not compatible with what, you know, they don’t even have dp specified. They have thirteen on this screen or twelve on this screen, etc.
The really powerful thing about the design spec is that those things are now fixed. I don’t care what the designer gives me because I’m basically going to ignore those. I know that the design spec says 16dp is the side margin and that’s it. It really dis-intermediates the designer from doing the tedious mocking per screen that they’re used to doing on iOS, and that we don’t really want to embrace on Android, right? We want to create these templates that are responsive and that are generic and not specific per screen.
Just kind of one other benefit, I mentioned I’ve dealt with designers forever, basically, I just ignore the stuff that they send me regarding incorrect dimensions and stuff. To be clear, no one has ever come back and said, hey dude, I specified 13 pixels and this is clearly not 13 pixels, go fix it. They never have noticed.
Donn Felker:
Would you say Material Design is based on some like scene in the spec, it looks like it’s based on some type of grid system. Can you talk maybe a little bit about what maybe that generic grid system is that we need to keep in our head. Is there any dimensions that we should kind of be aware of and that every developer should just know off the top of their head?
Mike Wolfson:
Yeah, so that’s pretty simple, the new Material Design spec creates a grid system where one grid point is equal to 8dp, so now instead of saying side margins are 16dp, they’re really two grids/points and so all of the Material Design specs are based on these 8dp grids. Basically it’s just kind of a little bit of an abstraction from eight to one. I have a sample Material Design app. I actually just abstract each of those grid points into dimensions. Grid one is equal to 8dp, grid two is equal to 16dp.
Kaushik Gopal:
As I understand the way Material Design works, so as developers when we dive in, right? There’s also this concept of like different primary or important colors. For example, you have color primary, you have color accent, color primary dark. So, can you touch a little on like what all these colors are about?
Mike Wolfson:
Sure, this is important to the Material Design spec. They’ve created a color palate that each app is supposed to use. You’re supposed to pick a primary color, which is your branding color, then a secondary color which will be used for different kind of secondary—I don’t want to use accents, but secondary color, and then a third, which is an accent color which is very different from your two primary colors. So, your primary color is, let’s say green. You pick a primary dark color that’s just another shade of green. Two shades darker and then your accent would be something pink or something very different. So, the important thing is once you start using the Material Design AppCompat libraries, and you define these colors within your styles, the system itself will start to apply these colors universally throughout your app and even the system, so certain system Toolbars will be changed on devices, I think L devices actually.
It allows you to create these three branding colors that define your brand very specifically, and then the system itself actually applies these universally, so it’s a really powerful thing because you’re able to choose these colors and the system itself applies them everywhere. It’s a really great way to get your brand kind of universal throughout your app.
Kaushik Gopal:
I mean it makes so much and obviously just adding those primary colors just sort of cascades the whole team adhering to the guidelines, like all the ripple effects, all those things. They just like use the right sort of color. They pick the right color from there.
Mike Wolfson:
The awesome thing is you don’t have to do that manually because before AppCompat, you basically had to apply your color, theme, to every single…
Donn Felker:
In all your views, right?
Mike Wolfson:
View that you have on your screen.
Donn Felker:
Oh geez, yeah. That was painful.
Mike Wolfson:
You ask me why we care about this and why we want to do this? One of my slides in a presentation I give is because I want to be lazy. Using this stuff makes things so much easier.
Kaushik Gopal:
Laziness, always the solution man. I’m all with you there.
Mike Wolfson:
So, I just want to address kind of the colors and the spec itself defines sixteen different color palates, so.
Kaushik Gopal:
Sixteen, oh okay, wow.
Donn Felker:
Wow.
Mike Wolfson:
I think it’s maybe twelve or sixteen where they have a green palate, a blue palate, a dark blue, etcetera, and then there’s different shades in each of those color specifications. Material Design spec actually wants you to use those colors predominantly, so they’re asking that you stick to that color palate predominately.
Kaushik Gopal:
Interesting. That is also something that I didn’t probably catch, like I was like oh, those are nice and pretty colors. I’ll use them, thank you.
Donn Felker:
Look at the pinks.
Kaushik Gopal:
I should use that for my t-shirt. The other thing, I know there are like a whole bunch of other specific colors. For example, we talked about colors primary, right? There’s color control normal, colorControlActivated, colorControlHighlight, colorButtonNormal. So, I think in most how tos and guidelines that we see online, just in the tutorials, they specified the main ones, color primary, primary dark and accents, right? But actually what happens is like you can, for the same reasons, if you want a little more control over how these colors show up, then basically you can specify a whole bunch of them.
I’ll try to add a link in the show like some of these handy diagrams that at least I use and at least some of the references that I use for this. For example, when I started out, I had no clue. But if you specify your primary or primary dark, etcetera. So the status bar that is like the top system bar is usually fixed color, usually primary dark, then your Toolbar or action bar is usually that color primary and then like the text is text color primary and then there’s a window background. I’ll add a link; I usually use this. It’s pretty helpful. Just for some people, there’s a huge number of these very specific colors that you can sort of control. It’s like a layer lower than you directly styling your competence with that color.
Donn Felker:
Now, in a lot of applications that I’ve worked with, I’ve had the luxury or pain of working with images a lot, and sometimes those images can have a drastic effect on the UI, for example, if my UI is, say, green, and then I load up an image and the image is like full of blue colors or like purples and it just doesn’t look right, is there anything in the Material Design specification or maybe even in the libraries that can help us with working with various images so we can maybe tint or change or application to match that? I feel like I’ve seen that in some applications.
Mike Wolfson:
Yeah, so you’re talking about something called the Palette Library, and what this does is this allows you to give the method the image that you’re looking for and it actually will look into that image and pull out a color pallet that provides complimentary colors and then contrasting colors to that. For instance, you said in an image that is predominately blue, it will send you back a pallet that includes and blue and different highlights, and then also one of those colors it sends back would be white, a contrasting color that you could set your title to make sure that it is always contrasting against that image.
Donn Felker:
Oh wow, and that’s one of the libraries we can use? The pallet library? Okay.
Mike Wolfson:
I’m not sure where the base is, but it’s an additional dependency.
Kaushik Gopal:
If I remember right, you have like these competent libraries and then you have like the compatible tool libraries. Just like how you have RecyclerView as a component, I think the palette also later on was brought in as just another competent. So, since we are talking about libraries, this is where it gets really interesting, right? If you take a step back, what exactly is the role of support libraries and materials then, right? I mean why do we even bring support libraries when we talk about Material Design? Because at least to my knowledge, there are like a hundred thousand varieties of these support libraries, right? There’s V7, V4, V13, design support library, AppCompat library, how do I make sense of all this? Like which one should I use? When should I use what? I mean let’s walk through this.
Mike Wolfson:
All right, so let’s talk about what the support libraries are, because there are kind of some different variations on them and they have different needs. The intention of the support libraries is to allow Google developers to back port new functionality to older devices. So obviously there’s lots of old Android phones out there that may or may not get the OS updated, but they do want to back port some of the new functionality to be able to be used on those older OS’s. For instance, one of the original reasons for this was Fragments. Fragments weren’t originally released with the OS and that’s obviously something super important to Android developers, and the support libs allowed fragments to be used on older versions of the OS.
Basically the support libraries are, they are software packages that you can add as dependencies to your project and then include that source code to be used on older versions. So, there’s a few different flavors of support lib and it’s worth kind of chatting about those just for a minute. There is AppCompat and Support and these are kind of the two—actually, there is V4 support and V7 app compact, so those two libraries are really important and are kind of the base of what everybody should use. The one thing I kind of wanted to mention, in that if people didn’t know, it’s the V4 and the V7 in that name stands for which version of the OS the library itself supports back to. V4 support is a library specifically designed to provide a shim layer for all of these awesome features like fragments or the other things we mentioned so that they can work back all the way to V4 phones.
Kaushik Gopal:
It’s basically the main SDK version, right? At least that’s how I think about. What’s your main SDK, right? SDK is 8 or 9, I really hope it is not 8 or 9, by the way. It should at least be 14 at this point, right? If it is then you can go all the way up to V7 and V13 and it also gives you the same functionality. It sounds like V4 is like older and V7 is newer.
Mike Wolfson:
Right, right. It has nothing to do with the library age. It has to do with the main OS support for that. Just from the docs, the docs suggest that everybody starts with the two libraries we just discussed as the foundation and then you start to add the rest of the support libraries which are more compartmentalized. So, you might add, like you said, the RecyclerView or Palette library as distinct dependencies but not as the complete package.
Kaushik Gopal:
Right, that makes sense.
Donn Felker:
Would you say that is it required to use these libraries or would just kind of make it a strong recommendation that you use the support libraries in this case?
Mike Wolfson:
Really important to talk about, and I would say required, so let’s talk about what this means. I mentioned that, and we’re just talking about support libraries. We’re not even talking about design yet. These libraries are designed to shim the core functionality back to OS’s that don’t support it. So, if you are on a device that supports Fragments natively, the support library itself will know that you’re on something that supports it natively and bypass the support lib version of that code and go right to the native version.
If you’re on an OS that doesn’t have the native support, it will go to the support version. Having said that, if you use the support libs, you’re confident that your codes going to work everywhere and in the cases where it can be run with OS native, you know, because Android M supports Fragments specifically, you know that you’re going to be using the native code when possible but you always have a fall back on older devices. There’s very little down side and obviously tons of upside being able to run on older versions of the OS.
Kaushik Gopal:
Obviously, I said it just before about the whole ten thousand support libraries, but the support library is essentially one of the most brilliant solutions Google has come up for us to be able to push the platform forward. It’s just like I truly think it’s like one of the most amazing libraries out there. Like without the support library, it would be impossible at least today to sort of for developers to be happy moving forward with like the newer features that come down the pipe, right?
Mike Wolfson:
Yeah, I know I’d like to move on but before we move on, it is worth kind of reiterating the point that you’re making that the reason these support libs exist is because this allows Google to develop these new functions and not be tied to the OS updates being done. They’re not tied to Verizon or Motorola to get these updates pushed out, so it allows them to innovate very rapidly and then allow the developer that wants to use that code base to push that code out to its users. It isn’t relying on any sort of phone update. It’s really important because they’re pushing tons and tons of innovation into both this and Play Services, those two libraries so that they are disintermediating themselves from the OS level itself and creating all their functionality in these external libraries.
Kaushik Gopal:
You spoke about reliability on that side? Let’s talk about the reliability for the support libraries and stuff and just a quick point because I know many times we try to jump on and like quickly use the support libraries, but is there like a concept of like stability for them, because I know sometimes these are just like libraries that Google develops, right? It’s just another super smart developer there whose like building these things, but they’re human in the end. So, what happens is sometimes things tend to break. What are your suggestions along those lines? I just want to quickly touch on this point.
Mike Wolfson:
I think that this is kind of a good thing to talk about. I think the design libraries work really great if you’re staying within the constraints that they define. There’s a few things to kind of mention with that. I think that the nature of the libraries are specifically designed to constrain you to stay within the Material Design specs. Certain things are very difficult to customize because they really shouldn’t be customized. Once you start changing those, then you’re kind of changing the Material Design. The other thing is because these are APIs and these are libraries, they have to be limited. You know, you can’t create a library that does everything for everybody because you know, it would never get out.
I think that the libraries are pretty reliable if you use them in the ways that they define them to be used. It’s once you start to customize or try to go outside of the patterns that they defined, then you’ll find the reliability goes down and the difficulty of customizing goes up greatly.
Kaushik Gopal:
My idea of having the FloatingActionButton go to random positions of the screen every time you click the button, that is not something you would recommend?
Mike Wolfson:
That’s probably not a good pattern, especially if that’s your FeaturedActionButton that you want people to press.
Kaushik Gopal:
Click here, no, now click there.
Mike Wolfson:
Like the chase the monkey spam ads that we used to deal with.
Donn Felker:
Speaking of widgets of the FABs and so forth, there’s all kinds of things that are inside of the support library for design, various different widgets. Now, I’d like to talk about a couple of those, like for example, just recently I re-noticed the CoordinatorLayout. This one previously seemed to me like it didn’t really do much. It was just like this weird container layout, but a recent article by Ian Lake, which is one of the Android developer relations team representatives. After I read it I felt a little bit differently and I’m seeing it to be quite useful. Am I correct in this thinking? What exactly does something like the CoordinatorLayout do?
Mike Wolfson:
Okay, so the CoordinatorLayout is kind of like your main container for kind of the new Material Design and what it does is it allows you to create associations between views within your container layouts. So, for instance, real simple example is the SnackBar. When the snack bar’s message that comes up on the bottom of the screen, it kind of animates in, stays there for a second and animates back down. A common pattern is if you have a FAB above the SnackBar, when your SnackBar animates up, the FAB animates up with it and that is all because of the CoordinatorLayout.
So, in the CoordinatorLayout, we’re able to create associations between different views and have the views then coordinate between each other. The way that you do that is something called behaviors. So, you create a behavior for your view and then you can tie it to other views. In the FAB instance, that behavior is included out of the box for us and there are a bunch of other ones that are also included out of the box. You could attach your FAB to a view so that when that view scrolls, the FAB scrolls with it, or like we discussed with the snack bar, it scrolls based on other things.
Kaushik Gopal:
I had a quick side question with respect to the CoordinatorLayout. Does the CoordinatorLayout add another layer? I know Google is like pretty big on making sure that we don’t have multiple nested layers of your views. Obviously, if the functionality requires it, it makes sense to add it in, but out of curiosity, is the CoordinatorLayout basically just a wrapper that doesn’t necessarily add a view to the view stack, but just like does the behaviors or does it actually really add another view? Does it extend like a frame layout on one of those other views? Would you know?
Mike Wolfson:
I think, and I’m looking this up now as we talk, I think that CoordinatorLayout is just a frame layout.
Kaushik Gopal:
Oh, so in that case it does add another additional layer I would imagine?
Mike Wolfson:
Yeah, but I’m honestly not sure about that.
Kaushik Gopal:
I was always curious because we have those XMLs and now with the new Android Studio, it actually shows you the level of nesting. Adding a coordinator layer sort of makes me feel, oh there’s another layer there, maybe I should, right.
Mike Wolfson:
Obviously we want to keep our View hierarchies as flat as possible, so.
Kaushik Gopal:
Do you think there’s any other must use widgets that we’ve talked about? We talked about some of the ones that we liked. Is there anything else that just comes off the top of your head that you think is super important that we should be using?
Mike Wolfson:
Yeah, so let’s talk about, I think one really important one is relating to navigation. That is the NavigationView and the Toolbar, and so these are really core navigation patterns in Android itself. That’s having a side menu that pops up and has a bunch of different buttons in the Toolbar that obviously does different things. So, the NavigationView is very difficult to customize. Again, this is one of those cases where that navigation is supposed to be very consistent and feel the same, and so you’ll see lots of people complaining. “How do I do this in the NavigationView? I want to add….?” - The answer is you really shouldn’t, but you really should be using those navigation controls to drive your apps. That drives not only the look and feel of your app, but also your app is kind of created and how your navigation flow is designed, and again, that’s really, really important. To make sure that this app feels like it’s designed to fit on Android.
I really think the NavigationView and the Toolbar are kind of two core components that make your app consistent and feel like someone that is first coming into the app knows exactly how they’re supposed to get around, exactly what they’re supposed to do. There’s not a lot of customization options only in the NavigationView, just the top header I think they call it. That area you can customize, but the nice thing about NavigationView is it’s super easy to create. All of the button coloring and highlight colors that are created in the list are all done for you. All you have to do is specify a menu, just like you did with ActionBarSherlock or any of the old action bars, and it generates all that magic for you. Really simple to use and really dynamic and easy.
Kaushik Gopal:
For the people who are like old time Android developers, the NavigationView is essentially like what you place inside your drawer layout, which is what it was called before and Toolbar is basically the action bar, right?
Mike Wolfson:
Yeah, right.
Donn Felker:
Now, are there any widgets that you would recommend not using, like for example, I’ve tried to use the FAB a couple of times, but it seems like the guidance on it is like so loose and I’ve also heard other developers that kind of just shy away from it. What do you advise, maybe in regards to that, or just in widgets in general that you just don’t advise people to use, or is there any at all?
Mike Wolfson:
I think there’s two. I think probably the FAB like you mentioned and also dialogues can have inconsistent margins. Some of the alert dialogues and some of those other ones are okay, but I had a discussion earlier this week with someone that called out those two. I think the FAB will, like you say, jump around, or be placed inconsistently and the dialogues, not alert dialogues, generic dialogues can have margins that don’t appear how you like.
Kaushik Gopal:
Would you have any like parting tips for if I wanted to become this wizard of Material Design like you, right? Do you have any tips on like some of the places that we can quickly touch and the different things that we should be using? Like how do I get better at Material Design?
Mike Wolfson:
Sure, I mean the first thing is the Material Design specs. They’re really hippy dippy and they talk about a lot of really fancy and fun stuff, but everything you ever want to know about Material Design, their intentions, it’s really well thought out, it’s really well documented and it’s really clearly written. It really kind of gives you, if you spend a little time familiarizing yourself, you really get the sense that the spec is a cohesive whole and that they really spent a lot of time thinking about how they create this framework.
First things first, learn the specs themselves, and that has nothing to do with coding. Next step is to start to dig into these support libs, and I did include some resources in the doc. I guess one that I want to call out is maybe a little self-serving, but I think it is super useful to the people that might be listening to this, is I created a project on GitHub called Android Historian…
Kaushik Gopal:
Whose this guy? Oh, oh.
Mike Wolfson:
My User ID is MWolfson. This is a project I created for the talk I gave on this subject at Droidcon NYC, and it’s a project that implements a ton of the different support libs, specifically designed to implement Material Designs. I include the most simple implementation of all the different components I could to create like a really simple Material Design app, and so it’s a really useful tool I think because it shows you how all of this stuff comes together and actually works. You can clone it and you can start from there, and I think that is a good real base material. I do want to mention that I actually forked this project from Chris Banes Cheesesquare project, which was his demo project for the design libs. I forked his basic project and extended it quite a bit and will continue to.
Kaushik Gopal:
Nice, and we’ll make sure we add links to all of those resources that you’ve given us on the show and also we will link those projects. Both Donn and I, I believe, were in New York for Droidcon NYC and it was a fantastic talk. We’ll make sure we add a link to that in the show as well.
One last point before we sort of wind the show down is very recently the support library 23.2 just dropped in on us. I would really encourage—I put this on Twitter the other day—definitely watch the video because the video is super funny. I love what the Android developer groups like Reto Meyer and Ian Lake have been doing with their videos. Just watch the video right until the end and you’ll get what I mean. But the two big things that were dropped in this library were Vectors, which is always an amazing thing. Not necessarily Material Design related, or no maybe it is because we have a whole bunch of like Material Design icons that you can just like drop in quickly, right? So, vectors was a huge thing and there were a couple of other things. Anything else that you guys want to talk about with respect to 23.2?
Mike Wolfson:
Well, there’s some hidden things. Let’s talk real quick about the rapid nature of the support lib iterations. They’re releasing a new version of the support lib about every two to three months and each one has like something else really big and really crazy in it. The other thing that’s kind of quiet in this one. There’s two things that are kind of interesting. They added a day/night mode which allows you to tie into the time of day on the phone and actually change your user interface based on that. They also have added some media router controls, which is really kind of a small thing, but what this does is this is going to allow people that use media in their apps the easiest controls and that will automatically handle pausing the sound when a phone call comes in or all the kind of tricky things that it takes to service media on the Android phone.
I haven’t dug into that yet, but for one of my clients, I really look forward to that. It’ll also allow you to quickly add Android auto controls and Android web controls, media controls without kind of needing to do that yourself.
Kaushik Gopal:
Right, right.
Mike Wolfson:
One last thing is bottom sheets which has come in animated view that pops up from the bottom.
Donn Felker:
That’s a good one.
Kaushik Gopal:
It’s crazy. Some of these features are like keynote worthy, right? And they just dropped it into a support library, so I mean double thumbs up. Google has been doing an amazing job with this, like the day/night mode and stuff. I can imagine other companies basically like announcing these as features in their keynote sessions and like here we have Google just like dropping left and right these amazing features.
Mike Wolfson:
Yeah, and I feel like this is kind of something new for us and kind of something that we really celebrate because as we’ve all been doing Android for a long time, frequently we get really cool ideas from the Material Design spec and this happened, but we’ve never had any controls. For instance, we never really had an ActionBar control all these years, right? They told us this is the ActionBar you’re supposed to be using, but there never was one that was—we all used, obviously ActionBarSherlock, and you know, we finally in fact, well there was an ActionBar, but even that got replaced by Toolbar.
What I’m getting is they’re finally giving us some of these really advanced controls that allow us to concentrate on the business logic and the fun stuff and not have to go through all work of creating native controls that match what they’re asking us for. It’s really awesome and it really feels like they’re making our lives so much easier.
Kaushik Gopal:
Definitely. Mike, thank you so much. This has been amazing. I’ve learned all ready so much from this discussion and I’m sure our listeners will enjoy this one as well. If people want to reach out to you, what would be the best way to do that?
Mike Wolfson:
Well, I guess I’m Mike Wolfson everywhere, so mikewolfson.com or @mikewolfson on Twitter, or Michael Wolfson on Google Plus. For some reason I couldn’t do Mike there.
Kaushik Gopal:
Can you give us your address so we can—I’m just kidding. Donn, how do we reach you?
Donn Felker:
Just get a hold of me on Twitter @DonnFelker or my website DonnFelker.com.
Kaushik Gopal:
Perfect, and I am Kaushik Gopal at Twitter and Kaushik.co is my website.
Thank you all for listening and we will catch you in the next episode.
Mike Wolfson:
Thanks for having me guys.
Donn Felker:
See ya.
END OF RECORDING