## 7 Results and Discussion
### Smart Cities: Portability of IoT Services in Different Districts  
The design of personalised applications represents one the main potentials of Appdaptivity. The data flow programming approach and the range of behaviours that can be defined with the PoCo components enable the definition of applications in a large set of areas in the widely expanded IoT field. To demonstrate this potential, we define a real use case and translate it into Appdaptivity. The goal of  
Figure 11: Response time with different numbers of user applications and the behaviour list of resources. this use case is to demonstrate how IoT applications can be created intuitively and agnosticly from the underlying IoT infrastructure with App adaptivity. In addition, the portability of the solution and personalised behaviours using resource-constrained devices. Consider a smart city with two districts. Both districts have different IoT services to allow the population to interact with, however the IoT services and networks can vary over the time. Therefore, to maintain the service continuity to the population without the need to install multiple applications or write specific and non-reusable code it is necessary to have a system that can cope with these challenges, and this is where App adaptivity can be applied. As mentioned above, the districts contain different IoT services. Let us suppose that in district D1, a light actuator is activated automatically when a presence is detected by a passive infrared sensor (PIR) or a illuminance sensor. The population could also query the luminosity measurements. On the other hand, in district D2, end users can control light actuators in a single way or individually, and see the average temperature in a chart. As the use case has different locations, the resulting data flow in the translation to App adaptivity should differentiate the behaviours for each district. In the D1 district, the luminosity control is managed automatically through an Actuation trigger component which receives the list of lights to interact with and an alert once a presence has been detected or the illuminance is lower than a given limit (e.g., 30%). This component sends the list of lights to trigger the send request component which is responsible for making these requests. The population can query the illuminance sensors directly in their applications through a direct connection of the illuminance sensors to the user applications. In the D2 district, the population obtains a chart of average temperature. Lastly, the lights can be controlled directly, sending the light resources to the user applications, and controlled in a group-way with the creation of a group. Figure 12 displays the resulting App adaptivity flow from the smart city use case presented. The mandatory components to enable the discovery of the underlying IoT and exchange information with the user applications have been grouped into two subflow components (Discovery and Output), so that the rest of components are PoCo components to define the use case behaviours. The development with just 20 components, shows the potential of App adaptivity for the intuitive development of an IoT use case. 6 LoWPAN has been choosen as the communication medium to deploy the smart city use case. 6 LoWPAN enables the transmission of IPv6 packets over constrained networks, thereby providing an IPv6 address for each device that will be IP-accessible through the Internet. The CoAP network comprises four Zolertia RE-Mote (Zolertia RE-Mote platform: [[https://github.com/Zolertia/Resources/wiki/RE-Mote](https://github.com/Zolertia/Resources/wiki/RE-Mote)]([https://github.com/Zolertia/Resources/wiki/RE-Mote](https://github.com/Zolertia/Resources/wiki/RE-Mote))) devices, two for each district. The Zolertia RE-Mote is a hardware development platform which provides support for 2.4-GHz and 863-950-MHz IEEE 802.15.4 and  
Figure 12: Smart-city use case translated into a App adaptivity flow. ZigBee compliant radios with low consumption.