community-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "larry akah (JIRA)" <>
Subject [jira] [Commented] (COMDEV-123) Taverna: Android app Taverna Mobile
Date Wed, 11 Mar 2015 12:28:38 GMT


larry akah commented on COMDEV-123:

Seems like i have already subscribed to the mailing list. However, i have
still sent a subscription request as requested.

> Taverna: Android app Taverna Mobile
> -----------------------------------
>                 Key: COMDEV-123
>                 URL:
>             Project: Community Development
>          Issue Type: Bug
>            Reporter: Stian Soiland-Reyes
>              Labels: android, gsoc, gsoc2015, java, mentor, mobile
> Project: Apache Taverna (incubating)
> Mentors: Ian Dunlop <>, Stian Soiland-Reyes <>
> Taverna Mobile: A year or so ago in conjunction with a University of
> Manchester undergraduate we developed an Android app to run Taverna
> workflows available on myExperiment (
> using Taverna Server. 
> It is available here Later on we updated it
to use the android IDE from google/idea and the gradle build system as well as fixing some
of the dependencies, see
> The code relies on some APIs from google and apache which have moved
> on since then eg the https libraries which needs updated.
> The project would be to:
> 1) fix the ssl/https parts and use the latest version of taverna server (with configurable
URI and username/password)
> 2) update the code to remove some legacy dependencies and use the
> latest APIs
> 3) improve the UI and responsiveness
> 1) & 2) are the most important bits with 3) being a bit extra
> depending on how the first bits progress.
> The original app was designed for Android 18 although there are now
> various SDK levels mentioned in various manifest files. Minimal
> testing on other API levels was done, pretty much just the developers
> phone. Targeting as low an SDK version as possible would be desirable.
> Obviously not way back to Android 2 but something which allows a
> reasonable percentage of devices to use the app
> ( 4.1 (SDK
> 16) may be a good target.
> The app uses various dependencies, listed in the build files. However,
> these dependencies may be out of date and in fact may be unused by the
> code. They need to be cleaned up.
> The original app used a modified version of the apache http libraries
> to talk to the taverna server code because the android sdk did not
> include an up to date version and the latest versions clashed with the
> android package namespaces. Android compatible versions of recent
> versions of the apache http libaries are now available
> (
> and I tried to use them in my 'fork' although testing was minimal.
> The mygrid taverna server library
> ( is used to access the
> taverna server API. This library is not actively supported and in fact
> may be too heavyweight for the app. It is not even clear what branch
> is used. The taverna server API is just a REST based API over HTTP
> ( so some
> refactoring is a good idea. It has to be able to handle talking to a
> taverna server over HTTPS with a username/password that is not the
> default taverna/taverna one. The HTTPS may have a user created
> certificate which is not from a CA.
> Some of the UI relies on the sliding menu library by Jeremy Feinsten
> which is included directly in the src rather than via gradle. The
> provenance of the code is unclear, possible from
> There may be a more
> modern Android way to do that kind of UI design but I am not convinced
> that the app needs it.
> The PullToRefresh library by Chris Baines (possibly
> is used via
> gradle but again there may be a modern Android way to do things.
> One of the important tasks is to ensure that the app can be supported
> beyond the project end and that means relying on 3rd party libs that
> are actively supported.
> Think of the current app as a demonstrator. I would be happy for the
> it to be developed from scratch. There is no need for it to even be an
> Android app, a web app would be just as good as long as the
> functionality is there. In fact, that is a good way to target multiple
> mobile platforms perhaps using some apache cordova
> ( for any native functionality required.
> The basic app functionality required (not an exhaustive list):
> View workflows from
> Log in to and view your workflows
> Talk to required parts of taverna server API over HTTPS.
> Run a workflow. Requires upload of input data and the workflow to a
> taverna server instance.
> Monitor workflow run.
> View workflow run results.
> Download results.
> The project would interest students with a good grounding in Java
> looking to get into Android mobile development.
> You would be part of he Apache Taverna community
> which would be giving advice and feedback on your
> app. 
> Videoes of the current app
> Paper:
> Interested students should sign up to the dev@taverna mailing list to discuss their proposal
in detail:

This message was sent by Atlassian JIRA

View raw message