-Smart agriculture applications are promising to improve traditional agriculture in developing regions. Farmers use these applications to collect data on agricultural activities and monitor different conditions in modern farms. However, from the development point of view, these applications are often implemented using text-based programming languages that require experienced programmers. Visual languages can be an alternative to text-based languages that may allow non-expert programmers (e.g., farmers) to implement these applications and make adjustments to existing ones. This study considers two exemplars of concrete and deployable smart agriculture applications (WebLog and UtafitiLog) developed using two different technologies. The study defines a set of parameters to evaluate these exemplars from which lessons are drawn that can be generalised to other smart agriculture applications. Index Terms-mobile applications, smart agriculture, distributed computing
Smart agriculture aims to improve processes in modern
farms to handle the increasing global demand for food. In
developing regions, smart agriculture is partially realised by
means of distributed mobile applications running on
smartphones. Farmers in these regions have the applications
installed and configured on their smartphones from where they
can collect data and monitor environmental conditions on the
farm. Farming activities in these regions happen in small scale
farms [
This study considers exemplars of two concrete and deployable smart agriculture applications (WebLog and UtafitiLog) implemented using two different technologies. The study defines a set of parameters to evaluate these exemplars from which lessons are drawn that can bee generalised to other smart agriculture applications. This study is guided by the following research question;
In the subsequent sections, the paper is organised as follows. Section II presents the motivation and running example on smart agriculture applications. This is followed by the application implementations in section III. Section IV presents the evaluation and comparison, while section V presents the discussions and the lessons learnt from the implementation. Section VI presents the related work and lastly, section VII presents the conclusions and gives directions for future work.
In this work, we focus on small-scale farmers in developing regions requiring distributed mobile smart agriculture applications to collect different kinds of data. The data is collected in a remote farm that is faced with intermittent network connection issues. Data gathered from a variety of weather sensors in the farm (e.g., temperature and humidity sensors) is uploaded automatically to a server and can be used by the farmer to make informed decisions on required agronomic practices such as initiating programmed misting of crops when temperatures exceed a set threshold. Changes in the data collected from the weather sensors are expected to reflect in real-time once uploaded onto the server. Using the distributed mobile application, the farmer can scan a crop label to invoke an interactive data input form that is adjustable depending on parameters of interest. These parameters may vary with regard to the farming season or type of crop, among others.
To guide our implementation, we derived the following functional requirements; (i) user login to access application services, (ii) viewing weather data on a dashboard, (iii) tagging and scanning plant labels, (iv) generating data collection surveys, (v) saving collected data to a database, (vi) fetching and receiving data from weather sensors, (vii) generating alerts based on set thresholds, and (viii) storing data on the mobile device when the network becomes unavailable.
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0)
From this application example, we consider the following (non-functional) requirements that form the key features for modern smart agriculture applications in developing regions.
Offline accessibility: The application should continue functioning whenever the network connection becomes unavailable. The application should use a client-side database to store data locally on the mobile device while waiting for the network connection to be regained.
Reactivity: The application should respond to events originating from the external environment in real-time.
Also, the application should support generating relevant notifications as soon as data from sensors is received to motivate farming decisions, e.g., misting crops when temperatures exceed certain thresholds.
Reconfigurability: It should be possible to change and adapt existing application components to fit different scenarios after the initial development. For example, it should be possible to change the data collection survey to meet data collection requirements for different farming seasons or crops.
Extensibility: It should be possible to add new features and services to the application after implementation, e.g., by supporting Applications Programming Interfaces (APIs) or reusable components.
Based on these requirements, our goal was to get insights
on developing smart agriculture applications for small-scale
farmers in developing regions. We conducted preliminary
experiments to compare the technologies used in implementing
the exemplar applications and provide the lessons learnt. The
implemented applications meet the requirements derived in
this section. WebLog was implemented using React-Native
framework for JavaScript while UtafitiLog was implemented
using DisCoPar [
In this section, we describe the implementation details for WebLog and UtafitiLog following the requirements identified in section II. These requirements were translated into application modules to support modular design with APIs. The development process followed an incremental and iterative mechanism. This enabled documenting the design process, results, and lessons learnt throughout the development phases. One developer was engaged in implementing both applications. As previously mentioned, WebLog and UtafitiLog were implemented using text-based and visual languages respectively.
The architecture for both applications is presented in Fig. 1.
Both applications provide similar services that are linked to a
Node.js server. The applications consist of an Android mobile
application to gather data, a server to store the collected data
and generate notifications, and a web client that acts as a
dashboard to the server. Both applications are targeted to run
on the Android platform since it is a popular platform in
developing regions [
Client-side
Web dashboard
In WebLog, the mobile application, server, and web dashboard are implemented in JavaScript. React-Native and ReactJS frameworks were used to implement the mobile application and web dashboard respectively. The server was implemented using Node.js linked to MongoDB for data storage. The mobile application is composed of different parts (views/screens) implemented as React-Native components (e.g., Login, Scan, SensorData, DataCollection components etc.) to realise the services the application offers. The application dashboard is the entry point that anchors all application views to one central navigation point. From the anchor point, users can navigate to the various sections of the application.
WebLog adheres to the previously identified requirements as follows;
1) Offline accessibility: WebLog uses a client-side database that runs on the mobile device to store data whenever the network becomes unavailable. The application keeps a counter that indicates to the user the number of unsynchronised records. If a farmer is collecting plant morphological data and a network disconnection occurs before sending the data to the server, the data is saved locally awaiting the network reconnection. When the network becomes unavailable, the application creates a database on the mobile device to save data as illustrated in Fig. 2. The application uploads locally stored data to the remote server when the network becomes available and deletes the local copies to free up storage space.
2) Reactivity: Code Listing 1 shows the specification for sending weather data to clients via sockets. Clients have to register to receive updates from the defined socket. New data updates are automatically pushed to the client (line 14 in code Listing 1). For example, the application provides a service to Connection available
Remote database
Upload data to remote server
Connection unavailable Client-side database
Connection regained Delete local copies
Upload
data monitor temperature, humidity, and pressure conditions. This data is displayed on a component that is updated whenever the server receives new data. 1 sendSensorDataToClients = data => { 2 const socketIds = Object.keys(this.
sockets); let allSockets = this.sockets; if (socketIds.length === 0) { console.log("No client sockets."); return; } const dataToSend = {
Temperature: data.temperature,
Humidity: data.humidity }; console.log("Sending sensor data!"); socketIds.forEach(socketId => { allSockets[socketId].emit("
socket_name", dataToSend); 15 16 };
});
Listing 1: Sending weather data to clients via sockets Also, notifications are generated based on set thresholds. For example, to generate alerts, we can set the threshold values at 25◦C and 35% for temperature and humidity in tropical regions respectively.
3) Reconfigurability: WebLog can be used to collect different kinds of data. Each time a data collection instance is created, it requires generating the corresponding data collection survey. Also, threshold values to generate notifications in [R2] can be changed to fit different scenarios. The data collection survey and threshold values for notifications can be changed by non-experienced programmers e.g., farmers via provided reconfiguration interfaces.
4) Extensibility: WebLog has been implemented as a textual component-based system with APIs that allow extending the application with new services. However, this extensibility is done in code since WebLog was implemented using a textual language.
As mentioned before, UtafitiLog was implemented using
DisCoPar, a VDSL for visual programming designed for
building applications for citizen science observatories (CSOs)
[
Components have output ports for emitting data and input ports for receiving data. These ports are typed based on the data that they emit or receive. On the application flowgraph (Fig. 3), each port is colour-coded with the type of data it emits or receives2. The arcs connecting components on the application flow-graph assume the colour of the origin port. These arcs represent data dependencies and always flow from the output ports of source components to the input ports of destination components. To explain these data dependencies, we split them into output and input data dependencies. Each component has at least one input or output data dependency with some components having multiple data dependencies because of having multiple input or output ports.
To implement UtafitiLog, we first identified the components that we required. The application flow-graph illustrated in Fig. 3 uses 26 components. Out of the 26, we reused 20 components from the existing component library. We implemented the remaining 6 components and published them to the component library. In regard to component scope, 6 components execute on the mobile device (i.e., Scan, ObservationPopSurvey, BufferObservation, and Label), 9 components execute on the web (i.e., Label, LineChart, Alert, and Table), and 11 components execute on the server (i.e., SensorWeather,
In Fig. 3, SensorWeather receives temperature, humidity, and pressure weather data from the sensor cloud and passes it as numeric values to the Rounding components that are used to set the precision level. SensorWeather component emits numeric data values which are accepted as input to the Rounding component. Data values (numeric) from the Rounding component are passed to the Label components for display and the LineChart components for visualisation on the dashboard. To generate notifications, the data is passed 1Black coloured components execute on mobile device; grey coloured components execute on the web; and light-grey coloured components execute on the server.
2Blue coloured ports receive or emit numeric data values; black ports receive or emit any data values; orange coloured ports emit or receive boolean values; green coloured ports emit or receive observations; and yellow coloured ports emit or receive datasets through IsGreaterThan component where thresholds are set. IsGreaterThan component accepts numeric data values and outputs boolean values. The input value is compared to the set threshold and if it evaluates to true, a notification is fired. The Alert component is used to display the notification message on the dashboard. Scanning of plant labels is done via the Scan component while creating data collection surveys is done using the ObservationPopUpSurvey. BufferObservation component supports offline accessibility while ObservationDatabase component connects the application to the database. AddDataToObservation component is used to aggregate data (observations) from different components.
UtafitiLog adheres to the previously identified requirements as follows;
is used to support offline accessibility by keeping copies of data on a client-side database each time the network breaks. The data collected when the network is unavailable is sent to the remote server when the network is regained.
2) Reactivity: UtafitiLog exploits the reactive and eventdriven design of DisCoPar VDSL ensuring the application components continue executing whenever they receive data on their input ports. The execution of one component in the application flow-graph triggers the execution of subsequent components that depend on the output from the previous component. Also, notifications are generated based on threshold values. In our application, using IsGreaterThan component we can set 25◦C and 35% threshold values for temperature and humidity in a tropical region respectively.
3) Reconfigurability: The data collection survey is implemented as a reconfigurable component to allow collection of different kinds of data. For example, each time the farming season changes and the data collection parameters change, the survey component is reconfigured to reflect the new data parameters. Also, threshold values for generating notifications can be changed for different farming scenarios. The ObservationPopUpSurvey and IsGreaterThan components are easily reconfigurable with minimal programming experience e.g., by farmers.
4) Extensibility: Adding new features or functionalities to the application is done by incorporating components from the component library to the application flow-graph. The application flow-graph can also be updated by removing components. Both adding and removing components can be done even when the application is already deployed.
To provide the functionality described in section II, both applications provide similar services i.e., (i) user registration, (ii) plant label scanning, (iii) generating data collection surveys, (iv) generating alerts based on weather information, and (v) visualising weather information on a dashboard. These applications present two perspectives to users; one perspective for logged in users and another for visitors. By default, a landing page is presented to a user visiting the application and is not yet logged in. This default landing page allows the user to navigate to the registration page to create an account or login page for authorisation and authentication to proceed to other application services. User registration is a public service that allows users to sign up into the application. Once logged in, the user can proceed to the application dashboard from where one can navigate to different sections of the application. The scanning service uses the device camera to read the plant labels and invoke the data collection surveys which are generated in both applications. Also, the alerts in the two applications are displayed on the web dashboard based on adjustable thresholds.
In this section, we compare WebLog and UtafitiLog. We use the features derived in section II as the primary criteria for qualitative evaluation. Since both applications support similar features and functionalities, and both are implemented in the same software stack, we postulate that both implementations exhibits similar performance. Therefore, the evaluation in this study is focused on the following questions; [EQ1] Which strategies are followed to implement the requirements identified in section II? [EQ2] What is the disk space utilisation for the implemented applications? [EQ3] How do the implemented applications compare to other smart agriculture applications?
In this section, we compare the implementation strategies used by both applications to adhere to the requirements in section II.
1) Offline accessibility: Both applications support offline
accessibility by keeping copies of data in a client-side database
whenever the network becomes unavailable. Different
strategies exist in the literature for implementing offline accessibility
e.g., caching, local storage, and client-side database [
2) Reactivity: Both applications support reactivity in different ways. UtafitiLog exploits the reactive and event-driven design of DisCoPar VDSL that ensures application components continue executing as long as they keep receiving data on their input ports. Execution of one component in the application flow-graph triggers the execution of subsequent components that depend on the output from the previous component. WebLog utilises reactive libraries to implement web sockets that push data to clients. Clients have to register to receive data from these sockets; new data is automatically pushed to the client.
3) Reconfigurability: Both applications support reconfigurability to adapt to different requirements within the farm. For example, changing the data collection surveys to fit different crops or farming seasons, the two applications make use of reconfigurable data collection surveys. This makes it easier for the farmer to reuse the same applications to collect different kinds of information on the farm for different farming seasons or various crops.
4) Extensibility: Both applications are extensible to add
new features and functionalities. Since each service in WebLog
is implemented as a textual component, extending the
application requires coding. Extensibility in UtafitiLog happens at
two levels; (i) at the code level to add new components to the
component library and (ii) the application flow-graph level to
add or remove features from an existing application. Also,
both applications support APIs for programmers to extend
application services. Since both applications are implemented
as components (either textual or visual components) they
support variability. In this case, variability allows reconfiguring
and extending the applications to meet new or changing
requirements i.e., adaptation [
Farmers in developing regions operate in remote areas and in most cases depend on paid mobile data to download and install applications on their mobile devices. The cost of mobile data positively correlates to the size of applications to download. Therefore, in this section, we measured (i) the size of the compiled application i.e., downloadable APK size, and (ii) disk space utilised by the installed application on the mobile device. The second parameter is important especially for resource constrained devices that, typically, have limited persistent memory available. In terms of downloadable APK file size, WebLog and UtafitiLog resulted in 25 MB and 10.8 MB respectively. In terms of disk space, WebLog utilised 122 MB, while UtafitiLog used 36.04 MB. The substantially more disk space used by WebLog could be as a result of insufficient compaction of the application bytecode. Also, React Native builds native libraries for armebi and x86 device architectures into the same APK, hence the larger APK size in WebLog compared to UtafitiLog. To minimise this size, it requires creating APKs for each device architecture.
The applications presented in Table I support different
activities on the farm e.g., crop disease diagnosis [
In this section, we discuss how text-based and visual languages compare in implementing smart agriculture applications. We re-examine the overall research question and provide the lessons learnt from the implementation.
The overall research question in this paper is how text-based and visual languages compare when used to implement smart agriculture applications. We address this research question with the specific research evaluation questions [EQ1], [EQ2], and [EQ3] introduced and described in section IV.
Different visual programming languages already exist in
the literature. In our implementation, we limit ourselves to
DisCoPar VDSL which falls within the family of flow-based
visual programming languages. In general, these languages
require modelling software applications as directed graphs
that connect networks of nodes. The nodes exchange data
via arcs connecting them. Applications take different names
depending on the language e.g., flows (Node-RED3, FRED
[
Writing software using textual languages still dominates the
current practice in application development [
Even though the approaches used in implementing our application yield two concrete and deployable applications with the same functionalities, there are key lessons learnt from the implementation and these are;
1) Programming effort and code reusability: Every functionality in WebLog was implemented from scratch and this required more programming effort. On the contrary, components were reused to implement UtafitiLog; only a few additional components were programmed to meet the application implementation requirements. UtafitiLog took faster to yield an application compared to WebLog, but required some changes to be done on DisCoPar. In general, visual components developed to implement UtafitiLog were reusable and helped reduce on the overall time taken to implement the application.
2) Cross-platform development: Though our applications were targeted for the Android platform, our implementation technologies support cross-platform development. This gave us room to write non-platform specific code that could be compiled to respective target platforms. This leads us to think that cross-platform development can serve different farmers with varied mobile hardware and software configurations.
3) Programming experience: Overall, while implementing WebLog required more programming expertise, using components to implement UtafitiLog required less programming expertise. Since, UtafitiLog demonstrates the simplified expressive power of VDSLs in representing software applications, we believe non-experienced programmers like farmers can use such technology to reconfigure their smart agriculture applications.
tools helped in implementing the application requirements and evaluating the performance of the implemented applications. As such, using software tools like editor, debuggers, monitors, and profilers boosts the process of implementing and evaluating smart agriculture applications.
plementing distributed applications. However, UtafitiLog uses scoped components that make implementing distributed applications easier for non-experienced programmers compared to WebLog. In WebLog, the client and server-side were implemented separately before linking them together.
6) Performance impact: There is no significant performance impact for the technologies used in implementing the two applications. Hence, we argue in support of the notion that using either a textual or a visual language yields applications with similar performance. This further implies that visual languages can be used as an alternative for building smart agriculture applications.
In this section, we present the related work on studies documenting experiences in implementing smart agriculture solutions and applications. To the best of our knowledge, there is no published report documenting experiences on implementing mobile applications for smart agriculture. We therefore, first, base our related work on experience reports for smart agriculture solutions addressing some of the issues described in section II. Secondly, we present related work on textual vs graphical representation of software applications.
Several studies document experiences in implementing
Internet of Things solutions for smart agriculture [
Several studies have focused on textual and graphical
representation of software. For instance, Heijstek et al. [
Labunets et al. [
Other studies have focused on making programming more
available to naive developers. For instance, the study done
by Mason and Dave [
Lastly, Sharafi et al. [
In this paper, we sought to understand how text-based and visual languages compare in implementing smart agriculture applications. We implemented exemplar smart agriculture applications using two different technologies resulting in two concrete and deployable applications with similar functionalities i.e., WebLog and UtafitiLog. WebLog was implemented using a text-based programming language while UtafitiLog was implemented using a VDSL. The findings show that both languages can be used to develop smart agriculture applications with similar performance. However, text-based languages require adequate prior programming experience compared to visual languages. VDSLs may provide a better alternative to allow non-experienced programmers (e.g., farmers) to adapt applications for different uses with minimal prior programming experience. Future work entails conducting controlled experiments to determine the cognitive load that textual and visual languages have on experienced and non-experienced application developers.
This work is supported by the Legumes Centre for Food and Nutrition Security (LCEFoNS) programme which is funded by VLIR-UOS. The programme is a North-South Collaboration between the Katholieke Universiteit Leuven, Vrije Universiteit Brussel (both in Belgium) and Jomo Kenyatta University of Agriculture and Technology (Kenya).