s-ayush2903 / keepitclean Goto Github PK

a feature is needed

• Explain how the clean architecture works, it functionality most of it along with the proper diagrams(handwritten or slides, either would work) and add some material/resources like blogs for absolute Naives to begin with.
• The readme should be powerful enough to instill a deep meaning of Clean Arch. in the mind of that Naive
• For your assistance, I'm attaching a few resources to begin with observe their documenting style(only of readme)

1. Repo(in Kt.)
2. Most Popular Repo(in Java)

• Ask if you get stuck, don't hesitate to ask

I think it is important to have contributing guidelines so that an open-source contributor know how to contribute properly.
Can I work on this?

• Currently there is no error handling for caching and
• There exists nothing like safeApiCall while updating/inserting the note(s) to the firestore
• SafeApiCall is something that responses in a good manner for failed requests, errors and exceptions
• Implement both of 'em

• Write Unit Test for InsertNewNote useCase

Having a Contributor's image in the Readme.md the file is a great idea to keep contributors motivated

DEMO

• Make use of the generic DataChannelManager and stuff like that
• Will add more info regarding the same issue later

@s-ayush2903 Sir, Did you see new feature on github ? We can set discussion on this repo. So what you have to do is just click this block in setting section of your repo. It's Amazing I guess. Have a try.

• Write gradle files containing dependencies in ktDomainSpecificLang.
• Keep it as clean as possible
• Structure package tree better/beautiful

Can I make issue templates to enhance the workflow of the repository?

• Start by writing constants
• Then go for event handlers
• Then write abstractions and implementations of network layer
• Afterwards, ResponseHandlers for the result from handlers(mentioned in 2nd point)
• If get stuck, then follow #16

• Plan UseCases for the module
• This is a simple noteTaking app, nothing fancy, only thing to learn is arch.
• So, write normal/common usecases
• Take care of networking services(Firestore) while writing 'em
• You are just supposed to plan 'em only, the functionality can/will be implemented later
• By planning, you are expected to just create classes only
• Don't disturb the module structuring, i.e., the way the packages are sorted and placed
• While filing an MR, attach the visual of the package structure for easy reviewing
• And please don't touch the gradle.kts files

• Start building the caching layer in the module
• Follow the practices that were being followed in solving the previous issues
• Use Generics

Also, Reindent 'em following squareAndroid

Can I make pull request template to enhance the workflow of the repository?

Initialize the project by writing a few of the innermost/core cases/files for the module so first begin by Domain Module.

Proceed as follows:

• Start by building the Domain Layer
• Define Note Objects/classes
• Add a factory for the same
• Simultaneously handle the timestamp and date conversion issues as well
• Make use of firebase utility/in-built functions to minimize the efforts and maintain brevity
• Do all of the above assuming that the dagger has been implemented
• (The best one is to introduce di and then start doing all that stuff)
• Be as succinct as possible
• Write proper neat and well documented code

• Abstract NoteDaoService and NoteFirestoreService the correct way
• Currently NoteDaoService has search function implemented the wrong way
• Change that and look for same nits in the NoteFirestoreService

• Write the insertNewNote useCase

The project is not having code of conducts so can I wor on it @s-ayush2903

• Optimize the current script.
• A couple of lines can be removed from it
• Follow !34007 for references.

NA

We'll be following the tdd completely, no excuses!

• So setup the environment for testing in the codebase
• Try using fakes as far as possible