Mark Eschbach

Software Developer && System Analyst

Android Styles

General Notes

  • Styles should express semnatic similarity (IE: The same buttons style repeatedly used or header text repeated across multiple views)
  • If a style's parent isn't explicitly used then it will default to the style above it: Some.Style.Child is parented by Some.Style.Child
  • When applying a style to a view it will not propogate that style to subviews (although themes may do that)
  • You can define string or other resources in the themes file, allowing you to define dimens in a location relevant to the definition.
  • AndroidStudio's support for renaming styles appears to be hit or miss.

Structural Notes

  • To keep L&F consistent across your appplication you should probably use a structure similar to {AppName}.{Area}.{SemanticElement}. Where {AppName} is the root theme name of the application, like BYT for BiteYourThumb. Depending on your application, you might have only one {Area} however I would recommend using a consistent term. In the future if you wish to add a registration flow with a modified look, then you could have BYT.Main and BYT.Registration. I haven't expirimented, however nesting {Area} in forms such as {AreaParent}.{AreaChild} may make sense depending on your level of change.

To be investigated furhter

  • API specific versions don't seem to inherit parents, should probably investigate further.