-
Notifications
You must be signed in to change notification settings - Fork 551
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
Fix #22: Introduce navigation drawer #84
Fix #22: Introduce navigation drawer #84
Conversation
https://docs.google.com/document/d/1Q9957ri3TlsTWdwBVAjn4g9EJzqmzBqrSXCHI3yRTEE/edit?usp=sharing #logout svg and profile image place holder pending
https://docs.google.com/document/d/1Q9957ri3TlsTWdwBVAjn4g9EJzqmzBqrSXCHI3yRTEE/edit?usp=sharing #logout svg and profile image place holder pending
@nikitamarysolomanpvt I'm assuming this is ready for review? If so please make sure to assign a reviewer on GitHub so that they know that they need to look at it. (And, if not, please explain that clearly in your PR description as well as a full list of "what is left to do" before the PR can be reviewed.) Thanks! |
@nikitamarysolomanpvt it appears your base branch is oppia:develop, but we want to merge into oppia-android:develop. Please update the PR base and rebase your branch, if needed. Regarding the changes, please split this up. We should first check in the navigation drawer with one specific item, and be sure that we like how that solution looks before replicating it for other pages. Can you also add screenshots to this PR for what this navigation drawer looks like in the app? That will better help contextualize the code for reviewers. Regarding the design doc, please aim to have the design doc reviewed and signed off by someone on the team before creating your PR. That helps provide team members with time to comment on your approach before all of the code is written. This is meant to help save you time as well, since ideally design docs should be written with little code to get early feedback on your approach rather than duplicating the work of the pull request. |
@BenHenning even though it is showing oppia:develop on click of it it is taking us to oppia-android:develop not able to find why is it showing oppia:develop .Please find the screenshot of the developed navigation drawer. |
Since this is actually the navigation drawer, I updated the title accordingly. This may actually fully fix #22--it's not yet clear to me. |
Thanks @nikitamarysolomanpvt, I'm not sure why the base branch is shown differently here but it appears to be the correct branch. Edit: Ah, I think it's actually because you forked oppia-android, and it's shortening the repository names to project:branch rather than project/repo:branch. |
…ies , ParentActivity for redusing boilerplates , On menu item clicks open corresponding activities(not fragments)on the basis of selected ids. animation for activity transitions
…ies , ParentActivity for redusing boilerplates , On menu item clicks open corresponding activities(not fragments)on the basis of selected ids. animation for activity transitions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please address some comments and assign it back.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@nikitamarysolomanpvt Please check these comments |
…m/oppia/oppia-android into navigation-drawer # Conflicts: # app/src/main/AndroidManifest.xml # app/src/main/java/org/oppia/app/activity/ActivityComponent.kt # app/src/main/java/org/oppia/app/fragment/FragmentComponent.kt # app/src/main/java/org/oppia/app/home/HomeActivity.kt
I think we can assign it to @BenHenning now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nikitamarysolomanpvt! Overall this looks really good to me. I have a few suggestions around readability and maintainability, but they are effectively nits.
|
||
/** Tests for [NavigationDrawerTestActivity]. */ | ||
@RunWith(AndroidJUnit4::class) | ||
class NavigationDrawerTestActivityTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the prod activities don’t support landscape currently, can you also add config change tests to make sure the desired behavior happens? Eg that the drawer works correctly in landscape for at least one test scenario, and that rotating closes the drawer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BenHenning Added test cases for landscape mode test.
Opened drawer stays open on orientation change, rotating dose not closes the drawer ... do you want me to change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Let’s keep that behavior. Despite my earlier comment, I don’t have a compelling reason for closing the drawer on config changes. I can see either scenario as being okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. just one nit change suggested.
Explanation
Fragment Navigation drawer
as per design document
https://docs.google.com/document/d/1Q9957ri3TlsTWdwBVAjn4g9EJzqmzBqrSXCHI3yRTEE/edit?usp=sharing
make NavigationDrawerTestActivity as launcher activity in Manifest file for checking test-cases.
Mock
https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/346dd03d-464b-4b49-9d7f-7ec6264fefd6/TP-Play-Side-Menu-1
Checklist