d4.2.2 advanced rich interfaces

This project is partially funded under the ICT Policy Support Programme (ICT PSP) as part of the

Competitiveness and Innovation Framework Programme by the European Commission under

grant agreement no. 621074

COMPETITIVENESS AND INNOVATION

FRAMEWORK PROGRAMME

CIP-ICT-PSP-2013-7 Pilot Type B

WP4 – Data analysis, modeling and synthesis

D4.2.2: Advanced Rich Interfaces

Deliverable Lead: CTIC

Deliverable due date: 29/02/2016

Actual submission date: 29/02/2016

Version: 2.0


http://www.foodie-project.eu Copyright © FOODIE Project Consortium. All Rights Reserved. Grant Agreement No.: 621074 Page:2 / 25

Document Control Page

Title D4.2.2Advanced Rich Interfaces

Creator Alfonso Noriega (CTIC)

Description This document introduces the second prototypes related to the Advanced Rich Interfaces

Publisher FOODIE Consortium

Contributors Alfonso Noriega (CTIC

Emilio Rubiera (CTIC)

Creation date 09/02/2016

Type Text

Language en-GB

Rights copyright “FOODIE Consortium”

Audience

internal

public

restricted

Review status

Draft

WP leader accepted

Technical Manager accepted

Coordinator accepted

Action requested

to be revised by Partners

for approval by the WP leader

for approval by the Technical Committee

for approval by the Project Coordinator

Requested

deadline



STATEMENT FOR OPEN DOCUMENTS

(c) 2016 FOODIE Consortium

The FOODIE Consortium (http://www.foodie-project.eu) grants third parties the right to use and

distribute all or parts of this document, provided that the FOODIE project and the document are

properly referenced.

THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY

EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. EXCEPT WHAT SET

FORTH BY MANDATORY PROVISIONS OF LAW IN NO EVENT SHALL THE COPYRIGHT OWNER OR

CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR

CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE

GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER

CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

About the project

FOODIE project aims at creating a platform hub on the cloud where spatial and non-spatial data related to agricultural sector is available for agri-food stakeholders groups and interoperable. It will offer: an infrastructure for the building of an interacting and collaborative network; the integration of existing open datasets related to agriculture; data publication and data linking of external agriculture data sources, providing specific and high-value applications and services for the support of planning and decision-making processes.

FOODIE project is addressed to four basic groups of users: a) stakeholders from the agriculture sector as end-users of final applications, b) public sector for communication with farmers about taxation, subsidies and regulation, c) researchers for large scale experimentation on real data and d) ICT companies for the development of new applications for agriculture and food sector, mainly using implemented tools

FOODIE specifically works on three pilots:

Pilot 1: Precision Viticulture (Spain) will focus on the appropriate management of the inherent variability of crops,

Pilot 2: Open Data for Strategic and Tactical Planning (Czech Republic) will focus on improving future management of agricultural companies (farms) by introducing new tools and management methods,

Pilot 3: Technology allows integration of logistics via service providers and farm management including traceability (Germany).

Contact information

Miguel Angel Esbrí

Project Coordinator

Atos Spain, Madrid, Spain

E-mail: [email protected]

URL: http://www.foodie-project.eu

Twitter: https://twitter.com/FOODIE_Project

http://www.foodie-project.eu/

mailto:[email protected]


https://twitter.com/FOODIE_Project



Table of Contents

Glossary................................................................................................................................................. 6

Abbreviations and Acronyms .................................................................................................................. 7

Executive Summary ................................................................................................................................ 8

1 Library overview ............................................................................................................................. 9

2 Visualization Widgets and dashboard ............................................................................................ 10

2.1 Implementation ................................................................................................................................ 10

2.2 Widget configuration ........................................................................................................................ 10

2.3 Visualization widgets ........................................................................................................................ 12

3 Widget development recommendations ........................................................................................ 18

4 Native android application ............................................................................................................ 20

4.1 Implementation ................................................................................................................................ 20

References ........................................................................................................................................... 25

Index of Figures

Figure 1: First config window .......................................................................................................................... 10

Figure 2: Web service config window ............................................................................................................. 11

Figure 3: Widget output config window .......................................................................................................... 11

Figure 4: Treatment list window ..................................................................................................................... 12

Figure 5: Treatment detail window ................................................................................................................. 12

Figure 6: Treatment widget configuration ...................................................................................................... 13

Figure 7: Treatment plan list window ............................................................................................................. 13

Figure 8: Treatment plan detail window ......................................................................................................... 14

Figure 9: Treatment plan widget configuration .............................................................................................. 14

Figure 10: Zones widget configuration ............................................................................................................ 15



Figure 11: Zones widget visualization window ................................................................................................ 15

Figure 12: Zones widget detailed window ...................................................................................................... 15

Figure 13: Choropleth configuration ............................................................................................................... 16

Figure 14: Choropleth widget view ................................................................................................................. 16

Figure 15: Production list window ................................................................................................................... 17

Figure 16: Production details window ............................................................................................................. 17

Figure 17: Login of the mobile app .................................................................................................................. 20

Figure 18: Map zones ...................................................................................................................................... 20

Figure 19: Annotations .................................................................................................................................... 21

Figure 20: Alert details .................................................................................................................................... 22

Figure 21: Prune details ................................................................................................................................... 23

Figure 22: Treatment details ........................................................................................................................... 23

Figure 23: Treatment plan details ................................................................................................................... 24

Index of Tables

Table 1: Abbreviations and Acronyms ................................................................................................................7

Table 2: References ......................................................................................................................................... 25



Glossary

The glossary of terms used in this deliverable can be found in the public document “FOODIE_Glossary.pdf” available

at: http://www.foodie-project.eu




Abbreviations and Acronyms

Abbreviation /

Acronym Description

API Application Programming Interface

CPU Central Processing Unit

DBA Database Administrator

DBaaS Database as a Service

DDD Domain-Driven Design

DNS Domain Name System

GTM Global Transaction Manager

HA High Availability

HDD Hard Disk Drive

HTTP Hypertext Transfer Protocol

IaaS Infrastructure as a Service

IDE Integrated Development Environment

JAR Java ARchive

MPP Massive Parallel Processing

OS Operating System

POM Project Object Model

RAM Random Access Memory

RDBMS Relational Database Management System

RDF Resource Description Framework

SLA Service Level Agreement

SQL Structured Query Language

TCP Transmission Control Protocol

TDD Test – Driven Development

VM Virtual Machine

API Application Programming Interface

Table 1: Abbreviations and Acronyms



Executive Summary

This document describes the second version of the prototypes for Advanced Rich Interfaces. It includes both a

description of the interfaces specifically developed for the dashboard, the widgets, and a section including guidelines

and recommendations on how to develop further widgets. A final section deals with the mobile application

implemented for the project, a native android application.



1 Library overview

The Advanced Rich Interfaces aim to provide the end user with the means to exploit data on an understandable and

user-friendly oriented way. To fulfil this task, the idea is to provide an environment, based on FOODIE services, already

populated with general visualizations in which the creation and integration of new forms of data presentation for a

specific scenario will be reachable for third parties.

In order to reach this functionality, two approaches have been taken:

The development of a web client dashboard, able to be configured to fit the end user needs and providing the

means to easily develop and integrate new visualization widgets more specifically for a given use case.

The development of a native android application, working both, as mobile visualization tool and as a

demonstrator on how to implement all the generic widget visualizations in a portable device and how to

make use of the FOODIE services.

Note that this second version of the deliverable includes and describes the efforts for both the old widgets now

adapted and aligned to the new data model, hence modified to fit the new requirements, besides new widgets fully

compliant with the new data model and a new version of the mobile application adapted as well to the changes in the

Web services API caused by the alignment with the FOODIE data model.



2 Visualization Widgets and dashboard

The generic visualization dashboard stands with the idea of providing a tool to enable, given a specific use case, the configuration of a set of visualizations fitting the exact needs of the end user. To support this target a dashboard and a set of generic visualizations has been developed, all together being capable of defining which widgets are going to be deployed and how they are connected between them.

Those end user needs may not be accomplished by generic visualizations; in some cases, the requirement of specific widgets could arise. For those scenarios, the dashboard architecture provides a specification on how to develop ad-hoc visualizations that will be easily integrated in the dashboard.

2.1 Implementation

The visualization widgets and dashboard are being developed using ExtJS 5[1].

The dashboard provides:

Possibility to select widgets to be shown on the visualization space.

Input and specific configuration for each widget.

Change the display position and size of the widgets.

Add new widgets developed by others and integrate them in the dashboard.

The dashboard will be packaged as a WAR file to its future deployment in any different server.

For the Foodie project it will be deployed on JBoss web server and will be available at:

http://foodie-vm9.man.poznan.pl/FoodieVisualization/

2.2 Widget configuration

Each time a widget is added to the dashboard, a configuration window will ask the user about some parameters that must be fulfilled before render the widget.

The first configuration window (Figure 1) asks the user about the title of the widget, and the kind of input that it will

use.

Figure 1: First config window

http://foodie-vm9.man.poznan.pl/FoodieVisualization/



Depending on the type of input selected, a second window will be shown. At the moment of this writing, there are only widgets supporting Web Service input and the Event Input.

If the user chooses Web Service input, a window asking for the URL of the web service and the root property of the

response will be shown (Figure 2).This new version features basic authentication (user/password) against the

exploited web service.

Figure 2: Web service config window

If the user chooses the Widget output a different window will be shown (Figure 3). This window will contain the

information about the outputs of the widgets already deployed in the dashboard that are compatible with the input of the new widget. So if the user adds a widget that accepts tabular data as widget output, information about all the previously configured widgets offering tabular data as output will be suggested in the config window. Once the user has selected one output widget, this output widget will be linked as input for the new widget.

Figure 3: Widget output config window

After these configurations, a last config window could show up asking for widget-specific configuration, if necessary. An example of this configuration can be seen in Figure 6.



2.3 Visualization widgets

There is already a set of widgets working that have been developed under the needs of the Spanish pilot Terras Gauda. Those widgets are namely:

Treatment Widget: Widget to show a list of treatments (Figure 4) and details of each of them (Figure 5).

For each treatment there is information about used products, supervisor, machines, quantity, treatment plans, type, zone, status and dates.

Figure 4: Treatment list window

In the detailed view more extensive information can be found for a selected Item.

Figure 5: Treatment detail window

As explained in the previous section, a third config window is necessary to introduce the

information required by a Treatment widget (Figure 6). This configuration information includes a

start date and a finish date.



Figure 6: Treatment widget configuration

Treatment plan Widget: Widget to show a list of existing treatment plans (Figure 7) and details about each

of them (Figure 8). For each treatment there will be information about the creation date, type of treatment,

campaign, products used in the treatment and observations.

Figure 7: Treatment plan list window

More information about each treatment plan in the treatment plans list (Figure 7) can be found in the

detailed view (Figure 8). In addition, more relevant details about each treatment plan can be edited from the

detailed view.



Figure 8: Treatment plan detail window

As occurs with the Treatment widget, a third config window is necessary to introduce the information

required by a Treatment Plan widget (Figure 9). This configuration information also includes a start date and

a finish date.

Figure 9: Treatment plan widget configuration

Plot&Crops Widget: This widget is currently deprecated due to some deep changes in the data model and, as a consequence, in the web services API. Instead of plots and crops, zones have been used to draw the plots so a new widget named Zones Widget has been developed (see next bullet).

Zones Widget: Widget that shows a map with the polygons representing the available zones. The first step in

the widget is to configure it by specifying the holding id (Figure 10), which zones will be entirely listed and

showed in the map (Figure 11).



Figure 10: Zones widget configuration

Figure 11: Zones widget visualization window

By clicking in each zone the user can obtain extended information about it (Figure 12). If the user clicks on a

zone some detailed information, including the name of the zone, will be shown.

Figure 12: Zones widget detailed window

Choropleth Widget: Widget that shows a choropleth map of the existing zones. The first step in the widget is

to configure it (Figure 13). In this configuration window the user must define the property that will be

evaluated for each zone within a given holding (selected by its id), and the colors and ranges that should be

used in the map.



Figure 13: Choropleth configuration

Once the widget is configured a map will be shown with each zone represented by the corresponding color.

In the left side, a legend is shown explaining the meanings of each color (Figure 14).

Figure 14: Choropleth widget view

Production Widget: Widget to show a list of existing productions (Figure 15) and details about each of them

(Figure 16). For each production there will be information about the year, amounts, notes and production

details per zone.



Figure 15: Production list window

Figure 16: Production details window



3 Widget development recommendations

Each Widget should have the following structures:

The name of the Widget should be WidgetNameWidget (i.e. TableWidget, FormWidget, MapWidget, TimeLineWidget). For the next steps, the words WidgetName will refer to WidgetNameWidget

The base namespace for the classes of the widget must be Foodie.widgets.WidgetName (i.e. Foodie.widgets.TableWidget)

The Widget must have a main view, which will be the view that will be use by the dashboard to show the widget. This view must be named with the template WidgetNameMainView. Its fully qualified name should be Foodie.widgets.WidgetName.view.main.WidgetNameMainView (i.e. Foodie.widgets.TableWidget.view.main.TableWidgetMainView).

The XType of the main view must be WidgetName.

The widget must implement a class with information about the widget. This class must be in the widget root folder, and its name must use the template WidgetNameInfo (i.e. TableWidgetInfo), its qualified name must be Foodie.widgets.WidgetName.WidgetNameInfo(i.e. Foodie.widgets.TableWidget.TableWidgetInfo). Its alternateClassName must WidgetNameInfo. This class must be compliant with the following requirements:

o This info class must be a singleton class. o This info class must have a property widgetName, which contains the human readable name of the

widget. o This info class can contain a property named inputDataType, which will indicate to the system the

kinds of data that accept the widget as input. This property must be an array of strings. The different types of data have to be decided, but could be something like:

record

tabular

data model related (plot, crop, treatment,…)

o This info class can contain a property named outputDataType, which will indicate to the system the kinds of data that this widget will produce as an output. This is an array of objects that must have the following structure:

eventName: id of the event that will be used to output data from the widget dataType: type of data that will be sent through this event description: description of the event

The widget can have an initial configuration view that will be shown just before the creation of the widget. This view must be named with the template WidgetNameInitialConfigView. Its full qualified name should be Foodie.widgets.WidgetName.view.config.WidgetNameInitialConfigView (i.e. Foodie.widgets.TableWidget.view.configTableWidgetInitialConfigView).

Also, if this initial configuration exists, there must be a view controller named

WidgetNameInitialConfigViewController. Its fully qualified name should be

Foodie.widgets.WidgetName.view.config.WidgetNameInitialConfigViewController (i.e.

Foodie.widgets.TableWidget.view.config.TableWidgetInitialConfigViewController). This view controller must

have implemented a class called getConfigData(), that return the configuration set in the configuration

window. The format of this object could be anyone, because it will be used internally by the widget.

The dashboard will set some properties in the widget main view that will help the widget to integrate into the dashboard. This properties are the following:

o widgetType: xtype of the widget.



o widgetInput: object containing the configuration of the input. The structure of this object will be the following:

type: type of the input. Can be “ws” (web service), “event”, “file” or “no”, if there is no input.

data: the input data. It depends of the type.

WS o urlWs: web service URL. o root: root property in the json response.

Event o events: array with the events to subscribe. Each event should have the

following properties. eventId: id of the event eventType: type of the data served by the event widgetId: widget that will fire the event

File: structure to be decided. o widgetConfig: object containing the configuration of the widget. The widget developer decides the

structure of this object.

So, the basic folder structure for a widget will be the following:

- WidgetNameWidget o WidgetNameWidgetInfo.js o view

WidgetNameMainView.js WidgetNameInitialConfigView.js (optional) WidgetNameInitialConfigViewController (optional, but mandatory if the configuration view

exists)

This structure defines the minimal requirements that the dashboard needs to be able to “understand” the widget.

Then, the widget developer could use every model, store, controller, view controller and view model that he would

need.



4 Native android application

Developed to implement the previous visualizations in native, usable mobile application, it also stands as a showcase

for the Spanish pilot showing how exploit FOODIE API to apply make use of visualizations in mobile devices.

4.1 Implementation

The application has been developed using the Android 5.0 Lollipop in order to cover natively a wide range of mobile

devices, providing the user with a better experience when navigating the visualizations. The functionalities have been

decided along with the Spanish pilot stakeholder and SERESCO.

The first screen shown is the login one, where credentials are asked to the user (Figure 17).

Figure 17: Login of the mobile app

Once logged-in, a map of the zones show up, where the user can browse and get information about treatments,

prunes or annotations for a specific one (Figure 18).

Figure 18: Map zones



That screen features a lateral menu enabling the user to navigate among the different options:

Locations

Annotations

Prunes

Treatments

Settings

Help

Exit

The features implemented in the application are:

Annotations visualization (Figure 19). List of annotations and info about them: attachments, plot, supervisor,

description, etc.

Figure 19: Annotations

Besides, this second version of the app supports adding new annotations, so the worker in the farm can add relevant

information on the field.



Alerts visualization (Figure 20). List of alerts and info about them: supervisor, description and actions.

Figure 20: Alert details



Prunes visualizations (Figure 21). List of prunes and info about them: supervisor, description and plot.

Figure 21: Prune details

Treatments (Figure 22) and treatment plan (Figure 23). List of treatments and treatment details showing

info like: supervisor, machine, liters and security info.

Figure 22: Treatment details



It also shows the treatment plans info: Date, description, product list and quantities, and ID.

Figure 23: Treatment plan details



References

References

01 http://www.sencha.com/products/extjs/

Table 2: References

d4.2.2 advanced rich interfaces

Software