Is it worth developing for Nokia?
Hello, dear habravchane!
I want to share my experience in developing and publishing for Nokia smartphones. I do not set a goal to show how everything is good or bad, and 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 still thinking about whether to write software for Nokia or just started to do it. In any case, I hope the information helps someone avoid my mistakes, save time and succeed in the field of mobile applications. Then there is a lot of text, who are interested - welcome to cat.
My acquaintance with Nokia’s development of the Symbian mobile platform began in early 2009, when I succumbed to some degree of excitement that reigned after the release of the first iPhone and Nokia 5800. Before that, I never had any smartphones — I was in my third year at university. just starting to earn extra money - in general, typical student half-starved everyday life. As a result, I saved up money and took a fresh Nokia 5800. The choice fell on Nokia, because before that there were phones of only this brand, and the equipment was at a very high level for that time. Since I was studying in IT specialties, I soon wanted to touch this phone from the point of view of the developer.
At that time, under Symbian they wrote either in Java or in C ++. Since C ++ was very familiar to me at that time, I decided to study its “dialect” for Symbian. Frankly, the study of the new platform was given with some difficulty:
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 in the development process you often had to be distracted by these small and not only things. Actually, I did not write anything serious at that time - for example, all sorts of cheat sheets for exams and other "Hello, World". There was no OVI Store at that time, there were only announcements. Nevertheless, I got a pretty good experience that came in handy in the future.
By the end of 2009, I had somehow forgotten about developing on Symbian C ++ - there wasn’t much motivation, and part-time was taking up more and more time. Meanwhile, Nokia launched the OVI Store, a new iPhone 3GS came out, and the mobile app market was booming. 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 engaged in development on Qt, so it was a sin not to recall the past and see what changed. A lot has changed:
In general, Nokia’s progress was noticeable in the direction of simplifying development for Symbian, which was not easy. But old problems remained, new ones were added somewhere:
Separately, I note the appeared OVI Store. At first, registration was paid (50 euros), plus, if necessary, it was also necessary to spend money on a certificate (now registration costs 1 euro). But when preparing for publication and in the process of the store’s work, “pleasant” trifles were found out:
Given all of the above, I’ll 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 not very sweet. True, now Nokia has actively campaigned for developers to switch to Qt, predicting a great future for him.
So, Qt was actively developing, productivity was improving, Qt Creator was improving (the phone stopped falling off with Symbian ^ 3, and in the meantime I switched to the N8 device). The assembly accelerated very much, and now I did not spend sleepless nights on empty wait. All the other horrors of the Symbian heritage were preserved and did not think to go anywhere. I especially “liked” the fact that sometimes not everything could be done in Qt Creator. For example, write a recognizer for some mime type (so that the application can automatically open this file). I had to collect it in separate SDKs (as many as 3 pieces) as separate libraries, with my own UID magic, then add the assembly rules to Qt Creator by hand. And adding support for this mime type to a Qt application is also a separate epic.
But, as often happens, the enemy crept unnoticed. Now Nokia has begun recommending writing applications on the new Qt Quick (JS-based language), the capabilities of which, to put it mildly, were poor (if you want a file open dialog - write it yourself!) Compared to a full-fledged Qt based on QWidget. And Nokia announced the development for mobile platforms based on QWidget ... outdated. As they say, less than a year has passed. No, Nokia did not prohibit writing applications on them further, but surprises awaited developers. How do you like the fact that, having assembled your Qt application under MeeGo (which, in fact, is Linux) without problems, you will not be able to change the orientation of the window (only landscape mode) when you rotate the phone? All the exclamations received one answer: rewrite to Qt Quick. Just like that. They didn’t give a damn that the MeeGo platform might not get those applications
And as usual, the preparation of the application for MeeGo itself was not without surprises. For example, a commonplace 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 the Internet, we find in Nokia wiki a way to solve the problem - we must put the icon in a different directory. Well, everything began to be displayed on the emulator, but on the device itself there is nothing again. What tricks?
I especially want to note the emulator for MeeGo. This is a 400-meter carcass that takes a long time to load, works very slowly, and has only a couple of buttons (that is, playing there with an accelerometer or something like that fails). But in reality this is a regular QEMU with a tightened “face” and a firmware image. Bravo, gentlemen from Nokia, developing under MeeGo without the device itself is simply unrealistic.
As a result, at this point, in order to develop on the main Nokia phones, you need devices based on: S60v5, Symbian ^ 3 (Anna, Belle) and MeeGo. Not bad, right? Moreover, under different devices, their own sets of Qt Quick components and Qt widgets. Weak to tear on all sides? As a result, I did not continue developing for MeeGo, limiting myself to S60v5 and Symbian ^ 3 only.
Developers for Nokia, apparently, are already used to being kicked like this, but no one expected what happened last year. Nokia said it will switch to Windows Phone, and Symbian will slowly be closed. Awesome move. Today they tell you - write on Qt, tomorrow - write on Quick, and the day after tomorrow - forget everything that 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 refuted these myths. Yes, many were shocked by this 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 due desire. Although I admit there is interest.
During the development for Nokia devices, I acquired both programming skills and gained development experience for mobile platforms. I can’t say that I received a lot of positive emotions. For myself, I concluded that Nokia is very disregard for developers, arranging a leapfrog of platforms and, in fact, deceiving directly in the face. Yes, there were 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 the plan. The company did not have a clearly defined and directed development vector, and 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 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 I didn’t set the goal of making some big money by developing Nokia, 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’ll answer in advance: over the year the application brought about 1,500 euros, of which 30% went to Nokia itself. I did not carry out any promotion and did not engage in advertising. In general, the cost of the device paid off, and that’s good :)
I want to share my experience in developing and publishing for Nokia smartphones. I do not set a goal to show how everything is good or bad, and 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 still thinking about whether to write software for Nokia or just started to do it. In any case, I hope the information helps someone avoid my mistakes, save time and succeed in the field of mobile applications. Then there is a lot of text, who are interested - welcome to cat.
History. Start.
My acquaintance with Nokia’s development of the Symbian mobile platform began in early 2009, when I succumbed to some degree of excitement that reigned after the release of the first iPhone and Nokia 5800. Before that, I never had any smartphones — I was in my third year at university. just starting to earn extra money - in general, typical student half-starved everyday life. As a result, I saved up money and took a fresh Nokia 5800. The choice fell on Nokia, because before that there were phones of only this brand, and the equipment was at a very high level for that time. Since I was studying in IT specialties, I soon wanted to touch this phone from the point of view of the developer.
Symbian C ++
At that time, under Symbian they wrote either in Java or in C ++. Since C ++ was very familiar to me at that time, I decided to study its “dialect” for Symbian. Frankly, the study of the new platform was given with some difficulty:
- new concepts of Leave exceptions (lightweight analogue of C ++ exceptions);
- two-phase object constructors, stacks with objects in Leave functions (those functions that can throw an exception, and the memory must be cleaned);
- fuss with obtaining certificates and signing packages;
- writing assembly rules and the package assembly system itself;
- writing dialog boxes through resource files and connecting these files;
- a combination of 3 identifiers (UIDs) and various access rights (capabilities);
- the SDK setup was rather confusing, especially when there were several of these 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 in the development process you often had to be distracted by these small and not only things. Actually, I did not write anything serious at that time - for example, all sorts of cheat sheets for exams and other "Hello, World". There was no OVI Store at that time, there were only announcements. Nevertheless, I got a pretty good experience that came in handy in the future.
Qt Appearance
By the end of 2009, I had somehow forgotten about developing on Symbian C ++ - there wasn’t much motivation, and part-time was taking up more and more time. Meanwhile, Nokia launched the OVI Store, a new iPhone 3GS came out, and the mobile app market was booming. 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 engaged in development on Qt, so it was a sin not to recall the past and see what changed. A lot has changed:
- a new Qt Creator IDE appeared to replace Carbide.c ++, which provided improved integration with Qt, a convenient help system, and an automated build system - now it was more easy to develop Symbian with 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 debugger for Symbian, which was able to "deploy" Qt classes;
- simplified the system of signing and creating packages;
- A new Symbian emulator has appeared.
In general, Nokia’s progress was noticeable in the direction of simplifying development for Symbian, which was not easy. But old problems remained, new ones were added somewhere:
- Qt Creator was very raw, often crashed after rebuilding the project (he sins this to this day);
- assembly speed was very low - you could start the process and go to drink tea or read articles on the Internet, a complete reassembly took especially long and painfully;
- the 5800 debugger was buggy very often, it stopped working, and Qt Creator often did not see the phone at all;
- The released emulator worked under Windows, that is, to test the application on the emulator, it was necessary to build it under Windows - it’s just wonderful, but what if it’s not built for me under Windows?
- some 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 really count on this;
- assembly rules still had to be written manually.
Separately, I note the appeared OVI Store. At first, registration was paid (50 euros), plus, if necessary, it was also necessary to spend money on a certificate (now registration costs 1 euro). But when preparing for publication and in the process of the store’s work, “pleasant” trifles were found out:
- for some reason, when updating the application, the description may first be updated, but only after a couple of days - the program itself. It's great, though, when users get an application that doesn't match the description?
- normal interface manuals did not appear right away, so a garbage dump was created, so to speak, where everyone threw away what they wanted;
- the time allotted for QA to check the application before publication was not clearly regulated anywhere, therefore, someone checked for a month. And now they can check for two (!) Weeks update of your application. And not the fact that the result will be positive. And the forum is full of messages that different people check applications and at the same time issue different verdicts;
- There is absolutely no customer feedback on the app. There is only a stupid rating system - you can’t even ask a person for details of a mistake in order to correct it. Moreover, the lion's share of the low rating comes from the fact that the user has not downloaded the application (ay, Nokia, is that really a developer’s problem?);
- the store itself is very strange. For example, why do some applications that do not have any user ratings already have 5 stars (is this the maximum)? What kind of merit? Or why it is possible to place screenshots only (attention!) In the size no more than 256x256? What can be shown on this piece: a screen fragment or a picture on which you can’t see anything, and the screens are not square on the phones! I still cannot understand this insanity;
- it seemed that Nokia didn’t give a damn 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 accept SVG, the mobile version of SVG Tiny is used. But, apparently, there are problems with her. When you make the application icon in SVG and add a shadow to the object in Adobe Illustrator, then you overtake it with a proprietary program from Nokia in Tiny SVG, then the “smears” icon 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 site of Nokia itself, I found out that they have special Actions for Illustartor to create shadows. That is, they knew very well about this jamb, but did not even write anything in the wiki about it! Why could not write about it,
- Nokia has a lot of different devices, and you need to check on many, you need to assemble it for different systems (now it is S60v5, Anna, Belle) - it takes a lot of time.
Given all of the above, I’ll 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 not very sweet. True, now Nokia has actively campaigned for developers to switch to Qt, predicting a great future for him.
The advent of Harmattan and Qt Quick
So, Qt was actively developing, productivity was improving, Qt Creator was improving (the phone stopped falling off with Symbian ^ 3, and in the meantime I switched to the N8 device). The assembly accelerated very much, and now I did not spend sleepless nights on empty wait. All the other horrors of the Symbian heritage were preserved and did not think to go anywhere. I especially “liked” the fact that sometimes not everything could be done in Qt Creator. For example, write a recognizer for some mime type (so that the application can automatically open this file). I had to collect it in separate SDKs (as many as 3 pieces) as separate libraries, with my own UID magic, then add the assembly rules to Qt Creator by hand. And adding support for this mime type to a Qt application is also a separate epic.
But, as often happens, the enemy crept unnoticed. Now Nokia has begun recommending writing applications on the new Qt Quick (JS-based language), the capabilities of which, to put it mildly, were poor (if you want a file open dialog - write it yourself!) Compared to a full-fledged Qt based on QWidget. And Nokia announced the development for mobile platforms based on QWidget ... outdated. As they say, less than a year has passed. No, Nokia did not prohibit writing applications on them further, but surprises awaited developers. How do you like the fact that, having assembled your Qt application under MeeGo (which, in fact, is Linux) without problems, you will not be able to change the orientation of the window (only landscape mode) when you rotate the phone? All the exclamations received one answer: rewrite to Qt Quick. Just like that. They didn’t give a damn that the MeeGo platform might not get those applications
And as usual, the preparation of the application for MeeGo itself was not without surprises. For example, a commonplace 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 the Internet, we find in Nokia wiki a way to solve the problem - we must put the icon in a different directory. Well, everything began to be displayed on the emulator, but on the device itself there is nothing again. What tricks?
I especially want to note the emulator for MeeGo. This is a 400-meter carcass that takes a long time to load, works very slowly, and has only a couple of buttons (that is, playing there with an accelerometer or something like that fails). But in reality this is a regular QEMU with a tightened “face” and a firmware image. Bravo, gentlemen from Nokia, developing under MeeGo without the device itself is simply unrealistic.
As a result, at this point, in order to develop on the main Nokia phones, you need devices based on: S60v5, Symbian ^ 3 (Anna, Belle) and MeeGo. Not bad, right? Moreover, under different devices, their own sets of Qt Quick components and Qt widgets. Weak to tear on all sides? As a result, I did not continue developing for MeeGo, limiting myself to S60v5 and Symbian ^ 3 only.
The final act. Windows Phone
Developers for Nokia, apparently, are already used to being kicked like this, but no one expected what happened last year. Nokia said it will switch to Windows Phone, and Symbian will slowly be closed. Awesome move. Today they tell you - write on Qt, tomorrow - write on Quick, and the day after tomorrow - forget everything that 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 refuted these myths. Yes, many were shocked by this 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 due desire. Although I admit there is interest.
As an epilogue
During the development for Nokia devices, I acquired both programming skills and gained development experience for mobile platforms. I can’t say that I received a lot of positive emotions. For myself, I concluded that Nokia is very disregard for developers, arranging a leapfrog of platforms and, in fact, deceiving directly in the face. Yes, there were 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 the plan. The company did not have a clearly defined and directed development vector, and 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 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 I didn’t set the goal of making some big money by developing Nokia, 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’ll answer in advance: over the year the application brought about 1,500 euros, of which 30% went to Nokia itself. I did not carry out any promotion and did not engage in advertising. In general, the cost of the device paid off, and that’s good :)