[jira] [Commented] (COMDEV-123) Taverna: Android app Taverna Mobile

["larry akah (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMDEV-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562585#comment-14562585 ] 

larry akah commented on COMDEV-123:
-----------------------------------

@Stian, i think you could assign this issue to me since it's my GSOC project. Thanks

> Taverna: Android app Taverna Mobile
> -----------------------------------
>
>                 Key: COMDEV-123
>                 URL: https://issues.apache.org/jira/browse/COMDEV-123
>             Project: Community Development
>          Issue Type: Bug
>            Reporter: Stian Soiland-Reyes (old)
>              Labels: android, gsoc, gsoc2015, java, mentor, mobile
>
> Project: Apache Taverna (incubating) http://taverna.incubator.apache.org/
> Mentors: Ian Dunlop <ia...@apache.org>, Stian Soiland-Reyes <st...@apache.org>
> 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 (http://www.myexperiment.org)
> using Taverna Server. 
> http://dev.mygrid.org.uk/wiki/display/tav/Taverna+Mobile
> It is available here https://github.com/myGrid/taverna-mobile. 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
> https://github.com/ianwdunlop/tavernamobile.
> 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
> (http://developer.android.com/about/dashboards/index.html). 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
> (https://hc.apache.org/httpcomponents-client-4.3.x/android-port.html)
> and I tried to use them in my 'fork' although testing was minimal.
> The mygrid taverna server library
> (https://github.com/myGrid/t2-server-jar) 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
> (http://dev.mygrid.org.uk/wiki/display/tav250/REST+API) 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
> https://github.com/jfeinstein10/SlidingMenu. 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
> https://github.com/chrisbanes/Android-PullToRefresh) 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
> (http://cordova.apache.org/) for any native functionality required.
> The basic app functionality required (not an exhaustive list):
> View workflows from http://www.myexperiment.org
> Log in to http://www.myexperiment.org 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
> http://taverna.incubator.apache.org/community/
> which would be giving advice and feedback on your
> app. 
> Videoes of the current app https://www.youtube.com/playlist?list=PLs1PhQrR0xxH3j-f6FXU2cp9fBVTDrl6T
> Paper: http://arxiv.org/pdf/1309.2787v3.pdf
> Interested students should sign up to the dev@taverna mailing list to discuss their proposal in detail:  http://taverna.incubator.apache.org/community/lists



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)