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
stringor other resources in the themes file, allowing you to definedimensin 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.