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: miguel.esbri@atos.net
URL: http://www.foodie-project.eu
Twitter: 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

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

More Related Content

Similar to D4.2.2 advanced rich interfaces

More from FOODIE_Project

Recently uploaded

D4.2.2 advanced rich interfaces