Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MissingDefaultResource + AppCompatCustomView + FragmentTagUsage #5186

Open
Tracked by #5169
adhiamboperes opened this issue Oct 12, 2023 · 10 comments · Fixed by #5191 · May be fixed by #5582
Open
Tracked by #5169

MissingDefaultResource + AppCompatCustomView + FragmentTagUsage #5186

adhiamboperes opened this issue Oct 12, 2023 · 10 comments · Fixed by #5191 · May be fixed by #5582
Assignees
Labels
bug End user-perceivable behaviors which are not desirable. good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). Work: Low Solution is clear and broken into good-first-issue-sized chunks.

Comments

@adhiamboperes
Copy link
Collaborator

adhiamboperes commented Oct 12, 2023

Description

We would like to fix all the remaining lint issues on Oppia Android in the "MissingDefaultResource + AppCompatCustomView + FragmentTagUsage" category.

Steps To Reproduce

Run the following command from a terminal in a checked-out Oppia Android repo:

./gradlew :app:lint

Output:

  • MissingDefaultResource mainly has a single issue with a string which has different names in english and other translations. It can be easily fixed, by matching the name of that string in english and other translations.
  • For AppCompatCustomView, it can be fixed by replacing the Normal views with AppCompat views
  • tags can be replaced with <androidx.fragment.app.FragmentContainerView/>.

Expected Behavior

Running the command above should not show any errors.

@theMr17 theMr17 added good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). bug End user-perceivable behaviors which are not desirable. Work: Low Solution is clear and broken into good-first-issue-sized chunks. labels Oct 13, 2023
@theMr17 theMr17 self-assigned this Oct 13, 2023
@sichchurov
Copy link
Collaborator

sichchurov commented Oct 15, 2023

./gradlew :app:lint
This command is always finished with failed

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.8/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 6m 38s
155 actionable tasks: 11 executed, 144 up-to-date

@adhiamboperes I have resolved the FragmentTagUsage issue
here is a lint report screenshot before
Fragment-Tag-Usage-before.png

and after
Fragment-Tag-Usage-after.png

@theMr17
Copy link
Collaborator

theMr17 commented Oct 16, 2023

Hi @sichchurov, Please look into those issues which are not assigned to anyone.

adhiamboperes added a commit that referenced this issue Dec 5, 2023
…gUsage (#5191)

<!-- READ ME FIRST: Please fill in the explanation section below and
check off every point from the Essential Checklist! -->
## Explanation
<!--
- Explain what your PR does. If this PR fixes an existing bug, please
include
- "Fixes #bugnum:" in the explanation so that GitHub can auto-close the
issue
  - when this PR is merged.
  -->

Fixes #5186 [part of #5169]

1. `MissingDefaultResource` has been fixed already by
#5172. It had issues with
these plurals:
-
[minutes_ago](https://github.com/oppia/oppia-android/blob/e060e2ff265ce35c92f1b969f6d7ad002d1a62ad/app/src/main/res/values/strings.xml#L456)
-
[hours_ago](https://github.com/oppia/oppia-android/blob/e060e2ff265ce35c92f1b969f6d7ad002d1a62ad/app/src/main/res/values/strings.xml#L461C18-L461C27)
-
[days_ago](https://github.com/oppia/oppia-android/blob/e060e2ff265ce35c92f1b969f6d7ad002d1a62ad/app/src/main/res/values/strings.xml#L465C18-L465C26)

3. For `AppCompatCustomView`, it is fixed by replacing the Normal views
with AppCompat views

4. `<fragment/>` tags are replaced with
`<androidx.fragment.app.FragmentContainerView/>`, with some changes in
the NavigationDrawerFragment to ensure that binding has been initialized
before it is accessed.

## Screen Recording

https://github.com/oppia/oppia-android/assets/84731134/3a340cff-70a4-4e77-a1a3-e5b7a8c71a6e



## Essential Checklist
<!-- Please tick the relevant boxes by putting an "x" in them. -->
- [x] The PR title and explanation each start with "Fix #bugnum: " (If
this PR fixes part of an issue, prefix the title with "Fix part of
#bugnum: ...".)
- [x] Any changes to
[scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets)
files have their rationale included in the PR explanation.
- [x] The PR follows the [style
guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide).
- [x] The PR does not contain any unnecessary code changes from Android
Studio
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)).
- [x] The PR is made from a branch that's **not** called "develop" and
is up-to-date with "develop".
- [x] The PR is **assigned** to the appropriate reviewers
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)).
<br>

---------

Co-authored-by: Adhiambo Peres <[email protected]>
adhiamboperes added a commit that referenced this issue Dec 23, 2023
BenHenning pushed a commit that referenced this issue Dec 23, 2023
…omView + FragmentTagUsage" (#5287)

Fix #5284: Reverts #5191. See issue for details.

This should be a clean revert.
BenHenning pushed a commit that referenced this issue Dec 23, 2023
…omView + FragmentTagUsage" (#5287)

Fix #5284: Reverts #5191. See issue for details.

This should be a clean revert.
@BenHenning
Copy link
Member

#5191 was reverted, so this is no longer fixed.

@M-e-h-u-l-21
Copy link

@BenHenning ./gradlew :app:lint , this command always resulted in errors.
I've fixed the AppCompatCustomView and FragmentTagUsage issues.
This is the lint report after fixing the mentioned issues:
image

@theMr17
Copy link
Collaborator

theMr17 commented Jan 28, 2024

Unassigning myself, as this can be a good first issue for new contributors.

@theMr17 theMr17 removed their assignment Jan 28, 2024
@tobioyelekan
Copy link

tobioyelekan commented Nov 13, 2024

Hi @adhiamboperes new contributor here, can I pick this up?

@adhiamboperes
Copy link
Collaborator Author

adhiamboperes commented Nov 15, 2024

Hi @adhiamboperes new contributor here, can I pick this up?

Hi, what's your proposed solution for this issue? Please refer to the issue thread for previously proposed solutions, and note that we had to revert a PR solving this due to some crashes.

@tobioyelekan
Copy link

Hi @adhiamboperes

  • For AppCompatCustomView -> I replaced it with AppCompat Views

  • For FragmentTagUsage, I followed a similar approach to the previous solution, but I used onViewCreated to setup the drawer, which is guaranteed to be called after the binding is initialized in onCreateView().

    More details:
    I also placed a breakpoint to ensure the desired order:
    onAttach()->setupDrawer()->onCreateView()->onViewCreated()

Screenshot 2024-11-19 at 1 25 07 AM

This solution worked, but I noticed an issue when I minimized and returned to the app, the drawer stopped working, which I believe is because when handleOnRestart() is called, it re-initializes the drawer fragment and calls setUpDrawer() again. At this point, I believe the fragment is not recreated thereby not calling onCreate() and onViewCreated(), I believe this should be set once, and will be called again when the activity is destroyed. I temporarily removed the handleOnRestart() and everything seems to be working fine.

Please let me know what you think, I look forward to your response @adhiamboperes

@adhiamboperes
Copy link
Collaborator Author

@tobioyelekan, please feel free to create a PR for this. At the same time, does removing thehandleOnRestart() call remove any required re-initializations? Please ensure that the app works the same way before and after the fix.

@tobioyelekan
Copy link

@adhiamboperes so far, there's no additional re-initializations, PR ready for review #5582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug End user-perceivable behaviors which are not desirable. good first issue This item is good for new contributors to make their pull request. Impact: Low Low perceived user impact (e.g. edge cases). Work: Low Solution is clear and broken into good-first-issue-sized chunks.
6 participants