How we designed the Toozla mobile guide for Symbian and MeeGo
The idea that our mobile audio guide to interesting places Toozla need to write for the Symbian platform, we visited for a long time. But before the creation of the application, the hands reached only in early 2011 - about a month before Nokia decided to bet on Windows Phone 7. However, this had no effect on our plans: Symbian devices still occupied a large percentage at that time On the market.
Choosing the necessary development option, we proceeded from three possible paths.
The first is to use the native Symbian SDK . The main advantage when choosing the Symbian SDK would be the maximum coverage of devices, starting with Symbian 3rd Edition. However, it is quite difficult to write programs on this SDK (especially when it comes to the UI), so we quickly dropped off this development option.
')
The second way is to use Qt SDK 1.0 . This devkit was released in mid-2010 and was based on Qt 4.6.3. Unlike the Symbian SDK, this option allowed us to simplify development (especially working with mobile-specific APIs) and rely on cross-platform. Among the drawbacks of this solution were smaller device coverage (only Symbian v1 and Symbian v3) and, nevertheless, some difficulty in developing a modern UI.
And the third is to resort to using Qt SDK 1.1 . At that time, he was in beta status, and therefore the main risks were associated. On the other hand, Qt 4.7 was used in this SDK, which introduced support for QML. Thanks to QML, interfaces could be created quickly and efficiently, while relying on cross-platform functionality. In addition, Qt Mobility contained QML controls for displaying maps - just what we needed.
In the end, we chose, of course, the SDK 1.1 - mainly due to the presence of the QML control itself and the simplicity of writing the UI.
The architecture of the application was chosen as follows: the entire engine is written in C ++, and QML is used only to create the UI. The connection between the engine and the interface is implemented through slots, signals and data binding.
The engine was written without any special comments and problems, but with the UI, due to incompleteness at that time Qt SDK 1.1, I had to tinker a little. When we wrote the application, the SDK did not yet have standard controls for mobile devices, so we built the interface from Rectangle, Text, Image ListView and MouseArea. But, despite this, we could without special expenses build quite complex controls like our player with the possibility of horizontal scrolling to select a story. Now all the necessary components in Qt Quick Components already have - we just did not wait a bit. :)
With guidelines for application design for that period, there was also confusion, but, in fairness, it should be noted that at the moment Nokia has already solved this problem.
The Qt SDK does not contain an emulator, but a simulator, so in my case all the code was compiled for x86 and used the Windows API to work. This leads to the fact that the application in the simulator looks a little different than on the device: other fonts and other anti-aliasing, and most importantly - a different speed of work. In the simulator, compared to a smartphone, everything just flies, and it gives a sense of false security. If you need to use the Symbian API, then to build a simulator you have to differentiate the # ifdef code. In any case, it is necessary to test the software performance on live devices - this rule applies to everyone, not just Qt-developers.
In the six months since the release of Qt SDK 1.1, Nokia has come a very long way. For example, Qt Quick Components appeared, so you can quickly create applications with Belle and Meego native interfaces. The latest version is quite stable, and QML along with Qt Creator is very pleasing. QML, in my opinion, is generally the best invention of mankind in terms of a declarative UI: if compared with other mobile platforms (Android, bada and even WP7 with its XAML), then it definitely wins. For example, due to the compactness and the possibility of using JavaScript right in the markup. In general, I am ready to write a couple more applications in QML just because I like to write on it ;-)
Immediately after the appearance of Toozla in the Nokia Store, the company received an offer to port the application to MeeGo. Why not? Actually, the porting went very quickly and painlessly. The main costs were incurred by the designer, who had to redraw the entire interface for a different screen resolution. For my part, porting has actually come down to its own set of some QML files and # ifdefs in the places where native API calls are made. My work as a programmer is 2 days, which is justified by the number of downloads for N9.
After developing Toozla for Symbian, I had a pretty good programming experience for this platform. At the time I wrote the application, Qt had its shortcomings and shortcomings, but I’m ready to forgive Nokia for QML and the cross-platform nature of Nokia. Now Qt SDK has lost many of its “childhood diseases” and has become a very attractive framework.
Choosing the necessary development option, we proceeded from three possible paths.
The first is to use the native Symbian SDK . The main advantage when choosing the Symbian SDK would be the maximum coverage of devices, starting with Symbian 3rd Edition. However, it is quite difficult to write programs on this SDK (especially when it comes to the UI), so we quickly dropped off this development option.
')
The second way is to use Qt SDK 1.0 . This devkit was released in mid-2010 and was based on Qt 4.6.3. Unlike the Symbian SDK, this option allowed us to simplify development (especially working with mobile-specific APIs) and rely on cross-platform. Among the drawbacks of this solution were smaller device coverage (only Symbian v1 and Symbian v3) and, nevertheless, some difficulty in developing a modern UI.
And the third is to resort to using Qt SDK 1.1 . At that time, he was in beta status, and therefore the main risks were associated. On the other hand, Qt 4.7 was used in this SDK, which introduced support for QML. Thanks to QML, interfaces could be created quickly and efficiently, while relying on cross-platform functionality. In addition, Qt Mobility contained QML controls for displaying maps - just what we needed.
In the end, we chose, of course, the SDK 1.1 - mainly due to the presence of the QML control itself and the simplicity of writing the UI.
Minor difficulties
The architecture of the application was chosen as follows: the entire engine is written in C ++, and QML is used only to create the UI. The connection between the engine and the interface is implemented through slots, signals and data binding.The engine was written without any special comments and problems, but with the UI, due to incompleteness at that time Qt SDK 1.1, I had to tinker a little. When we wrote the application, the SDK did not yet have standard controls for mobile devices, so we built the interface from Rectangle, Text, Image ListView and MouseArea. But, despite this, we could without special expenses build quite complex controls like our player with the possibility of horizontal scrolling to select a story. Now all the necessary components in Qt Quick Components already have - we just did not wait a bit. :)
With guidelines for application design for that period, there was also confusion, but, in fairness, it should be noted that at the moment Nokia has already solved this problem.
Simulator
The Qt SDK does not contain an emulator, but a simulator, so in my case all the code was compiled for x86 and used the Windows API to work. This leads to the fact that the application in the simulator looks a little different than on the device: other fonts and other anti-aliasing, and most importantly - a different speed of work. In the simulator, compared to a smartphone, everything just flies, and it gives a sense of false security. If you need to use the Symbian API, then to build a simulator you have to differentiate the # ifdef code. In any case, it is necessary to test the software performance on live devices - this rule applies to everyone, not just Qt-developers.In the six months since the release of Qt SDK 1.1, Nokia has come a very long way. For example, Qt Quick Components appeared, so you can quickly create applications with Belle and Meego native interfaces. The latest version is quite stable, and QML along with Qt Creator is very pleasing. QML, in my opinion, is generally the best invention of mankind in terms of a declarative UI: if compared with other mobile platforms (Android, bada and even WP7 with its XAML), then it definitely wins. For example, due to the compactness and the possibility of using JavaScript right in the markup. In general, I am ready to write a couple more applications in QML just because I like to write on it ;-)
Immediately after the appearance of Toozla in the Nokia Store, the company received an offer to port the application to MeeGo. Why not? Actually, the porting went very quickly and painlessly. The main costs were incurred by the designer, who had to redraw the entire interface for a different screen resolution. For my part, porting has actually come down to its own set of some QML files and # ifdefs in the places where native API calls are made. My work as a programmer is 2 days, which is justified by the number of downloads for N9.
After developing Toozla for Symbian, I had a pretty good programming experience for this platform. At the time I wrote the application, Qt had its shortcomings and shortcomings, but I’m ready to forgive Nokia for QML and the cross-platform nature of Nokia. Now Qt SDK has lost many of its “childhood diseases” and has become a very attractive framework.
Source: https://habr.com/ru/post/134202/
All Articles