### How to learn Android development

  1. First combine the official website to make an overall grasp (the official website is accurate and systematic)
  2. Learn through the official website or related tutorials
  3. Continue to iterate through actual projects or advanced tutorials

###Android development features

  1. The system provides a rich API to us
  2. An application is made up of a series of Components, so we need to know the Callback (life cycle) of each component, which needs to be declared in the Manifest to inform the system.
  3. Intents (implicit/explicit) bind independent application components together and work together. You need to know how to manipulate components using Intents.
  4. Understand two types of apis: 1. System-level apis, common and common apis used in application development. 2. Plugin-level API, only used by apps with specific functions, such as Media, Camera, Connectivity, etc.

### Thinking about design patterns and design principles in Android system architecture

#### 1. Introduction to design mode and design principles:

#### 2. Template method design mode

A common scenario in Android development looks like this:

The corresponding sequence diagram is as follows:

It is implied the template method design pattern, about the template method, please see: http://www.cnblogs.com/chenpi/p/5217430.html.

The callable types of template methods are:

  1. Concrete operations (ConcreateClass or on the client)
  2. AbstractCalss concrete operations (usually useful for subclasses)
  3. Factory Method
  4. Hook Operations, which provide default behavior that subclasses can extend as necessary. A hook operation is usually a null operation by default.

Such as:

Note:

  1. You must subclass — abstract, optional — hook, no subclass — final.
  2. The fewer abstract methods the better

#### 3. The Hollywood Principle

Design patterns through this template approach to lifecycle callbacks embody the Hollywood principle (Don’t call us, we’ll call You) :

  1. Underlying components can hook themselves into the system
  2. Low-level component pairs cannot call high-level components
  3. Does a high-level component determine when and how to use a lower-level component

#### 4. Inversion of control

The design pattern through this template approach to lifecycle callbacks also embodies the principle of inversion of control:

For example, why don’t we developers just go to the new component? As for the Activity, we used to use the Activity, but now it is the Android system that helps us maintain and manage it. We only need to implement the corresponding callback. This makes Android development a lot easier.

For example, an Intent starts a component procedure:

The knowledge of the inversion of control: http://blog.csdn.net/wu631464569/article/details/52433912

At the end of the article, dependency injection (DI) is just one way to implement inversion of control (IOC), for example when we operate on a Service:

After the Service is bound and injected into the Activity, the retrieval of dependent objects is reversed. Instead of new a Service ourselves, we inject it into the Activity by binding it.

# # #

Why do you need the above design patterns and principles?

  1. The last thing software does not change is “change” itself
  2. The need for our design architecture to adapt to changes requires that our software be loosely coupled, maintainable, and testable. To be in the driver’s seat.

Ultimately, we can develop programs that are loosely coupled, maintainable, and testable.

If you feel that my words are helpful to you, welcome to pay attention to my public number:

My group welcomes everyone to come in and discuss all kinds of technical and non-technical topics. If you are interested, please add my wechat huannan88 and I will take you into our group.