Separate view data in quest data classes

[westnordost]

Task

For the cycleway quest, the cycleway answer options are cleanly seperated into two files: Cycleway.kt contains the "pure data" (the enum) and CyclewayItem contains the view-related part of a cycleway answer option.

This is better than how it is done for for example the surface quest (and others). There, in Surface.kt, the enum is not pure data because it contains reference to Android-specific view stuff. So for these quest(s), the data class should be refactored to be like for the cycleway class.

Example

So it should be....

enum class Surface(val value: String) { // or osmValue?
  ASPHALT("asphalt"),
  // etc....
}

// in SurfaceItem.kt
fun Surface.asItem(): Item<Surface> {
   // ... well, see CyclewayItem.kt, ...
}

Reason

Apart from it being good style generally to seperate UI from data logic, it is a step towards making #1892 or any other port from Android to something else a little less work to do.

Quests where this "old style" is used

• BuildingType
• Surface

And then

And there is more. Quest types should no longer have a String as parameter but an enum.

Compare AddRecyclingTypeForm (new style) with AddRailwayCrossingBarrier (old style). It is okay for the enum to define an OSM value like in the example with surface above.

[westnordost]

Maybe you are interested in helping out here, @FloEdelmann

[FloEdelmann]

These are all the quest forms which extend from AImageListQuestAnswerFragment and have String instead of an enum as a parameter:

• AddBikeParkingTypeForm.kt
• AddBridgeStructureForm.kt
• AddCrossingTypeForm.kt
• AddFireHydrantTypeForm.kt
• AddKerbHeightForm.kt
• AddForestLeafTypeForm.kt
• AddOrchardProduceForm.kt
• AddParkingTypeForm.kt
• AddPowerPolesMaterialForm.kt
• AddRailwayCrossingBarrierForm.kt
• AddReligionForm.kt
• AddRoofShapeForm.kt
• AddSportForm.kt
• AddInformationForm.kt
• AddTracktypeForm.kt