Development of the Sheremetyevo application for Windows Phone through the eyes of a developer
Recently, (although already last year) the Sheremetyevo application was published, which was demonstrated at the exhibition “Transport of Russia”. Since I was the designer of this application, and Sheremetyevo asked to allocate a developer to attend the exhibition and consult on difficult issues, I agreed with great pleasure - not every day you can visit such exhibitions (and here also at the expense of working days.
At the exhibition itself there was a lively interest in the application and had to communicate and tell a lot. They asked on the topic and off topic. Unexpectedly, I had to tell a lot about Windows Phone itself, which was new to some. I was often mistaken for an employee of Sheremetyevo, and those who found out that I was one of the developers of this application were interested in the development itself. I also received from friends and colleagues requests to tell about the development of the Sheremetyevo application and now, when Aplana allowed to tell about the development of this application, I decided to publish an article with answers to the most frequently asked questions.
Of course, the design of the application is an important point for further planning the architecture and scope of the application. The prototype allows you to select the necessary functionality and requirements for the application and allows you to avoid many future errors. First of all, we worked out the navigation and design of the application. For example, one of the initial variants of the application map was as follows.
rice Design Map (clickable image (pdf))
')
The initial design subsequently underwent minor changes.
rice Visual Design (clickable image (pdf))
Of course, everyone has an understanding that this is not strict documentation with all the nuances, but only an approximate version. Such prototypes greatly simplify the understanding of the scope of work to be and allows the customer to see approximately what will happen in the end. After agreeing with the customer on the final project, we started writing the application itself and the backend.
The key functionality of the application is the board of flights. This function was assigned the first tab of the Panorama element on the first page.
By default, on the main page, in the first tab, only two tiles are displayed with a transition to a page from the scoreboard, where flights were separated by arrivals and departures in the Pivot element.
Accordingly, on this page from the board you can search by flight number or city name. When you select a specific flight, the option of “pinning” this flight on the main page of the application and on the desktop is added, with the possibility of attaching a secondary tile and the ability to subscribe to alerts on status changes. At the same time on the secondary tiles, you can track changes in flight status:
Also, when implementing the functionality of the reply from the change of flight status, we are faced with a problem. We wanted to implement the initially simple functionality: secured the tile - subscribed for notifications of the flight status change with receiving Toast notifications, detached the tile - unsubscribed from receiving notifications for the flight status. The solution was quite logical, given that the Toast notification is often almost useless, since there is a high probability that the user will simply miss it, especially in a noisy environment.
Implementing this behavior in its pure form was prevented by several circumstances:
1. Mandatory Guideline Requirement - You cannot spam a Toast user with a notification if he has not explicitly subscribed to it.
2. After removing the secondary tile from the desktop, without launching the application, it is not possible to find out whether the tile was deleted or unsubscribe the user accordingly.
In the end, we stopped at a slightly more complex version:
When you fix a flight, you are offered the choice of subscribing to flight changes or not. In the case of confirmation, a secondary tile is fixed on the desktop and on the main screen, and the application subscribes to receive Tile and Toast notifications. In case of failure, only the secondary tile is fixed to the desktop without the possibility of updating.
Perhaps, one of the most difficult components of the application was an airport map with maps on terminals on each floor with a POI object map ( Point Of Interest , later in the article I will use the POI term, which has become the working term for objects on the map). The idea was that POIs are displayed on the map and by clicking on them we can go to the details page of this POI and vice versa you can go from the POI details page to the map where this POI is located. At the same time on the map itself should be able to filter the displayed POI by category.
The application also required the ability to filter the POI on the map by category, which caused several problems. In particular, the optimization of the used memory.
In the original version, we did not have any information about specific POI coordinates (except for information about the terminal and floor) and, accordingly, there were no connections between points on the map and the POIs themselves. Because of this, the transition to the map from the details page of the POI had to be reduced to the opening of the map of the terminal and the floor on which the POI is located.
In this regard, I decided to keep several separate layers with drawn POI icons for each category, and before displaying on the map, layers from selected categories are glued together in one picture.
Later, when we still received information on POI with coordinates, I rewrote the work with layers in such a way that POI icons with selected categories are drawn on the main substrate at the moment of map display.
At first, I was afraid that gluing the card into the final image would be resource-intensive and slow to do. However, this solution turned out to be more efficient than displaying several layers on top of each other (because there was not enough memory) and allowed to get rid of lags even in cases when there was enough memory (overlaying a large number of icons on the substrate).
The next step I planned to rewrite the engine using tiles for more efficient use of memory, which can give an opportunity to work with cards of even higher resolution. Now the maximum size is 2000 x 2000 pixels. However, judging by the reviews, location support and more complete information on POI are much more relevant for users now than for higher resolution maps.
In addition to the scoreboard and maps, the application has a lot of different information about POI, data on airlines, rules for passengers, reference information. It is assumed that it will be updated very rarely, and planned to develop a content management system only for the release of later versions. Therefore, we decided to stitch such data inside the application in the form of files in JSON format, in which we intended to receive it from the network.
By the time we started developing the application, we did not have accurate information about the server-side infrastructure. Therefore, I decided to develop a standard server application on ASP.NET. It was assumed that this would be the usual delivered solution that will be deployed by Sheremetyevo experts on separate dedicated servers.
But during the development of new requirements from the customer: it should be possible to give support to the system to outsource.
However, the internal standards of airports contain special security requirements and any changes in the infrastructure must go through a lot of approvals. Due to these requirements, it is impossible to provide access directly to the internal infrastructure of the airport. An API for connecting mobile devices to the server was not provided for initially (in fact, we were developing this API).
As a result, we stopped at Azure as the most secure solution (compared to hosting in small companies). At the same time, we changed the logic of working with data: instead of requesting data, we provided an API to receive data from the Sheremetyevo server.
The current architecture of the server part in a simplified form is as follows.
In the new version, the only difference is that the server does not work with a specific WNS for WP, but Android, IPhone applications are connected directly to several platforms and to the REST API.
Another advantage of using Azure is the automatic management of the number of instances of the service, depending on the load. Those. when the server load increases, additional instances are launched, and a limit was imposed on the maximum number of instances to avoid unplanned expenses. The server part independently ensures its work in such a way as to maximally save on its content and at the same time ensure uninterrupted work without the need to monitor server operation 24 hours a day.
Since the flight information sent to us is only current, the server-side job is to analyze the flight information received regularly, compare it with previous data, update the active cache, and send notifications for those flights to which users have subscribed.
.
It is particularly interesting to note that now in our application, new information can be seen a little earlier than on the scoreboard at the airport or on the website.
Perhaps this question was one of the most popular questions at the exhibition. Especially against the background of the fact that few of the visitors had WP. Being present at such exhibitions makes it possible to see how much the preferences of my circle of communication differ from those of other “circles”. If not most, then exactly half of my acquaintances and friends who use smartphones, use Windows Phone (and I confess, for some I played a certain role in the choice). At the exhibition, despite the fact that in Russia, according to various statistics, Android is leading, it seemed to me that the IPhone devices were the overwhelming majority, and those who used Android mainly used the Samsung Galaxy, which ultimately made this issue particularly relevant.
A small digression is a little off topic: For my friends, it is no secret that even though I am developing for all platforms, my preference is given to Windows Phone. Some of the people came up just to feel WP8 devices kindly provided by Nokia, where we installed the applications, and accordingly I was happy to answer not only questions about the application but also questions about the WP platform itself. Surprisingly, many of the current owners of Apple technology that felt Windows Phone live at our booth responded extremely positively. Most of all, as it seemed to me, people were bribed by live tiles with up-to-date information and the very possibility of securing the secondary tile (in our case, the possibility of fixing live tiles separately for flights). There was only one person who rather tightly prowled me on the theme of the slopiness of Windows Phone and hardware, and that there is no steeper hardware and OS than the IPhone (even my personal Lumia 920, which I was pleased to demonstrate, did not convince him). I did not enter into polemics with this person and convince that WP is also not bad - at the exhibition I showed the capabilities of our application and the Windows Phone platform, and everyone made his own conclusions.
Before starting development, we had to choose one platform and port the final version of the application to other platforms. Of course, the choice of the Windows Phone platform was made not from our personal preferences (by the way, our director also uses WP as I do), and not so much due to the fact that now this platform is rapidly gaining popularity, but because the easiest and fastest development platform. As expected, in the end, this turned out to be the most successful solution, since in the development process we made many drastic changes to the project. Almost everything had to be changed - both the UI applications and the logic in all three applications (client, server, and utilities).
Using one platform (.NET) for the server, client parts and specially developed utilities for working with content allowed making changes relatively cheaply. Often it was necessary to make changes in just one assembly with models for all three types of projects (Special thanks for the Portable Library, which now became part of VS2012 and was provided as an extension for VS2010). Any changes to the data model immediately appeared in all projects.
As I wrote above, most of all I was carrying cards. This was one of the most difficult components to develop, for which requirements have changed several times.
LongListSelector has already failed more than once and even in the last update did not correct the image drawing bug, which can be observed if you use tiles instead of the usual letters in the headers. In the end, after some attempts to fix this bug on their own, they decided to replace it with a better-quality Telerik equivalent, which was spared from this bug.
Telerik controls are simply awesome, but I try to avoid paid products as much as possible due to the maintenance features.
Also in this project I used my open-source project WPExtensions, in particular, AdvancedApplicationBar, which greatly simplified the work with ApplicationBar. For example, in the details of the POI, it was necessary to hide those buttons in the AppBar for which there was no information (for example, to call or open a website, etc.), and the standard AppBar does not have the Visibility property. Accordingly, using this library it was also convenient to use MVVM with the ApplicationBar. Unfortunately, in the version that lies in nuget there are a few bugs with an ugly juggling AppBar. In the project I used a more recent version, corrected from these shortcomings, but not well-developed from the point of view of the quality of the code for displaying in nuget.
Like any other large company, Sheremetyevo has a certain bureaucratic mechanism. Of course, in this case it is more than justified - after all, at stake the safety of passengers and all the activities of the company are strictly regulated. Sheremetyevo is not a start-up that can very quickly change the structure, the responsibilities of people and the people themselves, depending on changing external requirements. On the other hand, this resulted in the fact that sometimes we had to wait a week to get even the simplest data or to agree on minor changes. We must pay tribute to colleagues from Sheremetyevo, who have made a lot of effort, obtaining the necessary data for the application and conducting the approval of changes through different departments within the company, without whose efforts we would not have released the application last year.
Some functions still had to be abandoned in favor of the following updates. For example, at the first stage we did not manage to get GPS bindings to maps and we did not have time to do positioning inside the premises. Now this is one of the priority updates.
Certification was also not without surprises.
In our case, the application did not pass certification due to the fact that the application “touches religious feelings in China”. What exactly the Chinese didn’t please with the content wasn’t found out. Thus, we lost another 5 days to republish the application, just in case excluding all countries with stricter content requirements.
In future versions, we hope to get certified in China, and developers can only advise that if an application needs to be released early, then when you first publish, you do not need to specify countries with increased content requirements, even if you are 100% sure that there are no violations.
At the exhibition itself there was a lively interest in the application and had to communicate and tell a lot. They asked on the topic and off topic. Unexpectedly, I had to tell a lot about Windows Phone itself, which was new to some. I was often mistaken for an employee of Sheremetyevo, and those who found out that I was one of the developers of this application were interested in the development itself. I also received from friends and colleagues requests to tell about the development of the Sheremetyevo application and now, when Aplana allowed to tell about the development of this application, I decided to publish an article with answers to the most frequently asked questions.
Application Design
Of course, the design of the application is an important point for further planning the architecture and scope of the application. The prototype allows you to select the necessary functionality and requirements for the application and allows you to avoid many future errors. First of all, we worked out the navigation and design of the application. For example, one of the initial variants of the application map was as follows.
rice Design Map (clickable image (pdf))
')
The initial design subsequently underwent minor changes.
rice Visual Design (clickable image (pdf))
Of course, everyone has an understanding that this is not strict documentation with all the nuances, but only an approximate version. Such prototypes greatly simplify the understanding of the scope of work to be and allows the customer to see approximately what will happen in the end. After agreeing with the customer on the final project, we started writing the application itself and the backend.
Client application development.
The key functionality of the application is the board of flights. This function was assigned the first tab of the Panorama element on the first page.
 |  |
By default, on the main page, in the first tab, only two tiles are displayed with a transition to a page from the scoreboard, where flights were separated by arrivals and departures in the Pivot element.
Accordingly, on this page from the board you can search by flight number or city name. When you select a specific flight, the option of “pinning” this flight on the main page of the application and on the desktop is added, with the possibility of attaching a secondary tile and the ability to subscribe to alerts on status changes. At the same time on the secondary tiles, you can track changes in flight status:
Also, when implementing the functionality of the reply from the change of flight status, we are faced with a problem. We wanted to implement the initially simple functionality: secured the tile - subscribed for notifications of the flight status change with receiving Toast notifications, detached the tile - unsubscribed from receiving notifications for the flight status. The solution was quite logical, given that the Toast notification is often almost useless, since there is a high probability that the user will simply miss it, especially in a noisy environment.
Implementing this behavior in its pure form was prevented by several circumstances:
1. Mandatory Guideline Requirement - You cannot spam a Toast user with a notification if he has not explicitly subscribed to it.
2. After removing the secondary tile from the desktop, without launching the application, it is not possible to find out whether the tile was deleted or unsubscribe the user accordingly.
In the end, we stopped at a slightly more complex version:
When you fix a flight, you are offered the choice of subscribing to flight changes or not. In the case of confirmation, a secondary tile is fixed on the desktop and on the main screen, and the application subscribes to receive Tile and Toast notifications. In case of failure, only the secondary tile is fixed to the desktop without the possibility of updating.
Perhaps, one of the most difficult components of the application was an airport map with maps on terminals on each floor with a POI object map ( Point Of Interest , later in the article I will use the POI term, which has become the working term for objects on the map). The idea was that POIs are displayed on the map and by clicking on them we can go to the details page of this POI and vice versa you can go from the POI details page to the map where this POI is located. At the same time on the map itself should be able to filter the displayed POI by category.
The application also required the ability to filter the POI on the map by category, which caused several problems. In particular, the optimization of the used memory.
In the original version, we did not have any information about specific POI coordinates (except for information about the terminal and floor) and, accordingly, there were no connections between points on the map and the POIs themselves. Because of this, the transition to the map from the details page of the POI had to be reduced to the opening of the map of the terminal and the floor on which the POI is located.
In this regard, I decided to keep several separate layers with drawn POI icons for each category, and before displaying on the map, layers from selected categories are glued together in one picture.
Later, when we still received information on POI with coordinates, I rewrote the work with layers in such a way that POI icons with selected categories are drawn on the main substrate at the moment of map display.
At first, I was afraid that gluing the card into the final image would be resource-intensive and slow to do. However, this solution turned out to be more efficient than displaying several layers on top of each other (because there was not enough memory) and allowed to get rid of lags even in cases when there was enough memory (overlaying a large number of icons on the substrate).
The next step I planned to rewrite the engine using tiles for more efficient use of memory, which can give an opportunity to work with cards of even higher resolution. Now the maximum size is 2000 x 2000 pixels. However, judging by the reviews, location support and more complete information on POI are much more relevant for users now than for higher resolution maps.
In addition to the scoreboard and maps, the application has a lot of different information about POI, data on airlines, rules for passengers, reference information. It is assumed that it will be updated very rarely, and planned to develop a content management system only for the release of later versions. Therefore, we decided to stitch such data inside the application in the form of files in JSON format, in which we intended to receive it from the network.
Development of the server side of the application
By the time we started developing the application, we did not have accurate information about the server-side infrastructure. Therefore, I decided to develop a standard server application on ASP.NET. It was assumed that this would be the usual delivered solution that will be deployed by Sheremetyevo experts on separate dedicated servers.
But during the development of new requirements from the customer: it should be possible to give support to the system to outsource.
However, the internal standards of airports contain special security requirements and any changes in the infrastructure must go through a lot of approvals. Due to these requirements, it is impossible to provide access directly to the internal infrastructure of the airport. An API for connecting mobile devices to the server was not provided for initially (in fact, we were developing this API).
As a result, we stopped at Azure as the most secure solution (compared to hosting in small companies). At the same time, we changed the logic of working with data: instead of requesting data, we provided an API to receive data from the Sheremetyevo server.
The current architecture of the server part in a simplified form is as follows.
In the new version, the only difference is that the server does not work with a specific WNS for WP, but Android, IPhone applications are connected directly to several platforms and to the REST API.
Another advantage of using Azure is the automatic management of the number of instances of the service, depending on the load. Those. when the server load increases, additional instances are launched, and a limit was imposed on the maximum number of instances to avoid unplanned expenses. The server part independently ensures its work in such a way as to maximally save on its content and at the same time ensure uninterrupted work without the need to monitor server operation 24 hours a day.
Since the flight information sent to us is only current, the server-side job is to analyze the flight information received regularly, compare it with previous data, update the active cache, and send notifications for those flights to which users have subscribed.
.
It is particularly interesting to note that now in our application, new information can be seen a little earlier than on the scoreboard at the airport or on the website.
Why windows phone?
Perhaps this question was one of the most popular questions at the exhibition. Especially against the background of the fact that few of the visitors had WP. Being present at such exhibitions makes it possible to see how much the preferences of my circle of communication differ from those of other “circles”. If not most, then exactly half of my acquaintances and friends who use smartphones, use Windows Phone (and I confess, for some I played a certain role in the choice). At the exhibition, despite the fact that in Russia, according to various statistics, Android is leading, it seemed to me that the IPhone devices were the overwhelming majority, and those who used Android mainly used the Samsung Galaxy, which ultimately made this issue particularly relevant.
A small digression is a little off topic: For my friends, it is no secret that even though I am developing for all platforms, my preference is given to Windows Phone. Some of the people came up just to feel WP8 devices kindly provided by Nokia, where we installed the applications, and accordingly I was happy to answer not only questions about the application but also questions about the WP platform itself. Surprisingly, many of the current owners of Apple technology that felt Windows Phone live at our booth responded extremely positively. Most of all, as it seemed to me, people were bribed by live tiles with up-to-date information and the very possibility of securing the secondary tile (in our case, the possibility of fixing live tiles separately for flights). There was only one person who rather tightly prowled me on the theme of the slopiness of Windows Phone and hardware, and that there is no steeper hardware and OS than the IPhone (even my personal Lumia 920, which I was pleased to demonstrate, did not convince him). I did not enter into polemics with this person and convince that WP is also not bad - at the exhibition I showed the capabilities of our application and the Windows Phone platform, and everyone made his own conclusions.
Before starting development, we had to choose one platform and port the final version of the application to other platforms. Of course, the choice of the Windows Phone platform was made not from our personal preferences (by the way, our director also uses WP as I do), and not so much due to the fact that now this platform is rapidly gaining popularity, but because the easiest and fastest development platform. As expected, in the end, this turned out to be the most successful solution, since in the development process we made many drastic changes to the project. Almost everything had to be changed - both the UI applications and the logic in all three applications (client, server, and utilities).
Using one platform (.NET) for the server, client parts and specially developed utilities for working with content allowed making changes relatively cheaply. Often it was necessary to make changes in just one assembly with models for all three types of projects (Special thanks for the Portable Library, which now became part of VS2012 and was provided as an extension for VS2010). Any changes to the data model immediately appeared in all projects.
The difficulties encountered in the work.
At the development stage
As I wrote above, most of all I was carrying cards. This was one of the most difficult components to develop, for which requirements have changed several times.
LongListSelector has already failed more than once and even in the last update did not correct the image drawing bug, which can be observed if you use tiles instead of the usual letters in the headers. In the end, after some attempts to fix this bug on their own, they decided to replace it with a better-quality Telerik equivalent, which was spared from this bug.
Telerik controls are simply awesome, but I try to avoid paid products as much as possible due to the maintenance features.
Also in this project I used my open-source project WPExtensions, in particular, AdvancedApplicationBar, which greatly simplified the work with ApplicationBar. For example, in the details of the POI, it was necessary to hide those buttons in the AppBar for which there was no information (for example, to call or open a website, etc.), and the standard AppBar does not have the Visibility property. Accordingly, using this library it was also convenient to use MVVM with the ApplicationBar. Unfortunately, in the version that lies in nuget there are a few bugs with an ugly juggling AppBar. In the project I used a more recent version, corrected from these shortcomings, but not well-developed from the point of view of the quality of the code for displaying in nuget.
Organizational problems
Like any other large company, Sheremetyevo has a certain bureaucratic mechanism. Of course, in this case it is more than justified - after all, at stake the safety of passengers and all the activities of the company are strictly regulated. Sheremetyevo is not a start-up that can very quickly change the structure, the responsibilities of people and the people themselves, depending on changing external requirements. On the other hand, this resulted in the fact that sometimes we had to wait a week to get even the simplest data or to agree on minor changes. We must pay tribute to colleagues from Sheremetyevo, who have made a lot of effort, obtaining the necessary data for the application and conducting the approval of changes through different departments within the company, without whose efforts we would not have released the application last year.
Some functions still had to be abandoned in favor of the following updates. For example, at the first stage we did not manage to get GPS bindings to maps and we did not have time to do positioning inside the premises. Now this is one of the priority updates.
Certification issues
Certification was also not without surprises.
In our case, the application did not pass certification due to the fact that the application “touches religious feelings in China”. What exactly the Chinese didn’t please with the content wasn’t found out. Thus, we lost another 5 days to republish the application, just in case excluding all countries with stricter content requirements.
In future versions, we hope to get certified in China, and developers can only advise that if an application needs to be released early, then when you first publish, you do not need to specify countries with increased content requirements, even if you are 100% sure that there are no violations.
Source: https://habr.com/ru/post/168309/
All Articles