The AlbumCameraRecorder project became cumbersome with the addition of new features. Because the core code had multiple state transitions, and different scenarios had different state processing, it was difficult to maintain later extensions, so we used this state mode optimization.

Jump right into the pros and cons

Advantages:

  1. Localizing state-related behavior and separating different states eliminates large conditional branching statements and distributes logic to state through various states. It is convenient to maintain the code later.
  2. Adding new states is easy and extensible.

Disadvantages:

  1. It is inevitable to increase the number of classes and objects in the system, because multiple states can switch between each other, improper use will lead to increased complexity of the system, poor readability, all of which require good code skills and comprehensive design.

Before explaining the state mode, let’s take a look at the simple logic of the AlbumCameraRecorder project. The project has a camera class CameraLayout, which needs to do the corresponding processing according to the current different states, such as taking photos, taking videos, etc. So let’s get started!

Let’s look at what classes make up this state pattern with the AlbumCameraRecorder project

Through mind mapping, the relationship between the classes below the State package is shown below:

Because the source code is too much, so here extracts the core part to let you quickly understand: ###StateInterface StateInterface

Public interface StateInterface {/** * commit the core event */ void pvLayoutCommit(); /** * Cancel the core event */ void pvLayoutCancel(); }Copy the code

StateMode Abstract parent class of the state

Public abstract class StateMode implements StateInterface {/** * Camerastmanagement is handling state transitions. CameraLayout cameraLayout; }Copy the code

Multiple state subclasses, pull out two Preview and VideoIn

Public class Preview extends StateMode {@override public void pvLayoutCommit() {cameralayout.xxxx (); / / change in the video recording state cameraStateManagement setState (cameraStateManagement. GetVideoIn ()); } @override public void pvLayoutCancel() {cameralayout.xxxx (); }}Copy the code
Public class VideoIn extends StateMode {@override public void pvLayoutCommit() {cameralayout.xxxx (); / / change in the video recording state cameraStateManagement setState (cameraStateManagement. GetPreview ()); } @override public void pvLayoutCancel() {cameralayout.xxxx (); }}Copy the code

CameraLayout photographing classes that optimize code for objects

Public class CameraLayout {public final CameraStateManagement */ public final CameraStateManagement; Public void the commit () {/ / deal with the current state of the corresponding logic mCameraStateManagement pvLayoutCommit (); } public void the cancel () {/ / deal with the current state of the corresponding logic mCameraStateManagement pvLayoutCancel (); }}Copy the code

CameraStateManagement status management

public class CameraStateManagement implements StateInterface { CameraLayout mCameraLayout; /** * Current state */ StateInterface state; /** * StateInterface preview; /** * State of recording video */ StateInterface videoIn; public CameraStateManagement(CameraLayout cameraLayout) { mCameraLayout = cameraLayout; // Preview = new preview (cameraLayout, this); videoIn = new VideoIn(cameraLayout, this); // Set the current default state state = preview; } /** * @return state */ public StateInterface getState() {return state; } public void setState(StateInterface state) {this.state = state; } @Override public void pvLayoutCommit() { state.pvLayoutCommit(); } @Override public void pvLayoutCancel() { state.pvLayoutCancel(); }}Copy the code

So the core code of this pattern is here, the code author after the change is very comfortable to maintain or add code, this is the benefit of elegant code! Also welcome small partners to point out better improvements, like a collection thank you for your support!