Developing Smart Agriculture Applications: Experiences and Lessons Learnt Isaac Nyabisa Oteyo, Kennedy Kambona, Jesse Zaman, Wolfgang De Meuter, and Elisa Gonzalez Boix Software Languages Lab, Vrije Universiteit Brussel, Pleinlaan 2 1050 Brussels, Belgium Abstract—Smart agriculture applications are promising to This study considers exemplars of two concrete and deploy- improve traditional agriculture in developing regions. Farmers able smart agriculture applications (WebLog and UtafitiLog) use these applications to collect data on agricultural activities implemented using two different technologies. The study de- and monitor different conditions in modern farms. However, from the development point of view, these applications are fines a set of parameters to evaluate these exemplars from often implemented using text-based programming languages that which lessons are drawn that can bee generalised to other require experienced programmers. Visual languages can be an smart agriculture applications. This study is guided by the alternative to text-based languages that may allow non-expert following research question; programmers (e.g., farmers) to implement these applications and make adjustments to existing ones. This study considers • How do text-based and visual languages compare when two exemplars of concrete and deployable smart agriculture used to implement smart agriculture applications? applications (WebLog and UtafitiLog) developed using two dif- ferent technologies. The study defines a set of parameters to In the subsequent sections, the paper is organised as follows. evaluate these exemplars from which lessons are drawn that can Section II presents the motivation and running example on be generalised to other smart agriculture applications. smart agriculture applications. This is followed by the ap- Index Terms—mobile applications, smart agriculture, dis- plication implementations in section III. Section IV presents tributed computing the evaluation and comparison, while section V presents the discussions and the lessons learnt from the implementation. I. I NTRODUCTION Section VI presents the related work and lastly, section VII presents the conclusions and gives directions for future work. Smart agriculture aims to improve processes in modern farms to handle the increasing global demand for food. In II. S MART AGRICULTURE APPLICATION developing regions, smart agriculture is partially realised by means of distributed mobile applications running on smart- In this work, we focus on small-scale farmers in devel- phones. Farmers in these regions have the applications in- oping regions requiring distributed mobile smart agriculture stalled and configured on their smartphones from where they applications to collect different kinds of data. The data is can collect data and monitor environmental conditions on the collected in a remote farm that is faced with intermittent farm. Farming activities in these regions happen in small scale network connection issues. Data gathered from a variety of farms [1] typically located in remote areas that are faced with weather sensors in the farm (e.g., temperature and humidity intermittent network connection issues [2]–[5]. These inter- sensors) is uploaded automatically to a server and can be mittent network connection issues contribute towards lowering used by the farmer to make informed decisions on required adoption rates for smart agriculture applications in developing agronomic practices such as initiating programmed misting regions. Also, the nature of modern farms requires distributed of crops when temperatures exceed a set threshold. Changes mobile applications that can be reconfigured to serve different in the data collected from the weather sensors are expected crops and farming seasons [6] i.e., the data parameters to be to reflect in real-time once uploaded onto the server. Using collected vary for various crops and farming seasons. These the distributed mobile application, the farmer can scan a crop applications require to be extended and reconfigured to meet label to invoke an interactive data input form that is adjustable the varying data parameters for various crops or farming depending on parameters of interest. These parameters may seasons. Hence, developing mobile software applications is vary with regard to the farming season or type of crop, among emerging as one of the vital sectors in smart agriculture to others. promote sustainable food security [7]. However, programmers To guide our implementation, we derived the following face several challenges while developing these applications functional requirements; (i) user login to access application [8]; (i) changing application scenarios and as a consequence services, (ii) viewing weather data on a dashboard, (iii) tagging application requirements, (ii) limited development time, and and scanning plant labels, (iv) generating data collection (iii) intermittent network connection issues. During implemen- surveys, (v) saving collected data to a database, (vi) fetching tation, developers can use either text-based or visual languages and receiving data from weather sensors, (vii) generating alerts to address the aforementioned concerns and the resulting based on set thresholds, and (viii) storing data on the mobile challenges. 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 dashboard to the server. Both applications are targeted to run (non-functional) requirements that form the key features for on the Android platform since it is a popular platform in modern smart agriculture applications in developing regions. developing regions [11], [12]. As shown in Fig. 1, the mobile • Offline accessibility: The application should continue application and web dashboard communicate with the server functioning whenever the network connection becomes via RESTful APIs, HTTP requests, and web sockets. Sensor unavailable. The application should use a client-side data coming from the sensor cloud is saved to the server database to store data locally on the mobile device while from where it is reactively pushed to the mobile client and waiting for the network connection to be regained. dashboard using web sockets. Communication between the • Reactivity: The application should respond to events server and clients happens through web sockets. originating from the external environment in real-time. Also, the application should support generating relevant Client-side Server-side Sensor Pressure notifications as soon as data from sensors is received cloud (delta, m) to motivate farming decisions, e.g., misting crops when Web dashboard Com Humidity m unic ation (delta, m) temperatures exceed certain thresholds. • Reconfigurability: It should be possible to change and Temperature (delta, m) adapt existing application components to fit different Server scenarios after the initial development. For example, it should be possible to change the data collection survey on icati Datastore to meet data collection requirements for different farming mun Mobile app Com seasons or crops. External environment • Extensibility: It should be possible to add new features and services to the application after implementation, Fig. 1: High level distributed application architecture e.g., by supporting Applications Programming Interfaces (APIs) or reusable components. B. WebLog Based on these requirements, our goal was to get insights on developing smart agriculture applications for small-scale In WebLog, the mobile application, server, and web dash- farmers in developing regions. We conducted preliminary board are implemented in JavaScript. React-Native and Reac- experiments to compare the technologies used in implementing tJS frameworks were used to implement the mobile application the exemplar applications and provide the lessons learnt. The and web dashboard respectively. The server was implemented implemented applications meet the requirements derived in using Node.js linked to MongoDB for data storage. The mobile this section. WebLog was implemented using React-Native application is composed of different parts (views/screens) framework for JavaScript while UtafitiLog was implemented implemented as React-Native components (e.g., Login, Scan, using DisCoPar [9]. DisCoPar is a reactive visual domain- SensorData, DataCollection components etc.) to realise the specific language (VDSL) specially designed for implementing services the application offers. The application dashboard is citizen science observatories in which applications are repre- the entry point that anchors all application views to one central sented as visual flow-graphs [10]. navigation point. From the anchor point, users can navigate to the various sections of the application. III. A PPLICATION IMPLEMENTATIONS WebLog adheres to the previously identified requirements as In this section, we describe the implementation details for follows; WebLog and UtafitiLog following the requirements identified 1) Offline accessibility: WebLog uses a client-side database in section II. These requirements were translated into appli- that runs on the mobile device to store data whenever the cation modules to support modular design with APIs. The network becomes unavailable. The application keeps a counter development process followed an incremental and iterative that indicates to the user the number of unsynchronised mechanism. This enabled documenting the design process, records. If a farmer is collecting plant morphological data results, and lessons learnt throughout the development phases. and a network disconnection occurs before sending the data One developer was engaged in implementing both applica- to the server, the data is saved locally awaiting the network tions. As previously mentioned, WebLog and UtafitiLog were reconnection. When the network becomes unavailable, the implemented using text-based and visual languages respec- application creates a database on the mobile device to save tively. data as illustrated in Fig. 2. The application uploads locally stored data to the remote server when the network becomes A. Application Architecture available and deletes the local copies to free up storage space. The architecture for both applications is presented in Fig. 1. 2) Reactivity: Code Listing 1 shows the specification for Both applications provide similar services that are linked to a sending weather data to clients via sockets. Clients have to Node.js server. The applications consist of an Android mobile register to receive updates from the defined socket. New data application to gather data, a server to store the collected data updates are automatically pushed to the client (line 14 in code and generate notifications, and a web client that acts as a Listing 1). For example, the application provides a service to Connection available C. UtafitiLog Mobile app Remote database As mentioned before, UtafitiLog was implemented using Connection DisCoPar, a VDSL for visual programming designed for unavailable building applications for citizen science observatories (CSOs) Connection regained Upload data [10]. In DisCoPar, programs are constructed by means of vi- Client-side to remote database server sual components. These components have an execution scope i.e., mobile, server, and web. To build an application, the Upload Delete local data components are wired together into a flow-graph using arcs copies and application components use these arcs to exchange data. Fig. 3 shows the application flow-graph for UtafitiLog. The Fig. 2: Offline accessibility in WebLog flow-graph is read from left to right. Each connection has an arrow on it indicating the direction of data flow. By design, the application flow-graph is a directed acyclic graph. Each monitor temperature, humidity, and pressure conditions. This component is coloured based on its execution scope1 . This data is displayed on a component that is updated whenever execution scope facilitates building distributed applications. the server receives new data. Components have output ports for emitting data and input ports for receiving data. These ports are typed based 1 sendSensorDataToClients = data => { on the data that they emit or receive. On the application flow- 2 const socketIds = Object.keys(this. graph (Fig. 3), each port is colour-coded with the type of data sockets); it emits or receives2 . The arcs connecting components on the 3 let allSockets = this.sockets; application flow-graph assume the colour of the origin port. 4 if (socketIds.length === 0) { These arcs represent data dependencies and always flow from 5 console.log("No client sockets."); the output ports of source components to the input ports of 6 return; destination components. To explain these data dependencies, 7 } we split them into output and input data dependencies. Each 8 const dataToSend = { component has at least one input or output data dependency 9 Temperature: data.temperature, with some components having multiple data dependencies 10 Humidity: data.humidity because of having multiple input or output ports. 11 }; To implement UtafitiLog, we first identified the components 12 console.log("Sending sensor data!"); that we required. The application flow-graph illustrated in 13 socketIds.forEach(socketId => { Fig. 3 uses 26 components. Out of the 26, we reused 20 14 allSockets[socketId].emit(" components from the existing component library. We im- socket_name", dataToSend); plemented the remaining 6 components and published them 15 }); to the component library. In regard to component scope, 6 16 }; components execute on the mobile device (i.e., Scan, Observa- tionPopSurvey, BufferObservation, and Label), 9 components Listing 1: Sending weather data to clients via sockets execute on the web (i.e., Label, LineChart, Alert, and Table), and 11 components execute on the server (i.e., SensorWeather, Also, notifications are generated based on set thresholds. For Rounding, IsGreaterThan, AddDataToObservation, Observa- example, to generate alerts, we can set the threshold values tionDatabase, and ObservationToTable). at 25◦ C and 35% for temperature and humidity in tropical In Fig. 3, SensorWeather receives temperature, humidity, regions respectively. and pressure weather data from the sensor cloud and passes 3) Reconfigurability: WebLog can be used to collect differ- it as numeric values to the Rounding components that are ent kinds of data. Each time a data collection instance is cre- used to set the precision level. SensorWeather component ated, it requires generating the corresponding data collection emits numeric data values which are accepted as input to survey. Also, threshold values to generate notifications in [R2 ] the Rounding component. Data values (numeric) from the can be changed to fit different scenarios. The data collection Rounding component are passed to the Label components for survey and threshold values for notifications can be changed display and the LineChart components for visualisation on by non-experienced programmers e.g., farmers via provided the dashboard. To generate notifications, the data is passed reconfiguration interfaces. 1 Black coloured components execute on mobile device; grey coloured 4) Extensibility: WebLog has been implemented as a textual components execute on the web; and light-grey coloured components execute component-based system with APIs that allow extending the on the server. 2 Blue coloured ports receive or emit numeric data values; black ports application with new services. However, this extensibility is receive or emit any data values; orange coloured ports emit or receive done in code since WebLog was implemented using a textual boolean values; green coloured ports emit or receive observations; language. and yellow coloured ports emit or receive datasets Fig. 3: UtafitiLog flow-graph showing component connections from left to right. The arrows on the connections show the direction of data flow. Black, grey, and light-grey coloured components execute on the mobile, web, and server in that order. through IsGreaterThan component where thresholds are set. 3) Reconfigurability: The data collection survey is imple- IsGreaterThan component accepts numeric data values and mented as a reconfigurable component to allow collection of outputs boolean values. The input value is compared to the different kinds of data. For example, each time the farming set threshold and if it evaluates to true, a notification is season changes and the data collection parameters change, fired. The Alert component is used to display the notification the survey component is reconfigured to reflect the new data message on the dashboard. Scanning of plant labels is done via parameters. Also, threshold values for generating notifications the Scan component while creating data collection surveys is can be changed for different farming scenarios. The Obser- done using the ObservationPopUpSurvey. BufferObservation vationPopUpSurvey and IsGreaterThan components are easily component supports offline accessibility while Observation- reconfigurable with minimal programming experience e.g., by Database component connects the application to the database. farmers. AddDataToObservation component is used to aggregate data 4) Extensibility: Adding new features or functionalities to (observations) from different components. the application is done by incorporating components from the UtafitiLog adheres to the previously identified requirements component library to the application flow-graph. The applica- as follows; tion flow-graph can also be updated by removing components. 1) Offline accessibility: The BufferObservation component Both adding and removing components can be done even when is used to support offline accessibility by keeping copies of the application is already deployed. data on a client-side database each time the network breaks. The data collected when the network is unavailable is sent to D. Application Services the remote server when the network is regained. To provide the functionality described in section II, both 2) Reactivity: UtafitiLog exploits the reactive and event- applications provide similar services i.e., (i) user registration, driven design of DisCoPar VDSL ensuring the application (ii) plant label scanning, (iii) generating data collection sur- components continue executing whenever they receive data veys, (iv) generating alerts based on weather information, and on their input ports. The execution of one component in the (v) visualising weather information on a dashboard. These application flow-graph triggers the execution of subsequent applications present two perspectives to users; one perspective components that depend on the output from the previous com- for logged in users and another for visitors. By default, a ponent. Also, notifications are generated based on threshold landing page is presented to a user visiting the application values. In our application, using IsGreaterThan component we and is not yet logged in. This default landing page allows the can set 25◦ C and 35% threshold values for temperature and user to navigate to the registration page to create an account or humidity in a tropical region respectively. login page for authorisation and authentication to proceed to other application services. User registration is a public service the farmer to reuse the same applications to collect different that allows users to sign up into the application. Once logged kinds of information on the farm for different farming seasons in, the user can proceed to the application dashboard from or various crops. where one can navigate to different sections of the application. 4) Extensibility: Both applications are extensible to add The scanning service uses the device camera to read the new features and functionalities. Since each service in WebLog plant labels and invoke the data collection surveys which are is implemented as a textual component, extending the appli- generated in both applications. Also, the alerts in the two cation requires coding. Extensibility in UtafitiLog happens at applications are displayed on the web dashboard based on two levels; (i) at the code level to add new components to the adjustable thresholds. component library and (ii) the application flow-graph level to add or remove features from an existing application. Also, IV. E VALUATION AND C OMPARISON both applications support APIs for programmers to extend In this section, we compare WebLog and UtafitiLog. We use application services. Since both applications are implemented the features derived in section II as the primary criteria for as components (either textual or visual components) they qualitative evaluation. Since both applications support similar support variability. In this case, variability allows reconfiguring features and functionalities, and both are implemented in the and extending the applications to meet new or changing same software stack, we postulate that both implementations requirements i.e., adaptation [17]. For example, anticipating exhibits similar performance. Therefore, the evaluation in this changing thresholds to generate alerts and allowing the user to study is focused on the following questions; change them appropriately. The user can also specify the alert • [EQ1 ] Which strategies are followed to implement the messages and change the data collection surveys. Application requirements identified in section II? flow-graph for UtafitiLog is changeable to add or remove • [EQ2 ] What is the disk space utilisation for the imple- components. Changes done at the application flow-graph level mented applications? require minimal programming experience and therefore can be • [EQ3 ] How do the implemented applications compare to considered suitable for non-experienced programmers. other smart agriculture applications? B. Disk Space Utilisation A. Implementation Strategies Farmers in developing regions operate in remote areas In this section, we compare the implementation strategies and in most cases depend on paid mobile data to download used by both applications to adhere to the requirements in and install applications on their mobile devices. The cost of section II. mobile data positively correlates to the size of applications 1) Offline accessibility: Both applications support offline to download. Therefore, in this section, we measured (i) the accessibility by keeping copies of data in a client-side database size of the compiled application i.e., downloadable APK size, whenever the network becomes unavailable. Different strate- and (ii) disk space utilised by the installed application on the gies exist in the literature for implementing offline accessibility mobile device. The second parameter is important especially e.g., caching, local storage, and client-side database [13]–[15]. for resource constrained devices that, typically, have limited Caching and local storage have limitations of size which are persistent memory available. In terms of downloadable APK addressed by the client-side database strategy [16]. The use file size, WebLog and UtafitiLog resulted in 25 MB and 10.8 of a database running on mobile devices for data storage MB respectively. In terms of disk space, WebLog utilised significantly eliminates the need for infrastructure to host 122 MB, while UtafitiLog used 36.04 MB. The substantially database servers in the farm. It also eliminates the need for more disk space used by WebLog could be as a result of middleware to cache data in the cloud. insufficient compaction of the application bytecode. Also, 2) Reactivity: Both applications support reactivity in differ- React Native builds native libraries for armebi and x86 ent ways. UtafitiLog exploits the reactive and event-driven de- device architectures into the same APK, hence the larger APK sign of DisCoPar VDSL that ensures application components size in WebLog compared to UtafitiLog. To minimise this size, continue executing as long as they keep receiving data on their it requires creating APKs for each device architecture. input ports. Execution of one component in the application flow-graph triggers the execution of subsequent components C. Comparison to other Smart Agriculture Applications that depend on the output from the previous component. The applications presented in Table I support different activ- WebLog utilises reactive libraries to implement web sockets ities on the farm e.g., crop disease diagnosis [18]; monitoring that push data to clients. Clients have to register to receive [19]–[23]; crop nutrient computation [24]; data collection [13], data from these sockets; new data is automatically pushed to [25]; and cost management [26]. Only MobiCrop [13] supports the client. offline accessibility through caching which has limitations of 3) Reconfigurability: Both applications support reconfig- storage size. Unlike most of the existing smart agriculture urability to adapt to different requirements within the farm. For applications, WebLog and UtafitiLog are offline accessible, example, changing the data collection surveys to fit different reactive, and reconfigurable. The implementations support crops or farming seasons, the two applications make use of APIs and components that allow extending the applications reconfigurable data collection surveys. This makes it easier for to add new services. TABLE I: Comparing smart agriculture applications textual languages have been used in software development for Offline accessible Reactive Reconfigurable Extensible years they still face some limitations that can be overcome by MobiCrop [13] 3∗ 7 7 3† visual languages, e.g., the cognitive load that they impose on Blynk [21] 7 7 3⋆ 7 non-expert programmers as opposed to visual languages [32]. AgDataBox [25] 7 7 7 3† SmartHof [22] 7 7 7 3† Even though, visual languages promise a better alternative Connected Farm [23] 7 7 7 3† to application development, the visual components are still CLUeFARM [27] 7 7 3⋆ 3† implemented using textual languages. This means the under- WebLog 3∗∗ 3 3⋆⋆ 3† lying architectures for visual languages have to be properly UtafitiLog 3∗∗ 3 3⋆⋆ 3†† and adequately crafted to allow easy addition of new visual 3∗ caching; 3∗∗ client-side database; 3⋆ widgets; 3⋆⋆ configurable surveys; 3† REST APIs; 3†† REST APIs and visual components programming constructs. Both text-based and visual languages can be used to develop smart agriculture applications with similar features. However, we take the view that text-based languages require adequate prior programming experience V. D ISCUSSION AND LESSONS LEARNT compared to visual languages. From the implementation expe- In this section, we discuss how text-based and visual lan- rience, several differences become apparent and we raise them guages compare in implementing smart agriculture applica- in the subsequent section as lessons learnt. tions. We re-examine the overall research question and provide the lessons learnt from the implementation. B. Lessons Learnt Even though the approaches used in implementing our A. Text-based vs. Visual Languages application yield two concrete and deployable applications The overall research question in this paper is how text-based with the same functionalities, there are key lessons learnt from and visual languages compare when used to implement smart the implementation and these are; agriculture applications. We address this research question 1) Programming effort and code reusability: Every func- with the specific research evaluation questions [EQ1 ], [EQ2 ], tionality in WebLog was implemented from scratch and this and [EQ3 ] introduced and described in section IV. required more programming effort. On the contrary, com- Different visual programming languages already exist in ponents were reused to implement UtafitiLog; only a few the literature. In our implementation, we limit ourselves to additional components were programmed to meet the appli- DisCoPar VDSL which falls within the family of flow-based cation implementation requirements. UtafitiLog took faster visual programming languages. In general, these languages to yield an application compared to WebLog, but required require modelling software applications as directed graphs some changes to be done on DisCoPar. In general, visual that connect networks of nodes. The nodes exchange data components developed to implement UtafitiLog were reusable via arcs connecting them. Applications take different names and helped reduce on the overall time taken to implement the depending on the language e.g., flows (Node-RED3 , FRED application. [28], and D-NR [29]), pipes (NoFlo4 , WotKit [30]), and 2) Cross-platform development: Though our applications process (MsgFlo5 ). Also, these languages provide different were targeted for the Android platform, our implementation constructs for application development e.g., nodes (Node- technologies support cross-platform development. This gave RED, D-NR, FRED, and NoFlo), components (MsgFlo, us room to write non-platform specific code that could be DisCoPar), and processors (WotKit). The languages fur- compiled to respective target platforms. This leads us to think ther provide channels to link different logical entities of that cross-platform development can serve different farmers an application. These channels are mainly wires (Node- with varied mobile hardware and software configurations. RED, D-NR, and FRED) and edges (NoFlo, MsgFlo, and 3) Programming experience: Overall, while implementing WotKit). Applications in these languages are presented as WebLog required more programming expertise, using com- graphs and application components react to any incoming data ponents to implement UtafitiLog required less programming on their input ports. Apart from DisCoPar, none of the other expertise. Since, UtafitiLog demonstrates the simplified ex- surveyed languages supports mobile applications i.e., they do pressive power of VDSLs in representing software applica- not support exporting application flow-graphs for execution in tions, we believe non-experienced programmers like farmers mobile platforms. can use such technology to reconfigure their smart agriculture Writing software using textual languages still dominates the applications. current practice in application development [31]. In this paper, 4) Software development support: Relying on libraries and our choice for React-Native framework for WebLog implemen- tools helped in implementing the application requirements and tation was motivated by its support for cross-platform devel- evaluating the performance of the implemented applications. opment. Similarly, DisCoPar VDSL supports cross-platform As such, using software tools like editor, debuggers, monitors, development in addition to the visual components. Though and profilers boosts the process of implementing and evaluat- 3 https://nodered.org ing smart agriculture applications. 4 http://noflojs.org 5) Distributed applications: Both approaches support im- 5 https://msgflo.org/ plementing distributed applications. However, UtafitiLog uses scoped components that make implementing distributed appli- in both recall and precision. However, this is still subject to cations easier for non-experienced programmers compared to cognitive complexity of software tasks. WebLog. In WebLog, the client and server-side were imple- Other studies have focused on making programming more mented separately before linking them together. available to naive developers. For instance, the study done 6) Performance impact: There is no significant perfor- by Mason and Dave [39] compares block-based (visual) vs mance impact for the technologies used in implementing the flow-based programming for naive developers. With visual two applications. Hence, we argue in support of the notion that programming, non-programmers do not need to have the using either a textual or a visual language yields applications same investment in particular syntax or semantics for textual with similar performance. This further implies that visual languages. languages can be used as an alternative for building smart Lastly, Sharafi et al. [40] investigate modelling and present- agriculture applications. ing software requirements using graphical vs. textual represen- tations. The findings show no significant difference in using VI. R ELATED WORK either textual or graphical representations. However, the study In this section, we present the related work on studies notes that training developers can significantly improve the documenting experiences in implementing smart agriculture efficiency of using graphical representations. solutions and applications. To the best of our knowledge, VII. C ONCLUSION AND FUTURE WORK there is no published report documenting experiences on implementing mobile applications for smart agriculture. We In this paper, we sought to understand how text-based and therefore, first, base our related work on experience reports visual languages compare in implementing smart agriculture for smart agriculture solutions addressing some of the issues applications. We implemented exemplar smart agriculture ap- described in section II. Secondly, we present related work on plications using two different technologies resulting in two textual vs graphical representation of software applications. concrete and deployable applications with similar functional- ities i.e., WebLog and UtafitiLog. WebLog was implemented A. Smart Agriculture Solutions using a text-based programming language while UtafitiLog was implemented using a VDSL. The findings show that both Several studies document experiences in implementing In- languages can be used to develop smart agriculture applica- ternet of Things solutions for smart agriculture [33]–[35]. For tions with similar performance. However, text-based languages instance, Gunasekera et al. [33] document their experiences require adequate prior programming experience compared to in implementing IoT solutions to meet different changing visual languages. VDSLs may provide a better alternative to user requirements with less programming effort and also offer allow non-experienced programmers (e.g., farmers) to adapt offline accessibility. Though the work promises to offer offline applications for different uses with minimal prior program- accessibility, this is done by providing a feature to export data ming experience. Future work entails conducting controlled into CSV files for offline accessibility. Jayaraman et al. [34] experiments to determine the cognitive load that textual and report on building a smart agriculture platform that can allow visual languages have on experienced and non-experienced adding new sensors with ease and allow real-time analysis application developers. of data coming from the sensors. The study supports "do- it-yourself" concept for non-experienced programmers to add ACKNOWLEDGMENT new sensors to the platform and extend its functionality. In This work is supported by the Legumes Centre for Food and their implementation, they use query-processing to fetch data Nutrition Security (LCEFoNS) programme which is funded by and trigger events. VLIR-UOS. The programme is a North-South Collaboration B. Textual vs Graphical Software Representation between the Katholieke Universiteit Leuven, Vrije Universiteit Brussel (both in Belgium) and Jomo Kenyatta University of Several studies have focused on textual and graphical rep- Agriculture and Technology (Kenya). resentation of software. For instance, Heijstek et al. [36] analyse the effectiveness of visual or textual artefacts in R EFERENCES communicating software design decisions. The findings show [1] H. B. Fiehn, L. Schiebel, A. F. Avila, B. Miller, and A. Mickelson, that neither diagrams nor textual descriptions is significantly “Smart agriculture system based on deep learning,” in Proceedings of more efficient to communicate software design decisions to the 2nd International Conference on Smart Digital Environment. New York, NY, USA: ACM, 2018, pp. 158–165. developers. However, this may not apply to non-experienced [2] M. Bacco, P. Barsocchi, E. Ferro, A. Gotta, and M. Ruggeri, “The developers as highlighted in the study done by Jolak et al., Digitisation of Agriculture: A Survey of Research Activities on Smart [37] (preprint). The findings in this study show that describing Farming,” Array, vol. 3-4, pp. 1–11, 2019. [3] M. Ayaz, M. Ammad-Uddin, Z. Sharif, A. Mansour, and E.-H. M. software designs graphically is better than textual descriptions Aggoune, “Internet-of-Things (IoT)-Based Smart Agriculture: Toward i.e., graphical descriptions promote better recall for developers. Making the Fields Talk,” IEEE Access, vol. 7, pp. 129 551–129 583, Labunets et al. [38] investigate comprehending software 2019. [4] M. O’Grady, D. Langton, and G. O’Hare, “Edge computing: A tractable risk models using graphical, tabular, and textual notations. model for smart agriculture?” Artificial Intelligence in Agriculture, The findings show that the tabular notation is comprehensible vol. 3, pp. 42–51, 2019. [5] A. Eitzinger, J. Cock, K. Atzmanstorfer, C. R. Binder, P. Läderach, [23] M. Ryu, J. Yun, T. Miao, I. Y. Ahn, S. C. Choi, and J. Kim, “Design and O. Bonilla-Findji, M. Bartling, C. Mwongera, L. Zurita, and A. Jarvis, implementation of a connected farm for smart farming system,” 2015 “GeoFarmer: A monitoring and feedback system for agricultural devel- IEEE Sensors, pp. 1–4, 2015. opment projects,” Computers and Electronics in Agriculture, vol. 158, [24] M. V. Bueno-Delgado, J. M. Molina-Martínez, R. Correoso-Campillo, pp. 109–121, 2019. and P. Pavón-Mariño, “Ecofert: An Android application for the opti- [6] A. Kamilaris and A. Pitsillides, “Mobile Phone Computing and the mization of fertilizer cost in fertigation,” Computers and Electronics in Internet of Things: A Survey,” IEEE Internet of Things Journal, vol. 3, Agriculture, vol. 121, pp. 32–42, 2016. no. 6, pp. 885–898, 2016. [25] C. L. Bazzi, E. P. Jasse, P. S. Graziano Magalhães, G. K. Michelon, E. G. [7] C. S. M. Babou, B. O. Sane, I. Diane, and I. Niang, “Home edge com- de Souza, K. Schenatto, and R. Sobjak, “AgDataBox API – Integration puting architecture for smart and sustainable agriculture and breeding,” of data and software in precision agriculture,” SoftwareX, vol. 10, pp. in ACM International Conference Proceeding Series, 2019, pp. 1–7. 1–8, 2019. [8] S. Al-Ratrout, O. Husain Tarawneh, M. HusniAltarawneh, and M. Yosef [26] Y. Murakami, “iFarm: Development of web-based system of cultivation Altarawneh, “Mobile Application Development Methodologies Adopted and cost management for agriculture,” in Proceedings of the 8th In- in Omani Market: A Comparative Study,” International Journal of ternational Conference on Complex, Intelligent and Software Intensive Software Engineering & Applications, vol. 10, no. 2, pp. 13–22, 2019. Systems, 2014, pp. 624–627. [27] M. Colezea, G. Musat, F. Pop, C. Negru, A. Dumitrascu, and M. Mo- [9] J. Zaman, K. Kambona, and W. De Meuter, “DISCOPAR: A Visual canu, “CLUeFARM: Integrated web-service platform for smart farms,” Reactive Programming Language for Generating Cloud-Based Partici- Computers and Electronics in Agriculture, vol. 154, pp. 134–154, 2018. patory Sensing Platforms,” in Proceedings of the 5th ACM SIGPLAN [28] M. Blackstock and R. Lea, “FRED: A Hosted Data Flow Platform for International Workshop on Reactive and Event-Based Languages and the IoT,” in Proceedings of the 1st International Workshop on Mashups Systems. New York, NY, USA: ACM, 2018, pp. 31–40. of Things and APIs, 2016, pp. 2:1–2:5. [10] J. Zaman and W. De Meuter, “DisCoPar: Distributed Components for [29] N. K. Giang, M. Blackstock, R. Lea, and V. C. Leung, “Developing Participatory Campaigning,” in 2015 IEEE International Conference on IoT applications in the Fog: A Distributed Dataflow approach,” in Pervasive Computing and Communication Workshops, 2015, pp. 160– Proceedings - 2015 5th International Conference on the Internet of 165. Things, IoT 2015. IEEE, 2015, pp. 155–162. [11] K. Heimerl, A. Menon, S. Hasan, K. Ali, E. Brewer, and T. Parikh, [30] M. Blackstock and R. Lea, “IoT mashups with the WoTKit,” in Pro- “Analysis of Smartphone Adoption and Usage in a Rural Community ceedings of 2012 International Conference on the Internet of Things, Cellular Network,” in ACM International Conference Proceeding Series, IOT 2012. Wuxi, China: IEEE, 2012, pp. 159–166. vol. 15, Singapore, 2015, pp. 1–4. [31] J. A. Wang, “Towards component-based software engineering,” Journal [12] S. Ahmad, A. L. Haamid, Z. A. Qazi, Z. Zhou, T. Benson, and I. A. Qazi, of Computing in Small Colleges, vol. 16, pp. 182–194, 2000. “A view from the other side: Understanding mobile phone characteristics [32] K. J. Harms, “Applying cognitive load theory to generate effective in the developing world,” in Proceedings of the ACM SIGCOMM programming tutorials,” in 2013 IEEE Symposium on Visual Languages Internet Measurement Conference, Santa Monica, CA, 2016, pp. 319– and Human Centric Computing, 2013, pp. 179–180. 325. [33] K. Gunasekera, A. N. Borrero, F. Vasuian, and K. P. Bryceson, “Ex- [13] R. K. Lomotey, Y. Chai, A. K. Ahmed, and R. Deters, “Distributed periences in building an IoT infrastructure for agriculture education,” mobile application for crop farmers,” in MEDES’13 Proceedings of Procedia Computer Science, vol. 135, pp. 155–162, 2018. the Fifth International Conference on Management of Emergent Digital [34] P. P. Jayaraman, A. Yavari, D. Georgakopoulos, A. Morshed, and A. Za- EcoSystems, Luxembourg, 2013, pp. 135–139. slavsky, “Internet of things platform for smart farming: Experiences and [14] C. Liu, B. C. Fruin, and H. Samet, “SAC: Semantic Adaptive Caching for lessons learnt,” Sensors, vol. 16, no. 11, pp. 1–17, 2016. Spatial Mobile Applications,” in Proceedings of the 21st ACM SIGSPA- [35] N. Dlodlo and J. Kalezhi, “The internet of things in agriculture for TIAL International Conference on Advances in Geographic Information sustainable rural development,” in Proceedings of 2015 International Systems. New York, NY, USA: ACM, 2013, pp. 174–183. Conference on Emerging Trends in Networks and Computer Communi- [15] F. A. Marco, J. Gallud, V. M. R. Penichet, and M. Winckler, “A Model- cations, 2015, pp. 13–18. Based Approach for Supporting Offline Interaction with Web Sites [36] W. Heijstek, T. Kühne, and M. R. V. Chaudron, “Experimental analysis Resilient to Interruptions,” in Current Trends in Web Engineering, Q. Z. of textual and graphical representations for software architecture design,” Sheng and J. Kjeldskov, Eds. Cham: Springer International Publishing, in 2011 International Symposium on Empirical Software Engineering 2013, pp. 156–171. and Measurement. IEEE, 2011, pp. 167–176. [37] R. Jolak, M. Savary-Lelanc, M. Dalibor, A. Wortmann, R. Hebig, [16] A. Wharry, “HTML5 Offline Technologies,” 2014. [Online]. Available: J. Vincur, I. Polasek, X. Le Pallec, S. Gerard, and M. Chaudron, http://andreawharry.com/assets/img/portfolio/WharryAndreaFinalPaper.pdf “Software Engineering Whispers: The Effect of Textual Vs. Graphical [17] A. Fortier, G. Rossi, S. E. Gordillo, and C. Challiol, “Dealing with Software Design Descriptions on Software Design Communication,” variability in context-aware mobile software,” The Journal of Systems EMSE Journal. and Software, vol. 83, no. 6, pp. 915–936, 2010. [38] K. Labunets, F. Massacci, and A. Tedeschi, “Graphical vs. tabular [18] M. A. Carmona, F. J. Sautua, O. Pérez-Hernández, and J. I. Mandolesi, notations for risk models: On the role of textual labels and complexity,” “AgroDecisor EFC: First Android™ app decision support tool for timing in 2017 ACM/IEEE International Symposium on Empirical Software fungicide applications for management of late-season soybean diseases,” Engineering and Measurement. IEEE, 2017, pp. 267–276. Computers and Electronics in Agriculture, vol. 144, pp. 310–313, 2018. [39] D. Mason and K. Dave, “Block-based versus flow-based programming [19] M. F. Işik, Y. Sönmez, C. Yilmaz, V. Özdemir, and E. N. Yilmaz, “Preci- for naive programmers,” in 2017 IEEE Blocks and Beyond Workshop. sion Irrigation System (PIS) using sensor network technology integrated IEEE, 2017, pp. 25–28. with IOS/Android Application,” Applied Sciences (Switzerland), vol. 7, [40] Z. Sharafi, A. Marchetto, A. Susi, G. Antoniol, and Y. Guéhéneuc, “An no. 891, pp. 1–14, 2017. empirical study on the efficiency of graphical vs. textual representations [20] M. Caria, J. Schudrowitz, A. Jukan, and N. Kemper, “Smart farm in requirements comprehension,” in 2013 21st International Conference computing systems for animal welfare monitoring,” in 2017 40th In- on Program Comprehension. IEEE, 2013, pp. 33–42. ternational Convention on Information and Communication Technology, Electronics and Microelectronics, 2017, pp. 152–157. [21] P. Serikul, N. Nakpong, and N. Nakjuatong, “Smart Farm Monitoring via the Blynk IoT Platform,” in 2018 Sixteenth International Conference on ICT and Knowledge Engineering. Bangkok, Thailand: IEEE, 2018, pp. 70–75. [22] F. Carpio, A. Jukan, A. I. M. Sanchez, N. Amla, N. Kemper, A. Isabel, M. Sanchez, N. Amla, and N. Kemper, “Beyond Production Indicators: A Novel Smart Farming Application and System for Animal Welfare,” in Proceedings of the Fourth International Conference on Animal- Computer Interaction, 2017, pp. 7:1–7:11.