2:44 Style. 3:16 Theme. 5:52 How style, theme apply. 8:56 ThemeOverlay. 9:47 Crafty tip. 12:08 Themes vs Styles summary. 13:09 Color state lists. 15:26 Color state lists tip. 17:43 Tip 1: Use literal names for resources. 19:12 Tip 2: Use consistent style names. 21:56 Tip 3: Split files base on purpose. 25:15 Material Color system. 28:04 Material Typography system. 30:12 Material Shape system. 34:10 34:38 Material examples. 34:42 Dark theme.
This was most practical/useful session of all summit'19. Also it should have been made 10 years ago. Comparing styles/themes with interface/implementation was brilliant, all tips and suggestions were useful. Overall 10/10 and this video should be added at the top of styling Android docs
What we really, really need is a graphical theme editor, like Android and Android Studio did so well to layouts and navigation. So designers can build a right application theme even before developers start to coding. We need also a clear separation between themes and stand alone styles, it is confusing like hell. An application need to have one style set and that is it: the developer can't be allowed to use any external style and components need to have a default appearance (when you don't use the style attribute) *picked on application's theme, not Android default theme*. When some external resource like a font, for instance, can't be loaded for some reason, the theme or application developer need to receive a clear warning about, instead of a silent fall back. And finally (for now) the style system is based of inheritance of inheritance of inheritance of inheritance of inheritance deep on platform foundations... When you find some issue in some style is very hard to locate the problem (even more because styles depends on device's configurations) and cumbersome to fix it. If some nice built in style isn't behaving how expected, you are toasted: you lose so many hours trying to figure out why, feeling like the dumbest guy in the world, or you just abandon it and try to do the things yourself (losing so many hours or adding some 3th party library, that will bulk your app a little more)
good presentation... but what a complete mess. why didn't android have a theme tag instead of overloading the style tag? and why have an implicit parent?
4 года назад
This video should be included in the android theming documentation!! It's nice once and for all to understand theming
Interesting talk, but can't really deny that styling and theming is still hard nowadays. For example, it seems a little bit of an overkill that one needs to create a color list just to change the background color of a button when selected.
why say something is good and simple and add stuff like parent="" , who comes up with random stuff to write that will create problems and people will have to google up
"Giving semantic meaning to hardcoded values" I find it practical to be in a layout, write color:@color/ and being able to select a color from the autocomplete list of available values based on the semantic name!
You did not get the point correctly. The emphasis was on giving literal name to the color resource, not the theme attribute. Watch that part again at 17:47
I don't think that giving literal names for colors is a good advice. What's the purpose of naming a color "blue"? We already know it's blue from its value. It's more interesting to name it according to the context in which it is used: colorPrimary is a better name and gives more information on where the color is being used. This way you can have the same name for light and dark theme (using the /night folder).
Agreed. Also what if the design team decided to change the color themes (e.g., from blue to green) at some point? We would also need to change the color names accordingly (from "brand_blue" to "brand_green"), which is a lot more work than just changing the color values themselves in the "colors.xml" file.
@@byunghwara I think that it is a misunderstanding. You will not use @color/ directly in your app, it will be used just in the theme definition and on all other places you will use just ?xyz. So you can define brand_light or brand_dark in colors.xml, and then use one in normal theme and second in the night theme. They suggest it in exactly this way.
@@ATomCzech What they were suggesting is that we should use literal names instead of semantic names. It's actually fine to use names like "brand_light" and "brand_dark". But they are not "literal" names. They are actually "semantic" names. What I'm saying is if we used names like "brand_blue_light" and "brand_blue_dark" (as suggested in the video), then if the design were later changed from blue to green, then we would also have to change the color names from "brand_blue_light" and "brand_blue_dark" to "brand_green_light" and "brand_green_dark". This is a lot more work.
@@ATomCzech You can't always use attribute (example is in app-widgets). Also, colors, like drawables can exist in multiple places with the same name (using qualifiers) to handle dark theme (for example). Using the current decision, you would need to set up the theme all over again for each qualifier that was supposed to be set for the color. How could you name something "blue" if it has a different value in dark theme? And, speaking of drawables, instead of "delete" would you prefer to name it "trash_can" ? All icons have the names by the purpose and not by what's shown there: material.io/resources/icons/?style=baseline
17:36 Having names of colors this way is wrong. It makes it harder to find, and doesn't let you use it correctly for qualifiers. Here, made a request from Google to avoid this: issuetracker.google.com/issues/157584215 Please consider starring
You shouldn't have different colors.xml files with different qualifiers, but only a single colors.xml file with all colors (= your "color palette") that you use in whole app. The semantic names should be defined inside the theme - then you can have different themes with different qualifiers (e.g. for light/dark modes) referencing different colors from the single colors.xml file.
