Modernization Hub

Modernization and Improvement

14 comments on “Developing Themes with Style (Android Dev Summit ’19)

  1. 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

  2. I love this, because it explains this huge mess that is styles, themes, attributes, but I'm shocked that the slide (shown twice) to give colors meaningful names, is utterly ignored in the very same promoted sample: https://github.com/material-components/material-components-android/blob/master/material-theme-builder/src/main/res/values/color.xml ;)))

  3. 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. 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

  5. https://developer.android.com/guide/topics/ui/look-and-feel/themes should probably be updated, because it uses semantic names for color resources. Maybe adding a link to this video there wouldn't be a bad idea too!

  6. @AskAndroid I know I'm a bit late, but I would like to know if it's possible to change the theme color programmatically without recreating the activity.
    supernote.org, here you can find my GitHub project where I change the theme by recreating the activity and setting a different theme…

  7. "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!

  8. 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.

  9. 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)

  10. If you don't actually want us to name colors like "colorPrimary" then you probably should not name it like that in template project

Leave a Reply

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