How to create a “Film Search” for Windows Phone
Not so long ago, the official client of the Kinopoisk site appeared in the Russian Marketplace, which was cheered by Windows Phone users and is now breaking all popularity records among free apps. Of course, we could not but interview Grigoriy Nikonov ( Anadale ), the developer of this application.
Gregory is the co-founder of Actis Wunderman, Russia's largest digital agency and the company's chief technical guru. In addition, Gregory collaborated with the ATM Forum European Marketing Awareness Committee and became one of the authors of a monograph on ATM networks. In total, his experience in the field of IT is more than twenty years.
Under the cut, you can read Grigoriy Nikonov's opinion about the Windows Phone platform and competing mobile operating systems (both from the developer and the user), about the problems of developing for mobile OS, and directly about the design and development of “Kinopoisk”.
')
- How does development for Windows Phone differ from development for other platforms?
From a developer’s point of view, iOS has a very good API that allows you to implement almost anything that may be needed and contains excellent documentation. However, when developing for iOS, there is one drawback, which in one way or another strains: development is conducted in Objective-C - a wonderful language that was tried to reach down to a high-level language. Unfortunately, you spend a lot of time on it explaining what you need to do to show your data, instead of saying “here is my data - show it”. And, of course, you have to remember such things as memory leaks, managing reference counters and the like.
If we talk about user interfaces, then because of the tremendous flexibility of iOS, developers are trying to stand out as they can. As a result, all applications for iPhone and iPad are divided into two large categories: either all applications are made exactly the same, according to a template, or this is a “gypsy camp”, when everyone tries to do what he wants, and, moreover, he succeeds . The problem is that someone does not succeed very well. If you sum up any assessment of the development under iOS, then I put a solid four.
The second widely known platform is Android. This platform is also striking in its flexibility in most places. In addition, under Android development is conducted in Java - a more modern and convenient language than Objective-C. Java simplifies development because of its object-orientation and the fact that it is a “managed” language, that is, there is a virtual machine that theoretically manages memory for you and everything else. But here there are some nuances. First, Eclipse is predominantly the development environment, and while it’s good for the developer by itself, it’s not helpful in drawing interfaces and doing other things. In addition, writing in Java for Android, as it turned out, is more difficult than for iOS. When developing for iOS in Xcode, there is at least some visual help, there is no such thing in Eclipse. In general, Android is wonderful and flexible, developing for it is like “going into exploration in the jungle”: you are dragging a lot of everything on yourself, you need to know all this too; There are a lot of nuances, about which you can not guess, until they hit you in the head.
After all this, the development for Windows Phone turned out to be “the pure joy of a child in a sandbox”. Firstly, Microsoft today has the strongest developer tools. Better Visual Studio did not come up with anything. Apple with Xcode only now came up to VS five years ago, and although Eclipse has very strong tools for working with text, it does not have all the “visual wrappers” that are often needed. But this is when developing for Windows Phone: you immediately see the code that you write, and immediately see how it all looks on the screen. In addition, C # is a newer language than Java, and taught by Java errors. It is just nice and pleasant to write.
Windows Phone doesn't have the flexibility that iOS and Android have. The guys from Microsoft honestly approached the Metro-concept, saying that we are dealing with a mobile phone, and that the phone cannot have all these wood textures and raised buttons that everyone is trying to do on iOS and Android. In Microsoft they say that this is a phone, this is a screen, everything should be simple and you need to concentrate on the content. They presented a lot of templates and design principles, which interpret what the Metro app should look like. Despite the fact that, on the one hand, it seems that Microsoft is driving developers into the framework of templates, practice shows that there is so much freedom inside these templates that you can do anything. And most importantly, the applications that are obtained - if, of course, they are correctly written, do not look copied under the tracing paper. So from the point of view of the principles of approach to the design of Windows Phone is very conducive to concentrating on what you want to present to the user, and not how you want to present it. When we did “Film Search,” we spent an insane number of hours arguing about how an application should look, and lost several dozen user interaction scenarios with the application.
Returning to development, I would like to say that C # is the best general-purpose programming language, and, most importantly, I really like the direction in which this language continues to evolve. It is worth saying that we cheated a little, using the wrong “naked” language in the version that is available to everyone, but used some properties to simplify asynchronous work with data that will only appear in the next version of the language. And for mobile devices, these are things without which it’s just impossible to live. There are no such things either in iOS or Android, and as soon as you get involved in asynchronous work with data on these platforms, you immediately wallow in a bunch of incomprehensible things that really demolish the brain.
With classical synchronous programming, we send some kind of request to the server and wait for an answer - at this moment the user interface does not react to anything, which hardly suits anyone. In order to make the interface work, the code is conditionally divided into two parts: what was before the request was sent and what happened after the request was sent. These are two completely different pieces (and if the request is not one, as often happens, then they are twice the number of requests). As a result, it all breaks down into many small parts and you need to keep in mind a picture of what is being called for and not get confused when and what happens. At first, this may seem funny, but then it becomes increasingly difficult to control this process, which translates into errors that are the hardest to correct. It is the errors associated with asynchronous and multitasking are the most common - simply because there is no way to go through the debugger and check everything.
At the same time, in C #, the language compiler automatically knows how to put it all into thousands of methods. For a programmer, it looks as if the whole process is a linear flow, and the compiler for it parses all the code into the necessary methods. This feature of the compiler saved us about two weeks in the development of “Film Search”. Despite the fact that Kinopoisk is not a big application, even in its development we saved so much time thanks to C #. And it’s scary to imagine how much time we would spend searching and debugging those errors that could have happened if all this was developed under Android or iOS.
- What difficulties do people expect when developing mobile applications?
Developing applications for mobile platforms for a person who previously wrote only desktop software is a completely different world, under which you need to purposefully restructure. And after you rebuilt under it, it becomes strange to write for desktops: desktop software is too slow and static. It is a good idea for a desktop application to “ponder” for 10–20 seconds to perform any operation, while the average session time on the phone most often is only a few seconds. And if the mobile application does not respond to the user's actions during these few seconds, then the user will most likely simply delete this application. Therefore, the emergence of smartphones has greatly shifted the development paradigm towards a quick response, as it only appeared - albeit partially, - to show the user that the application is working. Nothing infuriates mobile programs more than a download wheel.
On the other hand, besides the desire to quickly show something to the user, there is a cruel limitation - the data transmission channel. Users do not always use Wi-Fi or at least 3G, which means they need to be engaged in optimizing network traffic. In addition to optimizing traffic, you need to optimize the interface of mobile applications: in a small area of the screen, you need to place as much information as possible and observe all the zones where the user hits with a finger. Someone has fewer fingers, and some more; and here there is a very common mistake, when programmers believe that the button should be the same size as its image, and in fact the “touch zone” of the correct button is much larger than it is drawn. You need to consider how much the application consumes processor power and how much space it takes in memory and on disk. This optimization is familiar to programmers of the old school, but is unknown to new developers. When developing “Kinopoisk”, we initially planned to cache data to the maximum so that in the absence of a network the user could see some information, but we ran into a problem when downloading an image from the Internet via 3G is faster than reading it from the internal storage — about Such problems are initially very difficult to guess. In the first versions of Kinopoisk, we first looked for images in the cache, and if they were not there, first download them and load them into the cache, and then show them from the cache. Now we cache only those images that appear on the first screen - all other materials are immediately downloaded from the Web.
- “Film Search” is a Windows Phone Panorama Application. What is your impression of Metro UI? Did the new interface cause design difficulties?
It took us about three weeks to design and understand how to decompose all the data displayed in the application into the correct Metro interface, so that all the information is contained and that the application is not a copy of the iPhone version of “Film Search”. Unfortunately, the last problem affects so many applications in the Marketplace, whose developers did not bother to adapt them to the new platform, but simply pulled the design from the existing version for iPhone or Android.
In Kinopoisk, of course, we used panoramas. The entire application is arranged in such a way that in any panorama the most important information is displayed on the first screen, information that is slightly less important is always displayed with one scroll to the right, and a little less in importance - with one scroll to the left. And this is a huge plus panoramas and Metro UI. This is not in iOS or Android.
- Were any hints used during development that you can tell about and which I would like to share?
For a while, we spent on creating the right infrastructure for developing applications - some of our internal base platform on how to build mobile software. There is such an architectural pattern Model-View-ViewModel , and there are several different implementations of it in the form of basic libraries. We looked at them and wrote our MVVM template. We did this because we already had some set of basic libraries that we used to work with, and the MVVM concept went very well to these libraries. As a result, we did not think, for example, how to describe the acquisition of data and something else - basically, the work went on the presentation.
- How does the API work, were there any problems with it? If so, how were they solved?
For our application, “Film Search” has written a separate API, different from that for its own iOS client. In an amicable way, the API is being developed to meet the needs of the client, and we did not need calls used in the Kinopoisk iOS client. The fact is that the iPhone version used separate calls for each screen - a list of popular films for today, a list of popular people for today, a news feed, and so on. We, in the panoramas, needed all these data together, so for Kinopoisk, under Windows Phone, part of the requests was redone for more convenient, fast and compact receipt of the data we needed.
- How did the interaction with the Microsoft Marketplace? Did they immediately allow the app to the store?
Since Kinopoisk was developed on the initiative of Microsoft and Nokia, even before going to Marketplace we had a review of the project, where we presented our design concept and information architecture to the guys from Microsoft, and after their approval we developed the application. After development, they tested “Film Search” and looked at fulfilling a number of strict but fair requirements. Actually, in the Marketplace all the checks were very fast.
- What can advise novice developers of applications for Windows Phone?
I can give two tips to novice developers.
First advice: never neglect the opportunity to save yourself a lot of time and nerves throughout the development path, investing this time and nerves in the beginning. You should not rush into the development of mobile software from scratch and do everything with your own hands - it is better to think about how you can use either the things you already know, or those created earlier.
Second tip: use third-party error management systems. There is one great service called BugSense - it’s a single system for collecting and processing errors that occur when an application is running. The service is available not only for Windows Phone, but also for iOS and Android. If any error occurs, BugSense shows the user a window about the problem, and sends information about the error itself and all technical information about the status of the smartphone in which the error occurred to the website. As a result, on the site all this information is collected and processed, allowing you to quickly respond to problems that arise. This service is much more convenient than what Microsoft offers in its App Hub. The service is paid, but it also has a free version of the subscription with a number of restrictions, which, however, is quite enough.
Gregory is the co-founder of Actis Wunderman, Russia's largest digital agency and the company's chief technical guru. In addition, Gregory collaborated with the ATM Forum European Marketing Awareness Committee and became one of the authors of a monograph on ATM networks. In total, his experience in the field of IT is more than twenty years.
Under the cut, you can read Grigoriy Nikonov's opinion about the Windows Phone platform and competing mobile operating systems (both from the developer and the user), about the problems of developing for mobile OS, and directly about the design and development of “Kinopoisk”.
')
- How does development for Windows Phone differ from development for other platforms?
From a developer’s point of view, iOS has a very good API that allows you to implement almost anything that may be needed and contains excellent documentation. However, when developing for iOS, there is one drawback, which in one way or another strains: development is conducted in Objective-C - a wonderful language that was tried to reach down to a high-level language. Unfortunately, you spend a lot of time on it explaining what you need to do to show your data, instead of saying “here is my data - show it”. And, of course, you have to remember such things as memory leaks, managing reference counters and the like.
If we talk about user interfaces, then because of the tremendous flexibility of iOS, developers are trying to stand out as they can. As a result, all applications for iPhone and iPad are divided into two large categories: either all applications are made exactly the same, according to a template, or this is a “gypsy camp”, when everyone tries to do what he wants, and, moreover, he succeeds . The problem is that someone does not succeed very well. If you sum up any assessment of the development under iOS, then I put a solid four.
The second widely known platform is Android. This platform is also striking in its flexibility in most places. In addition, under Android development is conducted in Java - a more modern and convenient language than Objective-C. Java simplifies development because of its object-orientation and the fact that it is a “managed” language, that is, there is a virtual machine that theoretically manages memory for you and everything else. But here there are some nuances. First, Eclipse is predominantly the development environment, and while it’s good for the developer by itself, it’s not helpful in drawing interfaces and doing other things. In addition, writing in Java for Android, as it turned out, is more difficult than for iOS. When developing for iOS in Xcode, there is at least some visual help, there is no such thing in Eclipse. In general, Android is wonderful and flexible, developing for it is like “going into exploration in the jungle”: you are dragging a lot of everything on yourself, you need to know all this too; There are a lot of nuances, about which you can not guess, until they hit you in the head.
After all this, the development for Windows Phone turned out to be “the pure joy of a child in a sandbox”. Firstly, Microsoft today has the strongest developer tools. Better Visual Studio did not come up with anything. Apple with Xcode only now came up to VS five years ago, and although Eclipse has very strong tools for working with text, it does not have all the “visual wrappers” that are often needed. But this is when developing for Windows Phone: you immediately see the code that you write, and immediately see how it all looks on the screen. In addition, C # is a newer language than Java, and taught by Java errors. It is just nice and pleasant to write.
Windows Phone doesn't have the flexibility that iOS and Android have. The guys from Microsoft honestly approached the Metro-concept, saying that we are dealing with a mobile phone, and that the phone cannot have all these wood textures and raised buttons that everyone is trying to do on iOS and Android. In Microsoft they say that this is a phone, this is a screen, everything should be simple and you need to concentrate on the content. They presented a lot of templates and design principles, which interpret what the Metro app should look like. Despite the fact that, on the one hand, it seems that Microsoft is driving developers into the framework of templates, practice shows that there is so much freedom inside these templates that you can do anything. And most importantly, the applications that are obtained - if, of course, they are correctly written, do not look copied under the tracing paper. So from the point of view of the principles of approach to the design of Windows Phone is very conducive to concentrating on what you want to present to the user, and not how you want to present it. When we did “Film Search,” we spent an insane number of hours arguing about how an application should look, and lost several dozen user interaction scenarios with the application.
Returning to development, I would like to say that C # is the best general-purpose programming language, and, most importantly, I really like the direction in which this language continues to evolve. It is worth saying that we cheated a little, using the wrong “naked” language in the version that is available to everyone, but used some properties to simplify asynchronous work with data that will only appear in the next version of the language. And for mobile devices, these are things without which it’s just impossible to live. There are no such things either in iOS or Android, and as soon as you get involved in asynchronous work with data on these platforms, you immediately wallow in a bunch of incomprehensible things that really demolish the brain.
With classical synchronous programming, we send some kind of request to the server and wait for an answer - at this moment the user interface does not react to anything, which hardly suits anyone. In order to make the interface work, the code is conditionally divided into two parts: what was before the request was sent and what happened after the request was sent. These are two completely different pieces (and if the request is not one, as often happens, then they are twice the number of requests). As a result, it all breaks down into many small parts and you need to keep in mind a picture of what is being called for and not get confused when and what happens. At first, this may seem funny, but then it becomes increasingly difficult to control this process, which translates into errors that are the hardest to correct. It is the errors associated with asynchronous and multitasking are the most common - simply because there is no way to go through the debugger and check everything.
At the same time, in C #, the language compiler automatically knows how to put it all into thousands of methods. For a programmer, it looks as if the whole process is a linear flow, and the compiler for it parses all the code into the necessary methods. This feature of the compiler saved us about two weeks in the development of “Film Search”. Despite the fact that Kinopoisk is not a big application, even in its development we saved so much time thanks to C #. And it’s scary to imagine how much time we would spend searching and debugging those errors that could have happened if all this was developed under Android or iOS.
- What difficulties do people expect when developing mobile applications?
Developing applications for mobile platforms for a person who previously wrote only desktop software is a completely different world, under which you need to purposefully restructure. And after you rebuilt under it, it becomes strange to write for desktops: desktop software is too slow and static. It is a good idea for a desktop application to “ponder” for 10–20 seconds to perform any operation, while the average session time on the phone most often is only a few seconds. And if the mobile application does not respond to the user's actions during these few seconds, then the user will most likely simply delete this application. Therefore, the emergence of smartphones has greatly shifted the development paradigm towards a quick response, as it only appeared - albeit partially, - to show the user that the application is working. Nothing infuriates mobile programs more than a download wheel.
On the other hand, besides the desire to quickly show something to the user, there is a cruel limitation - the data transmission channel. Users do not always use Wi-Fi or at least 3G, which means they need to be engaged in optimizing network traffic. In addition to optimizing traffic, you need to optimize the interface of mobile applications: in a small area of the screen, you need to place as much information as possible and observe all the zones where the user hits with a finger. Someone has fewer fingers, and some more; and here there is a very common mistake, when programmers believe that the button should be the same size as its image, and in fact the “touch zone” of the correct button is much larger than it is drawn. You need to consider how much the application consumes processor power and how much space it takes in memory and on disk. This optimization is familiar to programmers of the old school, but is unknown to new developers. When developing “Kinopoisk”, we initially planned to cache data to the maximum so that in the absence of a network the user could see some information, but we ran into a problem when downloading an image from the Internet via 3G is faster than reading it from the internal storage — about Such problems are initially very difficult to guess. In the first versions of Kinopoisk, we first looked for images in the cache, and if they were not there, first download them and load them into the cache, and then show them from the cache. Now we cache only those images that appear on the first screen - all other materials are immediately downloaded from the Web.
- “Film Search” is a Windows Phone Panorama Application. What is your impression of Metro UI? Did the new interface cause design difficulties?
It took us about three weeks to design and understand how to decompose all the data displayed in the application into the correct Metro interface, so that all the information is contained and that the application is not a copy of the iPhone version of “Film Search”. Unfortunately, the last problem affects so many applications in the Marketplace, whose developers did not bother to adapt them to the new platform, but simply pulled the design from the existing version for iPhone or Android.
In Kinopoisk, of course, we used panoramas. The entire application is arranged in such a way that in any panorama the most important information is displayed on the first screen, information that is slightly less important is always displayed with one scroll to the right, and a little less in importance - with one scroll to the left. And this is a huge plus panoramas and Metro UI. This is not in iOS or Android.
- Were any hints used during development that you can tell about and which I would like to share?
For a while, we spent on creating the right infrastructure for developing applications - some of our internal base platform on how to build mobile software. There is such an architectural pattern Model-View-ViewModel , and there are several different implementations of it in the form of basic libraries. We looked at them and wrote our MVVM template. We did this because we already had some set of basic libraries that we used to work with, and the MVVM concept went very well to these libraries. As a result, we did not think, for example, how to describe the acquisition of data and something else - basically, the work went on the presentation.
- How does the API work, were there any problems with it? If so, how were they solved?
For our application, “Film Search” has written a separate API, different from that for its own iOS client. In an amicable way, the API is being developed to meet the needs of the client, and we did not need calls used in the Kinopoisk iOS client. The fact is that the iPhone version used separate calls for each screen - a list of popular films for today, a list of popular people for today, a news feed, and so on. We, in the panoramas, needed all these data together, so for Kinopoisk, under Windows Phone, part of the requests was redone for more convenient, fast and compact receipt of the data we needed.
- How did the interaction with the Microsoft Marketplace? Did they immediately allow the app to the store?
Since Kinopoisk was developed on the initiative of Microsoft and Nokia, even before going to Marketplace we had a review of the project, where we presented our design concept and information architecture to the guys from Microsoft, and after their approval we developed the application. After development, they tested “Film Search” and looked at fulfilling a number of strict but fair requirements. Actually, in the Marketplace all the checks were very fast.
- What can advise novice developers of applications for Windows Phone?
I can give two tips to novice developers.
First advice: never neglect the opportunity to save yourself a lot of time and nerves throughout the development path, investing this time and nerves in the beginning. You should not rush into the development of mobile software from scratch and do everything with your own hands - it is better to think about how you can use either the things you already know, or those created earlier.
Second tip: use third-party error management systems. There is one great service called BugSense - it’s a single system for collecting and processing errors that occur when an application is running. The service is available not only for Windows Phone, but also for iOS and Android. If any error occurs, BugSense shows the user a window about the problem, and sends information about the error itself and all technical information about the status of the smartphone in which the error occurred to the website. As a result, on the site all this information is collected and processed, allowing you to quickly respond to problems that arise. This service is much more convenient than what Microsoft offers in its App Hub. The service is paid, but it also has a free version of the subscription with a number of restrictions, which, however, is quite enough.
Source: https://habr.com/ru/post/140089/
All Articles