An open API service indexing awesome lists of open source software.

https://github.com/esoxjem/androidstylingguide

A simple guide for Styles and Themes
https://github.com/esoxjem/androidstylingguide

android styles themes

Last synced: 6 months ago
JSON representation

A simple guide for Styles and Themes

Awesome Lists containing this project

README

          

# Android Styling Guide
A simple guide for Styles and Themes

## Style
If you have a `View` with some attributes on it, you can extract them into a *style*.

```xml

<item name="android:background">#ffffff</item>

```

This is useful because you can apply the *style* to multiple views.

### When To Style
Use styles when you have multiple **semantically identical view**, i.e, all of the views mean exactly the same thing.

- Buttons on a calculator.
- Primary and secondary buttons in an app.

### When NOT To Style
- Single use styles.
- There is no particular advantage to styling these views.
- No reuse and mostly noise.

- Views that use same attributes but are semantically different.

```xml

```

Extracting a common style to reduce code duplication for title and body would just couples them and doesn't allow us from styling them differently in the future.

Analogous to using the same constant for two different concepts.

```kotlin
const val NUM_THREE = 3

const val COLUMNS = NUM_THREE
const val RETRIES = NUM_THREE
```
### Extracting Styles
Use built in refactoring menu.

```
Refactor > Extract > Style
```

### Inheritance
Styles can have parents and children.

```xml

```

- Don't mix both parenting styles. It's misleading.
- Prefer Implicit over Explicit parenting. Easier to read.

When dealing with the platform, use dotless child for simplicity.

```xml

```

### Multiple Styles
- Not possible on Android, unlike CSS.
- Other than `TextView` using `TextAppearance`.

Overriding priority:

```
view styling > style > textApprearance
```

### Organization
For starters,

- Attributes `android:layout_****` should be stay in the layout XML
- Attributes `android:****` should be defined in a style XML.

```xml

```

The idea is to keep only layout (positioning, margin, sizing) and content attributes in the layout files, while keeping all appearance details (colors, padding, font) in styles files.

This rule has exceptions, but in general works fine.

- `android:id` should obviously be in the layout files.
- `android:orientation` for a `LinearLayout` makes more sense in layout files.
- `android:text` should be in layout files because it defines content.

## Themes
*Styles* are local to a view, *Themes* are applied system-wide.

- Setup defaults. ex: spinnerItemStyle.
- Activity level theming.
- Enables theme swapping. Light vs Dark.
- Different scope than styles

```xml

<item name="android:background">@color/blue</item>

<item name="android:windowBackground">@color/white</item>

```

- Post Lollipop: Use view level theming if you want a portion of your app to look different than the rest of your app. Apply to a `ViewGroup`.
- Try modifying the theme first, then move to local styling.

## Miscellaneous
### Naming
Prefix the type info: `type_foo_bar.xml`.

- `fragment_contact_details.xml`
- `view_primary_button.xml`
- `activity_main.xml`

### colors.xml is a color palette
- `colors.xml` should be a mapping from a color name to an RGBA value.
- Abstract underlying colors from their usage in the app.

```xml

#FFFFFF
#2A91BD

#FFFFFF
#2A91BD

```

- Further separation between underlying colors and style usage can be achieved by defining an additional color resource file which references the color palette.

```xml

@color/white
@color/blue

<item name="android:foreground">@color/button_foreground</item>
<item name="android:background">@color/button_background</item>

```

Cost of maintaining another set of color mappings increases.

### Treat dimens.xml like a palette
- Define a "palette" of typical spacing and font sizes.

```xml


22sp
18sp
15sp
12sp


40dp
24dp
14dp
10dp
4dp


60dp
40dp
32dp

```

- Use the `spacing_x` dimensions in margins and paddings.

### strings.xml

- Name your strings with keys that resemble namespaces.
- Namespaces are necessary to bring context and break ambiguity.

```xml

Network error
Call failed

Enter email here
Enter name here

Logout
Contact Us

Network error
Call failed

Enter email here
Enter name here

Logout
Contact Us

```

- Don't write string values in all uppercase.
- Use attributes for in the view instead. ex: `textAllCaps` for all caps.

```xml

CALL FAILED

Call failed
```