dhis2 / dhis2-android-sdk Goto Github PK

Implement functionality for registering of Tracked Entity Instances

Some layouts and strings, colors etc are not in use due to migrations. Remove those that have been replaced and are now redundant.

Usually, lists of TEI or Events or other data value items are listening to a ModelChangeObserver, that is triggered by a save(), update(), or delete() call to registered data models.

When registering Events, Enrollments, or TEIs, we rather call a manual Update() query to set the received reference UID. When that happens, the ModelChangeObserver isn't triggered, and the items in whatever list they are in aren't updating. This might give the impression that something is Offline, while it actually was just sent to the server.

The new DBFlow release brings a lot of exciting functionality but a migration effort is needed

Common database for apps. Placeholder.

If the autosync is already activated it should not trigger on app startup, but rather continue waiting for its scheduled time. This is to reduce unnecessary data and battery use.

As of now, only the Hide field and Hide section program rule actions are supported in the DataEntryFragment. Implement Show warning and show error support.

If option set values is set to the wrong input type on the server, the Android client won't be able to post the value through the API. Should give warning or other feedback to user

Right now all fields in models are private. DbFlow knows how to handle those fields by discovering them through getters/setters combination. Recently, I have noticed that this mechanism does not work for all fields in models. Some of them are not recognized for unknown reason (It seems to be DbFlow issue), for example shortName in DataElement.

In order to solve it, I propose to make model fields to be package private. It means DbFlow will be able to recognize them easily (without using getters/setters combo), and at the same time, the fields won't be accessible directly through object properties outside of the models package.

Also, it will be good to explicitly specify column names like: @column(name = "shortName"). In future, it can save us time if we will decide to change field name without making database migrations.

Hello,

I am migrating the DB to a newer version (kudos for making the migration process easy) and I wish to drop a few columns which are no longer necessary. I've looked around but couldn't find any reference, is this possible?

Thank you!

Needs implementation back end, and in EventDataEntryFragment

When a TrackedEntityInstance is registered with server, the client receives a UID reference from server and updates locally, and it updates all enrollments/events that are referencing it.

Due to the transactional nature of saving data to persistence, these changes are not reflected when the synchronizer immediately after tries to send to server. This is because the synchronizer sends data in the following order:

1. Send all TEI
2. Send all Enrollments (that have a reference to a valid server UID TEI)
3. Send all Events (that are SingleEventWithoutRegistration or has valid UID references from server)

The problem is not consistency however, as the items with an old reference do get updated and will get sent on the next round of synchronization. The problem is rather that if the update frequency is very low (1 Day for example), it will take 3 days before Events are sent to the server, if they were originally registered with a TEI that was also created locally.

The users shouldn't have to remember and type in the server URL and username every time they log in.

Suggestion is to remember these two values and have them auto populate the fields, with the server URL field locked for editing until the user clicks a special edit icon in the field. This is to avoid the users from editing the server url by mistake as they normally should use the same URL and shouldn't need to remember this. If the username field should be locked in the same way is up for discussion.

Related to issue #18 as logging out is not very convenient currently when the database is wiped.

Hi, I am trying to integrate the SDK into an app. This is how my settings.gradle looks like

include ':app', ':sdk', ':core', ':persistence', ':core-java', ':models'
project(':sdk').projectDir = new File(settingsDir, '../dhis2-android-sdk-master/app')
project(':core').projectDir = new File(settingsDir, '../dhis2-android-sdk-master/core')
project(':persistence').projectDir = new File(settingsDir, '../dhis2-android-sdk-master/persistence')
project(':core-java').projectDir = new File(settingsDir, '../dhis2-android-sdk-master/core-java')
project(':models').projectDir = new File(settingsDir, '../dhis2-android-sdk-master/models')

My build.gradle for my app module looks like

apply plugin: 'com.android.application'

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"

    defaultConfig {
        applicationId "emmunify.com.emmunify"
        minSdkVersion 15
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    packagingOptions {
        // gradle requires to exclude these files both
        // with .txt extension and without.
        exclude 'META-INF/NOTICE.txt'
        exclude 'META-INF/LICENSE.txt'

        // without .txt
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/LICENSE'

        // gradle requires to exclude these files both
        // with .txt extension and without.
        exclude 'META-INF/notice.txt'
        exclude 'META-INF/license.txt'

        // without .txt
        exclude 'META-INF/notice'
        exclude 'META-INF/license'
    }
}

dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    testCompile 'junit:junit:4.12'
    compile 'com.parse.bolts:bolts-tasks:1.3.0'
    compile 'com.parse:parse-android:1.11.0'
    compile 'joda-time:joda-time:2.9.1'
    compile project(':sdk')
    compile project(':core')
    compile 'com.android.support:appcompat-v7:23.0.0'
}

and my build.gradle for my project looks like

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.3.0'
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
        maven { url "https://jitpack.io" }
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

ext {
    // SDK version.
    versionCode = 1
    versionName = "1.0"

    // Compilation configuration.
    minSdkVersion = 15
    compileSdkVersion = 23
    targetSdkVersion = 23
    buildToolsVersion = "23.0.2"
}

Now when I try to run my app it gives me the following build error

UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.RuntimeException: Exception parsing classes
    at com.android.dx.command.dexer.Main.processClass(Main.java:752)
    at com.android.dx.command.dexer.Main.processFileBytes(Main.java:718)
    at com.android.dx.command.dexer.Main.access$1200(Main.java:85)
    at com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1645)
    at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
    at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
    at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
    at com.android.dx.command.dexer.Main.processOne(Main.java:672)
    at com.android.dx.command.dexer.Main.processAllFiles(Main.java:574)
    at com.android.dx.command.dexer.Main.runMonoDex(Main.java:311)
    at com.android.dx.command.dexer.Main.run(Main.java:277)
    at com.android.dx.command.dexer.Main.main(Main.java:245)
    at com.android.dx.command.Main.main(Main.java:106)
Caused by: com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
    at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
    at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
    at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
    at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
    at com.android.dx.command.dexer.Main.parseClass(Main.java:764)
    at com.android.dx.command.dexer.Main.access$1500(Main.java:85)
    at com.android.dx.command.dexer.Main$ClassParserTask.call(Main.java:1684)
    at com.android.dx.command.dexer.Main.processClass(Main.java:749)
    ... 12 more
1 error; aborting
Error:Execution failed for task ':app:preDexDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Java\jdk1.8.0_65\bin\java.exe'' finished with non-zero exit value 1

Can somebody guide as to what I am doing wrong?

should give information on last sync, status (success, fail, why etc .. )

Implement programstagesections support. Needs to be loaded from server and stored locally.

To support translations for the user setting, the DisplayName needs to be included in all data requests.

Implement functionality for registering Tracked Entity Attribute values for when enrolling new enrollment
Do this in the webapi by sending attributes[] with enrollment

If user has modified data on device and someone else has modified data on server, the data on the device may get overwritten depending on race conditions with synchronization.

Sometimes if the user has insufficient priviledges, or there simply aren't any metadata items for something, the server will return "{ }". In some cases this isn't handled, and causes the loading to stop in Retry forever.

Fix is to check if node is null in the response callback, and send an empty list if it is.

Or some other way to explicitly update if user doesn't want to wait for auto sync

As a failsafe last resort to avoid data loss local unsent data should be stored on the device SD card. The format could be a csv that can be imported directly into DHIS 2, although it would require some investigation into if its at all possible.

This implies obvious security/privacy issues, so it is important to let the user disable this option.

It is possible add a description to data elements. For example this could be an explanation to health workers on being more exact in the data to enter, or something else.

Implement some sort of pop up bubble or toggle to show the description of a data element.
Default should be hidden, but perhaps add an "info" button somewhere that can be pressed.

It might be unnecessary for users to update metadata every time they want to initiate data value sending explicitly. Currently, to initiate data value sending, the user has to either save data in data entry, or initiate full synch in Settings.

If skip logic is applied to a data element and it hides other data elements that has values, the user should be asked if he wants to clear(set to "") those data element values.

Errors like "java.security.cert.CertPathValidatorException: Trust anchor for certification path not found." should be caught during log in and presented to the user.

Furthermore, it should cause loading and sending of data to stop, if somehow the user manages to glitch past login.

Implement delayed retry if synchronization fails due to missing internet connection. The delay should typically increase everytime the SDK retries but still has no internet connection.

If data element label has been changed on the server, it won't appear on the device when synchronizing

The app needs to namespace all content (programs, events, etc) per server and user. This to avoid that a user will see conflicting database content from other servers or users.

This can be done by creating and maintaining one database per full server URL and username. When a user logs in against a server URL and username, the application should check for existing databases. If found, it should connect to the database, if not, a new database should be created.

With the previous versions of DbFlow (< 2.0.0 ) the column properties had to be public, but they can now be private.

There might be complications because of the way there have been implemented a few custom getters for Jackson purposes.

In DataValueSender: if one item has an error returned from the server, sending of items stop until next sync. Should let it continue, and let user try to resolve the issue by using FailedItems where appropriate.

In some cases it can be helpful to see error logs or warning logs and stack traces from users experiencing problems. Therefore it should be implemented to write all stack traces to a log file on the SD card which the user can take out and send. It might however be a bit of a security issue so the user should be able to choose if this feature is on or not.

Take DataEntryFragment from Event Capture and Tracker Capture and make generic so it can be put in SDK and re-used in both.

No reason to have two of this since it is so similar. Could also be used for aggregate data entry probably.

So that all references by uid are valid

Limit number of Enrollments and TrackedEntityInstances being loaded (for example limit to 200 at inital load, and let user load more if desired). Also, currently the last 200 events are hard coded to be loaded as a temporary solution to limit data loaded - should find a better solution.

If user logs out data values stored on device will get lost, so the user needs to be made aware of this through an exit verification prompt.

Yes/no only (excluding 'none' option) as in DHIS2 web interface

It seems to be an offset depending on the locale setting of DHIS 2, which results in new data a few hours old (depending on locale) to be re-loaded as if it were new data.

In DbFlow there is an option to save async true|false. When true, saving is added to a transaction queue and is executed in bulk. This is better for flow and is safer when multiple threads are saving simultaneously. Setting the flag to false may cause crashes due to db locks if two "synchronous" save calls happen at the same time from different threads.

If possible make sure async is always true.