diff --git a/scripts/assets/todo_open_exemptions.textproto b/scripts/assets/todo_open_exemptions.textproto index 187cb76308c..0fa81fd297d 100644 --- a/scripts/assets/todo_open_exemptions.textproto +++ b/scripts/assets/todo_open_exemptions.textproto @@ -294,16 +294,16 @@ todo_open_exemption { todo_open_exemption { exempted_file_path: "wiki/Static-Analysis-Checks.md" - line_number: 169 - line_number: 177 - line_number: 182 - line_number: 186 - line_number: 190 - line_number: 192 - line_number: 207 - line_number: 217 - line_number: 220 - line_number: 223 - line_number: 226 - line_number: 229 + line_number: 170 + line_number: 178 + line_number: 183 + line_number: 187 + line_number: 191 + line_number: 193 + line_number: 208 + line_number: 218 + line_number: 221 + line_number: 224 + line_number: 227 + line_number: 230 } diff --git a/wiki/Overview-of-the-Oppia-Android-codebase-and-architecture.md b/wiki/Overview-of-the-Oppia-Android-codebase-and-architecture.md index 692e243066a..31c790b5aca 100644 --- a/wiki/Overview-of-the-Oppia-Android-codebase-and-architecture.md +++ b/wiki/Overview-of-the-Oppia-Android-codebase-and-architecture.md @@ -152,33 +152,33 @@ Following these steps would lead to completing the entire task with all the code **Task:** -Finding code from a string ( e g., topic description under topic info tab) that you see in UI when running the app all the way to the UI components, domain controllers and the tests ultimately behind that text appearing. +Finding code from a string ( e g., story name under lessons tab) that you see in UI when running the app all the way to the UI components, domain controllers and the tests ultimately behind that text appearing. -example 2 task image +example 2 task image **Walkthrough:** -**Finding the UI component (topic description)** +**Finding the UI component (story name)** 1. The first step is to identify the id of the UI component that is responsible for displaying the text. We can do this by using the layout inspector of the android studio. -2. To do this, run the app on an emulator. Now navigate to the screen that displays the UI component, i.e. the topic info tab. +2. To do this, run the app on an emulator. Now navigate to the screen that displays the UI component, i.e. the lessons tab. -3. Next, open the layout inspector from the android studio, and click on the UI component displaying the topic description. Now all the attributes of this UI component are displayed on the right side of the layout inspector. Here, you can see this UI component's id, i.e. topic_description text_view. +3. Next, open the layout inspector from the android studio, and click on the UI component displaying the story name. Now all the attributes of this UI component are displayed on the right side of the layout inspector. Here, you can see this UI component's id, i.e. story_name_text_view. -example 2 layout inspector screenshot +example 2 layout inspector screenshot -4. Now we have to find the file with a UI component with this id. We can do this by pressing double shift and then typing the id. Doing this, we see the id is the id of a text view present in the file topic_info_fragment.xml. +4. Now we have to find the file with a UI component with this id. We can do this by pressing double shift and then typing the id. Doing this, we see the id is the id of a text view present in the file topic_lessons_story_summary.xml. -5. Now that we know that the text view is present in topic_info_fragment.xml, according to the app architecture, we know that the name of this fragment is TopicInfoFragment. The files responsible for displaying this fragment are TopicInfoFragment.kt and TopicInfoFragmentPresenter.kt. +5. Now that we know that the text view is present in topic_lessons_story_summary.xml, according to the app architecture, we know that the name of this fragment is TopicLessonsFragment. The files responsible for displaying this fragment are TopicLessonsFragment.kt and TopicLessonsFragmentPresenter.kt. -6. Looking at the XML code for topic_description_text_view, we can see that TopicInfoViewModel sets the text in the text view using databinding. +6. Looking at the XML code for story_name_text_view, we can see that StorySummaryViewModel sets the text in the text view using databinding. **Finding the business logic for the UI component, i.e. domain controllers** -1. Following the app architecture used by Oppia, TopicInfoViewModel should be initialized in the TopicInfoFragmentPresenter. +1. Following the app architecture used by Oppia, StorySummaryViewModel should be initialized in the TopicLessonsFragmentPresenter. -2. Here we can see that the topic description is being updated in the viewModel by the TopicController. Therefore the business logic for getting the topic description will be present in the file TopicController. +2. Here we can see that the story name is being updated in the viewModel by the TranslationController. Therefore the business logic for getting the story name will be present in the file TranslationController. **Finding the tests** @@ -186,9 +186,9 @@ There are two sets of tests: - Tests to test the UI component - Tests to test the business logic of the UI component -Since the UI component is present in the TopicInfoFramgnet, the UI component tests are present in the file TopicInfoFragmentTest. +Since the UI component is present in the TopicLessonsFragment, the UI component tests are present in the file TopicLessonsFragmentTest. -Similarly, since the business logic is present in the file TopicController, the tests for this controller can be found in the file TopicControllerTest. +Similarly, since the business logic is present in the file TranslationController, the tests for this controller can be found in the file TranslationControllerTest. ## Dependency Injection diff --git a/wiki/Static-Analysis-Checks.md b/wiki/Static-Analysis-Checks.md index 5b82308601d..75acc335fba 100644 --- a/wiki/Static-Analysis-Checks.md +++ b/wiki/Static-Analysis-Checks.md @@ -11,6 +11,7 @@ - [KDoc validity check](#kdoc-validity-check) - [TODO open checks](#todo-open-checks) - [TODO issue resolved check](#todo-issue-resolved-check) + - [How to run static checks locally](#how-to-run-static-checks-locally) # Background Static analysis is a method of debugging by examining source code before a program is run. It’s done by analyzing a set of code against a set (or multiple sets) of coding rules. @@ -227,3 +228,11 @@ To fix the failures for this check: resolve the TODO items and then close the is # How to add a new Static analysis check // TODO([#3690](https://github.com/oppia/oppia-android/issues/3690)): Complete static checks Wiki + +# How to run static checks locally + +- Go to the failing CI check in your GitHub PR. +- Scroll to the top of the failing CI check logs, and find the Bazel command that was run for this script. +- Alternatively, in Android Studio, go to the `.github` folder and find the [static_checks.yml](https://github.com/oppia/oppia-android/blob/develop/.github/workflows/static_checks.yml) file. Search for the line that corresponds to the name of the job that failed. You can then run the same script on your local terminal. + +Note: Before running the script command in your local terminal, make sure you have Bazel installed. To learn how to set up Bazel for Oppia Android, follow these [instructions](https://github.com/oppia/oppia-android/wiki/Oppia-Bazel-Setup-Instructions).