AC-819 Added repository layer for formAdmission package

[LuGO0]

Description of what I changed

1. Added and fixed violations of repository layer Abstraction
2. converted callback interfaces into kotlin
3. Added default method to default interface to handle extensions gracefully without empty methods
4. renamed custom callbacks for uniformity

Issue I worked on

JIRA Issue: https://issues.openmrs.org/browse/AC-819

Checklist: I completed these to help reviewers :)

• My pull request only contains ONE single commit
  (the number above, next to the 'Commits' tab is 1).

• I have added tests to cover my changes. (If you refactored
  existing code that was well tested you do not have to add tests)

• All new and existing tests passed.

• My pull request is based on the latest changes of the master branch.

[LuGO0]

@f4ww4z Please review !!

[codecov-commenter]

Codecov Report

Merging #784 into master will increase coverage by 0.19%.
The diff coverage is 68.29%.

@@            Coverage Diff             @@
##           master     #784      +/-   ##
==========================================
+ Coverage   13.69%   13.88%   +0.19%     
==========================================
  Files         226      224       -2     
  Lines        9221     9194      -27     
  Branches      887      887              
==========================================
+ Hits         1263     1277      +14     
+ Misses       7861     7817      -44     
- Partials       97      100       +3     

Impacted Files	Coverage Δ
...vities/addeditpatient/AddEditPatientPresenter.java	40.10% <0.00%> (ø)
...openmrs/mobile/api/repository/VisitRepository.java	69.79% <ø> (ø)
...g/openmrs/mobile/utilities/ApplicationConstants.kt	10.00% <ø> (ø)
...nmrs/mobile/api/repository/ProviderRepository.java	35.41% <60.71%> (+9.41%)	⬆️
...tivities/formadmission/FormAdmissionPresenter.java	34.72% <90.90%> (+3.39%)	⬆️
...vities/visitdashboard/VisitDashboardPresenter.java	73.84% <100.00%> (ø)
...java/org/openmrs/mobile/databases/AppDatabase.java	0.00% <0.00%> (ø)
...rg/openmrs/mobile/databases/AppDatabaseHelper.java	0.00% <0.00%> (ø)
...ies/patientdashboard/PatientDashboardActivity.java	0.00% <0.00%> (ø)
...tientdashboard/details/PatientDetailsFragment.java	0.00% <0.00%> (ø)
... and 5 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 92dc444...e585cbd. Read the comment docs.

[rishabh-997]

can you rebase your branch with master and see if the PR passes the continuous-integration test as this fails in the latest commit at 0cdbaea . if not, then we might need a fix for that

[LuGO0]

@rishabh-997 actually I rebased with master before making a PR will check again!!

[f4ww4z]

@LuGO0 Good work, please address my comments.

[f4ww4z]

Rename the file and class to EncounterResponseCallback . Also start using Kotlin, convert this file to Kotlin please.

[f4ww4z]

This should also extend from DefaultResponseCallbackListener

[LuGO0]

@f4ww4z will it be possible to do I think we wont be able to override methods with different signatures if we extend from DefaultResponseCallbackListener, maybe I couldnt get it can you explain?

[f4ww4z]

@LuGO0 You just need to extend from the default callback so the onErrorMessage is consistent for all callbacks, and onResponse can be customized. Try this:

interface EncounterResponseCallback: DefaultResponseCallbackListener {
    fun onResponse(encounterRoleList: List<Resource?>?)
}

[f4ww4z]

Then there would be 2 onResponse's to implement, just leave the default empty-parameter one empty for now.

    public void getLocation(String url) {
        providerRepository.getLocation(restApi, url, new LocationResponseCallback() {
            @Override
            public void onResponse(List<LocationEntity> locationList) {
                view.updateLocationAdapter(locationList);
            }

            @Override
            public void onResponse() {

            }

            @Override
            public void onErrorResponse(String errorMessage) {
                view.showToast(errorMessage);
                view.enableSubmitButton(false);
            }
        });
    }

[f4ww4z]

We could theoretically use this way instead, then it would also mean we don't need to write the custom callbacks, the default callback with class type parameter is enough. Thoughts @LuGO0 ?

[LuGO0]

@f4ww4z if I am getting you correctly, then should I declare the interface methods in default callback listener as default so that when we override it there wont be any empty method like the onResponse above ??
I am doing this locally for now, just confirm this for me and I will push in the final changes 👍 .

[f4ww4z]

We could theoretically use this way instead, then it would also mean we don't need to write the custom callbacks, the default callback with class type parameter is enough. Thoughts @LuGO0 ?

@LuGO0 This is for the near future, we can refactor later. Right now it's ok to just inherit from the default callback and make a custom onResponse for each interface, according to what resource want to get.

[f4ww4z]

@LuGO0 See my comments and take care of the merge conflict.

[LuGO0]

@f4ww4z the build fails but I think its because some dependency repo returns error code 503 and maybe is down can you see and confirm for me.
build works fine for me offline though.

[f4ww4z]

@LuGO0 Clever use of the default keyword. LGTM