Hello implementers!
Do you use Android Client? If so, what would you like to see improved in future releases? If not, what prevents you? Are there any missing vital features? Compatibility or efficiency issues?
Currently we are planning work for coming weeks, and we’d love to hear your feedback about current state of this app.
Hi @gutkowski, thanks for asking!
We haven’t tried the Android client yet, mea culpa, but what we would hope for it is the ability to bring offline features for outreach community care. At minima:
We wouldn’t see much value in an Android client otherwise. Having said that it turns out that the Ref App is currently not mobile responsive, and this UI design flaw brings value for the Android client even without the offline features. But this flaw could be addressed without the need of a native app, in a similar way than what Bahmni apps do.
Can the Android client currently perform 1 & 2?
@gutkowski, I suggest also taking a look at this thread:
I’d suggest reaching out to @ibewes and also to those listed as the mUzima team, to get a better sense of what their real-world requirements were, and why they chose a different path.
I think that what a real-world implementation desires from a mobile tool is quite different from what the OpenMRS reference application does.
I’d speculate that the biggest use case is what @mksd alludes to: community health workers who might do home visits and provide care outside of the facility. CommCare is a popular solution to this problem. mUzima and OpenSRP also aim to solve it. Maybe OpenMRS should be integrating with existing tools, rather than replicating work they’ve likely already done.
There is a plausible use case (smaller, I think), for viewing patient summaries and charts while walking around a facility, and perhaps leveraging the hardware capabilities of a smartphone to easily add photos, videos, and audio to the patient record. But I would want real implementations to confirm they’d use this before devoting time to this use case.
@mksd Thank you for your input! According to this post, offline patient registration is already supported. About #2, I believe that @avijitghosh82, @raff or @tmarzeion will be able to answer that question much better than me.
@darius I see, probably you are right. Let’s see what implementers think about your suggested use case.
I’m wondering, @mksd, are you already using any of solutions mentioned by @darius?
Both #1 and #2 are supported. Yes, even offline. You can actually try out the app from the Play Store. The app has been tested with respect to the devtest04 server, but if you’re using an unmodified rest API things should work properly!
The set of forms needs to be returned via the /form API endpoint so that the app can download and save them at first run. If you require an example Json response please let me know.
Thanks @avijitghosh82 for clarifying.
I am not yet familiar with the /form API endpoint, I don’t even know where this (presumably REST) API lives.
What form technology are we talking about then? Will this expose, while offline,
Not yet. Offline features is something that gets pushed up & up in our interests list of features, but it was not yet required formally. So I jumped in to say what would be nice to have, from an implementer standpoint, for the Android client.