Code Commit

We generally commit code with jeera ticket no. So that it is easy to track.

Feature Development

Suppose you want to add a new feature to the app. You can create a new branch from develop and give a name as feature or bugfix keyword - jeera ticket no - feature or bugfix short name. this naming convention gives a meaningful name to the pr and helps in tracking. You can later merge your code to develop a branch once it is reviewed and approved.

Update feature branch

Sometimes it happens that you are working on some feature for a very long time and it is not merged to develop branch for a very long time. In this case, it becomes very important to update the feature branch otherwise you can get bugs whenever you raise a pr. It can be avoided by updating the feature branch from time to time by pulling changes from develop branch and merging them into the feature branch. It can be done easily. We do this in mac using the source tree. We select the feature branch and choose the pull option. In that, you can select develop branch to pull changes, and you are done. Congrats your feature branch is up to date with develop branch.

Stash

• It is a very powerful tool in version control
• If you are making multiple changes to a branch and you don't have to commit this code. Then stash can be helpful in this.
• you can save all changes in the stash and give a name to them. this stash can be applied to any branch whenever you need it.
• stash will save all your uncommitted changes under a particular heading and reset your branch to the default state.

Check out other code

• In the source tree, you can search other codes through jeera no.
• you will get a list of commits for that code.
• just click on any of the commits and check out the code.
• when the code is checked out, you can update the branch as the code is remote.

Delete branch safely

• you can delete any branch whether it is a feature or develop from your local
• just switch to another branch, then right-click the branch to delete and delete that branch.
• You can do this through the source tree.
• Then checkout branch code from remote into local

SOLID Principle

SOLID Principle

• The SOLID principle was introduced by Robert C. Martin, also known as Uncle Bob and it is a coding standard in programming.
• This principle is an acronym of the five principles which is given below…
• Single Responsibility Principle (SRP)
• Open/Closed Principle
• Liskov’s Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)
• The SOLID principle helps in reducing tight coupling. Tight coupling means a group of classes are highly dependent on one another which you should avoid in your code. The opposite of tight coupling is loose coupling and your code is considered a good code when it has loosely-coupled classes. Loosely coupled classes minimize changes in your code and help in making code more reusable, maintainable, flexible, and stable.

Single Responsibility Principle:

• This principle states that “a class should have only one reason to change” which means every class should have a single responsibility or single job or single purpose.
• Take the example of developing software. The task is divided into different members doing different things as front-end designers do design, the tester does testing, and the backend developer takes care of the backend development part then we can say that everyone has a single job or responsibility.
• Most of the time it happens that when programmers have to add features or new behavior they implement everything into the existing class which is completely wrong. It makes their code lengthy, and complex, and consumes time when later something needs to be modified.
• Use layers in your application and break God classes into smaller classes or modules.

Open/Closed Principle:

• This principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” which means you should be able to extend a class behavior, without modifying it.
• Suppose developer A needs to release an update for a library or framework and developer B wants some modification or adds some feature to that then developer B is allowed to extend the existing class created by developer A but developer B is not supposed to modify the class directly.
• Using this principle separates the existing code from the modified code so it provides better stability, and maintainability and minimizes changes as in your code.

Liskov’s Substitution Principle:

• Liskov Substitution Principle
• according to this principle “Derived or child classes must be substitutable for their base or parent classes“. This principle ensures that any class that is the child of a parent class should be usable in place of its parent without any unexpected behavior.
• eg - the child of two humans should be a human, not a duck
• If the above case happens, there is some problem with the parent class that the properties are not matching and you need to modify it.
• eg - Suppose rectangle is parent class of square. It opposes Liskov’s Substitution Principle. The rectangle will have width and height as properties but the square will have a property that if you enter width, height will be assigned the same value and vice-versa.
• To tackle the above problem you can use shape class as a parent class of rectangle and square. shape class will have height and width properties which will be the same in rectangle and square, only values will be different. here we are not changing the properties in the child class.

Interface Segregation Principle:

• Interfaces
• Static methods
• This principle is the first principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle.
• It states that “do not force any client to implement an interface which is irrelevant to them“. Here your main goal is to focus on avoiding fat interfaces and give preference to many small client-specific interfaces.
• You should prefer many client interfaces rather than one general interface and each interface should have a specific responsibility.
• For eg - when a vegetarian guy visits a restaurant and is given a general menu that contains both veg and non-veg items. Nonveg items are irrelevant to him. To tackle this problem instead of one general menu there should be two small separate menus for veg and non-veg items.

Dependency Inversion Principle:

• Abstraction in Java
• dependency injection in Java
• Dependency Injection in Java
• Dependency Inversion and Dependency Injection both are different concepts.
• two key points are here to keep in mind this principle
• High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.
• Abstractions should not depend upon details. Details should depend upon abstractions.
• The above lines simply state that if a high module or class will be dependent more on low-level modules or classes then your code would have tight coupling and if you will try to make a change in one class it can break another class which is risky at the production level.
• So always try to make classes loosely coupled as much as you can and you can achieve this through abstraction.
• The main motive of this principle is decoupling the dependencies so if class A changes class B doesn’t need to care or know about the changes.
• Your remote needs a battery but it’s not dependent on the battery brand. You can use any XYZ brand that you want and it will work. So we can say that the TV remote is loosely coupled with the brand name. Dependency Inversion makes your code more reusable.

Github Enterprise

• you can use GitHub enterprise in android studio or source tree to connect with your org GitHub account.
• all you need to do is provide your username, password, and org Github link.
• and you are set It will generate the ssh key automatically with all read and write permission.
• you can push your code to GitHub without providing a password every time.
• you can check out the code from your org Github much faster.

org emulator taking time to load apk

• you can simply delete your build folder from where your project is located and it will drastically decrease your app install time on the emulator