Cocos2d-x development: How to detach an interface Example from a project

Cocos2d-x development: How to detach an interface Example from a project
Cocos2d-x development, including core module interface development and script part of the business logic implementation. from the needs of upper-layer applications, scripts often depend on the underlying interface functions when implementing business logic, however, not all people can easily understand how to use lower-layer interfaces. This is not only a language difference, but also the method of use that interface developers expected at the beginning of the design, generally, interfaces should be provided to use demos. Because I use lua, unittest is often used to present interface function tests in the form of testcase. in fact, it is just a name. first, let's take a look at why I have made such a distinction. I have seen some projects. Otherwise, I will not provide examples, that is, I will write various tests in the project's entrance file. assume that our engine enters the luaEngine and src/main. in the lua file. therefore, many projects that are not separated will appear in main. make a variable in the lua file. then determine whether to enter the game, enter the test, or enter the tool mode. programmers, we can Without worrying about this implementation process, the results are also implemented in various aspects. however, I still want to analyze it: after all, project development is developed in cooperation with multiple parts. We do not want to manually modify the configuration file when using the tools we provide. in addition, since the initial stage was to facilitate the stacking of various tests in a project file, of course, good habits may not be learned by everyone. This bad habit is very contagious. everyone in the future will get used to this simple test method and take it for granted. the final result is that the heap test file cannot be viewed. finally, it is also the most important point. I have carefully thought about the underlying interface and what is the purpose of writing sample code? In fact, it is a supplement to the api deficiency. In a better case, reaching a positive specification can quickly familiarize you with the use of interfaces. I always believe that the interface designer should think about how to better use the self-written interface when implementing it. I have mentioned a lot above and hope to express my meaning accurately. If you cannot understand it, you can refer to my ideas and Implementation below. I believe it is easy to understand. I first thought about how to separate the implementation of the project business logic, such as tools and interface examples. It is not difficult to do this, it is nothing more than wearing a new folder in the same directory of the Project Script directory, and providing a new entry file. like the following: 1 frameworks2 runtime3 res4 src5 -- main. lua -- we usually see the game entry file 6 -- Tests7 -- TestsController. lua -- Test entry 8 -- Tools -- if necessary, the tool entry. in combination with my previous starting point, I do not want to change the script or configuration file This way. we all know that, whether in Windows or linux, the application can parse the command line parameters during running. of course, in Linux, argc and argv are used to parse the main function. In win, we can also parse the lpCmdLine or _ argc ,__ targv (tchar. h ). this part of Windows is written as unicode, but you should understand it. speaking of this, we should be very clear about how to implement this part of the function. the following code uses win32 as an example: 1 AppDelegate. h 2 public: 3 void setCmdLine (const std: string & cmdline) 4 {5 this-> M_cmdline _ = cmdline; 6} 7 std: string getCmdLine () const 8 {9 return this-> M _ Pipeline line _; 10} 11 private: 12 std: string getCmdByFlag (const std: string & flag, const std: string & defaultValue); 13 std: string m_pipeline line _; this is the entry proxy encapsulated by the engine. Here I add a private attribute to install the parameters read from the command line. whatever you read, you can install them together. however, since I wrote it, I certainly know what the format is. unzip xiaoyan.exe-esrc/Tests/TestsController. lua is like this. During parsing, I only need to parse the flag attribute field after-e, and I will know the code of the module to be run. now, I have converted the Unicode string to ansi as follows: 1 win32 main. cpp 2 // create the application instance 3 AppDelegate app; 4 if (_ argc> 1) 5 {6 # if (UNICODE) 7 std: wstring wcmdLine (lpCmdLine); 8 const wchar_t * wparams = wcmdLine. c_str (); 9 size_t size = ww.line. size () * 2 + 1; 10 char * tmp = new char [size]; 11 memset (tmp, 0, size); 12 wcstombs (tmp, wparams, size ); 13 std: string using line (tmp); 14 app. setCmdLine (cmdline); 15 delete [] tmp; 16 # else17 std: string cmdLine (lpCmdLine); 18 app. setCmdLine (cmdli Ne); 19 # endif20} 21 int ret = Application: getInstance ()-> run (); although I don't understand the win32 sdk, let's take a look at unicode processing, it is easy to write the above Code. now, I have obtained the command line parameters I want and implemented cross-platform conversion processing. Put them in std: string, and the parsing is simple, directly for implementation: 1 std: string AppDelegate: getCmdByFlag (const std: string & flag, const std: string & defaultValue) 2 {3 4 if (this-> M_cmdline _. empty () {return defaultValue;} 5 std: size_t index = this-> M_cmdline _. find (flag); 6 if (index = std: String: npos) {return defaultValue;} 7 std: size_t nextIndex = this-> M_cmdline _. find ("-", index + flag. size (); 8 if (nextIndex = std: string: npos) {return this-> m_1_line _. substr (index + flag. size (), std: string: npos);} 9 else {return this-> m_1_line _. substr (index + flag. size (), nextIndex-index-flag.size ();} 10 return defaultValue; 11} after the above changes, I can modify my engine entry implementation, don't talk nonsense, look at it directly. 1 bool AppDelegate: ap PlicationDidFinishLaunching () 2 {3 auto engine = LuaEngine: getInstance (); 4 ScriptEngineManager: getInstance ()-> setScriptEngine (engine); 5 std :: string entranceFile = getCmdByFlag ("-e", "main. lua "); 6 if (engine-> executeScriptFile (entranceFile. c_str () {7 return false; 8} 9 10 return true; 11} I just added an Interface Test Module, so there is no logical judgment, however, I believe that it is easy to add more functions, but it is not the entry above, instead, you can simply provide the module entry file you want to run during running. Because of the working directory issue, I used vs for testing. However, I also wrote the sublime text configuration section and gave it together. I first modified the build system and added a Test sub-module: (you can check against the previous article, if not too troublesome) 1 {2 "cmd": ["C: \ Users \ Administrator \ Desktop \ xiaoyan \ scripts \ compile-win32.cmd "], 3" working_dir ":" C: \ Users \ Administrator \ Desktop \ xiaoyan ", 4" shell ": true, 5" encoding ":" UTF-8 ", 6" variants ": 7 [8 {9 "cmd": ["start", "C: \ Users \ Administrator \ Desktop \ xiaoyan \ \ Xiaoyan \ runtime \ win32 \ xiaoyan.exe "], 10" name ":" Run ", 11}, 12 {-- add a Test with the parameter 13" cmd ": ["start", "C: \ Users \ Administrator \ Desktop \ xiaoyan \ runtime \ win32 \ xiaoyan.exe ", "-esrc/Tests/TestsController. lua "], 14" name ":" Test ", 15} 16] 17} as described above, additional parameters of Test are added to the end, that is, the entry to the test module. all right, here is the last detail. add a shortcut key: 1 [2 {"keys": ["alt + f1"], "command": "toggle_side_bar"}, 3 4 {"keys ": ["f5" ], "Command": "build"}, 5 {"keys": ["f10"], "command": "build", "args": {"variant ": "Run" }}, 6 {"keys": ["f8"], "command": "build", "args": {"variant ": "Test" }}, 7] Okay. Now, src/Tests/TestController. the lua test source code is not required, right? I believe it is easy to think about how to do this. Why should I do this? What is the relationship between this and separation? Before talking about this, let me first talk about how to use it. If you know how to use it, you will know where the advantages are. Naturally, you will understand the benefits. you can refer to the Lua-tests example as a good way to implement Tests, but of course we will not write so complicated. this may not be complete, but the separation work is very easy to see the results. If you do not understand anything in development, read the TestCase under Tests first. If you need to add interfaces, add the written API test to TestCase and submit it. here, I have finished the separation part. For the test implementation below after separation, I believe that different insightful programmers will have different practices, and those will be free to play. in fact, my purpose is to test the interface of the lower-layer module. before determining the game type and needs, blindly designing the underlying architecture will cause many problems in future development.