I Hi there. When porting an app from iOS, there ar...

# getting-started

[Michael Langford]

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.

[Michael Langford]

example of the type of code I'm porting from in swift, where you can see the "sparse renaming" I'm essentially going for:

//FYI: Codable is essentially Swift's Parcelable

enum BodyPartNames:String,Codable,Equatable {
  case Hand
  case Wrist
  case Forearm
  case Elbow
  case UpperArm = "Upper Arm"
  case Shoulder
  case UpperBack = "Upper Back"
  case LowerBack = "Bottom of Back/Spine"
  /// many other cases, almost all of them with no special string
}

[Michael Langford]

Am I missing a way in kotlin to get the "modifications" right next to the enum cases, but still use the defaults for the vast majority of items?

[Michael Langford]

Like this approach would be perfect, but, you can't default to "this.name":

enum class Planet(var population: Int = 0) {
    EARTH(7 * 100000000),
    MARS();

    override fun toString() = "$name[population=$population]"
}//from <https://devtut.github.io/kotlin/enum.html#functions-and-properties-in-enums>

[Michael Langford]

@Parcelize
enum class AdmininstrationReason:Parcelable {
  Prophy,
  StudyPlacebo,
  LightTherapy,
  DrinkingRelated{
    override val displayName:String get() = "Upper Arm"
  },
  Clotting,
  Other;

  open val displayName:String
    get() = name
}

This compiles, but I see literally 0 other people doing this, and worry I'm doing something really ill-advised or incompatible with something when doing it.

[Joffrey]

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

[Michael Langford]

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

[Joffrey]

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

[Michael Langford]

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.

[Michael Langford]

woo!, it worked great, thanks! It compiles, parcelizes, etc just great.