These should be used in all layouts, and it’s absolutely fine if multiple colours reference the same internal palette colour.įor example, textColour, titleColour, and subtitleColour may all reference M圜ompanyBlue, defined as # 003791.

A lengthy list of areas that need colouring, referencing the internal palette colours.M圜ompanyWhite), as other flavours won’t contain this colour so will fail to build. An easy way to ensure this is to give them colours unique to that flavour (e.g. These should not be defined in any layouts, and only be referenced by other colours. A limited list of colours, with hex codes, for the flavour’s internal palette.xml as any colour, whilst still ensuring a pre-defined palette is stuck to.įor this approach, the colors. This may seem counter-intuitive, but it has a major advantage: textBackground can now be defined in an app flavour’s colors. Not at all reliable! It’s also not possible to provide different colours for different app flavours. If you want to change a colour in the future, you’ll have to find and replace every instance of the hex code, and make sure there’s not any other uses of that hex code.

Just putting hex colour codes in your layout is the easiest way to immediately see results, but isn’t at all sustainable. Please note that these levels are by no means a standard, they’re based entirely on my own experience. A simple level 4 project using 2 app flavours is available as a GitHub repo. These article will walk through 4 “levels” of colour abstraction, in order from worst to best. Correctly utilising colours allows a single codebase to produce app flavours with radically different colours, e.g. However, standardising these across the entire app can be an easily ignored task, one which is essential for multi-flavour apps. Handling colours in Android apps is generally pretty straightforward, as simple hex codes are used.

Android studio app name colo