WeChat/Yixin public platform development (III): record user status and optimize program structure

 

In an earlier article, the implementation of a public platform PHP class, see http://blog.csdn.net/c80486/article/details/12316305

After using this class, the public platform program becomes the following simple form:

 

The main program has only three lines:

Include_once 'jostudio. wechat. php ';

$ Object = new WeChat (TOKEN, "onMessage"); // create a WeChat class instance
$ Object-> process (); // process the message

 

Write another message processing function

Function onMessage (WeChat $ object, $ messageType, $ content, $ arg1, $ arg2 ){

Switch (messageType ){
......

}
}

This program structure is similar to windows programming using C language (A WinMain main program and a message processing function)

 

However, as the processing logic increases, the code of the message processing function will become very complex (there may be many switches ), writing all functions in one function is not a good style (a good programming style is a function that is better than a screen ).

 

A public platform often provides multiple application functions, such:

"Welcome! Reply to number select project: \ r \ n1 tell joke 2 listen to music"

 

The preceding example has two applications: 1 for telling jokes and 2 for listening to music. Of course, the selection of the main menu can also be seen as an application.

Our program needs to record the status of the last user input, for example, remember what kind of role should be used before using a role, it is in the main course, joke, and audio.

Otherwise, you do not know which application the user inputs each time.

 

Because the public platform does not provide functions such as cookies, We must record the user's status on our website.

In other words, I first wrote a User class and used it for storage. (Source example file: jostudio. user. php, under example address: http://download.csdn.net/detail/c80486/6361281)

A user-defined data is saved as a text file, and the file name is stored as an external OpenID file. The data format is JSON.

In the initial state, there are two changes in the sequence: App and Stage. Both variables are string type.

The App is used to remember which application the App was before.

Stage is used to record the step of Using Stages in the application.

 

Usage of the User class:

1. Producer created with producer: $ user = new User ($ openId, $ savePath); // savePath is a stored entity

2. merge into pipeline: $ user-> setAppState ($ app, $ stage );

Auto-stored instances will be automatically saved after the lifecycle value is entered.

3. The value of the response returned to the App was $ user-> getApp ();

4. Extract the Stage into Sequence Value: $ user-> getStage ();

5. set the custom key value (for example, $ key = $ value) $ user-> set ($ key, $ value );

6. Read the custom key value $ user-> get ($ key );

 

 

Re-design this example:

 

"Welcome! Reply to number select project: \ r \ n1 tell joke 2 listen to music"

 

It is divided into three application states:

App = "main" main menu selection

App = "joke" tell a joke

App = "music" listen to music

 

The message processing function is modified as follows:

Function onMessage (WeChat $ object, $ messageType, $ content, $ arg1, $ arg2 ){

$ User = new User ($ object-> fromUser, $ savePath); // $ object-> fromUser is the user's OpenID

Switch ($ user-> getApp ()){

Case "":
Case "main ":

MainMessage ($ object, $ messageType, $ content, $ arg1, $ arg2 );

Break;

Case "joke ":

JokeMessage ($ object, $ messageType, $ content, $ arg1, $ arg2 );

Break;

Case "music ":

MusicMessage ($ object, $ messageType, $ content, $ arg1, $ arg2 );

Break;

}
}

 

The mainMessage () function is used to process messages in the main menu, the jokeMessage () function is used to process messages in joke applications, and the musicMessage () function is used to process messages in music applications ,...

Through this modification, we can determine the status of different apps and distribute the message processing to three functions: mainMessage, jokeMessage, and musicMessage. The program is much more elegant.

 

I write three message processing functions in three files, each file only writes one function, and then includes them in the main program.

The app. main. php file contains mainMessage ()

App. joke. php file contains jokeMessage ()

App. music. php file contains jokeMessage ()

 

What is the need to split a program like this?

This is the principle of module splitting. The advantage is that the overall program is reasonably split. The functions of each file and function are clear and simple, and the coupling degree is not high;

Each function code is not very long, easy to understand, not prone to errors, but can be divided by different persons for encoding

 

In practical applications, I saved the switch ($ user-> getApp () {...} section.

Use the call_user_func () function of PHP to dynamically call the corresponding message processing function by judging the App name

 

 

Detailed details, see the code (: http://download.csdn.net/detail/c80486/6361281)

 

The Code passes the test on the/Yixin platform.