Is this a good design practise?

object StringConstants {
    object DialogStrings {
        const val DIALOG_POSITIVE_BUTTON_TEXT = "OK"
        const val DIALOG_NEGATIVE_BUTTON_TEXT = "Cancel"
        const val DIALOG_EXCEPTION_INFO_TITLE = "Exception Info"
        const val DIALOG_VIEW_FILE_ERROR_TITLE = "Error trying to view file"
        const val DIALOG_CLEAR_CANVAS_TITLE = "Clear canvas"
        const val DIALOG_CLEAR_CANVAS_MESSAGE = "Are you sure you want to clear the canvas?"
        const val DIALOG_UNSAVED_CHANGES_TITLE = "Unsaved changes"
        const val DIALOG_UNSAVED_CHANGES_MESSAGE = "You have unsaved changes, are you sure you want to exit?"
    }

    object FragmentStrings {
        const val FRAGMENT_FIND_AND_REPLACE_TITLE = "Find and Replace"
        const val FRAGMENT_COLOR_PICKER_TITLE = "Select Color"
        const val FRAGMENT_NEW_COLOR_PALETTE_TITLE = "New Color Palette"
    }
}

grouping constants is fine, but… how will you handle localization?

For constants it's fine, but really only for constants.

object

is a singleton and not a purely static class, the moment you add a function or whatever initialization code is added. Simply adding things to files without any wrapping structure is going to create proper fully static things. I remember namespacing of symbols to be a future feature for Kotlin, not sure what the state is there.

Actually not a very good design… I would avoid the outer wrapper StringConstants and simply name the containing file the same way. According to Kotlin conventions:

If a file contains multiple classes, or only top-level declarations, choose a name describing what the file contains, and name the file accordingly.

https://kotlinlang.org/docs/coding-conventions.html#source-file-names

Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged as long as these declarations are closely related to each other semantically

https://kotlinlang.org/docs/coding-conventions.html#source-file-organization But really, like epheminent said this solution is going to work for a prototype, not for a product that needs localization, which is handled differently, involving properties files.

Namespacing is an issue, but it’s acknowledged and will be addressed in the future: https://youtrack.jetbrains.com/issue/KT-11968

I still have a hard time understanding why namespaces would be needed when packages already exist. What’s the difference? 🤔

It will allow us to create pure static symbols without the

object

singleton initialization, as well as adding extensions to anything, regardless of whether it has a companion object or not (incl. Java classes). This should also improve discoverability once implemented in IntelliJ because we are not looking at an endless amount of global symbols anymore, but can scope them to other symbols. 😎