IOS IM development suggestions (I) App framework design, iosapp

IOS IM development suggestions (I) App framework design, iosapp

Let's talk about the design of the framework.

First, the IM application is generally based on persistent connections, that is, the background is always sending and receiving data, so here there is a background concept;

2. If a user is a central character in a group, the data volume will be large. Page display and database processing require attention;

3. Splitting apps helps us reduce coupling, which is easier to maintain and upgrade later.

 

I think the framework is to disassemble parts before establishing a connection. There are many types of frameworks. I refer to dependency injection.

Dependency

This module is an intermediate node for running all components and is responsible for information transmission and data processing in the app. Therefore, the app must exist when it is running. Here are two suitable candidates: AppDelegate and RootViewController. Here I chose RootViewController. The reason is as follows: 1. If CoreData is used and APNS needs to be processed, AppDelegate is very burstable; 2. My app is based on TabBarViewController, while TabBarViewController is invisible to users. He does not need to process the UI, and several major pages are his viewcontrollers for convenient calls.

After the selection, we need to clarify its role. I assigned him the following tasks: processing the data pushed by the network module, storing the data in the database, and pushing the data update notifications to various pages. That is, the external data is stopped here and the UI interface is not operated directly.

Network Communication

This module is responsible for data transmission with the server, and cannot be destroyed during app operation. Therefore, this module needs to be created in the standalone mode and placed in the global thread. This module sends and receives data externally. Internally, it transmits data to dependencies and receives sending commands on the UI interface. That is, he only sends and receives data without operating the UI and database.

Database

He is responsible for addition, deletion, modification, and query... (It's easy to get an API)

UI

All visible and interactive pages of the app. All the reasons for getting rid of products are shown here. However, this is visible to users. That is to say, it is better to perform operations without freezing. Some pages have a lot of UI interaction, so we cannot afford it too much. Then I asked him to do two things to show and send requests. The presentation is his original work. Take the database and update the UI. The request is an interface, and he only needs to capture the data on the page and fill it in.

 

Summary: after each module is split, what they do is clear, the data source is also ensured, and the UI processing logic is also simple. The full API call method facilitates future expansion.

Appendix: