The purpose of software is to be a tool for us humans to help us perform tasks. A lot of software is also a replacement for something physical for which we had an opportunity to increase productivity by making it digital and also more accessible. When replacing a paper form with a digital solution, we as developers pretty much just copied the form field by field and never really thought through what we were trying to solve. This made the improvement all about the data rather than what the users were really trying to do. One of the benefits of having the forms digitally is that multiple users can see the same data at the same time and even edit it at the same time. However, since it has all been modeled as data, with often a single, large model representing it, we introduce new problems we never had in the real world on paper. Things such as transactions and data staleness make our software more complex and they never make sense at all for the user. These are technical requirements that we, as developers, have introduced to make sure the data is correct at all times.
Users are becoming better; they have new requirements based on their experience with software. Even in the enterprise, users are now demanding more of their IT systems. With the advent of the real-time Web, driven by services such as Facebook, Twitter, and other social media, our users are now used to different experiences that are more responsive and user friendly.
The Web has changed a lot over the years, but the core protocol, HTTP, has been pretty consistent since its first documented version was released in 1991. The protocol was optimized for the document delivery system that makes up the World Wide Web. Later, the protocol included information that helped us keep a session state on the server and be able to link subsequent requests coming into the same session state. Later with DHTML and AJAX, we didn't have to do full post backs to get the full document but get parts of the document, or maybe even just get the data and perform the necessary rendering or manipulation of the document in the client.
With the introduction of standards such as WebSockets, server sent events, and the like, we can go even further. We can now make our web solutions come even more alive by having persistent connections with a server and get notified from the server when something happens. This solves some of the problems discussed earlier, such as transactions and data staleness. By basically getting the changes continuously from any other users as they are doing them, we don't need to run into any conditions that put the system in a mode that it can't get out of. This will increase the user experience and make our job as developers a lot easier.
SignalR Blueprints will allow you to utilize SignalR to its fullest, showing you how to create different application types on the Web and mobile devices, along with a few tips and tricks along the way. In addition, this project book aims to show you the patterns that are not only good for SignalR but generally with cloud scale in mind. Most significantly, you will learn to think differently about software for users, keeping them in focus all the time.
Throughout the book, you'll run into things you might disagree with. It could be things in naming the classes or methods in C#, for instance, at times, I like to drop camel casing, both upper and lower and just separate the words with an underscore yielding "some_type_with_spaces". In addition, I don't use modifiers, without them adding any value. You'll see that I completely avoid private as that is the default modifier for fields or properties on types. I'll also avoid things such as read-only, especially, if it's a private member. Most annoyingly, you might see that I drop scoping for single line statements following an IF or FOR. Don't worry, this is my personal style; you can do as you please. All I'm asking is that you don't judge me by how my code looks. I'm not a huge fan of measuring code quality with tools such as R# and its default setting for squiggles. In fact, a colleague and I have been toying with the idea of using the underscore trick for all our code, as it really makes it a lot easier to read.
You'll notice throughout that I'm using built-in functions in the browser in JavaScript, where you might expect jQuery. The reason for this is basically that I try to limit the usage of jQuery, in fact, it's a dependency I'd prefer not to have in my solutions as it is not adding anything to the way I do things. There is a bit of an educational, quite intentional reason for me not using jQuery as well; we now have most of the things we need in the browser already.
Chapter 1, The Primer, shows us that in order to hit the ground running with SignalR, it is important to understand why we need SignalR, but even more importantly, the architectural decisions that lead to the thinking behind SignalR. For the remainder of this book, there will be patterns and practices applied; this chapter covers that. In addition, it also covers the libraries being used.
Chapter 2, Overheating the Discussion, starts gradually by getting to know the basics, without introducing too much technology and patterns and practices. This chapter goes through the building of a forum that benefits from SignalR.
Chapter 3, Extra! Extra! Read All About It!, introduces e-newspapers—a great scenario for SignalR and a quite common feature found on the Web. Having SignalR at the core could be the tiny thing that differentiates you from the crowd. You'll learn how to scale to meet demand when things go viral.
Chapter 4, Can You Measure It?, introduces increasingly popular dashboards that will give you numbers at a glance. Often, the aim is to have the dashboards as up to date as possible but without having to do a timer that refreshes. SignalR can help here and light it all up, and with the right technique, make it visually appealing.
Chapter 5, What Line of Business Are You In?, shows that enterprise line of business apps are often referred to as where user experiences go to die, leaving users out of the equation when the software is designed and implemented. There are no reasons whatsoever for this. This chapter investigates how can we start to think differently about things and make them twinkle, like the stars discovered by the many voyages of the Starship Enterprise.
Chapter 6, An Architectural Taste, shows that software architecture is very important for many reasons, and this chapter looks more closely at a particular flavor that lends itself to the idea of real-time applications.
Chapter 7, The Three Screens – Mobile First, teaches how to connect the phone as a frontend for what we built in the previous chapter. SignalR is not only for the Web; it supports a wide variety of platforms, one of them being the Windows Phone.
Chapter 8, Putting the X in .NET – Xamarin, builds a frontend for the forum in Chapter 2, Overheating the Discussion, for the iPhone.
Chapter 9, Debugging or Troubleshooting, shows a few techniques that you can apply to find out why the code gets broken or systems in general don't do what they are told to. Then, you need to figure out what went wrong.
Chapter 10, Hosting and Deployment, walks through the varieties and particularly focuses on cloud and Microsoft Azure. An important fact here will be how one scales.
This book is written for developers with experience in C# and JavaScript. At this stage, the developer should also have a basic knowledge of how SignalR works as well as what the developer needs to rethink when designing applications that have a persistent connection to the server.
Some of the things that we will discuss in the book are architectural in nature. Software architecture, patterns, and practices surround us; this book will present some less "mainstream" ideas that are ideal for the world of small changes. You don't need to be an architect to get this; the book will keep it at an intermediate level.
The book uses C# and JavaScript in the samples and we will be using Visual Studio 2013 as the IDE of choice. You will be able to use Visual Studio 2013 Express, the free edition as well. You will need to have NuGet installed, which can be accessed at http://www.nuget.org/. For the Xamarin part of this book, you will need to have access to a Mac with Xcode installed plus Xamarin Studio, which you can download at http://xamarin.com/. Xamarin does provide a plugin for Visual Studio, but it needs to work in conjunction with a tool running on Mac OS X that compiles the code for use on iOS and also runs it either on the iOS Simulator or a real device.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "At the core level of SignalR sits something called a PersistentConnection class; hubs build on top of this."
A block of code is set as follows:
@Scripts.Render("~/bundles/jquery")
@Scripts.Render("~/bundles/bootstrap")New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes, for example, appear in the text like this: "To add a reference to a project, we start by right-clicking on the References of your project and selecting Manage NuGet Packages."
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.