Recently, I have been working on a project, mainly to transplant the original Symbian C ++ project to the QT version. In this case, I have encountered n problems, and I have rarely summarized them. In the next few articles, I will summarize some of the methods, experiences and lessons, and share them with you.
After Symbian develops to symbian3 and symbian4: originally, the living space of Symbian C ++ is getting smaller and smaller, and QT will eventually become the main trend. Therefore, many projects originally written in Symbian C ++ are faced with a problem: either the latest version is pushed down to use QT for rewriting or transplantation. Many people may say that the framework and usage of Symbian C ++ differ greatly from that of QT, but it is not as cost-effective as rewriting. In my experience, the porting speed is faster, less risky. If QT is re-written, the UI may be implemented very quickly. However, the connection to the underlying engine and the original architecture logic will face great challenges in the future, or it will not be applicable at all. Therefore, we recommend that you port the tool properly, so that errors may be compared.
1: Build a development environment.
You can directly use the qtsdk and install it. But I do not recommend this because of the following reasons:
① The ID of QT creator is very immature. Many inexplicable errors may occur during compilation and debugging, and the GCC compiler itself is very slow. If the project is large, the Compilation speed is sufficient, this greatly reduces the development efficiency and project progress.
② QT-mobility some functions we found that debugging cannot be performed under QT-creator, and breakpoint cannot be implemented.
③ There may be many original Symbian C ++ programmers in the project. There is still a process to bring them into contact, and there are so many problems ··
Therefore, we recommend that you use VC + carbide for development and debugging in windows and carbide in Symbian. VC compilation is absolutely fast and stable. Carbide is the standard environment of Symbian, which is familiar to many c ++ programmers.
2: porting principles:
(1) Try to port data at the source to ensure code uniformity.
Exampl
E:The definition of Symbian system events is different from that of QT System events, but a large amount of data is transferred and used in programs. We should transplant and convert the event after obtaining it from the most source.
The event in QT is qmouseevent. The event in Symbian is tpointevent. During transplantation, we need to do the following:
(1) define a class tpointevent in the PC environment, and copy the Symbian Source Code accordingly.
(2) Write A Conversion Function qmouseevent2tpointevent () to convert the obtained qmouseevent event to a tpointevent event. (3) When the control receives the qmouseevent mouse event, we only need to call qmouseevent2tpointevent () to convert it to tpointevent, then we can continue to use the original Symbian code to use tpointevent after the event is transmitted in the series. You do not need to modify all of them. (4) Some people may have said: After you do this, there will be no problem in windows, but will there be no error in repeated definitions in Symbian? Yes. Therefore, we only need to wrap the definition of tpointevent with the system platform macro, Which is customized in windows and defined in Symbian.
②
Windows
Debugging in Windows as much as possible.
Due to the inherent advantage of debugging speed in the PC environment, the code that we can debug in Windows should never be debugged in the Symbian environment. After all, it is very slow to start the modemor or anything.
Example:If you use the qtmobility function, you need to set a switch for the corresponding part. This part can only be debugged on the simulator or on the real machine, but cannot be debugged on the PC. therefore, you must set a switch for debugging of other modules in the PC to enable and disable the modules on different platforms.
③ If system macros are available, custom macros are not used.
.
Example:For QT code, we may want to use different logical segments in Symbian and PC. In this case, we need to use the QT platform macro to differentiate them, instead of using custom macros. for example, in Symbian, we specify the full screen size, but in PC, the normal size. In this case, we need to distinguish between system platform macros.
Do not use custom macros. After all, manual control is not as automatic and rigorous as system control. Ifdef
Q_ OS _symbian
Widget-> resize (screensize );
Elif defined
Q_ OS _win32
Widget-> resize (qszie (360,640 ));
# Endif
3: porting method: 1: QT can be implemented in all. For some QT which cannot be implemented at present, pimpl design mode must be used to separate implementation to facilitate subsequent cross-platform implementation. Currently, QT provides better support for the desktop environment, but it does not support the mobile platform very well. Therefore, QT-mobility and other supplementary mobile functions are provided later. Currently, QT-mobility only supports mobile features, and many common features are not supported yet. Therefore, hybrid programming is required. Mixed Programming here is not good if it is understood to be mixed with Symbian code. After all, we have to debug it in the PC, and it won't work in the PC, therefore, it is better to use the pimpl mode to implement Phase Separation of interfaces. There is an article on Wiki specifically about this, but I read this article not very straightforward. A lot of things can be clearly understood in one or two sentences, and it has to be said for a while, maybe the style of foreigners is different from that of Chinese people. I wrote an article to explain it briefly. If you are interested, read it first. If you use pimpl once, you will find it amazing. I found in project contacts that QT for Symbian cannot implement the following functions: 1: Mobile Phone vibration function 2: Mobile Phone desktop tray 3: Mobile Phone frontend and backend switch event handling 4 :.....
