Should we ignore renaming Application class in new_project script?

[luongvo]

Issue

This is the old logic, however, I don't think we should rename the Application class to fit the generated project name. There is no best practice to rename it. Should we name the Application class as MainApplication from the templates & samples? 💭

IMO, removing Renaming application class... logic could simplify our script logic and allow us to focus on the rest of things more efficiently.

Solution

Instead of naming the Application class as TemplateXMLApplication and TemplateComposeApplication in the templates, and then having logic in new_project script to find and rename that class to fit the generated project name (e.g. SampleXmlApplication) and its reference in the AndroidManifest.xml file, we could just name them as MainApplication from the template level and ignore renaming it in scripting level. The idea is to keep the default name as MainApplication and let the developer rename it later if it's really necessary to do.

• Rename the Application class in templates and samples to MainApplication.kt and their references in AndroidManifest.xml.
• Remove the renameApplicationClass logic in the new_project script.

  android-templates/scripts/new_project.kts

  Lines 240 to 260 in 3924ed9

  	private fun renameApplicationClass() {
  	showMessage("=> 🔎 Renaming application class...")
  	File(projectPath)
  	.walk()
  	.filter { it.name == "$TEMPLATE_APPLICATION_CLASS_NAME.kt" || it.name == "AndroidManifest.xml" }
  	.forEach { file ->
  	rename(
  	sourcePath = file.absolutePath,
  	oldValue = TEMPLATE_APPLICATION_CLASS_NAME,
  	newValue = applicationClassName
  	)
  	if (file.name == "$TEMPLATE_APPLICATION_CLASS_NAME.kt") {
  	val newApplicationPath = file.absolutePath.replaceAfterLast(
  	delimiter = fileSeparator,
  	replacement = "$applicationClassName.kt"
  	)
  	val newApplicationFile = File(newApplicationPath)
  	file.renameTo(newApplicationFile)
  	}
  	}
  	}

Who Benefits?

Developers

What's Next?

• Creating a chore ticket if everyone agrees to remove that logic.
• Creating a content ticket to update the project structure in Compass.

[toby-thanathip]

Voted ✅

I think it makes sense to remove it, as the application name doesn't bring much value anyways

[lydiasama]

Voted. 🙌🏻

[manh-t]

Voted ✅

[Wadeewee]

Voted ✅

[minhnimble]

Voted ✅

I would prefer going with less code and simplicity most of the time so this cleanup makes sense to me.

[hoangnguyen92dn]

@luongvo Would we stick with MainApplication for the Application class in all our next projects? 🤔 If so, I would also suggest adding one more action by updating the project structure on the compass. What do you think? 😄

[hoangnguyen92dn]

@luongvo I agree updating to MainApplication.kt

[luongvo]

@hoangnguyen92dn I added 1 more action to update the Compass content, please vote 🤗

[hoangnguyen92dn]

@luongvo Just have an idea in mind, how about adding an option to change the Application class if developers want to do so? 🤔 By default, it will be MainApplication.kt

[luongvo]

@hoangnguyen92dn I still think we don't need to support it:

• The application class name does not bring much value to the project. Hence, naming it at the script level does not bring much sense to the project structure.
• The developer could rename it easily after generating the project. That's not a hard action (when compared to the project package name for example) so automating does not help us to solve a complex issue here.

[hoangnguyen92dn]

@luongvo Yeah. So that's fine if we stick with the MainApplication.kt

[doannimble]

Voted, we actually don't need a specific application name.

[toby-thanathip]

@luongvo Looks like it's settled! What happened to the "Convert discussion to issue" button? 💭

[toby-thanathip]

I don't think it's possible yet for RFC discussions 🙈

[toby-thanathip]

Issue created: #361