Background message push frame design __ Frame

Preface

The start of their own company's background push system can only be pushed when users online, push messages will not be saved, if the user offline, then this push message can no longer be obtained. More annoying is: push the content and push the system is coupled together, so often in a change of code at the same time, there will be unexpected bugs. The determination to reconstruct the push code is even more determined. The following is their own entire design process and the problems encountered during the period, write to share with you, hope everyone a lot of advice. Design Process

The beginning of the design is to store the data, modify and push the message into a class Pushmanager, all kinds of messages are blended into a message, from the background pull the message to Pullmanager, such as Figure 1:
　　
　　
The above design has the following drawbacks:
1, message to represent various types of messages, and it is directly related to the database table, so that the message to the various types of messages are included in different points, so, add a message type, you need to add a field in the database to indicate that it differs from other types of points. does not conform to the opening and closing principle, the maintenance is extremely poor.
2. The coupling of message storage and push is too strong.

For the above problem, it has been further optimized (the following figure):
1, using messagetypebase this abstract class to abstract the common behavior and attributes of the message, various types of messages to inherit this abstract class, and then for different types of messages to add different behavior and attributes
2, the message storage and push two separate, MessageManager is responsible for the deletion of the message to check (pull cancellation of the behavior also into which), it provides services, Pushmanager responsible for the push of the message (including single push, group push, group push)
3, MessageType use static constants to identify different types of message corresponding to the number, messagetypecontent different message types corresponding to the content template and title
4, add the Extendinfo field (string type) in the database table, to store the additional information of different messages, the specific message to the specific processing (refer to the final UML Diagram T_message table, the original forgot to modify the table structure of the following diagram)
　　
　　
In accordance with the above design to implement the code, I found that the above design scheme still has a lot of drawbacks:
1, MessageManager is not only responsible for the push and pull of messages, but also responsible for interacting with the database, the function is too complex
2, Messagetypebase not only express the type of message, but also responsible for push and pull cancellation of the assembly, the most unbearable is that if the message format to change, it is necessary to change the code messagetypebase, Specific message types such as Realnamemessage will also change.

As a result, he again splits the above system (pictured below):
1, add PushMessageType2 This enumeration type to identify the type of message push (that is, single push, group push, group push, etc.)
2. Change the name of MessageManager to Messagemanagerservice
3, the new Messagedao to specifically responsible for dealing with the message database, corresponding to the MessageManager in the DBHelper attribute to Messagedao
4, added three attributes in the Pushmanager, Clientcache used to cache the client object used to push, the remaining two to identify the Android and iOS devices, an increase of 5 methods, one is to get the single Sample object (the previous picture has been forgotten), One is to get the client object, one for log printing (for easy debugging), and the remaining two are the two two methods that are used when the group is pushed.
5, increase the MessageManager to be responsible for the interaction between Messagemanagerserver and Messagebase, with MessageType This attribute to identify the type of messagebase subclass (such as real-name messages, plus friend messages, etc.). MessageManager has a map, which maintains all the messagebase subclasses (such as real-name messages, plus friends and other types of messages), Messagemanagerserver can be used as required getmessagebase () To take out the corresponding message type, it is noteworthy that, in the Getmessagebase () method, you must first set up the messagebase with the setmessagetype (int messagetype,message message) Subclass and message content. Corresponds to the addmessagetype (int type,messagetypebase message) method and Removemessagetype (int type) in MessageManager The two methods are moved to the MessageManager. The Getmessagemap is added to get the message content (the primary user pulls) and getpushmessage () to get the push message (mainly for push). Add the Pushmanager property to set the content of the push message so that the content of the message can be flexibly sent to the messagemanagerserver on demand
　　
　　
When you write code, you are aware of the two drawbacks of the design above:
1, Channelid,tagname,pushtype,deploystatus and other push environment parameters placed in the messagebase, so in each push, Remove messagebase through MessageManager to get push environment parameters (the parameters of the push method in the above Pushmanager should be MessageManager type, and I forgot to change it. You can refer to the Pushmanager of the following figure in the push method parameters, and then, put these push environment parameters in the message type, the message content and environment parameters coupled together, not flexible, and inconsistent with the principle of single liability
2. In MessageManager, a map is used to maintain various message types (in the MessageManager constructor, new objects of various message types are created and then placed in the map), Using MessageType to identify which specific message the MessageManager uses, there are two disadvantages: (1) because only one specific type of message is used in the map, so that in this map there is only one specific message that has data. All other types of messages are empty objects that are bound to the map in MessageManager and are not reclaimed by GC (because there is a message type in the map); (2) If you add a message type, you change the MessageManager constructor, Violates the principle of opening and closing
　　
Follow the above reasons for further optimization (pictured below):
1. Move the push environment parameters from Messagebase to MessageManager, meeagebase only to identify messages
2, in the MessageManager only maintain a messagebase, in the business layer in the specific message types passed in. In this way, no matter how to add or delete specific message types, but only in the business to add or delete, the code in the MessageManager do not have to modify
　　
　　At this point, the entire background message push framework is basically designed to complete. From the initial design to the end of the code to achieve, can be described as twists, not only to abstract the business, split, decoupling, but also to consider the exception, error information output and so on various issues, oneself also learned a lot, also get a lot of happiness from it. If you have any ideas, please give us a lot of advice.