Hello, dear habravchane!
I want to share my experience in developing and publishing for Nokia's smartphones. I do not set a goal to show how good or bad everything is, and also I will not compare it with development for other mobile platforms. This post is an attempt to share experience with other people who, perhaps, are either still thinking about whether to write software for Nokia, or have just started doing it. In any case, I hope the information will help someone to avoid my mistakes, save time and achieve success in the field of mobile applications. Further there is a lot of text to whom it is interesting - welcome under kat.
Story. Start.
My acquaintance with the development of Nokia’s Symbian mobile platform began in early 2009, when I somewhat succumbed to the hype that prevailed after the release of the first iPhones and the Nokia 5800. I had never had any smartphones before - I was in my third year at university I was just starting to make some extra money - in general, typical student half-starved days. As a result, I saved money and took the fresh Nokia 5800. The choice fell on Nokia, because before that there were only phones of this brand, and the equipment was very high for that time level. Since I was studying for an IT specialty, I soon wanted to touch this phone from a developer’s point of view.
')
Symbian C ++
At that time, Symbian was written either in Java or in C ++. Since C ++ was well known to me at that time, I decided to study its “dialect” for Symbian. I admit honestly, the study of the new platform was given with some difficulty:
- new concepts of Leave-exceptions (lightweight analogue of C ++ exceptions);
- two-phase constructors of objects, stacks with objects in Leave-functions (those functions that can “throw out” the exception, and the memory must be cleaned at the same time);
- fuss with obtaining certificates and signing packages;
- writing assembly rules and the package building system itself;
- writing dialogs through files with resources and connecting these files;
- a combination of 3 identifiers (UID) and various access rights (capabilities);
- the SDK setup was quite confusing, especially when there were several SDKs;
- few examples and poor documentation.
In general, those who worked with Symbian C ++ remember well the horrors of those years. Yes, over time, of course, you get used to it, but still, during the development process, you often had to be distracted by these small and not only things. Actually, I didn’t write anything serious at that time - so, all sorts of exams for the exams and other “Hello, World”. There was no OVI Store at that time, there were only announcements. Nevertheless, I got a fairly good experience, which was useful in the future.
Qt appearance
By the end of 2009, I had somehow forgotten about the development on Symbian C ++ - there was not much motivation, and more and more time was part-time work. Meanwhile, Nokia launched the OVI Store, released the new iPhone 3GS, and the mobile application market experienced a real boom. But at the end of the year, a new event in the Nokia world occurred - the release of the Qt 4.6 framework with support for Symbian and Maemo. It just so happened that at that time I was actively developing on Qt, so it was a sin not to remember the past and see what has changed. A lot has changed:
- There is a new Qt Creator IDE to replace Carbide.c ++, which provided improved integration with Qt, a convenient help system, an automated build system - now you could more easily develop Symbian in regular C ++ and with a powerful set of graphical components, even at first Qt under Symbian and did not shine with speed;
- there was an improved Symbian debugger that could "deploy" Qt classes;
- simplified signature and package creation system;
- A new Symbian emulator has appeared.
In general, Nokia’s progress towards simplifying development for Symbian, which was not an easy one, was noticeable. But there were old problems, new ones were added somewhere:
- Qt Creator was very raw, often fell after rebuilding the project (it still suffers from this);
- assembly speed was very low - it was possible to start the process and go to drink tea or read articles on the Internet, especially long and painful was a complete reassembly;
- the debugger on the 5800 buggy very often, stopped working, and Qt Creator often didn’t see the phone at all;
- The released emulator worked under Windows, that is, to check the application on the emulator, it was necessary to build it under Windows - just great, and if it is not going to be built under Windows?
- some of the Qt dialogs looked very poor (for example, QInputDialog), but adding them in the old form in the resource file was not entirely trivial, because Qt Creator didn’t pay much attention to this;
- assembly rules still had to be written by hand.
Separately, I note the appeared OVI Store. Initially, registration was paid (50 euros), plus, if necessary, it was also necessary to spend money on the certificate (registration now costs 1 euro). But when preparing for the publication and in the process of the store, “pleasant” trifles came to light:
- For some reason, when updating the application, the description may first be updated, but only after a couple of days - the program itself. Great, really, when users get an application that does not match the description?
- normal interface tutorials did not appear immediately, so a cesspool was created, so to speak, where everyone threw away what he wanted;
- the time allotted for the QA department to check the application before publication was not clearly regulated anywhere, so someone checked the month. And now they can check for two (!) Weeks to update your application. And not the fact that the result will be positive. And the forum is replete with messages that different people check applications and at the same time render different verdicts;
- There is absolutely no feedback from the app buyers. There is only a stupid rating system - you can not even ask a person for details of the error in order to fix it. Moreover, the lion's share of the low rating comes from the fact that the user did not load the application (ay, Nokia, is this really a developer’s problem?);
- the store is made in itself very strange. For example, why do some applications that do not have a single user rating already cost 5 stars (this is the maximum)? What kind of merit? Or why you can put screenshots only (attention!) No larger than 256x256? What can be shown on this piece: a fragment of the screen or a picture on which you can not make out anything, and the screens are not square on the phones! I still can not understand this insanity;
- the impression was that Nokia didn't care about this store, because they simply could not describe all the “pitfalls” of preparing the application for publication. Let me explain with an example: Symbian does not normally perceive SVG, the mobile version of SVG Tiny is used. But, apparently, there are problems with it. When you make an application icon in SVG and add a shadow to an object in Adobe Illustrator, then you overtake Nokia’s proprietary program in Tiny SVG, then the icon “smears” on the phone. Apparently, the shadow is not supported. And only when I accidentally came across a video with an example of creating an icon on the Nokia website itself, I found out that they have special actions (Actions) for Illustartor to create shadows. That is, they knew about this joint, but did not even write anything on the wiki about it! Why it was impossible to write about it, because not everyone is watching the seemingly obvious 10-minute videos?
- Nokia has many different devices, and it is necessary to check on many, it is necessary to assemble for different systems (now it is S60v5, Anna, Belle) - it takes a lot of time.
Considering all the above, I will summarize: at times there were periods when the banal preparation of the application and the publication itself took more time than the development itself, which was therefore not very sweet. True, now Nokia has been actively campaigning for developers to switch to Qt, prophesying a great future for it.
The appearance of Harmattan and Qt Quick
So, Qt was actively developing, performance was improving, Qt Creator was improving (with Symbian ^ 3, the phone stopped falling off, and in the meantime I switched to the N8 machine). The assembly was greatly accelerated, and now I did not spend sleepless nights on idle waiting. All the other horrors of the Symbian heritage are preserved and have not thought of going anywhere. I especially liked the fact that sometimes not everything could be done in Qt Creator. For example, to write a recognizer for some mime type (so that an application can automatically open this file). I had to collect it in separate SDKs (already in 3 pieces) in the form of separate libraries, with their own magic UIDs, then add assembly rules to Qt Creator by hand. And adding support for this mime type in a Qt application is also a separate epic.
But, as is often the case, the enemy crept unnoticed. Now, Nokia began to recommend writing applications on the new Qt Quick (JS-based language), the capabilities of which, to put it mildly, were poor (if you want to open the file dialog - write yourself!) Compared to the full Qt based on QWidget. A development for mobile platforms based on QWidget Nokia announced ... obsolete. As they say, less than a year. No, Nokia did not prohibit further writing applications on them, but here developers were surprised. How do you like the fact that, having assembled your Qt-application under MeeGo (which, in fact, after all, Linux) without problems, you will not be able to change the orientation of the window (only landscape mode) when you turn the phone? All answers received one answer: write to Qt Quick. This is how simple it is. They didn't care what the MeeGo platform might not get those applications that are perfectly built for it, and the developers will lose the sales market.
And as usual, the preparation of the application itself for MeeGo was not without surprises. For example, the banal task is to display the application icon in the menu. But, for some reason, the default build rules in Qt Creator lead to the fact that it is not displayed. It doesn't matter, we search on the Internet, we find in the Nokia wiki a solution to the problem - we need to put the icon in another directory. Well, everything started to be displayed on the emulator, but there is nothing again on the device itself. What tricks?
I especially want to mention the emulator for MeeGo. This is a 400-meter-long carcass, which loads for a long time, works very slowly, and has only a couple of buttons (that is, it can play with an accelerometer or something like that will not work). And in fact, this is the usual QEMU with a stretched “muzzle” and an image of the firmware. Bravo, gentlemen from Nokia, to develop under MeeGo without the device itself is simply unrealistic.
As a result, by this time, in order to develop on the main Nokia phones you need devices based on: S60v5, Symbian ^ 3 (Anna, Belle) and MeeGo. Not bad, right? And for different devices, their own sets of Qt Quick components and Qt widgets. Weakly burst on all sides? As a result, I didn’t continue development under MeeGo, limiting myself only to S60v5 and Symbian ^ 3.
Final Act. Windows Phone.
Developers under Nokia, apparently, have become accustomed to kicking them like this, but nobody expected what happened last year. Nokia said it is switching to Windows Phone, and Symbian will be quietly covered. Awesome move. Today you are told - write on Qt, tomorrow - write on Quick, and the day after tomorrow - forget everything you knew - we are switching to Windows. At first, many thought that Qt would be ported to Windows Phone, and everything would be fine, but official myths have refuted these myths. Yes, many were shocked by such a turn of events, and such an attitude towards developers.
At the moment, the platform is quite new and young, so I have not had time to try it out due to lack of time and proper desire. Although interest, I confess, there is.
As an epilogue
In the course of development for Nokia devices, I acquired both programming skills and gained development experience for mobile platforms. I can not say that I received a lot of positive emotions. Personally for myself, I concluded that Nokia is very disregard for developers, arranging a leapfrog of platforms and, in fact, deceiving right in the face. Yes, there have been attempts to simplify the development process, but apparently the fact that Symbian is rooted in the distant past, to some extent did not allow to carry out his plan. The company did not have a clearly defined and directional vector of development, and the developers paid for it as well. Taking up the development for Symbian and MeeGo now, you can simplify the process using Qt Quick, but this will not save you from all the delays with the store. Be prepared to waste time besides the development itself.
Perhaps with the advent of Windows Phone, company policy will change, but only time will tell.
PS The goal to earn some big money with Nokia I did not set, and I don’t want to focus on my application, so I don’t call it. Usually they are interested here, but how much did you manage to earn in one way or another? For the curious I will answer in advance: for the year, the application brought about 1,500 euros, of which 30% went to Nokia itself. I did not make any promotion and did not engage in advertising. In general, the cost of the device paid off, and that is good :)