Fix part of #42: Exploration player base (Part 1) #42

[rt4914]

Explanation

This PR contains basic activities/fragment structure for exploration player. Currently the controllers are not functional which will be covered in subsequent PRs. Also this PR also contains one class for FakeDataProvider, this class is for couple of PRs only and later on it can be removed once domain / model layers are finished

Project structure:

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 assigned to an appropriate reviewer.

[rt4914]

@veena14cs @nikitamarysolomanpvt @BenHenning PTAL.

Also, @veena14cs @nikitamarysolomanpvt use this branch as base branch for your subsequent work on exploration-player.

[BenHenning]

Thanks @rt4914! Generally LGTM, but I had one concern around the fake data. Other than that, can you also add the initial tests for the exploration activity so that we have a place to add more as the activity grows? At some point, we need to figure out how to divide activity and fragment specific tests, but for now we can just keep UI tests activity-specific.

[BenHenning]

I actually think we should be faking data at a higher level than this (e.g. in domain logic controllers). We should spec out those interfaces and submit them with stubs that return structured fake data, then directly rely on those for the UI.

What fake data do we need for this PR? Can we just check in the structure and hook up to domain controllers in a subsequent PR?

[rt4914]

Actually, I created this file but we are not using it anywhere, so we can remove this right now.

But still there is one issue, we will be using models which are present in data module like GaeSubtitledHtml GaeState etc. in subsequent PRs and as far as I understand the Technical Document, we should not be interacting directly with data module from app module. So for that case I think domain module will need something similar to models defined in data module.

Any comments or suggestions on this?

[BenHenning]

If this is for testing purposes, we can use the mock GAE services directly in tests to influence the data returned by domain controllers. We can extend those services to actually set up state rather than returning the same fixed data.

If this isn't for tests, app code does not need to rely on GaeSubtitledHtml, etc. since it will receive data via the domain layer defined in the model module (see how topic list data is piped in #106).

Does this help clarify?

[rt4914]

Made changes related to all the files. (Test cases are pending)

[BenHenning]

Thanks @rt4914! This LGTM. Once my last few comments are resolved, feel free to submit.

[BenHenning]

If this is for testing purposes, we can use the mock GAE services directly in tests to influence the data returned by domain controllers. We can extend those services to actually set up state rather than returning the same fixed data.

If this isn't for tests, app code does not need to rely on GaeSubtitledHtml, etc. since it will receive data via the domain layer defined in the model module (see how topic list data is piped in #106).

Does this help clarify?

[nikitamarysolomanpvt]

LGTM

[rt4914]

@BenHenning Check the error related to test cases.

[BenHenning]

Ack, will follow up with a fix. Thanks for pointing this out.

[BenHenning]

#131 is now out for review, so sending this back to you to merge once ready.

[rt4914]

This PR can be merged now and everything has been clarified in respective comments.

[rt4914]

#131 is now out for review, so sending this back to you to merge once ready.

Merging this code now.