Fix #535,Fix part of #530: Material bridge theme and card-view issue fix approach -2

[nikitamarysolomanpvt]

Explanation

To use Material Components, we need to either use a Theme.MaterialComponents.* theme or a Theme.MaterialComponents.*.Bridge theme.

See here for more info on migrating to a MaterialComponents theme (recommended) - https://github.com/material-components/material-components-android/blob/master/docs/getting-started.md#4-change-your-app-theme-to-inherit-from-a-material-components-theme

See here for more info on Bridge themes if you don't want to migrate from your current AppCompat theme - https://github.com/material-components/material-components-android/blob/master/docs/getting-started.md#bridge-themes

Additionally, we don't need to add two dependencies for Material in your :app module's build.gradle file. Below are the latest stable, beta and alpha versions of the library. Should use a single version, depending on the features vs. stability our app needs.
So i removed com.google.android.material:material:1.0.0 and used alpha.

stable: com.google.android.material:material:1.0.0
beta: com.google.android.material:material:1.1.0-beta02
alpha: com.google.android.material:material:1.2.0-alpha02
Card corner white spacing fixed for all API

Oppia Android API 19 4.4.2 (Kitkat) UI issues.

Chapter List (Mathew goes..)

• Material Cards UI issues

• Drop shadow

• Card borders

Review

• Material Cards UI issues

• Drop shadow

• Card borders

Checklist

• The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
• The PR follows the style guide.
• The PR does not contain any unnecessary auto-generated code from Android Studio.
• The PR is made from a branch that's not called "develop".
• The PR is made from a branch that is up-to-date with "develop".
• The PR's branch is based on "develop" and not on any other branch.
• The PR is assigned to an appropriate reviewer in both the Assignees and the Reviewers sections.

[rt4914]

This and #536 looks good to me. The only thing which remain now is to decide which approach we are finalising out of the two.

[veena14cs]

LGTM.

[BenHenning]

Between this and #536, can you summarize which of the two we prefer and why?

[nikitamarysolomanpvt]

Between this and #536, can you summarize which of the two we prefer and why?

@BenHenning If we don't want to migrate from our current AppCompat theme we may go with bridge themes as we may continue using our style in buttons and other widgets whereas in required widgets like card-view we may access material-component theme(Later on we may migrate to MaterialComponents theme). More than this, migrating to a MaterialComponents theme demands through testing/fixing to make sure our current UI is working as expected, If we have enough time to invest on this then only we may go ahead with MaterialComponents theme.

[BenHenning]

I think we should go with the solution that doesn’t require material theme for now, and file an issue to migrate to it. I’ve had to do that on another app and it can be challenging and is definitely time consuming. I’m also not sure it will work in our benefit everywhere since the material components are aiming for GM2 styling, and our mocks are current based on GM1.

[nikitamarysolomanpvt]

GM1.

@BenHenning So you want me not use bridge also ... or we may use AppCompat through bridge?
If we are using only AppCompat then the material cardviews have issues .... So you want me as if now just to raise an issue regarding card-view issue?

[BenHenning]

Sorry I wasn’t clear—if using the bridge doesn’t cause issues, then that’s fine. My only concern is that cherrypicking material component pieced may have unintended side effects. That’s probably fine as long as there aren’t major inconsistencies with other elements in the app.

[rt4914]

Sorry I wasn’t clear—if using the bridge doesn’t cause issues, then that’s fine. My only concern is that cherrypicking material component pieced may have unintended side effects. That’s probably fine as long as there aren’t major inconsistencies with other elements in the app.

@nikitamarysolomanpvt I think what @BenHenning means here is that its fine even if you use bridge as long as its doesn't create any issues. Also, he was earlier suggesting you not to use this just because of the point that it is not a suggested to use only the specific components of material component and avoid others in which case there can be side effects.

[nikitamarysolomanpvt]

Sorry I wasn’t clear—if using the bridge doesn’t cause issues, then that’s fine. My only concern is that cherrypicking material component pieced may have unintended side effects. That’s probably fine as long as there aren’t major inconsistencies with other elements in the app.

@nikitamarysolomanpvt I think what @BenHenning means here is that its fine even if you use bridge as long as its doesn't create any issues. Also, he was earlier suggesting you not to use this just because of the point that it is not a suggested to use only the specific components of material component and avoid others in which case there can be side effects.

@rt4914 I was asking your opinion on going ahead with bridge theme because I am not so sure what to reply to ben. As per our discussion ...
@BenHenning As far as I had gone through the app I didn’t find any inconsistencies, So could you please review this PR.

[BenHenning]

Per our discussion during a recent team meeting, we'll be going forward with the bridge theme since that will make it easier to move to Google Material 2 style & components.

[nikitamarysolomanpvt]

Per our discussion during a recent team meeting, we'll be going forward with the bridge theme since that will make it easier to move to Google Material 2 style & components.

Okay