Building blocks

Here we can find an overview of the building blocks of our application, some of them were also the mandatory requirements of our project. We have a responsive layout, since we used the ConstraintLayout of Android supporting also landscape mode for every view, Google and Facebook sign in/sign up in our login, a multi-thread application, since many of our operations cannot be performed on the UI thread because we would like to prevent a bad UX and finally we deployed a personal backend on our RaspberryPi, supported by an external storage service by Firebase.

Application architecture

The following scheme briefly describe in a simple way what is the main architecture of our application and how the different components communicate among them.

We used a server built on top of a RaspberryPi to develop the main feature of the our video surveillance system and our client application communicate with it in order to control the camera in a ubiquitous way. In other words, no matter where the user is, he can move the camera, take snapshots, activate the motion detection or face recognition mode and receive notifications if a stranger breaks in.

Design pattern

In this section will be describe the software design pattern of SmartPi application. We used Android Studio for developing the front-end and we write the app in Kotlin, in order to try something different from Java. The design of the application is based on the Model View ViewModel (MVVM), since we tried to follow the suggestions of the Android documentation.

Concept of activity

Every Android App is made up of activities that initiates code invoking specific callbacks methods. The activity typically provides the screen where the user interaction takes place and it can occupy the whole screen or not, so one application can contain more activities or fragments. Furthermore an activity can host one or more fragments (a sort of “sub-activity”) to support more dynamic and flexible UI, more info can be find in the official developer android documentation.

Model View ViewModel

Apart from the official documentation there is an interesting article on Medium that explain in a clever and fast way the MVVM design architecture, that you can find here. Basically, the most important principle to follow is the separation of concern, trying to avoid to write all the code inside the activity or the fragment.

We tried to stick to this principle as much as possible, but since this was our first experience with this paradigm, we achieved a pretty good result but is not perfect, since in some occasion we give to much importance to the view model, we allow it to call some Web API and this may not result in a very desirable user experience. In practice, the view model should not be aware of the how data are fetched, namely how the model is provided, it should only react to UI interaction and perform the action triggered by the user. Moreover, talking about the view model we really find very useful the presence of LiveData and MutableLiveData. Live data are observable data holder, that allow to monitor the changes of data without creating explicit and rigid dependency paths between them. Now, suppose that you want to add a new room to your house and you would like to modify displayed number of rooms immediately, instead reassign the value, you can simple observe the data, with the following lines of code:

viewModel._roomNumbers.observe(viewLifecycleOwner, Observer {
          // ...
       })

Lesson learned

We were glad to learn something new, but we still not get used to this kind of model, changes are not always easy and this transition may take a while. Personally, we like more some features of the MVC and our mindset is more close to this kind of paradigm, but we would like to get more experienced with the MVVM, try to understand its idea by writing more code and hopefully by updating and deploying new functionalities to smartPi application.