Microsoft acknowledged death of Windows Phone

Is it worth "crying about" death of Microsoft Windows Mobile? Let's figure out
11 October

Recently, Microsoft official announced that they stop "building new features" for Windows Mobile 10. This was reported by the Joe Belfiore, Corporate Vice President in the Operating Systems Group at Microsoft.

Also, he said that "as and individual user, I switched platforms." 

The fact that Windows Phone is a "dead" platform is not a new for everyone. Verde ascertained death of the platform in January 2016. They pointed to the constant sales drop Lumia phones and to the fact that such phones were sold for an order of magnitude less than devices on iOS and Android: 110 million versus 4.5 billion (Androids plus iPhones).

In 2015 and 2016, Microsoft conducted massive layoffs of employees from mobile units - the work lost several thousand people.

But Windows 10 Mobile update was released in September 2017. It has some bugfixes and new features, like 2FA. 

The main reason of the platform's death is low quality and quantity of available apps. 

At the end of September, even Bill Gates reported on the rejection of the Windows phone: during an interview about Steve Jobs and new iPhones, he told that he switched to Android "with a bunch of programs from Microsoft." 

So, is it a big pitty that Windows phone died? We've made small research of search engine trends, and here's what we've found.

Search Trends
Search Trends

On a chart above, blue line is a popularity of Andoid, red line - iOs and yellow - Windows Mobile. As you can see, Windows Mobile was on the one level with other operating systems only 10 years ago, at the age of smartphones. So, there is no need to cry about the death of Windows Mobile OS. 

Also, check out our mobile OS popularity ranking.

SignalR alpha for ASP.NET Core 2.0 released

Alpha version of SignalR for ASP.NET Core 2.0 available now
15 September

Alpha version of SiglanR for ASP.NET Core 2.0 released. 

What is SignalR?

ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.

SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. While chat is often used as an example, you can do a whole lot more. Any time a user refreshes a web page to see new data, or the page implements Ajax long polling to retrieve new data, is candidate for using SignalR.

What's new?

Let's check main updates.

  • JavaScript/TypeScript Client
    • SignalR for ASP.NET Core has a brand-new JavaScript client. The new client is written in TypeScript and no longer depends on jQuery. The client can also be used from Node.js with a few additional dependencies.
      The client is distributed as an npm module that contains the Node.js version of the client (usable via require), as well as a version for use in the browser which can be included using a <script> tag. TypeScript declarations for the client included in the module make it easy to consume the client from TypeScript applications.
      The JavaScript client runs on the latest Chrome, FireFox, Edge, Safari and Opera browsers as well as Internet Explorer version 11, 10, 9. (Not all transports are compatible with every browser). Internet Explorer 8 and below is not supported.
  • Support for Binary Protocols
    • SignalR for ASP.NET Core offers two built-in hub protocols – a text protocol based on JSON and a binary protocol based on MessagePack. Messages using the MessagePack protocol are typically smaller than messages using the JSON protocol. For example a hub method returning the integer value of 1 will be 43 bytes when using the JSON based protocol while only 16 bytes when using MessagePack. (Note, the difference in size may vary depending on the message type, the contents of the message and the transport used – binary messages sent over Server Sent Events transport will be base64 encoded since Server Sent Events is a text transport.)
  • Support for Custom Protocols
    • The SignalR hub protocol is documented on GitHub and now has extension points that make it possible to plug in custom implementations.
  • Streaming
    • It is now possible to stream data from the server to the client. Unlike a regular Hub method invocation, streaming means the server is able to send results to the client before the invocation completes.
  • Using SignalR with Bare Websockets
    • The process of connecting to SignalR has been simplified to the point where, when using websockets, it is now possible to connect to the server without any client with a single request.
  • Simplified Connection Model
    • In the existing version of SignalR the client would try starting a connection to the server, and if it failed it would try using a different transport. The client would fail starting the connection when it could not connect to the server with any of the available transports. This feature is no longer supported with the new SignalR.
      Another functionality that is no longer supported is automatic reconnects. Previously SignalR would try to reconnect to the server if the connection was dropped. Now, if the client is disconnected the user must explicitly start a new connection if they want to reconnect. Note, that it was required even before – the client would stop its reconnect attempts if it could not reconnect successfully within the reconnect timeout. One more reason to remove automatic reconnects was a very high cost of storing messages sent to clients. The server would by default remember the last 1000 messages sent to a client so that it could replay messages the client missed when it was offline. Since each connection had its own buffer the memory footprint of storing these messages was very high.
  • Sticky Sessions Are Now Required
    • Because of how scale-out worked in the previous versions of SignalR, clients could reconnect and/or send messages to any server in the farm. Due to changes to the scale-out model, as well as not supporting reconnects, this is no longer supported. Now, once the client connects to the server it needs to interact with this server for the duration of the connection.
  • Single Hub per Connection
    • The new version of SignalR does not support having more than one Hub per connection. This results in a simplified client API, and makes it easier to apply Authentication policies and other Middleware to Hub connections. In addition subscribing to hub methods before the connection starts is no longer required.