The initiative of a TSM application for Windows Phone was born more than one year ago, within the 3PillarGlobal center of competence, as a way of exploring and acquiring of new knowledge regarding the Microsoft platform for mobiles. The project continued afterwards, with a lot of voluntary dedication and commitment of the people involved: Cosmin Jeler, the author of the present article, responsible for the development part; Robin Molnar - focused on the quality assurance part, Dan Hădărău for the support given on the design and server-side part and Ovidiu Mățan, project manager/ product owner.
Windows Phone is, at the moment, in the lower part of the chart regarding the market share of mobile devices. Microsoft has entered this game much too late, and once it got here, its classical marketing and product development methodologies could not overtake the competition. This is the reason why the Redmond giant was forced to start a massive process of self-reinvention: the changing of the CEO, the openness towards the open-source software, the development of applications for other ecosystems. These are only but a few points to mention in this direction.
The data for the first trimester of 2015 show an increase on the West-European market, the Windows Phone mobiles have come to surpass the 10% of the mobile market in France, Spain, Germany, Italy and Great Britain. In the last few years, Microsoft has invested into the lessening of the effort made by the developers of applications for this platform, enforcing a series of actions such as: lowering the price for obtaining the developer's account, the unification of the development platforms for tablet and phone, and soon, together with the release of Windows 10, the unification of the Stores for all the devices in the Microsoft ecosystem, including Xbox One. On the other hand, Microsoft has also recently started numerous collaborations with the producers of popular applications from AppStore and Google Play, in order to bring these applications to the Windows platform and diminish the frustration of the users regarding the lack of applications. All these point to some high stakes placed by Microsoft on the release of Windows 10.
As a hardware platform, the software giant has focused lately on the devices of the low budget area, launching many new models, or improved variants of the existing models. However, in the area of top devices, the dynamics is much poorer. Probably, the purchasing of Nokia and the associated processes of transition are two of the reasons, but in such a dynamic market as the one of mobile devices, launching at time distances that are bigger than a year is not allowed. Still, we should applaud the partnership with HTC for the M8 model, it's just that continuity and presence of mind is required in order to keep the buyers on the boil - as no one would be content to pay the price of a top Windows phone when the newer model with Android is already launched. Nevertheless, let us hope that together with Windows 10, Microsoft will bring a new spurt to the hardware part, too.
The first challenge I faced in the development for mobile was the much greater dynamics of the platform: the moment we started the project, Windows Phone 7 was still a full rights citizen, and WP8 was becoming the new trend. During the development, WP 8.1 appeared and, though it seems a minor update, it is actually an entirely different platform from 8.0. Passing to WP 8.1 would have meant an unsustainable effort, considering the fact that we already had to deal with the differences between 7 and 8. And later on, at the moment of release of the application, we already had a preview for Windows 10, and the application for WP7 had, unfortunately, become too old to be published in the Store.
The initial tendency when starting the application was to take the design of the iOS version and transpose it in Windows Phone. But it didn't take me long to realize that some things did not seem right at all. If, with Android, one can keep some similarities between the applications, in Windows Phone the user experience is completely different. A few examples in this line would be the manner of opening the menu (left side in iOS, with no equivalence in WP), the navigation manner (with soft versus hard buttons), the contextual menu specific only to WP and many others.
Very soon, I saw myself facing the mission of conceiving a new design, adapted to the experience and capabilities of the Windows Phone devices, which had to comply with the recommendations for the user experience of the platform and, maybe the hardest part for a programmer, it had to look good. I took into consideration all the suggestions and feedback from all the people around me which I managed to involve: colleagues, friends, family, so that the versions I would present to the final beneficiary (Ovidiu - TSM), for another round of feedback, be as attractive as possible.
But even the most accomplished design is not enough to make the application captivating; that is the reason why I also turned to those little tricks called animations. My much more experienced colleagues from the iOS platforms brought their contribution through suggestions and sometimes even details regarding the dynamics of animations, reason for which I would like to take this opportunity to thank them.
For those with experience in the technologies based on the XAML language, the MVVM pattern we used is a model that is too well tethered in the professional environments to be considered "a choice" in the true meaning of the word. I will not go into details concerning this pattern, but in order for you to get an idea about it, we may say in a few words that it represents a specialized variant for the XAML technologies of the Presentation Model (PM) pattern, with the purpose of simplifying the programming model based on events of the user interfaces. The PM pattern, as well as the Model-View-Presenter, separates the user interface from behavior and mood and it creates an abstraction of the interface.
The range of technologies we had to choose from was quite restricted, since we were dealing with a rather young development platform.
As we needed a data base to store the magazines and the articles, we were lucky to begin the implementation in a very favourable manner from this point of view, as we had the LINQ to SQL data base available - a simplistic variant of the Entity Framework technology, known to every .NET developer. The only problems we encountered were related to the access synchronization - the writing of data on a tablet, from which another execution thread is trying to read, proved to be problematic, reason for which I had to synchronize the access to the data base.
Unfortunately, in the RT version of Windows Phone 8.1, the data base support was omitted, the newer applications being forced to use SQLite. This thing would not be necessarily a problem, if Microsoft had also made available a LINQ provider for it. Unluckily, at the moment there is only one single decent external library, namely sqlite-net - we cannot but hope that Microdoft will not postpone the solving of this situation too much and will come with an official solution.
Example of code of synchronized access to DB:
public T Find(Expression> selector, params Expression>[] includes)
where T : class
{
OperationOnDatabase.WaitOne();
using (DataContext dataContext = IoC.
Get())
{
if (includes != null && includes.Length != 0)
{
DataLoadOptions loadOptions =
new DataLoadOptions();
foreach (Expression>
include in includes)
{
loadOptions.LoadWith(include);
}
dataContext.LoadOptions = loadOptions;
}
IQueryable query = dataContext.GetTable();
T result = query.FirstOrDefault(selector);
OperationOnDatabase.Set();
return result;
}
} A nice surprise was for me to discover the availability for WP of some libraries that are already famous in the other technologies .NET. I am talking here about the well-established Google Analytics and Json.NET - useful for the transformation of the results in JSON format from the server in the inner models of the application. Another advantage was the availability of share actions on e-mail and the social networks, offered by the operating system.
Another external library we used is an extension of those from Caliburn Micro called BindableAppBar, which allows the handling of the events in the application bar (the bottom menu of the WP applications) in a MVVM specific manner - in contrast to the bar provided by the operating system that supports only code-behind events.
Maybe the most interesting aspect related to the technologies would be the manner of choosing the additional MVVM library. Though there are plenty of options on the market, only few of them have reached a relative degree of maturity and are available on WP. I would mention here the well-known MVVM Light Toolkit and Prism. With Prism I had already had some experience before and I knew it had its limitations; it has probably evolved meanwhile, but I preferred not to take a risk, but rather learn something new. So, the next option was the well-established MVVM Light. Unfortunately, I soon ended up doubting the choice I had made, but probably many of you find familiar the scenario of not knowing for sure if the problem resides in the choice you made or in the user's competence… In such situations, I usually look for objective signs which can take me out of the dead end, and in this case, the decision factor was the total lack of documentation. Probably the authors of MVVM Light rest upon the fact that their tool is so easy to use that it needs no documentation - which was not my case. Even today, by taking a look at their web page, one can notice the lightsomeness they have treated this subject with, so that I ended up testing a less popular library at the time, namely Caliburn Micro. It has attracted me from the beginning, through its simplicity and offered power. It's just that simplicity which is not also intuitive can become frustrating. But, reaching their documentation page, I realized it was of an utter professionalism - one can notice from no more than two lines that the authors have thought once and again about every thing they have written and implemented.
Another interesting topic is the life cycle of the application - completely different from the experience of desktop and web programming up until then. The application has more states than the classical on and off, introducing many interesting scenarios related to the manner in which a page of the application gets to be visible to the user. The access to any page can be done from a previous page by following the standard navigation flow. It can also be done by returning from the following page (in this case, the page is already in the memory, it no longer has to be initialized, just becoming visible on the screen), or by starting the application from the suspended state directly to the last visited page. Besides these ways, my experience from other projects has shown me that there is also a hybrid case, where through the call from external applications or from the system, the application can be started directly into an intermediary page, without going through the normal navigation flow between the pages and it can also accept input parameters. All of these cases, plus the asynchronous nature of mobile communication, can generate very interesting states of the application.
Having a lot of experience in WPF and especially in Silverlight, I would have expected the development of Windows Phone applications not to raise too many problems. The reality, however, was a little different: on the user interface and language level, things are relatively similar, though I have noticed a big difference in the navigation between pages and the life cycle of the application. The experience can be compared to moving from desktop to web programming, for those who have been through such a thing.
It's very simple: in WP, the state is not kept between the pages of the application. Passing the parameters from one page to another is done through query strings, and for more complex types the situation gets complicated, since there is no standard method for solving the problem. Caliburn.Micro proved to be a real help in this case, providing a simple and intuitive solution:
navigationService.UriFor\<
ArticlesInIssueViewModel\>()
.WithParam\(articleVM =\> articleVM.IssueId
,selectedIssue.Id).Navigate(); Example of navigation code using Caliburn.Micro.
The animation part was one of the most interesting parts of the development, as they contribute to the identity and appealingness of an application. There is no way we can compare the present application to those from the top of the application stores, but this does not mean, however, that we have to settle for a trashy variant, such as plenty of those that are rearmost of the mobile applications stores. On the other hand, the more interesting the animations are, the more consuming they are in terms of time of involvement.
There is a level of animations implicitly provided by the operation system, and here I am referring to the pre-established styles of the controls used in the application (themes and transitions between states).
Another level of animations are those made available in libraries, which only need to be manually imported and properly used. Of these, I would mention the animations for entering and exiting a page and the rotation animations when changing the orientation of the screen.
The next level would be the personalized animations, which, even though discrete, cannot be neglected. I am referring here to the buttons for choosing the language, the animation of the latest issues of the magazine when launching the start page, the oscillations of the images of the editions from the full list of magazines (still in the start page), the progressive intensity of appearance of the images of the articles in the magazine, the header that appears and hides away depending on the manner of unfolding of the content of an article. Those who had to deal with the iOS ecosystems will probably notice the similarity to the address bar of Safari, whose functionality I tried to reproduce.
By far, most of the problems encountered were related to the content page of the articles.
The most important piece of advice which I hereby give you for free is related to the web controls: do not use web controls in mobile applications. If, nonetheless, you have to use one, try to limit yourself to interacting with it in a manner as minimalist as possible, such as sending the address of the HTML page that has to be visualized, as everything else in cancan.
The problems of the web control are numerous and not all of them are related to the fact that we are talking about Internet Explorer - there are many which have to do with the very different nature of the control. Below, I will present a list of some of these problems I have encountered:
The control does not report the navigation events and those of completing the uploading of a page in an accurate manner, requiring many tricks in order to offer a pleasant experience to the user. I am referring here to situations when the web page does not upload or it uploads with errors or the uploading simply takes too much time - for such situations, we have to find methods of administration, which are quite expensive.
Implicitly, the web control gives the possibility of navigating to addresses from the content - I had to remove this functionality so as to prevent the situation in which the user uses the TSM application as a web browser. This thing could not be done by merely setting a simple attribute. The control swallows the gestures and other events generated by the user, believing that they are part of the interaction with the imbricated HTML content, and no longer exposes them to the programmer for further processing. This is the reason why the header, which appears and hides away according to the vertical movements of the HTML content of the article, has raised several synchronization problems.
Upon leaving a page, the content of the control has to be deleted - I used the trick of uploading an about:blank - because, otherwise, one can end up in some strange situations such as the one when a Video that has been played sticks into memory and keeps running continuously, even if the user has navigated to another page.
A video imbricated in the HTML page does not report the events, by any means, so that it was impossible for me to implement the scenario that, when the user presses the complete-screen button, I could hide the rest of the elements of the page.
Another huge failure concerning web control was the attempt to implement an endless horizontal scroll between the articles of the same magazine. A swipe gesture from the right side of the screen would have led to the next article, through some animation, and analogously for a swipe from the left side. Even though I was about to complete the implementation of a functional variant, I was forced to give this idea up completely, because the web control would not report the user's gestures faithfully, in terms of delta distance, frequency of reporting and acceleration.
Other interesting aspects from a technical point of view were related to the asynchronous nature of calls in the development on mobile. What happens, for instance, when the result of an asynchronous call (to the server or the data base) returns after the user has already navigated to another page? In a first instance, nothing, but on a more careful testing, the application throws an exception which is sometimes ignored, other times ends the application. Those calls can be cancelled, but when this is not possible, the results of those calls can and should be ignored. C# language offers support for the cancelation of asynchronous calls, the point of entrance into this subject being the TaskCancellation class, for those who wish to find out more details. What happens in the case when a page alters certain data which already appear on a previous page? When navigating to the previous page, will the changes be visible? The default answer is no, because there are no stages between the pages and neither notifications can be conveyed. The programmer can, however, be careful to deal with such situations by manually testing the state of the objects that are susceptible to change. An eloquent example is the main page, where the number of articles from a magazine is only visible after exploring that edition, moment when the list of articles is uploaded from the server. When returning to the main page, the number of articles from the respective edition needs to be manually updated.
Another pretty costly section was the changing of language. Although it seems a rather simple action in itself, the final version of implementation was far from being simple. The calls in progress to the server have to be canceled, the data base has to be emptied, some settings of the application have to be reset and the application needs to be restarted without the possibility of navigating backwards.
Robin Molnar, our team mate from 3PillarGlobal, was responsible with ensuring the quality of the application, proving a lot of professionalism in respect to the testing process. He got involved in the mobile application part, as well as in the server part, and his thoroughness and suggestions will surely have a considerable impact on the users' perception of the application. The different test scenarios applied to different devices and platforms required a lot of attention and effort.
Without meaning to sound like an Oscar award cliché, I would like to thank 3PillarGlobal for the support given, the manager, Dan Suciu, for starting and supporting this project, Robin Molnar for his outstanding professionalism and Ovidiu Matan, Dan Hadarau for the design part and the Gemini Solutions team for the support offered in all the stages of development of the application.
As a conclusion, I may say I have learnt a lot from this project, from a technological point of view, but especially on the communication and coordination part. I have learnt that a lot of hard work is required in order for a product to be considered complete and that you can only say this in the moment when the product is in the hands of the final clients. Though it seems easy from the point of view of the programmer who writes the code and completes the final task, the effort required until it's really completed cannot be neglected at all. It is not the case here, but sometimes this effort can get as big as or even bigger than the implementation effort. There are many other factors that contribute to the success of a product, and rarely does the manner of implementation done by the programmer have the major impact.
I conclude by inviting you to install the application from WP Store and contribute with suggestions and feedback, which we will appreciate and which will obviously constitute the starting base for the following versions of the application.