If you find that you’re spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you’re spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice.
– Donald Knuth
This week we started working on our projects. On Monday, we had our first sprint meeting. Islam and Hind discussed the tasks with us and what we needed to focus on doing for the duration of the sprint. The project that I will be working on is called Balsam.
To start contributing to the project, I first read and understood the project source code. I also read about Retrofit, the REST client used in the project.
First Task: Login Screen
For my first task, I had to develop a login screen for the users of the app. There was already a login screen that is partially implemented, built on the MVP architecture. As the company has switched to using MVVM architecture pattern in its apps, I had to refactor a lot of the code from MVP to MVVM and implement the missing parts. This meant I had to transform the presenter class into a view model, changing the flow of control. The main difference between these two patterns is the how events or updating the view is implemented. Also, the presenter keeps a reference to the view, while the view model does not. Using MVVM has eliminated lots of the boilerplate and complexity of MVP. This doesn’t mean MVVM is in itself less complex really, but the fact that Android helps you designing apps using this pattern makes it easier in this context.
In MVVM, the ViewModel exposes the required data and interested parties can listen to it. For the firing of events MVVM is normally used with data binding or LiveData. The Android framework developers have actually implemented classes (those in the Android Architecture Component which is a collection of libraries that helps you design robust, testable, and maintainable apps) to help develop apps using the MVVM architecture. one of these classes is the AndroidViewModel, which makes the view models aware of the application context. The second class is the LiveData class which is a lifecycle-aware observable. Armed with these two classes building an app using MVVM becomes an easy task to do cleanly.
The LiveData Class
The AndroidViewModel doesn’t really do much, but I want to briefly talk about the LiveData class. Instances of the LiveData class hold data that can be observed within a given lifecycle (the observer is paired with a lifecycle owner, which is typically a fragment or an activity.) This means that the observer is automatically removed when the lifecycle owner moves to the destroyed state. The last interesting property of LiveData is its ability to retain its state between configuration changes, this makes for a cleaner code that is not bloated with code for managing that.
The SingleLiveEvent Class
Its not always desirable to retain the state, Think of the case of error signaling, showing a toast or a snackbar. It would be better if the state is reset when a configuration change occurs, but we also would like to keep the properties of LiveData, and this is exactly what the SingleLiveEvent class offers.
Developing the login screen, I learned a lot about AndroidViewModel, LiveData, SingleLiveEvent, and retrofit. This concluded my first task, I felt so proud moving this task from todo to done log.
Second Task: Displaying a List of Payments
I added the activity for displaying the list of payments, this list contains a bunch of details which for displaying it I used the RecyclerView. I started by designing the layouts of the list. There were a bunch of features I needed to support, like swiping for refreshing and endless scrolling effect. The interesting part of this was implementing the endless scrolling. At first I didn’t have a clear idea of how to do it, I spent a lots of my time doing it in different ways. Eventually I used two kinds of layouts to inflate in the adapter depending on what was in the list.
Wrapping Up
One thing that is still annoying me is the amount of state the view model of the payment list stores to achieve its task, I think it can be refactored to store less state than what it currently stores, but this was my first implementation of it and I hope I get some time to refactor it. The implementation of the adapter is also not as efficient as possible, in particular using DiffUtil and ListAdapter could improve the performance and the code a lot. I think if I get more time I will focus on doing these two things first. I also want to add animations to the recycler view.
The login screen isn’t perfect as well, as I mentioned when I started developing it there was already some code written. There are small details about the UI which I hadn’t touched yet and I would like to change it a bit.
Next week, we will have another sprint meeting, I am excited to get feedback on my code as well as to start working on the next tasks.
