eyeseetea / dhis2-android-sdk Goto Github PK

At least create the following sections:

• Functions:
• Sync methodology:
• Installation/configuration:
• Debug:
• Test:
  • Include how to run the tests
  • Include how to extract DB from a test
• Development methodology:
  • Include little explanation about MockWebServer and Mockito and detail the steps you used to develop the first functionality

A quick login-logout-login test demonstrates that either in the login or the logout process, something's going wrong regarding the downloaded OUs. The first pull downloads both the OU directly assigned to the user and the descendants, while subsequent logins after a logout, only retrieve the directly assigned ones.

When you pull datavalues with a user without the right permissions the response brings an error (403) that it simply catch without any type of notification.

See: (TrackerDataLoader):

                        try {
                        getEventsDataFromServer(dhisApi, organisationUnit.getId(), program.getUid(), serverDateTime);
                        } catch (APIException e) {
                        e.printStackTrace();
                        //todo: could probably do something prettier here. This catch is done to prevent
                        // stopping loading of the following program/orgUnit as throwing and exception would exit the loop..
                        }

Introduce fields:

• code in DataElementFLow
• path in OrganisationUnitExtended

Methods:

• DataValueExtended:
  setProvidedElsewhere Is not necessary?
  getEvent() Is returning null

• EventExtended:
  setFromServer Is not necessary?
  getDataValues() Is returning null.

• ProgramStageExtended
  getProgramStageSections()
  getProgramStageDataElements()

• New ProgramRuleActionType.SENDMESSAGE.
• Its corresponding action class needs to be created in core-rules.
• The class takes only one parameter "notification"
• Apart from that, we need to add control flow statement in RuleEngineExecution.

logout() functionality would be migrated to a wipeDB() function, and logout() would stay just for deleting the AuthorizedUser table

• Reintroduce batch saving
• Reintroduce indexes

• Add new constraints in the migration (add foreign keys in new fields in tables: Program, DataElement and event tables)

Create a branch from the parametrise number of event branch #13

Please

• use TDD for the implementation.
• take note of the implementation made in trackercapture from @tokland, concretely in this PR

• Categories integration tests
• CategoryComboLinkStore tests

Parametrise how many events are downloaded. At the moment 200 events are downloaded (hardcoded number). This should be the value by default.

Try new method to download events proposed by @xurxodev

The SDK is currently downloading just a few parameters for each OrgUnit. We need to add columns in the SDK DB to hold all the OrtUnit parameters that we've actually available in the json answer to the API call

Some optionSets are not saved in the dhis database, for example "akyRgB3QVhB"

Instead of downloading a number of events, modify the sdk be able to download by time (last X months)

• Option Attributes
• OU Attributes
• Program Attributes

See this documentation

This is a fork of sqlbrite, so you probably would need to change the use of sqlbrite as it is now, and replace it by this library, that facilitates the introduction of DB migrations

Done, but needs to be tested

• MAX_EVENTS
• START_DATE
• END_DATE

https://codurance.com/2014/12/13/naming-test-classes-and-methods/

checkControlDigits: not implemented in the web app
https://github.com/dhis2/d2-tracker/blob/master/src/dhis2.angular.services.js#L2380

addControlDigits: implemented in trackercapture web app but not in android app
https://github.com/dhis2/d2-tracker/blob/master/src/dhis2.angular.services.js#L2323

Done but needs to be tested

There is an api call to get the OrgUnit levels. The idea would be to get those OrgUnit levels, combine that information with the downloaded OrgUnits looking at the "ancestors information" of each OrgUnit api call to build the dependencies between levels and build the tree in our DB

Using sqlbrite-migrations or sqlbrite-dao, or any other suggestion that could raise anyone in the team