Separate the "template" project for xml and compose instead of only switching "screens" package

[luongvo]

Issue

Currently, we're trying to switch between XML and Compose project structure by screens package. From my experience when using this structure for the new Compose project, it's not really a good approach to go:

• There are too many redundant components from XML method to be removed.
• There are too many missing configs for Compose that we don't need to appear in XML method.
• Setting up nav graph steps are too different between XML and Compose.
• Setting up tests for XML fragments and Compose screens are totally different.
• Only data and domain are the same and could be cloned for both UI methods.

From these issues above, I think the way to have 1 template project for both XML and Compose does not make sense, or we will need quite a much effort to make it usable and clean for each one without separating.

This topic is related to the one #214, so we should finalize the approach of having template projects for XML and Compose UI methods before touching on #214.

Solution

• Instead of having 1 template project for both XML and Compose, then separating the UI method by screens package, we could have 1 separated template project for each. Each template project includes:

  • clean & neat configs for each XML or Compose method only.
  • both data and domain modules; so data and domain modules will be the same for both templates. I think we just need to duplicate the logic for both whenever we have updates on them, we don't need to make any shared config to ease the template scripting action.

• At the end, we will have 3 templates: template-xml, template-compose, template-rxjava. The next task Update init script to have an option to start with either XML layout or Jetpack Compose #214 will need to build the option to select which one to go (actually almost cloning, re-packing, and renaming action 🤷‍♂️ ).

Who Benefits?

Developers

What's Next?

• Separate template project into 2 template projects: XML and Compose.
• Clean up unnecessary components in each project, keep it clean & neat for each one.
• Add more necessary config for each XML or Compose if needed.

[toby-thanathip]

Hmmmm, what if I want to generate a project which has compose + rxjava OR xml + flow ? 💭

[luongvo]

@Tuubz You can clone the missing components & configs in the others to the current one instead. There is the same question:

Why do I need to keep a lot of redundant components and configs in Compose project for nothing? My project can not build with them.

[toby-thanathip]

I like your idea of simplicity, but sadly it still requires some manual work.

What do you think of @manh-t's idea? It looks quite challenging, but I think we can make it work. 🙏

[luongvo]

@Tuubz @manh-t I just checked out your ideas and had a reply here. I think we should consider it carefully between pros & cons for both approaches.

[hoangnguyen92dn]

@luongvo If we separate into 2 templates, it means we have to maintain 2 projects at the same time, when we have a new update on XML (ex: on :data or :domain) then we will need to update on the Compose template as well 🤔 How about we split the UI parts into module 🤔 Then we could reuse from ViewModel -> Repository -> DataSource (:data, :domain)

[toby-thanathip]

@hoangnguyen92dn

Do you mean to have only one template, but to dynamically switch between a ui-xml or a ui-compose module? 🙏

If yes, how will we manage the difference in the configs, tests and nav_graph.xml? 💭

[hoangnguyen92dn]

@Tuubz 🤔 nav_graph.xml should belong to ui-xml, the tests could contain the same package as the main classes. we could share the configs on different modules.

[luongvo]

@hoangnguyen92dn The opposite story as well: it's more convenient when you need to deprecate the xml and just want to maintain the latest compose template.

In addition, when we need to add more features into compose template, but not xml template, we don't need to maintain the existing config like @manh-t's idea. We don't need to add more config to eliminate those new feature updates for xml template. 🤔

[luongvo]

How about we split the UI parts into module 🤔 Then we could reuse from ViewModel -> Repository -> DataSource (:data, :domain)

It could be the next level of optimization. However, please consider it carefully, or we have to maintain the UI part of XML method after deprecating it when we need to bring breaking-changes in the shared data+domain modules.

[luongvo]

@Tuubz I think we could mark this RFC as resolved because we're in action for it?

[luongvo]

@Tuubz again here, please mark this as Resolved 🙏

[toby-thanathip]

@luongvo Done!!

[toby-thanathip]

Issues created: #332 #333 #334 #335 #356