public enum ThemeMode

  1. Object
  2. Enum<ThemeMode>
  3. ThemeMode

ImplementsComparable<ThemeMode>

The look a build asks the platform for.

ONE enum for every hint that selects a theme, not one per platform. The domains overlap almost entirely and differ in a constant or two, which is not a reason to make a developer learn three names for modern – and three enums drift, which is worse than the thing they were separated to prevent.

Where a hint really does accept less than all of this, its attribute says so with @Hint(valuePattern = ...) and the annotation processor refuses the rest. That is a build error naming the constant and the hint, which is what the old arrangement could not give: passing a constant the builder does not recognise is not an error there, it is a silent fallback to the default.

Enum constants

DEFAULTSay nothing, and let the build server apply its own default.
AUTOFollow the device’s own light/dark setting.
MODERNThe current platform look.
IOS7The flat iOS 7 look.
HOLOLIGHTThe Android Holo light look.
LEGACYThe pre-modern look for the platform.
CUSTOMThe theme the application ships, rather than a platform one.

Methods

public static ThemeMode[] values()
public static ThemeMode valueOf(String name)

Inherited methods

Enum constant details

DEFAULT

DEFAULT
Say nothing, and let the build server apply its own default.

AUTO

AUTO
Follow the device’s own light/dark setting.

MODERN

MODERN
The current platform look.

IOS7

IOS7
The flat iOS 7 look.

HOLOLIGHT

HOLOLIGHT
The Android Holo light look.

LEGACY

LEGACY
The pre-modern look for the platform.

CUSTOM

CUSTOM
The theme the application ships, rather than a platform one.

Method details

values

public static ThemeMode[] values()

valueOf

public static ThemeMode valueOf(String name)