42 lines
3.1 KiB
Markdown
42 lines
3.1 KiB
Markdown
## 1. Project health \& build validation
|
|
|
|
Before performing any analysis, you must confirm the project is in a functional state.
|
|
\* **Integrity check:** Verify the project syncs (Gradle) and builds successfully.
|
|
\* **Error resolution:** If there are pre-existing build errors or sync failures, you must report these immediately and attempt to fix. **Do not proceed** with migration until a stable baseline is established.
|
|
|
|
## 2. Compose pattern \& consistency analysis
|
|
|
|
If Jetpack Compose is already present, you must align with the established implementation style.
|
|
\* **Pattern identification:** Scan the codebase for `@Composable` functions. Identify the project's "Best Practices" regarding state hoisting, composable construction and naming conventions, and file organization.
|
|
\* **Theming review:** Determine how `MaterialTheme` or custom theme systems are implemented.
|
|
\* Identify if the project uses a custom design system theme.
|
|
\* Map how attributes, styles, and other theme components are accessed in Compose.
|
|
|
|
## 3. Design system \& infrastructure audit
|
|
|
|
Understand the design system classification (e.g. Material 2, Material 3, or custom design system).
|
|
\* **Resource mapping:** Locate central XML definitions:
|
|
\* `colors.xml` (Light/Dark variants)
|
|
\* `dimens.xml`
|
|
\* `styles.xml` / `themes.xml`
|
|
\* **Hybrid analysis:** Determine if the project is **XML-only** , **Compose-only** , or **Hybrid** .
|
|
\* **Reuse constraint:** If a Compose theming layer (e.g., `AppTheme.kt`) already exists, **DO NOT** generate a new one. You must reuse the existing infrastructure and contribute to it by following its existing implementation pattern.
|
|
|
|
## 4. Candidate layout decomposition
|
|
|
|
Analyze the specific XML layout targeted for migration. You must extract and document the following requirements for the new composable:
|
|
\* **Inputs:** UI State objects, primitive parameters, and click listeners.
|
|
\* **Styling:** Specific color constants, typography styles, and shape definitions referenced in the XML.
|
|
\* **Resources:** Identifying string resources, drawables, and dimensions.
|
|
\* **Layout logic:** Modifiers required to replicate the XML constraints (padding, alignment, weight).
|
|
|
|
## 5. Architectural \& non-UI analysis
|
|
|
|
Understand the environment in which the UI resides to ensure proper integration.
|
|
\* **State management:** Identify the usage of `ViewModel`, `Flow`, or `LiveData`.
|
|
\* **Dependency Injection:** Check for Hilt, Koin, or manual DI to understand how dependencies are provided to the UI layer.
|
|
\* **Testing \& architecture:** Note the architectural pattern (MVI, MVVM, or custom architecture setup.) and existing UI testing frameworks to ensure the migrated code remains testable. Unless the user explicitly requests, **DO NOT** make any changes to any non-UI code that aren't strictly required for the migration of the XML View.
|
|
|
|
*** ** * ** ***
|
|
|
|
> **Pro-tip:** Always prioritize the "Existing infrastructure" over "Default templates." If the project has a custom way of handling spacing or colors, composable code, or any other project layer, your generated Compose code must reflect that specific implementation. |