11A screen mechanism

              11A screen mechanism 11A screen mechanism When you first come into contact with 11A, I believe everyone is also confused. When you hit the breakpoint to EntryNewScreen or mmi_frm_scrn_enter, you rarely run, which leads to a slow development rate. I am also deeply affected by it, so I looked at the current screen management, and just briefly talked about the current processing ideas, without a deep analysis of each function. The concept of screen in 11A is very weak, but it is also involved, and the tree structure processing in 10A is not abandoned. The following is a brief introduction to the process based on adding a new application. 1. When adding a new APP, we will define the corresponding launch function, and its implementation will execute VfxAppLaunc her::launch, and we generally only pass 3 parameters in, and the others are treated as default values. The first is APP_ID (this is more important, the group_id that maintains the tree structure is obtained based on it), the second is the corresponding class information, and the third is the ID called in mmi_frm_group_send_event (this is generally ROOT). Then it will create group_ID according to APP_ID and enter. It can be simply understood as: VfxAppLauncher::launch is the previous mmi_frm_group_create and mmi_frm_group_enter. The special thing is that we no longer actively define ID, and the GROUP_ID obtained from APP_ID is placed under ROOT. (In fact, the previous similar ID definitions were also accumulated based on APP_ID, and now it is just MTK that helps us do this step) 2. Next is entering the screen. We will re-implement the onRun function of the VfxApp class (complete polymorphism). In this function, we will create the VfxXXXMainScr class (inherited from VfxMainScr), and then call its member function show. This function will actively obtain an unused screen_id to call mmi_frm_scrn_enter, so that we can enter the screen as we are familiar with...