I Hi there. When porting an app from iOS, there are several lists of possible locations and methods of doing things in a medical context. Typically, we just want to use the enum's name (in the display and elsewhere, like json encoding), but occasionally, we'd like to slightly modify it. Example:

enum class AdmininstrationReason {
  Prophy,
  StudyPlacebo,
  LightTherapy,
  DrinkingRelated, //<- We might want to display this as "Swallowing Disorders"
  Clotting,
  Other;
}

So I certainly can implement it as above and then use automatic parcelize/@Parcelable stuff and it works. I can even add an annotation and then get clever when displaying the value. This causes a performance hit by possibly dipping into reflection. I can make a companion object and use associatedBy to get part of the way there, but this breaks automated parcelization. I can make vals with getters for specific properties and use that, but it makes the per-item edits non-local to the list. I could make every item have a "String" value with it, but I don't want to have to add strings for some of these entries (of which there are hundreds) and duplicate the name of the items in an error prone matter.

This last snippet is ok, I've seen it several times. It doesn't come up often but that's what I would go for if I needed this. Another option:

enum class AdmininstrationReason(val overriddenDisplayName: String? = null) {
  Prophy,
  StudyPlacebo,
  LightTherapy,
  DrinkingRelated("Swallowing Problems"),
  Clotting,
  Other;

  open val displayName: String
    get() = overriddenDisplayName ?: name
}

That being said, for your specific use case, I would actually really recommend using an actual string in the constructor for all entries. Using the enum value name as display name is sensistive to refactoring. It's much clearer IMO to use a separate value explicitly. It also opens the door more easily to localization and such.

I could make every item have a "String" value with it, but I don't want to have to add strings for some of these entries (of which there are hundreds) and duplicate the name of the items in an error prone matter.

I find it more error prone to use the name of a variable/constant in code as something that's displayed to the user. Variable names and constant names should not matter to the execution of the program, they should be for developers. IMO I should always be able to refactor/rename any variable without having any impact on the business

Thanks! I thought the null constructor broke parcelize. let me try that.

I actually don't know about parcelize (sorry if I made it sound like it), this was just a suggestion from the top of my head

I mean, your code is compiling so far and far simpler than my options. I agree with your general code independence vs displayed strings point: if the app gets applied beyond this study, we may implement a "per item" display string.