Event Calender

Event Calender is a simple event storing android application with cloud backup

Technology Used:

• Java
• MVVM Achitectural Pattern
• Room
• JUnit4 (unit testing)
• LiveData
• Firebase Authenthication
• Cloud Firestore

Problem Requirement Analysis

Use Cases:

1. Authenticate user
2. User Opens the app
3. See weekly calender with current dates events
4. User can add new events
5. Events store to room database
6. Backup events from room db to cloud firestore
7. Restore events from cloud to room db (if nessessary)

UI Design On Figma

---

How I approached

1. First did the requirement analysis and use case diagram
2. Google searched for UI design and got inpired from them
3. Designed my UI
4. Prepared android project for MVVM pattern (made all packages and all and spd , room, view-model etc dependencies)
5. Coded xml of homepage and Event input dialog
6. Test CalenderUtils functionality using JUnit4
7. Thought about Class diagram but here only simple one class so didn't design any
8. Event info data store to ROOM database and test if it's working
8. Add firebase dependencies and project add to firebase
9. XML of Login Register pages and Code functionality
10. Backup and restore from cloud firestore

Reason behind technology and library selection

• MVVM (Model View ViewModel): MVVM is a popular architectural pattern which is recommeneded by google. In this pattern, user requests from UI , that request first goes to corresponding ViewModel. Then that ViewModel requests to data repository. Meanwhile, Observable (LiveData) continues to obserse the data changes and notify when requested data is ready to serve.

• ViewModel: ViewModels holds the LiveData. As it is lifecycle aware, we don't need to think about sync data with UI and don't have to request multiple time for same data.

• ROOM Database: Room Database basically an abstract layer on top of SQLite database. It helps to write less code and do more of the local database works. We don't have to think about database cursor.

Challenges I faced And How I solved it

• MutableLiveData Nullable: Problem: At first observers are getting null value and if we use that value directly, app crashes. Solution: I had to check null before using that value

• Executor Interface: Problem: While creating new account or login account, firebase provided method requires Executor instance. In general case, we call those method from Activity class, so, firebase snippet recommend to use "this" as paramenter in the place where Executor object needed. In my case, I had to use it from "AuthRepo" class. "this" was not working as "AuthRepo" is not on UI thread. Solution: So, I created another class which extend from "Executor" interface and used instance of that class. That's how background thread was being created.

• postValue() vs setValue(): Problem: At first I used setvalue() method to assign values on a MutableLiveData instance. It was not working. Then I found out the reason. Solution: setValue() sets value only on UI thread. In my case, I need to assign value from background thread. So, I used postValue() method.

• Room Database Insert and Background thread: Problem: RoomDatabase doesn't allow to store data from Main Thread(UI Thread) Solution: I created different java thread and inserted value from there.

Design Pattern Used

• Singleton Pattern: RoomDatabasase Instance is heavy object, so I need to stop creating many object of it. So, singleton pattern is the answer. I used the same object using a method. That method was synchronised, that mean's thread-safe
• Observer Pattern: Didn't implemented from scratch but it came with LiveData

Clean Code

• Code Reuse: LoginActivity and RegisterActivity both need to use validate method to check email and password. So, I created another class "AuthCommonActivity", later LoginActivity and RegisterActivity both extended from "AuthCommonActivity".

• Meaningful variables and function: Tried to use as meaningful as possible variable and method name. Some case, that names became bigger.

##Data Structure Used

• HashMap
• Array
• ArrayList

OOP principles

• Single Responsibility: "Event" and "CalendarUtils" both have single responsibility. For example: CalendarUtils only deals with calerdar related data formatting.

Future works

• Email validation, varifications and forgot password feature
• User profile with personalised data
• Events auto synchronization with cloud
• Events manipulation
• Different colored event based on priority
• Notifications feature before event time

Screenshots of the app