- Pre MSoC
- Work Accomplished
- Reviewing existing Pull-Requests
- Project Upgradation
- Java to Kotlin Migration
- ButterKnife to ViewBinding Migration
- Navigation Components
- UI Enhancement
- Dagger2 to Hilt Migration
- MVP to MVVM Migration
- Fineract SDK Dependencies Upgradation
- Fineract SDK Integration
- Unit tests for ViewModels
- Improving Github Actions
- Project Cleanup
- Impact
- What more can be done?
- Conclusion
- I played a crucial role in the development of the Android client from the very beginning. My dedication was evident even before I officially joined the team, as I proactively tackled the documented issues on the GitHub repository, methodically resolving existing bugs within the project's architecture. Furthermore, a noteworthy achievement was unlocked when we successfully upgraded the Gradle build and addressed login bugs associated with Retrofit in our project. Going beyond these accomplishments, I also provided assistance to a group of budding contributors, mentoring them as they took their initial steps into the world of open-source collaboration.
-
In the Android client project, there had been an accumulation of nearly 200 pending Pull Requests dating back to 2016. In response to this backlog, I undertook the responsibility of reviewing and addressing these PRs. To mitigate potential merge conflicts, I made the decision to close the Java-based PRs and subsequently created new PRs in Kotlin for the more critical issues. Through this concerted effort, I successfully reduced the PR count to a much more manageable 12.
-
This proactive approach towards tackling the PR backlog not only contributes to a more streamlined and efficient codebase but also demonstrates a steadfast commitment to preserving the project's overall health and sustainability.
-
Android client previously used Kotlin version
1.7.0
, which included support forkotlin-android-extensions
. However, sincekotlin-android-extensions
is only supported up to Kotlin version1.7.0
, I have upgraded the project to Kotlin version1.8.10
. As part of this upgrade, I have removed thekotlin-android-extensions
plugin and added thekotlin-parcelize
plugin. -
I have undertaken the process of upgrading all other dependencies to their latest versions in order to rectify existing bugs and enable the incorporation of new features. This strategic initiative is intended to enhance the competitiveness of the application and ensure its alignment with current trends.
-
The upgrade process has been completed within the following pull requests.
-
After a period of three months, I transitioned from an Android client predominantly composed of 73%
Java
code toKotlin
. This migration was prompted by Kotlin's superior support within the Google ecosystem, as it offers a more contemporary and expressive programming language compared to Java. Kotlin's advantages include enhanced type safety, null safety, and a concise syntax. -
The following list comprises the pull requests that I have submitted.
- PR #1969: Java to Kotlin Migration : SplashScreen
- PR #1970: Java to Kotlin Migration : Authentication
- PR #1981: Java to Kotlin Migration : HomeActivity
- PR #1984: Java to Kotlin Migration : Mifosbase Class
- PR #1986: Java to Kotlin Migration : Individual Collection Sheet
- PR #1989: Java to Kotlin Migration : Collection Sheet Migration
- PR #1990: Java to Kotlin Migration : Adapters
- PR #1991: Java to Kotlin Migration : Dialog Fragments
- PR #1993: Java to Kotlin Migration : Widgets
- PR #1994: Java to Kotlin Migration : Payloads
- PR #1995: Java to Kotlin Migration : Objects
- PR #1996: Java to Kotlin Migration : DataClasses
- PR #1997: Java to Kotlin Migration : DataClasses
- PR #1998: Java to Kotlin Migration : Utils
- PR #1999: Java to Kotlin Migration : TestClasses
-
During the Android client development process, the developer extensively employed Butterknife as an alternative to the traditional
findViewById
method. In the contemporary landscape, we have two viable alternatives at our disposal: DataBinding and ViewBinding. Following thorough discussions with our mentors,we've opted forViewBinding
as our preferred choice. Its innate synergy with our current workflows and the assurance of expedited compilation times were pivotal in this selection. Moreover, this strategic shift sets us up for a smooth transition into embracingJetpack Compose
in the future, a realm where ViewBinding truly excels. This choice underscores our unwavering dedication to streamlining our development processes for maximum efficiency and adaptability. -
Here are the pull requests I've submitted.
- PR #1969: ButterKnife to ViewBinding Migration : SplashScreen
- PR #1970: ButterKnife to ViewBinding Migration : Authentication
- PR #1981: ButterKnife to ViewBinding Migration : HomeActivity
- PR #1984: ButterKnife to ViewBinding Migration : Mifosbase Class
- PR #1986: ButterKnife to ViewBinding Migration : Individual Collection Sheet
- PR #1989: ButterKnife to ViewBinding Migration : Collection Sheet Migration
- PR #1990: ButterKnife to ViewBinding Migration : Adapters
- PR #1991: ButterKnife to ViewBinding Migration : Dialog Fragments
-
Previously, the Android client application employed the
.replace
method to manage all navigation logic. This approach introduced a heightened level of complexity to the project, elevating the potential for errors that could impede performance and complicate maintenance efforts. Additionally, it led to issues in managing thebackstack
effectively. -
In order to address this challenge, I have implemented
Navigation Components
. This implementation serves to streamline the navigation process and enhance the management of the back stack. Additionally, it facilitates secure and efficient data transfer between destinations viasafe-args
, thereby fortifying the robustness and maintainability of the navigation code. -
Following pull requests contain modifications.
-
Initially, our user interface suffered from numerous issues, ranging from bugs to deficiencies in padding, color formatting, text size, and alignment. These shortcomings not only hindered the user experience but also left a negative impression on our users. To address these concerns and enhance the overall design and usability, I decided to implement the
Material 3
design principles. This involved a comprehensive transformation of our UI components, aligning them with the Material 3 guidelines to ensure a more intuitive and user-friendly experience. -
A distinguished User Interface has the capacity to generate immediate appeal towards the application, whereas an exceptional User Experience has the ability to leave a profound and enduring impression on the users.
-
I have attached a screenshot below that depicts the interface following the migration to Material 3.
- This Pull Request shows everything that was modified.
-
Previously, Dagger 2 was employed for dependency injection, and when using Dagger, setting up a
ViewModelFactory
necessitated a substantial amount of boilerplate code. As a result, I transitioned to Hilt, a framework that streamlines much of this boilerplate code, including the creation of a component interface and its implementation. -
This Pull Request demonstrates the migration that has been completed.
-
Three months ago, the Android client application was utilizing the MVP (Model-View-Presenter) architecture. Since then, I have completely transitioned the project to follow the MVVM (Model-View-ViewModel) architecture pattern. As part of this migration, I have restructured the codebase so that repositories now handle the retrieval of data from the DataManager.kt module. Additionally, I have adopted the practice of injecting these repositories into their respective ViewModel classes through constructor injection.
-
We have created a repositories package that lists all of the repository interfaces and their implementation. The reason for creating an interface was that it followed two fundamental SOLID principles:
Open/Closed
Dependency Inversion
-
I have employed the use of LiveData in our ViewModel components to facilitate the observation of states within our application.I have implemented sealed classes to encapsulate objects, and data classes to encapsulate MutableLiveData instances. As part of MVVM migration efforts, I have compiled a comprehensive list of all the pull requests associated with these changes.
-
Initially, Fineract SDK entails the utilization of outdated dependency versions. In response to this circumstance, I have initiated a comprehensive endeavor aimed at modernizing all remaining dependencies to their most recent iterations. This meticulous process has been instigated with the overarching objectives of rectifying extant bugs, facilitating the seamless integration of novel functionalities, and ultimately bolstering the overall competitiveness of the application. The paramount goal is to align the SDK with contemporary industry trends and standards.
-
Jitpack utilizes Java 8 for deploying Android libraries. In order to enable Jitpack to operate with Java 17, I have authored a jitpack.yml configuration file to specify the use of JDK 17.
-
I have provided the details of my pull request below.
-
Previously, all REST API calls were managed by creating service classes, resulting in the generation of boilerplate code. This practice not only increased the size of the application but also resulted in a suboptimal user experience.And also, any modifications to the backend necessitated extensive code changes within the Android client, making it a challenging and time-consuming task.
-
I have implemented the fineract-android-sdk, which offers significant advantages in terms of development efficiency. This SDK streamlines the process by automating many of the labor-intensive and repetitive tasks associated with making REST API calls. also, it enhances the flexibility of our Android client application. In the event of any backend modifications, we can make the necessary adjustments within the Fineract SDK without the need to modify the Android client codebase. This decoupling of the backend and client code simplifies maintenance and ensures that our application remains adaptable to changes in the backend infrastructure.
-
During the implementation process, I encountered several issues with the SDK, including non-functional endpoints and inaccuracies in data fields. I have diligently documented these issues and will address the necessary changes in future.Below is a list of pull requests related to these changes:
-
Following the transition from MVP to MVVM architecture, a critical component of our endeavors entailed the establishment of rigorous unit testing methodologies. More precisely, I steered our attention toward the development of exhaustive unit tests for ViewModels.
-
Previously, unit tests were originally implemented for the presenter components. However, I subsequently undertook the task of replacing all of these presenter unit tests with unit tests specifically designed for the view models, ensuring comprehensive coverage of 100%.
-
I have utilized the Mockito testing framework, in conjunction with the JUnit testing framework to create and submit the following Pull Requests.
-
Previously, GitHub Actions were configured to utilize JDK 8, which has become outdated in light of contemporary software components. As a response to this, I have adjusted the GitHub Actions configuration to utilize JDK 17.
-
You can observe the alterations here.
-
After implementing the aforementioned modifications, it is incumbent upon me to undertake the task of cleaning up unused elements and reorganizing all files into well-defined packages according to their respective features.
-
This Pull Request serves as an illustration of the cleanup efforts undertaken.
-
The transition of the Android client from Java to Kotlin represents a pivotal milestone in Migration. This shift not only allows us to leverage the capabilities of Jetpack Compose in the future but also empowers us to harness the rich ecosystem of Kotlin libraries.
-
The transition from MVP to MVVM architecture marked a significant and transformative evolution in the project's structural framework. The judiciously constructed repositories package, coupled with exhaustive unit testing for ViewModels, has significantly bolstered the platform's dependability, scalability, and ease of maintenance.
-
Following the successful implementation of Material 3, the user interface exhibits a remarkable visual appeal, leaving a highly favorable impression on users.
-
The implementation of the Fineract SDK has significantly streamlined our processes by automating numerous labor-intensive and repetitive tasks associated with initiating REST API requests. Furthermore, it has notably augmented the adaptability and versatility of our Android client.
-
So far, I have exclusively focused on composing unit tests for a subset of our view models. Moving forward, we can extend this practice to cover all of the existing view models within our application.Also, we can initiate the process of creating unit tests for our repository classes. Furthermore, it would be beneficial to commence the development of Instrumentation Tests to facilitate comprehensive UI testing for our application.
-
During the implementation of the Fineract SDK, I have encountered several issues with the SDK, which include non-functional endpoints and inaccuracies in data fields. It is imperative that we address these issues in order to ensure the successful integration continues.
-
Jetpack Compose offers a more efficient approach to UI implementation compared to the traditional View-based UI approach in Android clients. The View-based approach can lead to inefficiencies in terms of memory usage and application performance. In contrast, Jetpack Compose employs a declarative programming model to express the UI, simplifying the process of understanding and designing the user interface. Instead of imperatively manipulating the view hierarchy, Jetpack Compose's declarative approach results in faster performance and reduced memory usage, making it a superior choice for modern Android app development.
-
Compared to three months ago, the Android client is far better now, and I'm confident that with further improvements, it will keep getting better. Continuously refactoring code and keeping an eye on quality are the keys to Android Development.
-
I had a great experience throughout this three-month-long program. I received tremendous support from the community as well as my mentors Avinash M Vijayvargiya and Rajan Maurya during this three-month journey. I would also like to thank Ed Cable for his outstanding support. The weekly check-ins were excellent. I had a great opportunity to bond with the community, as well as solve some problems that I encountered in the interim. I learned and grew a great deal as a result of this experience. It would be my pleasure to contribute to this organization in the future, as well as to assist new contributors to get started in this community.