QuestMark is a framework that facilitates developers to build custom applications that connect to DHIS2. This is the presentation from EyeSeeTea members at the DHIS2 Symposium 2018

1. Ignacio Foche - Adrian Quintana
DHIS2 Symposium - Washington DC - 2018
DHIS2 Android for human beings
QuestMark

2. 1. INTRO
a. What is QM?
b. Motivation
c. How is it being developed?
d. Who?
2. QM
a. Definition
b. Structure
c. Modules
d. Architecture
e. Configuration Layer
f. Android variants & strategies
3. DISCUSSION
a. Android dev costs reduction
b. Difference with UiO roadmap
c. What’s next.

3. What is QuestMark?
QuestMark is an open source modular
framework for developing Android applications
which are capable of generating graphical
interfaces based on a backend (DHIS2 data and
metadata)

4. Why to develop QM?
Development started in 2015
in the context of the PSI HNQIS project

5. Why to develop QM?
Ease custom apps development
Reuse code in an easier way
Abstract the user from complex concepts
Declarative definition files and defined module
interface

6. Who?

7. Contributors
PSI
Save the Children Myanmar
UiO
Volunteers
…and others...

8. Open Source
for an Open World
How is it being developed?

9. Open Source, GPLv3 License
3+ years of development
9 modules
7 applications
100,000+ lines of code
Growing community
Open process
Regular Releases
How is it being developed?

10. Open Process
Github - Waffle: More than just Source Control!
Agile methodology
Releasing
Online development
Quality Assurance

11. Git - Github - Waffle

12. Main Principles
Everyone wants to recycle,
even if they don’t know
Do it fast > do it wrong > do it slow
Compromise is everything

13. QM is a Framework...

14. General diagram

15. Detailed diagram

16. Modules
● Core
○ Login core
○ Metadata & Data population
● App domain
○ Organizer
○ Data collector
○ Feedback provider
○ Statistical analysis
○ Multimedia library
○ Stock management
○ Treatment Selector

17. Modules

18. QM Foundations
Clean Architecture
Configuration layer
Android variants & strategies

19. Technology stack

20. Clean Architecture

21. ● Hide implementation details
● Split software in layers
● Follow a strict dependency rule
● Make the system testeable
● Make it easy to change details
● Presentation logic, application logic and
business logic don’t depend on the technology
Clean Architecture

22. Configuration layer

23. Configuration layer
● Parameters to activate/deactivate modules
○ ActiveMonitoringFragment
○ ActiveAVFragment
○ ActiveStockFragment
● Parameters to alter a module behaviors
○ ActiveSwipeNavigator
○ ReviewScreen
● Parameters to activate/deactivate core module functionalities
○ DevelopersOptions
○ Multiuser
○ CustomFont
● …

24. Android variants & strategies

25. DISCUSSION
● Community empowerment:
○ open source, many can develop
● Cooperative approach:
○ Costs of developing modules are shared between
organisations
○ Quality improvement by shared testing
● Custom Android Apps costs reduced:
○ Accessible for organisations with less resources

26. DISCUSSION
● When using QM and not UiO official apps?
○ They solve different problems. Look at QM entities to
understand the kind of concepts that can be associated
○ QM doesn’t provide a DB constantly synced approach, but
import-export data from-to DHIS2
○ Use multiple backends and not only DHIS2
○ Simplify user language

27. DISCUSSION
● What’s next?
○ This is an announcement to the community. We’re on the way
for releasing QM during the next year
○ Still a WIP. This year is crucial for its first version open to the
public
○ New per-module repositories
○ Separate repo for the domain (core)
○ Documentation for developers during the next year
○ Do you want a new app with a new module? Let’s talk

28. Thanks for the attention!
Ignacio Foche / Adrian Quintana
DHIS2 Symposium - Washington DC - 2018
QuestMark