Professional Windows Live programming 9780470110010, 0470110015
*Windows Live is the collective name for a group of Microsoft tools whose services and user data are available anywhere-
231 111 7MB
English Pages 459 Year 2008
Recommend Papers
File loading please wait...
Citation preview
Professional
Windows Live™ Programming Jon Arking
Wiley Publishing, Inc.
Professional
Windows Live™ Programming Acknowledgments ........................................................................................ xv Introduction ............................................................................................... xvii Chapter 1: Background of Windows Live ......................................................... 1 Chapter 2: Knowing the Platforms and Services............................................ 17 Chapter 3: Overview of Windows Live SDKs .................................................. 29 Chapter 4: Windows Live Search .................................................................. 41 Chapter 5: Virtual Earth ............................................................................. 105 Chapter 6: Windows Live ID ....................................................................... 153 Chapter 7: Windows Live Expo ................................................................... 191 Chapter 8: Windows Live Spaces................................................................ 227 Chapter 9: Windows Live Messenger .......................................................... 261 Chapter 10: Windows Live Gadgets ............................................................ 279 Chapter 11: Custom Domains .................................................................... 299 Appendix A: HTML/DHTML Primer ............................................................. 333 Appendix B: ASP.NET for Web Developers ................................................... 347 Appendix C: C# .NET for Web Developers.................................................... 391 Index ........................................................................................................ 415
Professional
Windows Live™ Programming
Professional
Windows Live™ Programming Jon Arking
Wiley Publishing, Inc.
Professional Windows Live™ Programming Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-11001-0 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002. Library of Congress Cataloging-in-Publication Data Arking, Jon, 1973Professional Windows Live programming / Jon Arking. p. cm. Includes index. ISBN 978-0-470-11001-0 (pbk.) 1. Microsoft Windows (Computer file) 2. Internet programming. QA76.625.A72 2007 005.4’46—dc22
3. Operating systems (Computers)
I. Title.
2007035567
Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Windows Live is a trademark of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
About the Author Jon Arking is a Java certified and Microsoft certified software architect working in the greater Philadelphia region. He has been designing and developing multi-tiered enterprise systems for 10 years, specializing in system migrations and online web applications. Jon has spent much of his career designing systems, teaching classes, giving lectures, providing on-air interviews, and writing articles on various technical topics.
Credits Executive Editor
Vice President and Executive Group Publisher
Chris Webb
Richard Swadley
Development Editor
Vice President and Executive Publisher
Ed Connor
Joseph B. Wikert
Technical Editor
Project Coordinator, Cover
Daniel Jin
Adrienne Martinez
Production Editor
Proofreader
Eric Charbonneau
Sossity Smith
Copy Editor
Indexer
Foxxe Editorial Services
Jack Lewis
Editorial Manager
Anniversary Logo Design
Mary Beth Wakefield
Richard Pacifico
Production Manager Tim Tate
Contents Acknowledgments Introduction
Chapter 1: Background of Windows Live The Microsoft of Old Along Came the Web The MSN ERA The Rise of Interactive Services So What Is Windows Live? New Programming API
Principles of Windows Live Make It Easy for the Developer Community to Integrate with Windows Live and Make Money Easy to Develop Easy to Use
Why Should I use Windows Live? The Windows Live Paradigm The Virtual Smart Mall
Summary
Chapter 2: Knowing the Platforms and Services The Programming Landscape
Summary
Chapter 3: Overview of Windows Live SDKs Overview of the Windows Live API Emerging Windows Live Services
Summary
Chapter 4: Windows Live Search What Is It? How It Works Live Search API A Live Search Client
xv xvii
1 2 2 3 5 7 7
9 9 10 11
13 14 15
16
17 17
27
29 29 39
40
41 41 44 45 50
Contents The Big Picture Summary
102 103
Chapter 5: Virtual Earth
105
What Is Virtual Earth?
105
Visual Extension to Windows Live
How It Works Building a Sample Map Controlling the Map Using Pushpins Finding Locations, Businesses, and Landmarks Advanced Virtual Earth Features Working with 3D Images
The Big Picture Summary
107
109 109 113 123 131 143 147
151 152
Chapter 6: Windows Live ID
153
What Is Windows Live ID? How Windows Live ID Works
154 156
Building the Sample Building the Ruby Sample
160 170
The Big Picture Summary
189 190
Chapter 7: Windows Live Expo
191
What Is Windows Live Expo? Live Expo Features
191 192
Postings Profile Messaging Saved Searches Communities
How It Works
195
Live Expo API
196
Getting Started
200
Building an Expo-Powered Web Page Getting the Application Key Create an ASP.NET Project Adding a Live Expo Web Reference Using Visual Studio .NET Adding a Live Expo Proxy Class Manually
xii
192 193 194 194 195
200 201 201 207 207
Contents Retrieving Live Expo Categories
The Big Picture Summary
208
225 225
Chapter 8: Windows Live Spaces
227
What Is Windows Live Spaces?
228
Themes
How It Works Building the Sample
The Big Picture Summary
235
236 237
258 259
Chapter 9: Windows Live Messenger
261
What Is Windows Live Messenger?
262
Windows Live Messenger Client Extensible API
How It Works The Activity API Development Process
The Big Picture Summary
Chapter 10: Windows Live Gadgets What Are Live Gadgets? How They Work Setting Up the Environment Understanding the Code The Gadget API
The Big Picture Summary
Chapter 11: Custom Domains What Is It? How It Works Setting Up Administering Your Site
The Big Picture Summary
262 264
267 267 270
276 278
279 279 281 282 288 295
298 298
299 299 302 313 319
331 331
xiii
Contents Appendix A: HTML/DHTML Primer
333
Appendix B: ASP.NET for Web Developers
347
Appendix C: C# .NET for Web Developers
391
Index
415
xiv
Acknowledgments There is no way that I would have been able to finish this book without the help and support of many people. Thanks to Chris Webb, Ed Connor, and my technical editor, Dan Jin for their patience and understanding along the way. Thanks also to Kevin Ledley, George Moore, Gerard Gjonej, Koji Kato, Jim Gordon, Jay Fluegel, John Bruno, and the entire Windows Live development team for their early support and continued assistance. Of course, I owe all things good in my life to my wife Andrea and to my children, without whom I simply wouldn’t have a clue. Finally, a word of gratitude to my crazy mother-in-law Carol “Mamme” Harding, who told me to stop whining and start writing.
Introduction Welcome to Professional Windows Live, your guide to the next generation of Microsoft web programming. Windows Live is an exciting new set of tools and features offered by Microsoft that will change the way we design, build, and market websites. Even though many people have heard of it by name, most are still confused about what Live offers, and just who it is supposed to help. So, before jumping into the deep waters of the Live development platform, allow me to take this opportunity to clarify a few things. Windows Live can be many things at once. It is a powerful business model, consisting of highly specialized advertising models and a set of potent tools that help business decision makers refine their markets and target the right consumers. It is also a series of consumer-oriented websites, offering a suite of online services that enhance your web experience. Websites such as spaces.live.com, a place where people can create blogs, post photos, and network to make new friends and contacts, and expo.live.com (also expo.org), an online marketplace where people can buy, sell, and exchange products and services, provide some of the cool new services to come from the Live initiative. Live is also a development platform, offering a wide range of APIs and XML-based web services that allow developers to leverage many of these new services in their own websites. With so much being offered at one time, how does one make heads or tails of it? The purpose of this book is just that — to help people understand what Windows Live is, and the many different ways it can be used. Although the book is intended for web developers and programmers interested in incorporating Live services into their own software, time is taken to carefully provide a broad understanding of all its features and business models.
What This Book Covers This book is meant to serve as a roadmap for web developers interested in incorporating Windows Live into their own programs and websites. It is intended for those with some background in web programming and design, and is especially geared towards people familiar with both ASP.NET and the C# .NET language. This book does not aim to cover every facet of the Windows Live SDK. Windows Live is a living, breathing platform that is constantly evolving. It is a moving target, with new services and APIs born every month. Instead, this book provides a comprehensive overview of Windows Live programming, covering some of the individual SDKs, as well as the larger ideas that drive each service. The initial sections address the overall Live initiative. Beginning with a brief history of online consumer services that inevitably became MSN (the Microsoft Network) and then Windows Live, the reader will first become familiar with Microsoft’s larger design (which, I might note, is much more powerful than other platform releases). Subsequent chapters delve into the APIs directly, demonstrating the different ways Live services can be automated and leveraged into other software. Although this book does tell a story, it is also intended to be a useful reference for Live programmers. With that in mind, here is the chapter-by-chapter synopsis.
Introduction
Chapter 1 – Background of Windows Live We begin by discussing the background of Microsoft’s development initiative, beginning with MSN services and continuing on through the general view of Windows Live. A brief history of platform evolution is explained, highlighting those points in development history that are reflected in the Windows Live API. The reader then begins to explore the various models associated with the Windows Live platform. The Live business model is an important element of the Microsoft’s new web programming paradigm, and is essential for developers to understand. It consists of a powerful marketing and analytics engine that will help web designers carefully analyze and target their core markets. Here, readers will be exposed to Microsoft’s AdLab, an online resource for testing keywords and evaluating user demographics. Understanding how these marketing themes fit into the bigger picture of Live is vital to the successful implementation of Live services. With each new user consuming any one of Microsoft’s Live services, the analytical model grows and the availability of marketing data increases exponentially.
Chapter 2 – Knowing the Platforms and Services You don’t have to be an award-winning Microsoft web programming genius to develop software using Windows Live. In fact, you don’t even have to be familiar with Microsoft technologies per se. However there are various web-related development patterns with which the reader needs be familiar. This chapter focuses on the generic platforms and languages prevalent among the Live services APIs. Basic knowledge of these subjects is assumed, especially pertaining to web technologies such as client scripting, HTML, server-side programming, and XML. However since not all web developers are created equal, a brief description of the important technologies is provided for review. The reader will be introduced to the building of mashups, multifaceted online applications that combine features from various independent online services. In addition, some mention is made of various Microsoft programming technologies, as some of these can be used to streamline application development.
Chapter 3 – Overview of Windows Live SDKs Windows Live is a living, breathing thing; a project with a life of its own. As such, each new month brings the possibility of new tools, websites, and services released by Microsoft. At the time of this writing there are officially eight Windows Live services with developer APIs. That number can, and will, grow as more people adopt Microsoft’s new development methodologies. In this chapter, we discuss the general purpose of the official eight API, along with ancillary tools, also extensible, for Microsoft developers. These services and tools include:
xviii
❑
Live Search
❑
Virtual Earth
❑
Live ID
❑
Live Expo
❑
Live Spaces
❑
Live Messenger
Introduction ❑
Gadgets
❑
Custom Domains
❑
Live Data
❑
Live Writer
❑
Live Alerts
❑
Silverlight Streaming
The aim of this chapter is to lay a conceptual groundwork for all services together, helping the reader to understand the purpose of each API, how they can be used, and most importantly, the part each plays in the larger picture of Windows Live.
Chapter 4 – Windows Live Search We now jump right into the first of the Windows Live API, Live Search. We discuss some of the triedand-true practices of search as they existed in their previous platform (MSN Search), taking careful aim to introduce newer transport mechanisms for data, namely using XML-based web services. Some of the new things we’ll explore are targeted searches, simple application integration, and an emerging feature of Microsoft’s search technologies, macros. Macros allow you, and your users, to customize their searches and store that customization in a pliable, atomic vehicle. Macros are one of the most important features of Live Search to understand, so our first sample code and demo will consist of a customized search macro.
Chapter 5 – Virtual Earth Virtual Earth is the next generation mapping and location-based search tool from Microsoft. This chapter provides an in-depth view into the Virtual Earth API. We’ll review the general thrust of the mapping API, taking a good look at the Virtual Earth map control and its many dynamic and flexible features. Code samples will be section-specific, demonstrating specific features of Virtual Earth that are simple to control and easy to consume.
Chapter 6 – Windows Live ID Live ID is Microsoft’s answer to the sign-in once, sign-in anywhere approach to multiple websites. Formerly known as Microsoft Passport, Live ID is the driving model for the creation of Microsoft-held user accounts. This chapter discusses the newer features of Live ID, and shows the user how the entry of information on one Live-powered website can empower the user to reuse that information on another Live-powered site at the user ’s discretion.
Chapter 7 – Windows Live Expo The first of two chapters focused on some of the social networking aspects of Windows Live, this chapter concentrates on Live Expo. Live Expo is an online marketplace where people can publicly post categorized items for sale, browse public listings for purchases, create public announcements, post listings to
xix
Introduction customized user groups, and much more. Live Expo and its accompanying API are great tools for enabling people to connect with one another by interests. Incorporating Expo into your site instantly adds a flush marketplace to sites of any type.
Chapter 8 – Windows Live Spaces The second chapter focusing on social networking in Windows Live, this chapter discusses Windows Live Spaces, Microsoft’s online social networking application. In it you’ll find people from all over the globe connecting, sharing ideas and information, exchanging pictures, chatting, and more. Create your own space and express yourself as you please. Upload pictures, create interest lists, link to your favorite videos, play songs, and find friends online. The Live Spaces API is a combination of remote procedure methods and straight URL feeds for adding, updating, or posting different types of content. Moreover, the API can be used not only to control individual Spaces accounts but also to incorporate social networking features directly into your web application.
Chapter 9 – Windows Live Messenger Live Messenger builds on Microsoft’s previous instant messaging tool, MSN Messenger, to create an experience that’s more interactive than ever before. Here, we’ll be looking into some of the more advanced features now available with Live Messenger. New features such as the Messenger add-in, which allows developers to create new features within the Messenger client, and Activities, interactive applications that harness the Live Messenger communicative model, are each explored in detail.
Chapter 10 – Windows Live Gadgets Gadgets are small mini-applications hosted from within a web page or gadget-hosting desktop environment. Gadgets represent an architectural shift in web development. They provide a vehicle for developers to embed complex, networked logic into a client-side component. Unlike web components widely used today, Gadgets do not rely on a server-side implementation to effectively maintain state and perform tasks. Instead, the Live Gadgets API contains a native suite of objects, events, and services that enable developers to make connections from other domains into various parts of the client-rendered page. The result is a more responsive client application that completely abstracts the web developer from having to perform cumbersome postbacks to execute commands. This takes a great load off the site’s server and proliferates direct browser-to-domain interconnectivity. Gadgets can be created by anyone familiar with common web programming technologies, such as JavaScript and Dynamic HTML. This section outlines the programming model required for gadget design, and walks the reader through creating a beginner sample gadget and posting it on the live.com website.
Chapter 11 – Custom Domains This last chapter takes a step back from some of the application features of Windows Live and focuses on Custom Domains. Custom Domains is a Windows Live API that lets you create Live ID accounts based off of your own website URL. Users given a custom domain account can log into any Live ID-powered site. They also get all of the basic Live services accounts that come with a Live ID, including a Spaces account, an Expo account, a Live Mail account, and a Live Messenger account. Websites implementing Custom Domains can control each registered account through remote procedure-based methods.
xx
Introduction
Appendices Throughout this book readers will need to be familiar with various programmatic and developmental tenets. However, if you’re like me, you’ve likely touched on some of these patterns at some point in your career, but you don’t recall all of the basics. Although it is assumed that most readers will have a working knowledge of both web programming and C# .NET, the appendices at the end of this book are provided as a means of quick reference. Appendix A is a brief tutorial on HTML and DHTML design. It may help to reinforce some latent (though previously learned) web design knowledge. Appendix B covers some of the ins and outs of ASP.NET. If you have some experience with simple web design and maybe some client software programming, use this chapter to get up to speed on some important ASP.NET practices. Appendix C covers some of the fundamentals of the C# .NET language, and object-oriented programming tenets as they relate to third and fourth generation programming languages.
Who This Book Is For This book is ultimately a book about web programming. Although Windows Live expands a developer ’s web palette into the business realm by providing tools for marketing and business analysis, the overall aim of this piece is to help the reader become a Windows Live developer. Whether you’ve written web pages or designed large enterprise systems, Professional Windows Live can be a valuable aide in the evolution of web development patterns. Readers do not need to know Microsoft technologies to use the Live services API. However, a knowledge of ASP.NET and C# is assumed. The reader should also be familiar with HTML, DHTML, JavaScript, XML, and to a certain degree, XML-based remote procedure call methodologies such as Simple Object Access Protocol (SOAP) and XML-RPC.
How This Book Is Structured Professional Windows Live is meant to be used as both a step-by-step guide as well as a continuous source of reference. To that end, the book is broken into distinct sections which can be read either as a whole, or in piecemeal. The sections covering the API consist of elements that demonstrate a service’s features. These sections also contain material that relates the service to the overall Windows Live initiative. To support this approach, each chapter follows a similar pattern, comprising of the following subsections.
What Is It? The first subsection introduces a service or tool to the reader. In this portion the purpose is explained, followed with distinct examples that may include practical, real world examples and case studies.
How Does It Work? This second subsection explains the mechanics of the service or tool. Here the reader will become intimately familiar with the API calls, their uses, and supporting Microsoft documentation.
xxi
Introduction
Example/Sample Code Code samples are introduced here. The samples will vary depending on the type and nature of the service assessed. A simple web page that shows how to render three dimensional views using Virtual Earth will function entirely differently than a mashup that shows listings into expo.live.com. Most important to note is that the samples themselves in each section complement a larger, mashup application that serves as a showcase website for many of the services covered. The website can be found in its entirety as www.JustHelpMe.net.
The Big Picture The third section relates a tool or service to the grander scheme of the Windows Live initiative. Whereas the first two subsections assess the service directly, this portion builds on that knowledge, carefully joining it with models and concepts explained in the overview sections of the book.
Conventions To help you get the most from the text and keep track of what’s happening, we’ve used a number of conventions throughout the book. Examples that you can download and try out for yourself generally appear in a box like this: This section gives a brief overview of the example.
Source This section includes the source code. Source code Source code Source code
Output This section lists the output: Example output Example output Example output
Source Code As you work through the examples in this book, you may choose either to type in all the code manually or to use the source code files that accompany the book. All of the source code used in this book is available for download at www.wrox.com. Once at the site, simply locate the book’s title (either by using the
xxii
Introduction Search box or by using one of the title lists), and click the Download Code link on the book’s detail page to obtain all the source code for the book. Because many books have similar titles, you may find it easiest to search by ISBN; this book’s ISBN is 978-0-4701-1001-0. Once you download the code, just decompress it with your favorite compression tool. Alternately, you can go to the main Wrox code download page at www.wrox.com/dynamic/books/download.aspx to see the code available for this book and all other Wrox books.
Errata We make every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty piece of code, we would be very grateful for your feedback. By sending in errata, you may save another reader hours of frustration and at the same time you will be helping us provide even higher-quality information. To find the errata page for this book, go to www.wrox.com and locate the title using the Search box or one of the title lists. Then, on the book details page, click the Book Errata link. On this page, you can view all errata that has been submitted for this book and posted by Wrox editors. A complete book list including links to each book’s errata is also available at www.wrox.com/misc-pages/booklist.shtml. If you don’t spot “your” error on the Book Errata page, go to www.wrox.com/contact/techsupport .shtml and complete the form there to send us the error you have found. We’ll check the information and, if appropriate, post a message to the book’s errata page and fix the problem in subsequent editions of the book.
p2p.wrox.com For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a Web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums. At http://p2p.wrox.com you will find a number of different forums that will help you not only as you read this book but also as you develop your own applications. To join the forums, just follow these steps:
1. 2. 3.
Go to p2p.wrox.com and click the Register link.
4.
You will receive an email with information describing how to verify your account and complete the joining process.
Read the terms of use and click Agree. Complete the required information to join as well as any optional information you wish to provide, and click Submit.
xxiii
Introduction You can read messages in the forums without joining P2P, but in order to post your own messages, you must join. Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the Web. If you would like to have new messages from a particular forum emailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing. For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.
What You Can Expect from ME and This Book I am not a die hard, rah-rah, Windows-in-your-face, Microsoft evangelist . . . let’s get that out of the way. I am a pragmatist. I design and develop software that works for my clients, and I make decisions about platforms and SDKs based on my clients’ needs. That being said, if you are looking for a compelling book that sells Windows Live to you or your development team, you may be in for a surprise. Although much of my experience has been with Microsoft technologies, I have also worked with Java, PHP, C++, Macromedia, and plenty of other non-Windows languages and platforms. Yet despite my relatively diverse background I truly believe in Windows Live. It is a strong movement in the right direction. It is a powerful set of consumable services that makes your applications richer, your business decisions better, and your development effort easier. It takes many of the repetitive, cumbersome tasks of programming out of your tired hands, allowing you to develop code that directly affects business. This book is your guide, your primer to effective Windows Live programming, sans the hype that so often accompanies a new development platform. Over the next few months you’re bound to find plenty of pro-Microsoft books that pitch Windows Live for Windows Live’s sake. This book is about understanding the true power of Windows Live, and how it works best for you. We’ll be discussing both the benefits and, in some cases, the disadvantages of using Live services depending on the context of your development needs. I’ll point out the strengths of some APIs, and the weaknesses of others. Most importantly, I will try to make comparisons to other available online services. Understanding the differences between Windows Live and its competitors will help you to better gauge your own programming needs.
xxiv
Background of Windows Live The world is addicted to the Internet. We use it for our work, our meetings, our fun, even for our health. Whether you’re a die-hard techie who relies on the information superhighway to run your business and make a living or the avid web surfer Googling your favorite movies and blogging to your heart’s content, the web is the undeniable driving force behind all things tech. Unlike the colder days of the late 1990s when websites were mostly trinkets to hype overpriced startups, today’s Internet is truly personal and interactive. It has become part of the fabric of our daily lives, and nobody knows this better than Microsoft. The reigning Redmond giant, whose past is firmly rooted in client software and operating systems, recognizes this seismic shift to web as an inevitable need for flexibility, creativity, and innovation. To answer these needs, Microsoft gives us Windows Live. In this first chapter, we will cover the following areas:
❑
Discuss some of the history of software development and the role Microsoft has played
❑
Discuss the different ways that the Internet has changed both software development and the business of technology
❑
Review the basic tenets of Windows Live
❑
Consider the benefits of the Windows Live business model
Windows Live is many things. On the surface, it is a collection of websites offering interactive online services to people all over the world. They boast rich user experiences, mimicking the more traditional client application, while enabling the user to view and work with their information from anywhere. Rebranded from the previously named MSN services, Windows Live applications are a comprehensive set of user experiences that attempt to bridge the web divide through seamless, Internet-enabled tools and features. Yet the Microsoft Live initiative is more than just a tight confederation of online services. It is also a new business model for consumers and developers of Microsoft software, offering streamlined branding features for business and direct channels of monetization for Microsoft developers. It’s a reorganized set of service-oriented API, enabling developers to quickly leverage powerful, online
Chapter 1: Background of Windows Live capabilities and combine those features into highly specialized applications. Live is also the next generation of some of Microsoft’s most popular existing software and services, such as Office and MSN Search. With so many different features and services, it’s no wonder so many people are having difficulty fully understanding just what it is that Microsoft is trying to accomplish. Despite the many different layers that compose Microsoft Live, its main purpose is clear and undeniable: to unite users on the web and provide them with the information they need.
The Microsoft of Old In order to fully understand the significance of Windows Live, it is useful to reacquaint yourself with Microsoft’s history of software development. Over the last 20 years or more, Microsoft has established itself as one of the world leaders of client-driven software providers. Client software can be thought of as any application that installs locally on a user ’s computer and that operates almost entirely as an isolated, stand-alone unit. Two of the most obvious examples of popular client applications are industry top sellers Microsoft Word and Microsoft Excel. Both Word and Excel are purchasable as CD-ROM or DVD packages that install on one or a limited number of user workstations. The tools they provide are powerful, leveraging the entire set of features and capabilities available in a basic Intel computer. This software model was long thought of as the main channel of software sales and indicative of the only real way to make money selling computer software. As more and more consumers over the years bought cheaper, more powerful PCs, the need for more powerful software grew steadily. Other popular client applications such as Microsoft Mappoint, Microsoft Access Database, and Microsoft Outlook Mail began to proliferate on the market, giving users access to increasing amounts of information and giving them commanding tools to automate more of their lives. However, tools like Word and Excel have their obvious limitations. If a user is away from their PC, they are also away from their documents and financial spreadsheets. As copies of documents are made, maintaining the correct version becomes increasingly difficult. For programs such as Microsoft Mappoint, which provides the user with large amounts of data subject to unpredictable change, newer versions of the application code have to be redistributed and directly installed on the user ’s PC. If their programs aren’t updated, they inevitably became outdated, providing users with old information, often without their knowledge. Yet these limitations were once widely accepted as a natural part of personal computing.
Along Came the Web This all began to change with the growth of the World Wide Web. The history of the web, as well as other Internet-driven platforms and programs is its own wild, wily tale, fraught with conspiracy, browser wars, piracy, romance, and tragic heroes (pardon the drama), and falls outside of the scope of this book. It is important to note, nevertheless, that the meteoric rise of the web forced the Redmond giant to rethink its business model entirely. Despite the web slow down in the early part of the new millennium, it was evident to all that the Internet was something much more than a fleeting phenomenon. As more home PCs connected online, the need for readily available services and ubiquitous information began to grow. Companies such as Yahoo! and Google realized massive growth in online traffic and advertising sales by offering information portal tools and simplified search capabilities. Powerful firms
2
Chapter 1: Background of Windows Live such as America Online dominated the Internet service provider (ISP) market scooping up tens of millions of dollars in revenue and offering alternative tools to those otherwise bundled in the Windows operating system. Innovative sales and auctioning services such as eBay empowered small home businesses to sell items to people from virtually anywhere on the planet, shaping new Internet-based markets. The world had suddenly become a much smaller place. While there may always be a place for packaged goods and client-installed applications, the spectacular growth and popularity of the Internet quickly developed into something more personal. More and more home users have begun to use online services as an integral part of their daily activity. The centralization of data and our ability to access information from any Internet-enabled PC has moved out of the realm of “cool” and rooted itself deeply into the realm of the expected. Of course, Microsoft couldn’t ignore the Internet. It, like most other large software manufacturers, wanted to leverage growing online trends in lots of ways. Some of these early approaches were somewhat ineffective (does anyone remember Active Documents?!!), amounting to little more than building Internet-capable or browser-capable features into already popular platform tools. That wasn’t enough to keep up with the competition. Noting the undeniable popularity of its portal and search engine competitors, Microsoft finally created a series of powerful Internet services called the Microsoft Network and branded as MSN.
The MSN ERA MSN was Microsoft’s first strong foray into the world of online services. Originally released in the Mid-third-quarter of 1995 to coincide with the release of Windows 95, it has since markedly expanded its services. Although the initial release offered a number of different online tools, most people came to quickly know MSN by its search services, email services, and instant messaging tool. MSN search has enjoyed a long, steady growth in use over time. At first, MSN search was yet another search engine in a sea of otherwise waning websites, such as Lycos and Excite.com. However Microsoft isn’t the world’s biggest software giant for nothing. Revamping their search algorithm and carefully integrating free email services, MSN’s usage began to take hold. Following the form of some of their competitors, MSN began to beef up its site to be more revisit-friendly. Daily news, stock quotes, horoscopes, and local weather forecasts peppered the user ’s home page and encouraged people to visit the site for reasons other than simple searches. MSN has also become a well-established Internet service provider, with over 30 million paying subscribers worldwide. By partnering with popular PC manufactures and software distribution services, MSN quickly gained ISP market share, parlaying that advantage into even more MSN service users than ever before. Figure 1.1 shows a typical day on an MSN user ’s home page, complete with articles, links to mail accounts, and other online tools, with the telltale search box at the top of the page. AS MSN’s popularity grew so did the services it offered. Its Hotmail webmail service was one of the first free online tools offered by MSN to enjoy swiftly growing popularity. Hotmail allowed people to access their email from a web browser, freeing them from corporate firewalls and from the often cumbersome and limiting mail services that came with ISPs. Hotmail eventually became a strong unifying force within MSN’s multiservice framework and inevitably became an integral part of Microsoft’s first stab at universal online data access initiative, MSN Passport.
3
Chapter 1: Background of Windows Live
Figure 1-1
MSN Passport is Microsoft’s single sign-in service created to allow users to log in to multiple websites at one time with a unique ID. A Passport account is required to fully utilize other MSN services such as MSN Encarta, Microsoft’s online encyclopedia; MSN Shopping, a shopping tool affiliated with many popular online retailers; and MSN Spaces, an online blogging tool. MSN Services and MSN Passport continued to grow on their own merits for sometime, yet the original intent of these tools were never fully realized. In the early part of 2001, Microsoft unveiled the Hailstorm project. Hailstorm was intended to be a series of application building blocks that leveraged the MSN Passport model to offer subscription-based online services to their users. Users could enter their personal data one time into their Passport account, including their credit card numbers and personal demographic data, and access that data from any number of websites in order to create profiles, make purchases, receive orders, and so on. Despite Microsoft’s best efforts and diligent marketing campaigns, Hailstorm was ultimately dropped. The reasons for Hailstorm’s inevitable failure are highly debatable, though most experts agree that consumers simply didn’t trust an online service to safely store their most personal data. Thus, while MSN Services and its supporting technologies remained useful and continued to attract users, their intended purposes were never fully realized. MSN remains a strong online service competitor and powerful search engine.
4
Chapter 1: Background of Windows Live
The Rise of Interactive Ser vices While Microsoft was struggling to turn MSN Services into a comprehensive blend of subscription services, the competition was getting stronger. Newcomers to the web market were creating new online services for work and home that replaced otherwise traditional types of software. Salesforce.com, a provider of online customer relationship management (CRM) tools gained popularity among small and medium-sized firms looking to keep their sales personnel’s data available on the go. Their web-based model allowed members of company sales personnel to access up-to-date information from any computer, using only the web browser as a single vehicle of data delivery. Weblogs (“blogs”), an online, publicly viewed discussion forum where a person can enter opinions and thoughts in a diary format became a fast-growing phenomenon. People began flocking to other people’s blog pages to read their entries, post feedback, and connect with other people with similar interests. Figure 1.2 shows the home page of Blogger.com, one of the more popular free blogging websites.
Figure 1-2 Perhaps Microsoft’s toughest competitor, Google Inc., was growing its relatively limited services at a frenzied pace. In addition to a unique search algorithm that trumped that of other search engines, Google’s pay-per-click advertising model won it both popularity and huge earnings. Expanding past the confines of web searches, Google began to release ancillary services, many of which have met with great
5
Chapter 1: Background of Windows Live success. Some of these services have targeted popular MSN services, adding valuable features free of charge. GMail, for example, Google’s answer to webmail, competes directly with MSN’s Hotmail and offers integrated web chatting and unlimited email storage. Many of Google’s newer services also boast rich user experiences, while remaining entirely web-based. Google Maps competes with the extremely popular Mapquest web service to provide online driving directions. Although Mapquest has been integrated into many third-party websites as a paid mapping service, Google Maps offers a pointand-drag feature that allows users to move about the map without constantly reposting the page for more map data. Google Maps also combines satellite imaging, so users can get a zoomable bird’s-eye view of their destination. As these new features each met with positive fanfare, Google began to shift its focus away from web searches and more towards interactive services. Bold new initiatives were instated to move users off their desktops and into the web for more personal, tangible needs, while downloadable Google tools began to infiltrate the mostly homogenous Windows desktop. Google Desktop search, for example, applied Google’s popular, effective search algorithm to items on a user ’s computer, bypassing native Windows search tools and bridging the divide between local desktop applications and directly accessible online tools. The popularity of Google’s new services began to change the way people perceived their software experiences. The trend towards interactive services really began to peak with the advent of user content-driven websites. Often referred to as “Web 2.0,” this trend of highly interactive sites got people to stop thinking of the web as a tool for their lives, and to think of it more as a place where they live. Community-based websites like Friendster, LinkedIn (displayed in Figure 1.3), and the ever-controversial MySpace.com swept the young adult demographics and became the driving force behind a whole new generation of online users. Whole social communities began to build themselves using simple person-to-person networking tools built right into the site. Musicians, comedians, and actors took the initiative and began to market themselves heavily through these channels, often creating true celebrity for themselves as the result. Personal posting websites like Craigslist.org moved from the realm of the conveniently local to the coveted tech stardom of a top traffic-producing website. Finally, the Internet came to be regarded as a destination for users and client bases, and not simply as a means of transport. The rise of so many interactive services presented a new challenge to Microsoft. Not only was their ever-popular client software model beginning to fade into the sunset, but the tools on which much of their software was built no longer fulfilled the needs of the industry. Developers began to reconsider their programming preferences, switching to languages and development kits that could build functional code on all different kinds of platforms. Although ASP and its more powerful successor ASP.Net were fine platforms for website server processing, there were no client-driven tools or services provided by Microsoft to enhance the user experience. Website developers started to build on existing services and libraries, combining them into their own applications to create “mashups.” Mashups were interesting combinations of data feeds from disparate online sources. Yet they lacked the uniformity of a single development source. For example, web developers would combine an RSS feed from public postings sites such as Craigslist.org with the mapping features provided by Google. What the development community needed was a fresh new set of tools that were expedient for developing a mashup and provided them with the ability to easily integrate services in a predictable, controllable fashion. Likewise, Microsoft wanted to provide a new set of development tools that would capture the web developer ’s interests. To satisfy both of these needs, Microsoft released Windows Live services.
6
Chapter 1: Background of Windows Live
Figure 1-3
So What Is Windows Live? Windows Live is Microsoft’s answer to the demand for online services. It is collection of newly developed websites and recently revamped tools that can be accessed via a web browser, accessing data on a remote, centralized server. Currently, Live is composed of many different sites, and the number of sites is growing each month. In its core services, Live is a rebranding of popular existing Microsoft Internet services, such as MSN search, MSN Messenger, and MSN Spaces. However, Live is also a fresh new batch of potent websites that unshackles the user from their PC, letting people access and save information from just about anywhere. Websites such as Windows Virtual Earth are commanding replacements of client software, such as Microsoft Mappoint, that implement client-like user experiences right through the web browser.
New Programming API At the time of this writing, Windows Live is composed of roughly 8–10 official website platforms, each providing its own application programming interface (API). As Windows Live grows, there are countless more services to come, though not all of them are necessarily suited for mashup-type development. Figure 1.4 shows a list of all of the different development SDKs that now fall under the guise of a
7
Chapter 1: Background of Windows Live
Figure 1-4 Windows Live service. Many of these API are older development kits, renamed and subsumed within the Windows Live brand. APIs for existing services such as MSN Search, MSN Messenger, and MSN Spaces have remained relatively static during the unveiling of Live. Developers who have used these API in the past will find that consuming their Live counterparts will ultimately require only minor changes to nomenclature. The purpose of this, of course, is to ease the transition of current MSN developers into the Live programming platform, preventing older programs from becoming obsolete. New services offered through Live.com offer a series of programmatic extensions that are more flexible and simpler to use than previous Microsoft SDKs. These newer API are language and platform independent, enabling web developers from just about any environment to build applications leveraging Windows Live services. These APIs are exposed mostly as public web methods and browser client code and live almost exclusively within public Jscript or JavaScript libraries and Soap-based web service definitions. Using these flexible, public libraries, developers have an opportunity to combine their existing applications with Live tools or build Live-powered sites from the ground up. At the time this book is being written, there are eight official Windows Live platform SDKs:
8
❑
Windows Live Search
❑
Virtual Earth
Chapter 1: Background of Windows Live ❑
Windows Live ID
❑
Windows Live Expo
❑
Windows Live Spaces
❑
Windows Live Messenger
❑
Windows Live Custom Domains
❑
Windows Live Gadgets
Each of these platforms provides its own public API, allowing users to integrate and leverage Windows Live services in their own sites with ease. We will be exploring each of these platforms in this book, taking time to understand their core API and apply them to tangible, real-world applications.
Principles of Windows Live Understanding Windows Live means more than just knowing how to create a Live blog or showing map pushpins in a Virtual Earth application. Windows Live was created to provide support for both the developmental and business aspects of software development. As a Live programmer, you should be aware of the core principles of the Windows Live services and how they affect consumers and developers alike.
Make It Easy for the Developer Community to Integrate with Windows Live and Make Money The Windows Live model provides various avenues of business development to help software programmers and web developers optimize their revenue streams. This business model is an important aspect of Microsoft’s new development model. In the past, Microsoft provided no such business-enhancing services. The ability to leverage services and build revenue streams sets Microsoft apart from other similar online service providers. The combination of these Windows Live services, the broad MSN/Windows Live user base, rapid application development tools, and revenue-building options create unique opportunities for developers seeking to build their business value through one of four business scenarios:
1.
Direct Monetization The primary means of earning revenue using Windows Live services is through Microsoft’s contextual advertising program branded as Microsoft adCenter. Note that at the time of this writing, adCenter has not been fully implemented. Microsoft adCenter is a pay-per-click advertising model that enables website publishers and developers using Live services to earn money directly through user clicks. This idea is not necessarily new, mind you, as other successful competing services such as Google’s AdSense and Yahoo! Search Marketing (formerly Overture Inc.) have made profits that rival the GNP of third world nations using the pay-per-click model. However the Microsoft version has far more depth than the aforementioned competitors. Rather than using simple context-based patterns to provide targeted advertisements, Microsoft adCenter will also be using demographic data provided and stored through Windows Live services to narrow advertisements to an extremely personalized, laser-precision targeted advertisements. The combination of Microsoft advertisements with your Live-powered website works directly to your advantage.
9
Chapter 1: Background of Windows Live 2.
Customer Relationship Management (CRM) Windows Live services helps you perform ongoing relationship management with existing customers. That enables increased frequency of activity or revenue, longer retention as an active customer, or decreased support costs. Generally speaking, CRM can be quite a hassle. The overhead of maintaining data integrity, providing tools for simple upkeep, and making data available to peoples or programs in different parts of your company can be staggering. Using Windows Live services, much of the CRM burden no longer sits with you, the business owner. The acquisition of personal data and the sharing of that data across applications is one of the core features of the Windows Live initiative.
3.
Customer Acquisition Windows Live services aren’t just great for maintaining customer data; they’re ideal for finding new customers. As more people begin to share their data across applications, leveraging Windows live features, developers can use this sharing of data to turn people into loyal clients.
4.
Brand Awareness Although no direct monetization is available through this scenario, developers can leverage the Windows Live service to facilitate brand awareness through a broad contingent of end users.
Easy to Develop In order to attract the widest cross-section of web developers, Windows Live services have been made available in a manner that facilitates simple, easy-to-use development patterns. Programmers developing for any platform and in just about any language can consume Live services, integrating them directly into their existing applications with minimal effort. The result is a set of powerful tools that allows programmers to concentrate on creating sites that work for their business.
Simple HTTP-based Protocols Just about all of the major method calls available from Windows Live services can be invoked using simple HTTP-based calls over the Internet. Using XML-based formats such as the Simple Object Access Protocol (SOAP), developers can invoke methods from any web-enabled application. These calls are readily available to developers using any language. Thus, Java developers who want to incorporate specific search features using Windows Live Search (formerly MSN Search) can do so without the cumbersome overhead of bridging their non-Windows code with Microsoft’s API. Just about every public method that creates use accounts, modifies existing data, or manipulates features within an integratable Live service can be called using SOAP.
Public JavaScript/Jscript Libraries HTTP-based calls are fine for retrieving and saving data, but what about the user interface (or “UI”) itself? Does Windows Live offer features that deliver rich content right into a running application? You bet it does. Using publicly available Jscript libraries, users can integrate fantastic client UI right into their own applications with minimal overhead. This is especially useful when using graphic-intensive Windows Live services such as Live Virtual Earth. Virtual Earth supplies participating websites with all of the graphics, methods, and code required to inject interactive maps directly into web pages. Developers need only to reference the correct Virtual Earth libraries, define the size and location of their map layer, and call Jscript methods as if they wrote them locally.
10
Chapter 1: Background of Windows Live In fact, Microsoft made sure that these client libraries were flexible enough to also allow for plenty of customization. Let’s say that you are a web developer with an online database of local restaurants. It would be great to add interactive mapping so that your users could easily get directions to their favorite eateries. Well, not only can you add these features with only a few lines of code, but you can also create customized thumbnails for each type of restaurant, and change the way the directions are presented, all using a fraction of the code otherwise required without Windows Live Jscript libraries.
Straightforward Licensing and Accommodating Terms of Use Windows Live is an initiative based on integration, and the licensing shows it. Unlike other competing platforms, Microsoft allows developers to integrate and leverage Windows Live services according to the following guidelines (taken directly from the dev.live.com website).
❑
Obey the law.
❑
Obey any codes of conduct or other notices we provide.
❑
Obey the Microsoft Anti-spam Policy, which is available at http://privacy.msn.com/anti-spam.
❑
Keep your service account password secret.
❑
Promptly notify us if you learn of a security breach related to the service.
Users should take the time to read through the contractual agreement to be sure that they are not in violation of any spamming or indecent conduct as defined by Microsoft. However, most developers will certainly appreciate that implementing the Windows Live services API can be done with only nominal degree of legalese.
Any Platform, Any Language Windows Live is about interaction and cooperation. The tools provided, method calls, APIs, and SDKs available to a Live developer are without the encumbrances of platform-specific technologies. Any programmer can use Live services. Although the manner of implementation might vary depending on the types of applications used, the delivery of data by Live websites is done using industry-standard, open protocols and patterns. No need for ActiveX, plug-ins, specialized runtimes, or downloadable libraries—Windows Live works in your web browser or HTTP-supporting client application. . . that’s it!
Easy to Use Your users will find the new Windows Live–powered features of your site to be not only powerful but simple to use as well. Live tools such as interactive maps and gadgets make accessing data easy for everyone, no matter what type of computer you use.
Rich User Experience Windows Live services provides the next generation of interactive web applications. Unlike the web apps of old, these new sites embrace powerful client-based methodologies to facilitate a much richer end user experience. By using web client patterns such as AJAX (Asynchronous JavaScript and XML) and Microsoft’s newly released ASP.Net AJAX framework (formerly known as ATLAS), the web app has moved beyond boring, static HTML. Highly responsive images, tags, and layers make the need for constant page reposts almost completely obsolete. As a result, applications using Windows Live services enjoy the combined convenience of responsive client-like functionality and a portable web architecture.
11
Chapter 1: Background of Windows Live Although the objects used in AJAX applications are in no way new to web programming, their implementation within a flexible, reusable framework is. Much of the ASP.Net AJAX model falls outside of the scope of this book. For more information about ASP.Net AJAX patterns, readers should visit the official website shown in Figure 1.5 at http://ajax.asp.net.
Figure 1-5
Accessible, Up-To-Date Information Perhaps one of the most compelling reasons to integrate with Windows Live is that your users will have access to information at the speed of the web. Windows Live delivers content in real-time, providing website users with the most accurate, up-to-date information available. Website designers and administrators don’t have to update their files or add data to their databases- Windows Live does all the footwork. Services such as Live Search, Virtual Earth, and Live Expo connect your users with vast amounts of online resources such as maps, satellite imagery, user postings, website searches, addresses, phone numbers, and more. With each service you add to your application, the less updating and maintenance you need to perform.
12
Chapter 1: Background of Windows Live
Why Should I use Windows Live? Now that we’re past the part where I tow the company line, let’s discuss why Windows live works for you, the developer. At its core, Live services is simply another SDK. It is a collection of advanced APIs and services that you may choose to use or to ignore. If you are a traditionalist, deeply rooted in monolithic systems, you may not be particularly turned onto the Live methodology. Likewise if you are a staunch anti-Microsoft developer, you may choose to cast Windows Live aside, telling yourself it is a useless whim on the part of the Mother Ship (I have always loved calling Microsoft that) to compete with similar market-absorbing services. Yet before passing judgment, there are certain undeniable advantages to the Live platform you should consider. The first thing one needs to understand is that the Live methodology is here to stay. The notion of leveraging other online services and incorporating them into your own is neither a passing whim nor a contrivance of the Microsoft development team. Rather, it is the natural progression of software development in an increasingly connected web world. The services offered by Windows, such as Live Virtual Earth, Live Spaces, Live Search, and even Live Expo are commonly used services in websites and applications of all kinds. Offering these features communally to developers of all technological backgrounds gives everyone the power to create software more quickly. Also, consuming Microsoft’s services in a manner loosely connected to your own software places the onus of maintenance and upgrading almost completely on Microsoft. That means that you, the developer, can spend more time concentrating on providing software that directly benefits your business. So, even if you despise the idea of combining your software with the services of other websites, you might as well get used to it, because it’s here to stay. Now if you’re like me, you welcome the idea of third-party service integration, but you might be skeptical of using Microsoft’s services. Let’s be frank, shall we? Windows Live isn’t the only provider of consumable online features. Companies like Google and Yahoo! have also released public APIs for mapping, blogging, and the like. So why use Microsoft? Why Windows Live? There are plenty of reasons. To begin with, you have the services of at least 10 different platforms at your fingertips. That means that integrating not just one, but many, online services into your websites will be easier using Windows Live. Take, for instance, a website that provides information for people shopping for new and used boats. The website owner would like to list classified ads for various locations and maybe even provide an interactive map so that buyers can easily find their way to sellers. The site developer could certainly elect to grab RSS feeds from one site and implement mapping tools from another. However, wouldn’t it be easier to use Windows Live Expo for the listings and Virtual Earth for the maps? The APIs are all maintained through Windows Live services, and the implementation patters are far simpler to use. In fact, the site owner might even decide to take their features a few steps further, providing some blogging capabilities for his/her clients and maybe even a cool chat tool where people can exchange boat pictures. Using Windows Live, a developer can implement all of these features without referring to multiple third-party resources. Another compelling reason to choose Windows Live services is familiarity. Most of us, have worked with Microsoft development tools at one point or another. If you’re reading this book, chances are that you’ve worked with Microsoft languages and platforms as well, such as Visual Basic, C#, and ASP.Net. Although Windows Live APIs are in no way platform-specific, Microsoft developers will find that extending many offered features is quite simple using Microsoft patterns. That means that you’ll be able to create powerful applications with greater ease. Live Gadgets are a good example of this advantage. Gadgets can be written for any platform that supports Jscript or JavaScript. Many gadget developers will no doubt want to employ JavaScriptAJAX patterns. People familiar with ASP.Net development will find that Microsoft’s ASP.Net AJAX project provides an ideal client/server toolset for AJAX development. ASP.Net AJAX not only simplifies the otherwise cumbersome client coding required for rich, responsive UI, but it also integrates nicely with the Live Gadget model. Using Windows Live, seasoned Microsoft developers will find that their skills can be a definitive advantage when leveraging features and services.
13
Chapter 1: Background of Windows Live Perhaps the most compelling reason to develop with Windows Live tools is data. Windows Live is a comprehensive initiative, providing tools and features for many different types of applications. At its core lives a data engine that can collect demographic information in an opt-in model, allowing users to access and reuse their data in situations that suit them. . . This might not seem all that innovative on the surface, but consider the implementation. Perhaps you have created an application that uses Windows Live ID as your web domain gateway. Users registering with your application provide various private pieces of demographics, such as their home address, their age, their marital status, and favorite websites. Over time you decide that you’d like to expand your services to include specialized searches using Windows Live Search based on geographic locale and preferences. Since the user ’s information is centralized, you can request users to share some of their data with you application, explaining the valueadded features their data will expose. Using the data already stored using Windows Live ID services, your users can elect to make that information available, benefiting from your new search tools each time they authenticate through your website. The users’ data is available only upon their permission, giving them full control over their personal information. Once they elect to share their data with your site, their experience is enhanced and repeat traffic is born! Now add in services for instant messaging, blogging, and chatting and you get something that other online services can’t easily provide: synergy. That’s what Windows Live does best for you. By leveraging features that help capture and consume your user ’s information, you can expand your site to cater to each user ’s individual needs.
The Windows Live Paradigm The full embracing of Windows Live services requires a change in the way you think of your website. Up until now the lion’s share of a web developer ’s experience centered around building a stand-alone website. The tools implemented benefited only the site’s owner, and any proceeds earned fed a business model completely disjoint from other, possible similar web based businesses. This seems practical for the most part. No need to share services, traffic, or even customer information with competitors, right? Wrong. Not only is this line of thinking counterproductive, but it doesn’t necessarily follow more traditional lines of retail marketing. If every store in the world followed the web business model, we’d inevitably be saddled with hundreds of thousands of retail outlets scattered all over the world in an entirely inconvenient manner. Yet we know this is not the case. Quite often in the retail world groups of stores are strung together to optimize the consumer shopping experience. Strip malls give you five or ten small shops conveniently located in one complex. Although some of these stores might compete on some level for consumers’ attention, they also benefit from one another ’s traffic. A mother who goes to a strip mall to pick up a movie at the local DVD rental shop might also decide to grab a slice of pizza from the Italian restaurant two doors over. She may then also remember that she’s out of milk and quickly swing into the convenience store at the end of the parking lot to pick some up. Although this person might have gone out another time to make her purchases, the convenience of having all shops in one location saved her time and effort, and ultimately lead to purchases for three of the stores in the mart. Shopping malls provide an even stronger example of this retail-sharing model. When a store or shop opens inside a shopping mall, they are not only benefiting from a large stream of localized traffic, but they are also able to share feature and services. A shopping mall offers features that most retail shops would need to provide to their own customer base, such as public bathrooms, handicap accessibility, daytime and nighttime security, basic utilities, ample parking, and much more. Provided that the cost of running a shop in a particular shopping mall isn’t exorbitant, the benefits are obvious. In fact, it stands to reason that unless you’ve got a well-known product, a great location, and a flush bank account for some serious marketing, opening a stand-alone shop can be a more difficult way to start a business.
14
Chapter 1: Background of Windows Live The same idea of retail sharing can be applied to the web world. In some cases, we’ve already seen this pattern. Portal websites that connect the user to other like-purposed sites is a simplified way of sharing traffic. Rather than having to surf with search engines for hours on end to find websites offering appliance repair, a portal solution would be more direct. Users could come to one website that lists many appliance repair websites, rates their customer feedback, and offers direct links to each if a user wants to surf further. Portals help websites of a similar business type or service share traffic with one another. Portals are often limited in scope, however. Listing a website within the portal might increase traffic, yet the person who comes to a portal for appliance repair will buy only that. There is no chance for cross-selling a slice of pizza or a carton of milk as discussed in the strip mall example. Since the grouping of links to other websites doesn’t really provide the same level of convenience as a physical grouping of retail shops, most portals keep their themes homogenous. As a result, new websites interested in getting new business pursue other options such as search engine optimization (SEO). SEO can be an effective way to get new business; however, that practice is more about direct site marketing, and is more akin to taking out big ads in the yellow pages than it is to sharing traffic implicitly.
The Virtual Smart Mall Windows aims to rectify web business model by providing many of the same utilities and services available to non web-based businesses. Using the shopping mall analogy as a vehicle for comparison, there are three levels of services that Windows Live offers that can help web businesses. These three levels of service offer a kind of “smart mall” model. The small mall model mimics the conveniences of a regular shopping mall described in the proceeding section, while also adding services around client demographics. Imagine a shopping mall that not only provides you with utilities, bathrooms, and 24-hour security but also with a service that helps you figure out who your clients are and how to best cater to their needs and trends. The result would be a series of stores that shared traffic, shared services, and implicitly helped one another to optimize their marketing, while providing a high degree of convenience to the customer base. The first level of services is shared utilities. These are the many different tools and features offered through the Windows Live API that can be added to your own website. Live tools, such as Virtual Earth, which allows you to add interactive maps to your application, and Live Search, a comprehensive searching and indexing tool that works directly within your web domain, can be valuable additions to your site. They embody commonly used features that add value to your application but that you’d otherwise have to build and maintain yourself. The second level of service offered to your website by Windows Live is shared data. Windows Live services builds on a long history of MSN services and leverages from that quite a bit of user data. This data centers around user accounts and comprises demographic information, such as a user ’s name, email address, contact list, and other profile-specific data collected from applications such as MSN Messenger. Microsoft has rolled these profiles, along with their aggregate data, into Windows Live services. The result is the ability to create an account using Live Messenger and opt to have this data available to other applications using Windows Live services. What’s more, the amount of personal information available from an account is entirely up to the user. They are in full control of their own information, and may choose to share certain pieces of it in ways that may benefit their website experiences. Newer Live services such as Live Contacts and Live Data are available for precisely this purpose. Again, the amount of data available is entirely up to the user. Clients need to opt in to data-sharing relationships before they can be seen by other users in Live-powered websites. Once they do, they can conveniently reuse much of their information in different websites.
15
Chapter 1: Background of Windows Live The third level of service offered by Windows Live is shared demographic and trend-based data. Although an individual Live user is completely anonymous to the Windows Live reporting engine, his or her demographic information is tracked and built into a series of trend-producing data stores that ultimately allow businesses to determine their core demographic and to provide services to those users directly. Here is where the virtual smart mall model really comes to life. Online services and advertising solutions such as the previously mentioned Microsoft adCenter and Microsoft adLab offer targeted advertising postings and demographic targeting reports to help website administrators target their business effectively. These tools use the data generated from statistics related to Windows Live traffic and trends. So, as more people use Live-powered websites, there is more information available to help you market your site or services. Imagine a shopping mall that remembers what people buy, what they browse, and where they like to go, and makes that anonymous information available to shop owners. Consumer trends could be discerned and needs quickly fulfilled. The result is a more efficient mall market where people always find things they need and shop owners can consistently determine and sell precisely what their clients desire. In addition to the growing online community connected through Live ID and rich service functionality, this business model is the driving force behind Windows Live. Participating websites get the benefit of free upfront features and services that drive traffic to the engines that ultimately improve the way they run and market their services.
Summar y In this chapter, we took a step back and reviewed the history of software. We discussed the difference between the client software development models of old and the newer ubiquitous online development patterns and how they shaped the online services market. We then took an in-depth look at Windows Live itself and the benefits it offers, discussing some of the similarities that online business has to retail industries and considering the different ways that Windows Live aims to improve upon website marketing. In the next chapter we will explore the various technologies that drive Windows Live, and discuss the ways Live services can facilitate building mashup web applications.
16
Knowing the Platforms and Ser vices Before you begin developing with Windows Live services, you should take some time to familiarize yourself with the programming landscape. Although the Windows Live APIs do not require Microsoft-specific programming skills, developers will need to have a strong grasp of widely used web standards and commonly used scripting techniques. In this chapter, we will do the following:
❑
Discuss widely used web programming languages and techniques supported by Windows Live services
❑
Review nonstandard tools and platforms that can catalyze the Live development process
❑
Review each of the Windows Live services directly, pointing out the main features of each and how each can be automated and consumed
The Programming Landscape It’s best to familiarize yourself with the programming landscape before jumping head first into the Live API. Readers should be familiar with most web programming languages and platforms in order to fully grasp some of the tenets discussed here. If you are an avid programmer in need of a refresher in commonly used development tools, three primers can be found in this book’s appendices that serve as quick lessons for DHTML, ASP.NET development, and the C# programming language, respectively. Windows Live is unlike other conventional platforms to which most developers may be accustomed. It comprises multiple, seemingly disparate APIs, each delivered in whichever programmatic vehicle best suits its implementation. Web developers will find themselves at home with some SDKs, particularly those that use standard client scripting and references to public libraries, such as Live Virtual Earth and Live Gadgets. Obviously, these development tools target web applications, or at least those applications that utilize HTML as their primary UI layer. Other SDKs, however, are not as web page– focused and employ the use of SOAP-based web services. These services, such as Live Search and Live Expo, can be leveraged by any application regardless of its design. That being said, it may help to familiarize yourself with some commonly used web-based technologies.
Chapter 2: Knowing the Platforms and Services Web Services Many of the Live API are exposed via public web methods that can be invoked through industrystandard remote procedure call (RPC) protocols. Users familiar with consuming web services will find these API very pliable, conforming to standard calling conventions. Using XML-formatted calls developers can remotely invoke methods in Live services from any web-enabled server. These methods are entirely transparent to the developer, and can be called from any platform that supports standard HTTP requests. However, developers should be aware of the different protocols used to enable remote method invocation. Although some emerging services take advantage of newer web-based patterns such as Representational State Transfer (REST), there are primarily two protocols used in the Windows Live world: XML-RPC and SOAP. XML-RPC is a simple, lightweight protocol that can be used to access public methods over a network or through the web. Its features include simplified standards for defining types, arrays, and structures without overburdening the programmer with an overwhelming number of features. XML-RPC has been around since the late 1990s and, though it has not been officially ratified or recommended by the W3C, it remains a stable platform for simple public method calling. A typical XML-RPC request contains a method name and a list of simple parameters required by the method. XML-RPC sample:
examples.getStateName
41
SOAP, meaning Simple Object Access Protocol, picks up where XML-RPC leaves off. It provides a set of standards for defining types, arrays, and structures; however, it also allows for advanced extensibility. SOAP adheres to extensive namespacing and attribute specification tags. This allows for more data to be delivered in a simple message call, such as who the recipient is and message-specific processing control. A typical SOAP call can consist of four sections. The first, called the Envelope, identifies the XML document as a SOAP message. The Envelope is the root XML element that contains the three other portions of the RPC. An optional Header section is next, containing message-specific data. The third section, know as the Body, contains the method call and response information. An optional fourth section is the Fault element, providing information errors that may have occurred while invoking the method or processing the message. Here is a SOAP sample:
18
Chapter 2: Knowing the Platforms and Services
int string
It is worth noting that the SOAP standard is widely used throughout the Microsoft world and is supported within the Microsoft.NET programming platform. XML-RPC is ideal for very simple, limited method calling. At the time of this writing the Windows Live Spaces (Formerly MSN Spaces and MetWeblogAPI) is the only SDK in the Live initiative that used XML-RPC over SOAP, primarily for the automation of blog postings. Other, more feature-rich services, such as Live Expo and Live Search, use SOAP as the default formatting for all method invocation.
JavaScript/DHTML Much of the Windows Live SDKs provide UI to consuming applications. These services employ the use of DHTML and extensive client scripting. Web-based languages such as JavaScript and HTML allow for consumers on any platform to leverage the rich UI service provided by Windows Live. When possible, Microsoft makes available their own JavaScript libraries, which can be referenced and consumed by any web-enabled application that supports HTML-based interfaces. However, in some cases, the use of these libraries provides only an event model that needs to be implemented in a fashion specific to its corresponding Windows Live service. A good comparative example might be Windows Live Virtual Earth and Live Gadgets. Virtual Earth provides extensive mapping and location-based search features. Because the implementation of Virtual Earth is limited to images actually served out from the Virtual Earth site, the implementation of its features is very simple. Users need only to reference the Live Virtual Earth library within the header of their HTML form to be able to call its services. Consider the following code sample:
19
Chapter 2: Knowing the Platforms and Services This is one of the simplest examples of the Virtual Earth SDK. Using relatively little code, this snippet will load a page with the Virtual Earth map control positioned in the upper-left corner of the page. The map will be centered above Philadelphia, PA, with the zoom control positioned in the upper-left corner of the map. Since I am not attempting to add any advanced mapping features of my own (we’ll be covering those features later in this book), the map control loads with all of its default settings. If you click on the control, you can drag the map in any direction without forcing the page to reload more images. Try zooming or changing the default map style to show satellite images; all of the basic map features are functional. The key to providing the map features is the page reference located in the HTML page’s header section:
This reference allows me to call the VEMap control as if it were local to the application’s source code. In fact, a closer look should reveal that most of the HTML provided in this sample is required simply to load and display the web page. Ultimately, two lines of code do most of the work for you: map = new VEMap(‘myMap’); map.LoadMap(new VELatLong(40.10123,-75.219445), 9 ,’r’ ,false);
Mind you, there are some requisite settings you’ll want to include in your page to optimize the map and enable all of its provided features (such as using UTF-8 encoding for text and loading the map into its own layer). Nevertheless, the public library mapcontrol.js provides just about everything you need to implement a fully interactive, zoomable map without any prerequisites. The Windows Live Gadgets SDK also allows for the use of public client script libraries. Gadgets are a new type of platform-independent mini-application that can be used to provide useful information or enhance the user experience on a web page or Windows PC. Unlike the Virtual Earth SDK, the Gadget SDK demands that the user be familiar not only with the method calls, but also with a specific event model to which all gadgets must adhere. This is because Gadgets are run inside of a host page and need to “plug in” to the host page’s event model. Gadgets are more pliable than the Virtual Earth controls, allowing developers to create just about any type of UI they need. To accommodate for this flexibility, the Gadget SDK does not serve out any default UI or controls. Instead, each gadget must come with its own XML file (called a manifest) and JavaScript file that calls certain gadget-specific methods. Note the HelloWorld gadget JavaScript sample below: registerNamespace(“Microsoft.Live.GadgetSDK”); Microsoft.Live.GadgetSDK.HelloWorldGadget = function(p_elSource, p_args, p_namespace) { Microsoft.Live.GadgetSDK.HelloWorldGadget.initializeBase(this, arguments); this.Output = function() { p_elSource.innerText = “Hello, world!”; } Microsoft.Live.GadgetSDK.HelloWorldGadget.registerBaseMethod(this, “Output”);
this.initialize = function(p_objScope) {
20
Chapter 2: Knowing the Platforms and Services Microsoft.Live.GadgetSDK.HelloWorldGadget.getBaseMethod(this, “initialize”, “Web.Bindings.Base”).call(this, p_objScope); this.Output(); } Microsoft.Live.GadgetSDK.HelloWorldGadget.registerBaseMethod(this, “initialize”); this.dispose = function(p_blnUnload) { Microsoft.Live.GadgetSDK.HelloWorldGadget.getBaseMethod(this, “dispose”, “Web.Bindings.Base”).call(this, p_blnUnload); } Microsoft.Live.GadgetSDK.HelloWorldGadget.registerBaseMethod(this, “dispose”); } Microsoft.Live.GadgetSDK.HelloWorldGadget.registerClass(“Microsoft.Live.GadgetSDK. HelloWorldGadget”, “Web.Bindings.Base”);
The first thing you’ll likely notice is that this snippet of code does not define an HTML page, nor does it include any page-specific elements, such as the header or body elements. More importantly, this client sample does not directly reference any public script libraries as was demonstrated in the Virtual Earth sample. That is because every Gadget runs as a component of a Gadget-supporting page. The variables referenced, along with the methods called, are predefined in the Gadget-supporting environment. Understanding the subtle difference between the way that the Virtual Earth SDK uses client scripting and the way that the Live Gadget SDK uses client scripting is imperative when developing UI with Windows Live services.
Server-Side Technologies Web applications come in all shapes and sizes. If you’re building a handful of sample pages with some static content and maybe a few hyperlinks, simple client markup may be all you need to know. However, if you’re goal is to build highly interactive sites with dynamic content, it’s best to be familiar with a multifaceted server-side web technology. These platforms ultimately provide the same raw content to the web browser, but they also provide a strong set of development features that make complex web processing more flexible. When building applications powered by Windows Live services, server-side technologies can help quicken your development. There are quite a few to choose from, PHP, for example, is a universally accepted scripting language that runs on most operating systems and that can be embedded directly into your web page. Java, another widely accepted language, has web-specific constructs such as Servlets and Java Server Pages (JSP), which help to isolate server-side logic while still providing a strong degree of scripting flexibility. Newer languages such as Ruby are ideal for layering in strong software development tenets such as object-oriented design and, more recently, aspect-oriented design. Consider any of these platforms for a more adaptable approach to your web development.
A Word about ASP .NET If you are a seasoned Microsoft web developer, you may find occasion to use the ASP.NET model for creating and consuming Windows Live services. Although Windows Live services do not target any single platform, language, or operating system, the ASP.NET model does provide for a streamlined development process. It supports the same web conventions described in the previous sections, such as JavaScript, DHTML, and HTTP web services. It also provides a convenient web event model that fits in nicely with many Live services. Creating custom web controls and reusable templates becomes a far simpler process. This book does not explain all of the ins and outs of ASP.NET programming; however, many of the samples are written in C# targeting an ASP.NET environment. It may be useful to familiarize yourself with some of its basic tenets (after all, Live is a Microsoft-supported initiative). For more information on ASP.NET development, refer to the ASP.NET primer located in Appendix B.
21
Chapter 2: Knowing the Platforms and Services ASP .NET AJAX Asynchronous JavaScript and XML, known by its popular acronym “AJAX,” is another popular development pattern users will find in the Live Services API. AJAX is a methodology that uses powerful client script objects to send and receive information from a web server without forcing a reposting of the entire page. Web pages using AJAX technologies are generally more responsive than non-AJAX pages, functioning more like an application running on your PC rather than a web application. The primary AJAX object, the XMLHttpRequest object, has been around since the late 1990s, and has recently enjoyed resurgence in popularity due to client-heavy web applications requiring a seamless retrieval of data and images, such as Google MapsVirtual Earth. Here is a small sample of an AJAX-powered web page: function xmlOpen(method, url, toSend, responseHandler) { if (window.XMLHttpRequest) { // browser supports XMLHttpRequest object natively req = new XMLHttpRequest(); } else if (window.ActiveXObject) { // try creating the XMLHTTP using fully qualified name req = new ActiveXObject(“Microsoft.XMLHTTP”); } if(req) { req.onreadystatechange = responseHandler; req.open(method, url, true); req.setRequestHeader(“content-type”,”application/x-www-form-urlencoded”); req.send(toSend); } else { alert(‘Your browser does not seem to support XMLHttpRequest.’); } }
This example shows an AJAX-consuming method that might be found inside of a simple web page. Note the creation of the XMLHttpRequest, and the properties supported within it. As the acronym’s name suggests, AJAX patterns are asynchronous. They require a callback model to support changes in state. Knowledge of AJAX design patterns is not a prerequisite when consuming Windows Live services. However, much as with ASP.NET, it might be useful to understand how AJAX pages function. Both Windows Virtual Earth and Live Gadgets employ AJAX patterns. Understanding how AJAX works will help you better understand many of the examples provided in the Live SDKs. Users familiar with advanced ASP.NET programming might want to take a look at the Microsoft ASP.NET AJAX project (formerly known as the ATLAS project). ASP.NET AJAX is a Microsoft-supported initiative to provide AJAX-powered templates in cohesive, reusable controls and templates. ASP.NET AJAX combines the server-side event model of ASP.NET with the client-heavy code of AJAX to create powerful templates that will catalyze AJAX development and help coordinate otherwise unruly client scripts. In fact, the ASP.NET AJAX templates can be used in non-ASP.NET platforms as well, integrating with PHP, JSP, and most other web patterns. The base code that powers ASP.NET AJAX applications is
22
Chapter 2: Knowing the Platforms and Services identical to non-Atlas AJAX code, with the not-so-subtle difference being that the actual AJAX calls are stored away in reusable JavaScript libraries. This is a technique common to ASP.NET client development. Rather than creating the XMLHttpRequest object and handling each event directly, developers can place ATLAS-powered controls and regions into their ASP.NET pages. By setting certain properties and placing various configuration settings into the web.config file, developers are able to make their applications more responsive without writing much client script.
Visual Studio.NET 2005 You do not need to have an advanced interactive development environment (IDE) to create applications powered by Windows Live services. In fact many of the examples within this book rely only on the use of a good text editor to build and deploy the samples. However, if you have Visual Studio.NET 2005 edition, you might find some of the built-in features useful. Visual Studio.NET comes with functionality that will certainly simplify your coding, such as refactoring tools, block wrapping, and direct method navigation. Yet Visual Studio.NET 2005 edition can also be used to create project templates called addins to support commonly used frameworks. If you intend to build applications using ASP.NET AJAX templates for example, you’ll find that the ASP.NET AJAX SDK comes with a Visual Studio.NET add-in to simplify your development. If you do not have a version of Visual Studio.NET available, you won’t be able to easily follow many of the examples in this book. As an alternative, readers should consider installing the free IDE editions, Visual Studio.NET Express Edition. More information on Visual Studio.NET Express edition can be found at http://msdn.microsoft.com/vstudio/express/. Figure 2.1 shows the Visual Studio Express home page.
Figure 2-1
23
Chapter 2: Knowing the Platforms and Services Mash it up Developers incorporating Live services and features into their own applications are creating a type program commonly referred to as a Mashup. A mashup is simply any application that combines the features of one or more public API or controls into a distinctly separate program. The goal of creating a mashup is to build advanced, multi-featured applications while saving development time and maintenance effort. By definition, any site can be a candidate for a mashup. Sites that offer public data, images, or remote procedure calls, which can be directly (and legally) built into other websites could be considered for a mashup. There are all types of mashups currently available online. Many combine mapping features with, public real estate listings in order to provide a visually geographic view of home sales within an area. Other mashups combine search engine services with online resume postings to connect people looking for jobs with opportunities that match their skill sets. Mashup applications also help to reduce the maintenance load from site administrators by collecting the data directly from the data source in real time. If the real estate mashup mentioned above were to run on its own, it would require not only the incorporation of features to find the listing and create the map, but also the data that drives the listings. Both would have to be stored and accessed on a local server. What’s more, the site administrator would have to maintain the data regularly, updating the real estate listings to show new and sold homes and adding map images to the mapping portion of the application. However a well designed mashup application instead pulls home sales directly from a separately supported online service. Likewise, the maps that display the listings would download images from a separate online mapping program. As a result, the development overhead is limited to incorporating the external services, and the listing data and map images never have to be updated. Windows Live is a platform created for building mashups. Each Live service is explicitly designed to work hand-in-hand with other Live services. In fact, the very engine that handles user accounts is carefully woven into many of the method calls found in the Live services API. This makes the combination of services a far simpler task. Though each feature set of the Windows Live platform certainly provides its own unique benefits, the entire software suite has been designed to work with each other. For example, consider the aforementioned real estate mashup. Some of the available applications combine postings and mapping from two different disparate sources, such as Craigslist.org and Google maps. That same application could also be built using Windows Live Expo for postings and Virtual Earth for geographic mapping. Since both Expo and Virtual Earth use Live ID, a Live ID authenticated user could also connect to their Live Spaces account, save searches performed within the application, and connect with other application users for instant messaging — all with little or no extra development effort on the part of the site designer. The more Live services you integrate with your site, the greater the overall benefit.
Features of Windows Live Let us now take a moment to examine the Live Services covered in this book. Bear in mind that these areas represent the major Windows Live services available during the writing of this book. There are certain to be many more services to choose from in the coming months. * Live Search — Microsoft’s Web search tool for finding online resources. It can be used to look for web pages based on subject matter and relevant text, and also for images, products, books, locations, newsfeeds, and many other forms of online content. Primary web address: http://search.live.com * Virtual Earth — An interactive mapping tool that can be used to find geographic locations, obtain driving directions, view satellite images, and much more. Virtual Earth is designed for direct web page integration. The components and features within Virtual Earth provide a rich set of interactive UI served out in real time from Microsoft’s mapping servers and delivered directly into a browser’s client web page. Primary web address: http://local.live.com
24
Figure 2-2
Figure 2-3
25
Chapter 2: Knowing the Platforms and Services * Live ID — Microsoft’s authentication model. Replacing the previously-named Passport network, Live ID is a comprehensive user ID system design with single sign-on in mind. Each individual Live ID uniquely identifies a user to any Live ID-powered website, taking the burden of maintaining credentials off of site designers and placing it squarely on the shoulders of Microsoft. * Live Expo — The first of two social networking services, Live Expo allows users to create public postings in a classifieds advertisement-like model. Users can create postings detailing items for sale, items for purchase, job opportunities, social announcements, and more. Primary web address: http://expo.live com (also http://www.expo.org)
Figure 2-4 * Live Spaces — The second of two social networking services, Live Spaces allows users to create personalized web pages for expressive content. Users can create Spaces accounts to show photos, express opinions, share interesting information, or just plain hang out online and meet people. Primary web address: http://spaces.live.com * Live Messenger — Microsoft’s newest version of their popular instant messaging tool. Improving on many of the features of its predecessor, MSN Messenger, Live Messenger connects Live ID users with one another for direct, real time communication. * Gadgets — Small mini applications that combine advanced component design with industry-standard design patterns. Though early in their design and implementation, Gadgets can be developed by anyone and distributed in various Gadget-supporting websites. * Custom Domains — A Microsoft service that lets website administrators create Live ID accounts with names corresponding to a registered domain name. Custom Domain accounts are full Live ID accounts, providing the same set of features and benefits available to regular Live ID users.
26
Chapter 2: Knowing the Platforms and Services
Figure 2-5
Summar y In this chapter, we took a closer look at some of the technologies that drive Windows Live. We discussed some of the standard platforms and services that can be used to leverage Live services, such as XMLbased web services and JavaScript libraries that work in conjunction with DHTML. We then moved to some other technologies that can improve Live service integration or enhance the user experience. We concluded with a high-level overview of the Windows Live Services covered in this book. In the next chapter we will review each Windows Live service and explore their individual APIs.
27
Over view of Windows Live SDK s Each Windows Live service provides an API for automation. Though each service has the ability to integrate with one another, their individual interfaces support different patterns and technologies. In this chapter, I will:
❑
Discuss each of the major Windows Live services and the tasks developers can perform with each
❑
Review the API provided by each service
❑
Review some of the emerging Windows Live services Microsoft will be releasing
Overview of the Windows Live API Perhaps it is best to begin looking at the individual Windows Live SDKs from a 10,000-foot point of view. The entire initiative covers at least eight different SDKs, each providing its own features and its own degree of interactivity. Although you might be inclined to just download one of the SDKs and start playing around, your efforts will yield only a limited understanding of a single tool. Remember, the power of Windows Live lies in its ability to mix services together. This brief chapter attempts to familiarize readers with some of the details of each Live services’ API, as well as discuss some of the newer services on the horizon. That being said, let’s get familiar with each of the services.
Live Search Live Search, formerly MSN Search, is the web search engine from Microsoft we’ve all come to know and love. Like most web search tools, Live Search allows users to query an extensive online index of public websites and web pages to find relevant matches to text searches. Web search sites powered by Live search, such as MSN.com, allow users to enter text phrases and submit them to Microsoft in order to produce relevant website matches. However the power of Live Search
Chapter 3: Overview of Windows Live SDKs extends much further than simple user queries. Using the web service API provided by Windows Live Search, developers can easily build complex searching and indexing capabilities directly into their applications. Search for news, maps, product and shopping data, information in academic journals, images, and more. Live Search exposes a series of classes wrapped in SOAP-based web methods called transparently through normal HTTP channels. The main classes used are defined below:
❑
MSNSearchService — Main object used to invoke asynchronous searches
❑
SearchRequest — Object containing data pertaining to the search criteria
❑
SearchResponse — Object returned by the Live Search engine after a search request
is submitted
❑
Result — Object containing data pertaining to a result from a requested search
The tools provided by Live Search are deceptively simple to use. Even though there are precious few objects to call, the different ways Live Search can be implemented can be staggering. What’s more, Live Search already integrates with existing Windows Live sites, such as Live.com, to save your searching results for future use. Figure 3.1 shows a sample Windows Live Search page.
Figure 3-1
30
Chapter 3: Overview of Windows Live SDKs Virtual Earth One of the most versatile and exciting platforms included with the Windows Live release is Virtual Earth. Virtual Earth (VE) is a comprehensive API for displaying and consuming detailed maps for just about anywhere in the world. It’s a location-based search utility that can be used to find restaurants, hotels, tourist attractions, museums, or just about anything. Unlike some of its slower, more cumbersome predecessors, VE maps are interactive, allowing the user to move about the imaged terrain with the simple click of a mouse. The map component exposed by VE uses flexible client scripting over unwieldy iterative postbacks, enabling the maps to be more responsive and resulting in an exciting user experience. With relatively little code, users can create web pages with robust, interactive images that can display road maps, satellite imagery, even close-up images of many of the worlds most populated cities. Virtual Earth comes packed with all kinds of cool features, each of which can be automated and expanded upon through the use of its powerful API. Each instance of the map control comes with a zoom slide control for zooming in or out of the images. Users can switch between map views and aerial views for road maps or satellite images, with the option of combining road labels directly to the satellite images. Want a closer look at Fifth Avenue in Manhattan or the Golden Gate Bridge? Switch to the available Bird’s Eye view option and jump from block to block. All of the basic images and controls are served directly from the Live Virtual Earth website, using AJAX technology to repost images directly to your client browser. Developers can also take advantage of some of the more advanced features available through the Virtual Earth API. Use the available Pushpin functions to allow users to mark positions on a map. Then, use the Route functions to connect them together and create driving directions with customizable line mapping. Use floating text areas to allow users to search for businesses by name, type, or category without needing to implement your own search methods. Add extra layers to the map for total customization, and completely submerge Virtual earth into your own application design. The Virtual Earth API is entirely client-based, relying mostly on script libraries available through the Virtual Earth website. Users begin developing with VE by first making a local reference to the script file in the web page as follows:
Developers can then display the map control, control the map’s location, and add or remove features using the extensive JavaScript object model. Below are some of the more frequently used objects available from the VE script libraries:
❑
VEMap
❑
VEShape
❑
VEFindResults
❑
VELatLong
❑
VERoute
31
Chapter 3: Overview of Windows Live SDKs Figure 3.2 shows a sample Windows Live page powered by Virtual Earth.
Figure 3-2
Live ID Windows Live is full of great features, yet without a ubiquitous identity you’re only getting a small part of the Live user experience. Windows Live ID is Microsoft’s next generation of single sign-on authentication. Using a single name or ID for all Windows Live services is tantamount to successfully embracing the Windows Live platform. Live ID is a fully integratable off-site authentication service that is simple to leverage and powerful to use. Aside from the obvious benefit of offloading the sign-on process and the maintenance of passwords, Live ID provides a user with an identity that spans multiple websites. By signing into one Live-powered application, users can navigate to other websites while preserving the state of their login. As I’ll discuss in other sections of this book, Windows Live ID is the glue that binds sites services together, ultimately helping administrators to better understand their business and traffic. Unlike other Live Services, Live ID doesn’t expose a dedicated set of API. Rather, it implements a pattern for Live ID authentication, giving developers a sort of roadmap for integrating the Live ID authentication process into their own applications. Figure 3.3 shows the Live ID authentication page.
32
Chapter 3: Overview of Windows Live SDKs
Figure 3-3
Live Expo One of two very powerful social-networking applications, Windows Live Expo is a free online marketplace where people can buy, sell, or offer just about anything you can think of. Live Expo is a public posting forum, where people can create themed listings for other people to view. Similar to other classified listing types of applications, Expo is nearly freeform; the types of postings people can submit are nearly limitless. Yet unlike many of the simpler classified postings sites, Windows Live Expo provides a number of tools that enhance each listing. Users can post photos, link to their websites, create communities of online Expo users, save commonly executed searches and more. The Live Expo API allows developers to integrate Expo postings directly into their applications. Using a handful of relatively simple SOAP interfaces, application designers can connect people with available postings, or allow their users to retrieve postings using different kinds of search criteria. The Live Expo API consists of a handful of public RPC methods callable via an XML SOAP interface. The following are some of the methods available to web developers: * GetCategories() * GetSites() * ListingsByCategoryKeywordLocations() * ListingsByCategoryKeywordLocations_V2() * ListingsByUser()
33
Chapter 3: Overview of Windows Live SDKs Figure 3.4 shows a sample Live Expo posting.
Figure 3-4
Live Spaces The second of two social networking applications, Windows Live Spaces lies at the heart of Microsoft’s content-driven and traffic-driven model. Spaces allows for users all over the web to create personal “spaces,” or home pages wherein they can broadcast themselves via public blogs, personal photos, personalized lists, and much more. Live Spaces continues a thriving trend of online applications that conform to what is commonly referred to as the “Web 2.0” standard. That is, an application that provides a loose front-end framework and lets the user provide the content and control the look and feel. Other poplar websites such as MySpace.com, Facebook.com, and LinkedIn.com use a similar model. However, Live Spaces takes this trend to the next level, allowing for users to add and remove functional modules to and from their spaces. Many of these modules are provided by Microsoft, while others can be developed as Windows Live gadgets by third-party sources. The result is a highly flexible online community that both safe and useful. The Live Spaces API expands on the social-networking trend. Using various URL-based interfaces application developers can integrate Live Spaces features into their own programs. Spaces content such as pictures and blogs can be retrieved directly, and user-to-user interaction can be incorporated using some of the emerging social-networking APIs. Figure 3.5 shows a sample Live Spaces page.
34
Chapter 3: Overview of Windows Live SDKs
Figure 3-5
The Spaces API consists of an XML over RPC platform for blogging, as well as a list of URL-based methods which expose different portions of Spaces accounts. The following represents a list of some of the XML-RPC methods of the MetaWeblog API, as well as various URL methods:
❑
newPost() — posts a new entry to a blog.
❑
editPost() — edits an existing entry on a blog.
❑
getPost() — returns a specific entry from a blog.
❑
getCategories() — returns the list of categories that have been used in the blog.
❑
getRecentPosts() — returns the most recent draft and non-draft blog posts in descending order by publish date.
❑
deletePost() — deletes a post from the blog.
❑
getUsersBlogs() — returns information about the user’s space.
❑
getUserInfo() — returns basic user information, such as name, email address, and userid.
❑
Add Module — adds a Spaces UI module to a Space.
❑
Add Gadget — adds an available Gadget to a Space.
❑
View Space — redirects a user to a given Spaces account via a user account ID.
❑
View Updated Spaces — returns an XML-formatted string containing a list of recently updated Spaces accounts.
35
Chapter 3: Overview of Windows Live SDKs ❑
Space Signup — redirects a non-authenticated user to the Spaces account creation wizard.
❑
View Settings — redirects the user to a specific account settings page based on a specific url.
❑
View Lists — allows navigation to the full page version of the lists module, which will list all of user’s lists.
❑
View Communication Preferences — redirects to the signed in user’s communication preferences page.
Live Messenger The last three chapters are more of an overview of three emerging services. The first of these. Live Messenger, is the next generation instant messaging platform by Microsoft. Known also as MSN Messenger (name to be changed to Live Messenger in the coming months), this new version allows users to communicate with people not only using existing versions of MSN Messenger but also using other popular IM tools such as Yahoo! Instant Messenger. Yet the Live Messenger API allows for much more than simple text messaging and exchange. Using the MSN Messenger Activity SDK, developers can create highly interactive mutli-user applications. Create file-sharing applications, video exchange systems, and even teleconferencing programs using the Live Messenger API. In addition, users can leverage existing MSN accounts already registered with Microsoft. As I’ll discuss later in this book, this gives developers a unique avenue of marketing unlike other Instant Messenger API. Developers create mini-applications running within Live Messenger, called Activities, which use a combination of client script libraries, web services, and DHTML to drive interaction and UI. Although there are a number of classes and methods available for creating a Live Messenger Activity, the main objects are:
❑
Messenger object — Represents a running instance of a Live Messenger client.
❑
User object — Object containing a set of properties that can provide information about the local user or the conversation starter (also known as the inviter).
❑
Users collection — A collection of objects that contains methods and properties for getting information about the participants in a conversation window.
❑
Channel object — Object containing properties, methods, and events for sending and receiving data and for interacting with the MSN Messenger Chat History window.
❑
Error object — Object containing properties for ascertaining the type of error that occurred and for retrieving a copy of the data that could not be sent.
❑
FileInfo object — Object containing properties for ascertaining the path, file name, size, progress, and status of a file transfer. A FileInfo object is created during a SendFile or File event.
Live Gadgets Gadgets, mini-applications that can be hosted from within a web page or gadget-hosting desktop environment, are new to the world of Windows, and at the time of this writing, are perhaps the most elusive of all of the Windows Live services. A gadget can be used as an interactive tool for displaying, retrieving, or capturing customizable content to or from Windows users. They can be used to show the current weather conditions in a user’s area, recent news clippings, traffic conditions, or even just a quote of the day. Part web component, part scripted application, gadgets live on your Windows Live.com home page, and can be added or removed by users as they see fit. There are currently three types of Windows gadgets that a developer can create: Windows Live Gadgets, which run on Live.com; Sidebar Gadgets, which run on Windows Vista Sidebar; and Sideshow Gadgets, which run on the auxiliary
36
Chapter 3: Overview of Windows Live SDKs display on some Windows Vista notebook computers. Since the latter two types of gadgets are not necessarily considered part of the Windows Live initiative at the time this book is being written, we will be concentrating on building the first of the three types. The Gadget API works a bit differently from other SDKs available for Windows Live services. To begin with, a gadget is designed to run within an existing framework that supports one or more gadget instances. Developers will essentially be creating components that act like robust applications but that do not have all of the control or events normally available to a full-fledged web page or client program. Rather, they work more like components, requiring various initialization steps that enable the host’s event model to effectively receive and retrieve information from the gadget once the page is running. Yet despite their component-like runtime model, gadgets are quite robust. Developers can use a gadget to deliver just about any type of content otherwise displayable within a fully controlled web page. The anatomy of a Live Gadget consists of three essential pieces:
1.
Gadget manifest — This XML file defines several properties of your gadget, including the location of your script file and an optional style sheet. The following gadget manifest template can also be found on the MSDN website:
Write a short description here.
CompanyName.TeamName.Feature.ExampleGadget
http://www.mydomain.com/Gadgets/ ExampleGadget/ExampleGadget.css
-->
-->
| Site Filter: | MSNBC.com CNN.com ArticleDashboard.com Other |
| Safe Search: | Strict Moderate Off |
| Results per page: | |
| City: | No Location (continued) 85 Chapter 4: Windows Live Search Default.aspx (continued) |
| SourceType: | Web News Ads InlineAnswers PhoneBook WordBreaker Spelling QueryLocation |
| Site Filter: | MSNBC.com CNN.com ArticleDashboard.com Other |
| Safe Search: | Strict Moderate Off |
| Results per page: | |
| City: | Philadelphia, PA New York, NY Washington DC San Francisco, CA Seattle, WA Chicago, IL Dallas, TX Miami, FL No Location |
| SourceType: | Web News Ads InlineAnswers PhoneBook WordBreaker Spelling QueryLocation |
| Site Filter: | MSNBC.com CNN.com ArticleDashboard.com Other |
| Safe Search: | Strict Moderate Off |
| Results per page: | |
| City: | Philadelphia, PA New York, NY Washington DC San Francisco, CA Seattle, WA Chicago, IL Dallas, TX Miami, FL No Location |
| SourceType: | Web News Ads InlineAnswers PhoneBook WordBreaker Spelling QueryLocation |
This code creates the simple page framework that will support the control panel. At the top of the page’s body is a static element containing the basic configuration choices. The first line allows a user to enter a fully qualified spaces account, such as “coragi.spaces.live.com”. Although the Spaces API provides a few different ways to indicate the account to be modified, this example will require the user to enter the account as .spaces.live.com. The next two lines display a drop-down menu containing the different configuration tasks to perform and a Submit button to render the appropriate corresponding to the selected task. As we explore the different APIs, we will add new elements with the task-appropriate fields and integrate them into the framework accordingly. The last line in the top panel contains a hidden field. We will use this field to hold the name of task panel we are working on, providing a means by which to enable to disable (or rather, set visibility and remove visibility) as different tasks are entered.
238
Chapter 8: Windows Live Spaces Next, we’ll need to add some simple scripting to change the task panel we’re looking at. In the
| My Spaces Control Panel | |
| Spaces account: | |
| Select the Spaces task to perform: | ------ Blog It Add a Module Get a Feed Add a Friend View Photo View Profile |
| |
Hello World http://www.microsoft.com
(continued)
289
Chapter 10: Windows Live Gadgets (continued)
en-us
http://localhost/Gadgets/Hello/HelloWorldGadget.js
tags are comments only.)
My First Web Page
335
Appendix A: HTML/DHTML Primer
HTML
| tag, which marks a cell within a row. Other commonly used elements are the and elements, used to define the number of columns in a table. There are also various important attributes used to control the manner in which rows and cells are displayed. The align and valign properties indicate which side of a cell components are rendered on, and the colspan property defines the number of columns a given cell can span. The following example displays the textbox and button components in the previous code in a table. My First Web Page 336 Appendix A: HTML/DHTML Primer HTML Advanced web page design often employs the element. This tag allows the designer to designate a physical region on the page with its own explicit styles and layout. regions are convenient for breaking a web page out into noncontiguous areas for better control over layout. elements combine well with the
Page Links It is very common for a web page to contain HTML links that navigate directly to other web pages. This type of navigation does not deliver any data from the page unless explicitly coded to do so, but it is not encumbered by the constraint of same-domain posting. Page links are implemented using the tag. The tag can contain other HTML elements and provide them with a navigatable click event. The HREF attribute of the link contains the instructions for the browser to execute when the link elements are clicked. This text can be client script, a reference to a scripted function in the page header, or most commonly, a URL indicating the next web page to load. The following code demonstrates how to create an image link with a click event that posts the browser to a new web page: Mixing HTML Elements The Internet is filled with HTML of all shapes and sizes, each with its own unique features and functions. Yet it is not the individual HTML elements that makes a web page unique, but rather the proper implementation of many different elements and patterns. The effective use of HTML requires an understanding of the subtleties of these interactions. A form post can submit an entire set of data fields to the server with little coding by the developer, while a hyperlink can call a JavaScript function that posts data to the server and navigates to a different page. Tables can carefully align your data into a tightly controlled grid, while nested areas allow you to move whole regions of the page dynamically. 338 Appendix A: HTML/DHTML Primer Applying a style to multiple elements can help distinguish your design, but setting styles for the entire applies your design uniformly with much less code. As you become more experienced with web page design, these combinations of elements and patterns will become more natural to implement. Below is a nonfunctional web page containing each of the elements mentioned in this section.
Cascading Style Sheets An important and sometimes overlooked facet of Dynamic HTML (DHTML) design is the Cascading Style Sheet. Cascading Style Sheets, or CSS, are documents that define global styles and patterns that can affect broad portions of your web application. They control many of the same elements and attributes available on the page level, yet the definitions and declarations made in the style sheet can be applied to elements in many (if not all) of an application’s web pages. Like HTML, CSS has moved through many 339 Appendix A: HTML/DHTML Primer different versions. The initial releases were not widely accepted. It was quite a bit of time before comprehensive versions of CSS were ratified by the World Wide Web Consortium (W3C). Nevertheless, CSS has come to play an imperative role in advanced DHTML, providing an avenue for establishing global themes, style-based groupings, and application behavior. CSS design can get complicated, often requiring a good deal of DHTML knowledge. For more information about CSS, you should visit the CSS web page on the World Wide Web Consortium website at www.w3.org/Style/CSS. DHTML Primer Web pages nowadays are rarely made of static HTML. Most web surfers expect much more than billboard layouts, simple forms, and indexed lists of hyperlinks. They expect some flash, some finesse, some pizzazz. They want pages that are fully functional, responsive to their clicks and feature-rich. Web pages that can accommodate that kind of magic employ the use of Dynamic HTML. Dynamic HTML, known more commonly as DHTML, is not a simple toolkit a developer can reference to animate a page or pull data without a postback. It is a set of web design patterns that combine static HTML elements with commonly used programming techniques. DHTML pages can implement a wide array of features, including dynamic layouts and responsive UI, animations, as well as some non-UI-specific features, such as background posts and asynchronous processing. Understanding DHTML requires skill sets in both HTML design and client script programming. The Document Object Model Competent DHTML programmers must have a solid grasp on the Document Object Model. The Document Object Model, or DOM, is the programmatic construct used to define different parts of an HTML document. The DOM enables web designers to reference and access other components and elements within a running web page. Without it, client scripts would have no way to set properties on objects or dynamically extract data from fields. As its name suggests, DOM is a hierarchical mapping of page objects. At the top level exists the document object, a singleton point of reference to the page it self. Designers can call the document object to change the page layout, behavior, look and feel, or even the web site to which the browser is currently pointing. Client Scripting Client scripts are small portions of specialized code that complete or affect discreet web page tasks. Scripting can be done using a wide array of languages, including VBScript, PHP, Perl, and more. However, the most widely used client script language is JavaScript. JavaScript scripts are implemented within a web page using the
Once the function or functions have been defined in the page header, they are accessible to elements throughout the page. Client Script Functions Scripted functions are necessarily simple. This is especially true if you have any experience with C-based languages. Each function begins with the function keyword, then the name of the functions followed by a list of incoming parameters within parenthesis. This declaration is then followed by an opening brace “{” indicating the beginning of the function. When the function is completed, an end brace “}” is used, indicating the function’s terminus. The following example shows a function that receives two numbers, adds them together, and displays the result in a user-friendly popup message window: As mentioned in the previous sections, all scripted portions are contained with the
382 Appendix B: ASP.NET for Web Developers Figure B.4 shows an ASP.NET calendar control. Figure B-4 Login Another advanced control in the ASP.NET toolkit is the Login. New to ASP.NET 2.0, the Login encapsulates all of the requisite features of a simple authentication panel. It comes complete with Username and Password fields (the password is masked, of course), client validation controls, a submit button, and a host of server-side events and methods to easily hook the control into your security model. Server script: Automatically rendered client script: (continued) 383 Appendix B: ASP.NET for Web Developers (continued)
(continued) 385 Appendix B: ASP.NET for Web Developers (continued) Figure B.5 shows a sample ASP.NET login control. Figure B-5 Validators Not all web controls in ASP.NET are interactive. In addition to the myriad collection of components for design-interactive data binding, XML generation, reporting, and content-display, users can use Validators to ensure correct data entry. Validators are client-side script elements that check the data entered into a field (usually a textbox) for certain conditions. A Range Validator will check to see if data entered falls within a specified set of limits. A Required Field Validator will prohibit the user from skipping data entry altogether. A Regular Expression Validator will check the data for formatting that follows a prescribed pattern. Each Validator control performs its check when the user tabs out of a field (the Blur event) or when the page is about to be submitted. If a validation does not meet the intended criteria, the page post is stopped. In both the page submission and the blur event, the error message shows dynamically. 386 Appendix B: ASP.NET for Web Developers Enter your phone number here: You must enter a phone number before submitting That is NOT how you enter a US phone number! Figure B.6 shows a field using an ASP.NET RequiredFieldValidator. Figure B-6 Figure B.7 shows a field using an ASP.NET RangeValidator. Figure B-7 387 Appendix B: ASP.NET for Web Developers FileUpload The FileUpload control is a fantastic tool that allows the user to upload local files to your web server through an HTTP post. In previous version of ASP.NET, file uploading was accomplished using the older HTML equivalent and required some massaging of both client and server script to make it work effectively. Now, designers can drop the control in the page and the runtime renders the correct HTML elements and adjusts the page settings accordingly. On the server, developers can call the FileUpload.SaveAs method to begin the HTTP upload and save it to a directory on the server. The result is a Browse button on the client web page that renders a file search popup window, which allows users to navigate to a desired file, and the fully-qualified path of the selected file in the adjacent textbox. File uploading generally requires some changes to server security. Most versions of Windows, as well as most modern web servers don’t allow HTTP file posts from client connections. Note in the samples below the server-side script containing the FileUpload declaration, and the code-behind page code containing the call to the FileUpload.SaveAs method from the button’s server-side click event. Server script: Code behind: using System; using System.Web; namespace Appendix_B_proj { public partial class _Default : System.Web.UI.Page { protected void btnsubmit_Click(object sender, EventArgs e) { this.flupTest.SaveAs(@”C:\myfile”); } } } Figure B.8 shows a sample ASP.NET FileUpload control. 388 Appendix B: ASP.NET for Web Developers Figure B-8 Summar y ASP.NET is a web programming model that helps developers manage and effectively design tiered code. First released as Active Server Pages and known by its simpler moniker ASP (now commonly referred to as “Classic ASP”), ASP.NET is a combination of dynamic scripting and object-oriented design tenets applied to Internet programming. Although developers will find a great many useful classes available within the ASP.NET SDK, some of the more commonly used classes are Request, Response, Server, Session, Application, View Sate, and Context. Part of the power behind the ASP.NET design is the tightly controlled web event model. Most events can be hooked using server-side event handlers, with page-level events raised in the following order: init, load, control events, prerender, unload. In addition to page-level events, developers can enhance the control of their application using various public event handlers available through the ASP.NET Global.asax page. Some of these events 389 Appendix B: ASP.NET for Web Developers include Session Start, Session End, Application Start, Application End, Application BeginRequest, Application AuthenticateRequest, Application Error, and Control ItemDataBound. ASP.NET simplifies otherwise complicated UI design by providing built-in web controls. Web controls are server-side design components with complete sets of events, properties, and methods. When added to a web page, these controls are rendered dynamically in HTML/DHTML by the ASP.NET runtime. Some examples of these controls are buttons, textboxes, drop-down lists, listboxes, the Calendar control, the Login control, Validators, and the File Upload control. 390 C# . NET for Web Developers The term “.NET” (pronounced “dot net”) has a lot of different meanings. At a high level, it is Microsoft’s development platform for designing software and building applications targeting the Windows operating system. It is also a term used to define Microsoft’s server platform initiatives, representing a loose collection of server-based products that run distributed applications and support large, multi-tiered systems. .NET is a term also used to define the latest system runtime environment, enabling applications written in different languages to execute and behave similarly. In this section, we discuss how to build programs and design software using .NET languages and targeting the latest .NET runtime. .NET is unique to Microsoft development platforms, and is quite different from most development platforms for non-Windows operating systems. Unlike older, more traditional programming environments, .NET programs can be written in one of many different .NET-enabled languages. Developers familiar with languages such as Visual Basic, C++, Java, or even older mainframe languages such as COBOL can leverage their skills sets by building .NET programs using their language’s .NET equivalent. This helps to make the .NET learning curve a little less steep. Of course, understanding .NET programming goes well beyond the simple syntax of disparate languages. Modern software development requires programmers to have at least a cursory understanding of object-oriented programming patterns. Object orientation, or OO, can help you separate your code into tighter, reusable components. Although not every .NET program demands a strong degree of OO design, it is important for .NET programmers to be familiar with object-oriented concepts as consumption of the .NET SDK relies on them. In this section, we will review and discuss many aspects of .NET programming, along with the basic principles behind it. .NET Concepts .NET represents a dramatic shift in the way we think about software. More than just a series of libraries and APIs, the .NET framework is a collection of services that manage code development, compilation, and execution. Understanding some of the fundamental differences between .NET and previous Microsoft SDKs is the key to building well-designed, full-featured applications. Appendix C: C# .NET for Web Developers Multiple Languages One of the facets of .NET that make it unique is the ability to program in multiple languages. Traditional development platforms require a programmer to be familiar with a single language targeted at a limited compiler, which turned the code into platform-specific machine code. .NET works a bit differently. Rather than a single language and compiler, the .NET SDK comes equipped with multiple compilers, each for a different .NET-targeted language. Each compiler creates code targeted not for a specific platform, but rather for the .NET runtime environment. Because of this, programs can be crafted with modules and classes built in different languages. Here is a list of some of the available .NET languages: ❑ C# ❑ VB.NET ❑ J# ❑ C++ ❑ COBOL ❑ Python ❑ JScript ❑ PHP ❑ JCL ❑ Ruby Flexible Runtime Environment Equally as important as the language compilers is the .NET runtime environment. When building programs in .NET, compilers no longer turn modules of programming code into machine code. Rather, each compiler takes the .NET code and turns it into Microsoft Intermediary Language, or MSIL. MSIL is a commonly understood code base for the .NET runtime, and represents the midpoint in a program’s compilation lifecycle. Once a program has been compiled into MSIL, it is the job of the runtime environment to complete the code’s transformation into machine code when the program is initially executed. This is known as just-in-time compilation. This late compilation pattern allows .NET developers to essentially ignore the target machine on which their code will run, trusting only in the runtime environment itself to effectively translate the correct code. That kind of abstraction not only simplifies the development of desktop applications but also helps developers build applications that target other devices, such as servers and portable mobile devices. Garbage Collection Memory management has always been a burdensome task for application developers. Previous platforms required users to null out memory blocks used to maintain code state, which meant keeping constant track of variables, pointers, references, and instance objects. Failure to effectively manage your memory often leads to memory leaks. Large numbers of leaks over extended periods of time inevitably has a negative effect on both the running application and the machine on which it is executing. .NET alleviates the burden of memory management by implementing garbage collection. Garbage collection is an unobtrusive service that runs within the .NET runtime. It looks for unreachable object references and 392 Appendix C: C# .NET for Web Developers variables and automatically frees up their memory space for use by other applications. One should think of garbage collection as a low-priority thread that constantly runs in the background of your runtime environment. As long as .NET applications can execute on your machine, garbage collection will sweep up after them. The presence of garbage collection also changes the manner in which users implement their code. Since lower-level memory management is now handled by the runtime, direct access to memory blocks is not allowed. That means that coders cannot instantiate or reference objects or variables using pointers. Instead, all instances of objects are handled by way of an object reference, the .NET equivalent of the pointer. Many users of third and fourth generation languages are already quite used to coding without pointers. However, veterans of older languages such as C++ may have to adjust to a slightly more abstracted level of memory control. No More COM .NET replaces Microsoft’s previous platform development model known as the Component Object Model, or COM. COM has its roots in much older version of Windows programming. It, too, was designed to be (somewhat) language or platform independent. However, the level of skill set needed to properly model and control interchangeable components was necessarily high. In addition, the memory management portion was unpredictable, requiring coders at almost all levels to implement object and variable cleanup to be safe. COM applications have classes that share a single interface, which it used to invoke methods on one another. Since this level of interoperability was relatively low, various aspects of state had to remain isolated. This primarily manifested itself in the COM threading model, which often made it difficult to marshal data in between objects at runtime. Thankfully, the .NET platform replaces all of this. To be fair, .NET doesn’t really replace COM, but rather abstracts from it, providing a layer of management with which developers and users need not be concerned. COM libraries are quite prevalent throughout the Windows OS. Though many COM libraries are being redesigned completely in .NET, a good deal of the .NET SDK invokes COM objects and COM servers. However, what’s important to understand is that the runtime environment that sits on top of COM provides a much-needed level of indirection to help developers create multi-threaded, multifaceted applications without needing to understand the underpinnings of the core Windows framework. The .NET SDK still has not completely replaced all COM libraries. For this reason, .NET applications can utilize specialty wrapper classes known loosely as interop classes. Interop is an advanced concept that falls outside of the scope of this tutorial. However, developers interested in incorporating .NET into older VB/COM/ATL applications should familiarize themselves with these classes. Programming in C# C# is a relatively new language created by Microsoft for developing .NET applications. It is a C-based language, consisting of many of the same elements of syntax and flow control associated with the languages C and C++. However, unlike its pointer-laden predecessor, C# is a much cleaner language, filled with new features and containing simpler programming tenets to facilitate a shallower learning curve. Still, mastering C# takes plenty of time and experience. However, web designers and developers will find that understanding some of the key concepts can help when reading Microsoft code samples, especially those pertaining to Windows Live and ASP.NET. 393 Appendix C: C# .NET for Web Developers Types and Entities When it comes to delivering code, web developers don’t require as much design as straight C# programmers. After all, just about all web code is contained within a web page, its natural vehicle of delivery. Even though the same page-specific model is used in ASP.NET, all C# code is delivered within strongly defined templates of code called types. C# comes with a great many built-in types, some of which are basic values types, such as integers and characters; others are complex types built into external libraries in the .NET SDK. However, the power of an object-oriented language like C# is the ability to create new user-defined types. User-defined types can become a fairly in-depth topic when it comes to object-oriented design, so for the purposes of simplicity let’s just say that types manifest themselves most commonly in one of four C# items: classes, objects, structs, and interfaces. System-Defined Types The following is a list of simple .NET types, their full name in the .NET SDK, their sizes, and their descriptions. Keyword Size (Bytes) Description byte 1 8-bit value ranging from 0 to 255 (unsigned) sbyte 1 8-bit value ranging from -128 to 127 (signed) char 1 Unicode character bool 1 true or false short 2 16-bit value (signed) ushort 2 16-bit value (unsigned) int 4 32-bit value (signed) uint 4 32-bit value (unsigned) float 4 Single precision floating point value double 8 Double precision floating point value decimal 8 Fixed-precision number up to 28 digits past the decimal point. Does not undergo standard floating point number rounding. Requires an appended suffix of “m” long 8 64-bit value (signed) ulong 8 64-bit value (unsigned) object n/a Base type used for references of class instances string n/a An immutable sequence of Unicode characters 394 Appendix C: C# .NET for Web Developers User-Defined Types ❑ Classes — User-defined type definitions that can contain functions, properties, variables, and other user-defined types. Classes represent a blueprint for a type; many instances can be created from a single class definition. Classes are reference types — each instance is allocated to the heap. ❑ Objects — Individual instances of a class created by using the new keyword. Each object represents a single copy of a class, maintaining its own state separately from like copies of the same class. ❑ Structs — User-defined type definitions that can contain functions, properties, and variables. Similar to classes, structs can be instanced using the new keyword. However, structs cannot be inherited or derived from. Structs are value types — each instance is allocated on the stack. ❑ Interfaces — User-defined type containing definitions of function signatures, properties, and events without any implementation. Interfaces cannot be instantiated using the new keyword. They represent a binding contract for a type, defining a minimal set of rules for the type. Scope and Declaration Like all things programming, C# code requires declaration and a varying degree of scope. All C# code is compiled into classes. Classes represent a sort of blueprint for a user-defined type or entity. As classes are instanced using the new keyword, copies of the class are held in memory and are called objects. The new keyword can be used to create as many instances of a class a computer can handle. Thus, one class can become multiple instances or objects. Classes generally contain functions, properties, and variables. Web developers can think of functions and variables similarly to functions and variables on a web page. Once created, they can be invoked to set values and state, or to execute various tasks from different points in your code. C# applications can have multiple levels of scope. When working with C# for web applications, one should be familiar with these basic declaration keywords (known as modifiers.) ❑ Public — Used to declare a function, property, or variable that is accessible from any other calling or consuming object. ❑ Private — Used to declare a function, property, or variable accessible only from within the containing class or entity. Items with this declaration cannot be accessed from inheriting classes or other classes on the same assembly or library. ❑ Protected — Used to declare a function, property, or variable accessible only from within the containing entity or inheriting entities. Items with this declaration cannot be accessed or invoked from other entities on the same assembly or library. ❑ Static — Modifier that defines a method, property or variable as class-based only. Instances of the item cannot be created, and instances of the containing entity all share access to the same state of the item. ❑ Internal — Used to declare a function, property, or variable accessible from any calling or consuming object in the same assembly or library. Items with this declaration cannot be accessed by classes or objects on different entities or libraries. Internal scope is the default accessibility designation for items that are declared without an explicit modifier. ❑ Sealed — Modifier used to define a class as noninheritable. Classes declared with this keyword cannot be derived by other classes. 395 Appendix C: C# .NET for Web Developers ❑ Virtual — Modifier used to define a function or property as overridable. Classes inheriting from the declared item’s container classes can reimplement the item using the overrides keyword. ❑ Abstract — Modifier used to define a class, method, or property as requiring derived implementation. Classes inheriting from the declared item or declared item’s container must reimplement the item using the overrides keyword. ❑ Overrides — Modifier used to identify a method or property as one that is reimplementing a predefined abstract or virtual entity in the parent class. Properties, Delegates, and Events C# has a few interesting features that can help to make your code design more efficient and compact. Properties, for example, are a C#-specific implementation that facilitates class encapsulation. As a concept, encapsulated properties are not new to object-oriented design. Languages such as C++, Java, and Visual Basic have supported propertied patterns for some time. In these languages, developers would declare private variables and then expose them through public ally accessible functions. Yet their support was more of a well-known best practice, utilizing user-written accessor functions and contrived naming conventions. In C#, properties are more compact, consisting of a single definition with either a set block, a get block, or both. In this fashion, properties can be designed much more intuitively. Likewise, developers using popular IDEs such as Visual Studio .NET 2005 will notice that properties appear as single items in an autocomplete drop-down menu, rather than as two or more disparate methods connected to one another merely through their like naming conventions. The following example shows two property definitions, exposing two privately declared variables. Note that privately declared variables are often prefixed with a leading underscore, and that the keyword value used in the set blocks represents any value or state to be assigned to a property at runtime. private string _firstName; private string _lastName; public string FirstName { set { this._firstName = value; } get { return this._firstName; } } public string FirstName { set { this._lastName = value; } 396 Appendix C: C# .NET for Web Developers get { return this._lastName; } } Delegates are an entirely new item for those new to C# programming, and a powerful feature of the .NET SDK. Delegates are, for lack of a better description, strongly typed function pointers. They are object references that point to other methods and functions for the purpose of indirect method invocation. Programmers familiar with function pointers might remember that they are convenient vehicles for background processes and callback methods. The same holds true for delegates. As strongly typed entities, delegates can be declared and attached/associated with a method, then passed to other portions of code without loosing their initial function reference. Under the covers, all delegates hail from either the System.Delegate or System.MulticastDelegate classes. However, delegate types can be declared simply by using the delegate keyword. Each instance of one defines a method signature to which all methods in its invocation list must conform. A delegate declared as accepting two string parameters and returning an integer can only invoke methods with exactly the same signature. Designing applications for effective delegate use can be tricky. This is especially true when defining events. Events themselves receive a list of other delegates for iterative invocation. Thankfully, the .NET SDK comes with a handful of built-in delegates that correspond to commonly used events. The following two examples show how to create and consume a custom delegate, and how to handle a button’s click event using the .NET-provided delegate, respectively Example 1: using System; using System.Windows.Forms; namespace Appendix_C_proj { /// /// Delegate available for remotely invoking any method accepting a single /// string parameter and a void return /// /// name public delegate string HandlerForMyDelegateClass1(string name); /// /// This class contains methods which can be remotely invoked using the delegate /// declared above. /// public class MyDelegateClass { private string SpecialMethod(string myName) { //NOTE: this is another way to dynamically assemble strings in C# without // using the string + string notation. return String.Format(“Hello {0}, good to hear from you!”, myName); } (continued) 397 Appendix C: C# .NET for Web Developers (continued) public HandlerForMyDelegateClass1 GetSpecialMethodHandler() { HandlerForMyDelegateClass1 h = new HandlerForMyDelegateClass1 (SpecialMethod); return h; } } /// /// Consuming class that uses the delegate declared above to remotely invoke /// methods in MyDelegateclass1 /// public class MyDelegateClass2 { public MyDelegateClass2() { MyDelegateClass m = new MyDelegateClass(); HandlerForMyDelegateClass1 h1 = m.GetSpecialMethodHandler(); MessageBox.Show(h1.Invoke(“Jon Arking”)); } } } . Example 2: using using using using using System; System.ComponentModel; System.Drawing; System.Text; System.Windows.Forms; namespace Appendix_C_proj { public partial class Form1 : Form { Button myButton; /// /// Simple Form class that will display a button /// public Form1() { InitializeComponent(); //Button initialization - standard on most Windows //Forms applications. myButton = new Button(); this.myButton.Location = new System.Drawing.Point(86, 58); this.myButton.Name = “myButton”; 398 Appendix C: C# .NET for Web Developers this.myButton.Size = new System.Drawing.Size(75, 23); this.myButton.TabIndex = 0; this.myButton.Text = “MyButton”; this.myButton.UseVisualStyleBackColor = true; //Single instance of a .NET EventHanlder delegate. EventHanlders //have a signature accepting an object, an instance of EventArgs, //and a void return type System.EventHandler buttonHandler = new EventHandler (this.myButton_Click); //Attaches the EventHanlder instance pointing to myButton_Click() //to the button’s Click event this.myButton.Click += buttonHandler; } /// /// Button click handling method with a signature matching the /// EventHandler delegate /// /// /// private void myButton_Click(object sender, EventArgs e) { MessageBox.Show(“Button has been clicked!”); } } } Example 1 shows how a delegate can be created and passed indirectly to calling or consuming classes. In MyDelegateClass1, a private method labeled SpecialMethod is not accessible to objects outside of MyDelegateClass1 itself. To allow objects to call this method, another public function is declared, which creates a delegate pointing to SpecialMethod() and passes the delegate to the calling class. As a result, MyDelegateClass2 can raise the private method by calling the invoke method on the delegate class received. Example 2 consists mostly of Windows Forms code with only a small example of delegate usage. All of the Windows Forms controls and ASP.NET UI controls expose events to consuming classes. All events are handled using delegates in .NET, especially in C#. Other .NET languages, such as VB.NET, use different event-handling objects for events, but ultimately these types of verbose handlers evaluate to delegates at the MSIL level. As you can see, the System.EventHandler object is instantiated in a fashion similar to that of the HandlerForMyDelegateClass1 object in the first example. The delegate is then added to the Button.Click event, using the +=notation. Events can have multiple event handlers in its invocation list, all of which are called when the event is raised. Thus, the +=notation is ideal for increasing the list by one more delegate. Namespaces The term namespace refers to a scope of code or collection of items under a common grouping. Items within each namespace have a definition related to the group theme and each is unique among other items in the namespace. Thus, no two items can have the same name. The .NET development libraries 399 Appendix C: C# .NET for Web Developers are separated into separate .dll files called assemblies, each one pertaining to one or more specific namespaces. Also, a single namespace can span multiple assemblies. Each namespace contains types that you can use in your program such as classes, structures, enumerations, delegates, and interfaces. Each and every type in the .NET platform can be identified using it’s fully qualified name with the namespace: System.Web.UI.WebControls.Button System.Xml.XPath.XPathDocument Likewise, every method, property, or member of a type can be referenced using the type’s fully qualified name: System.Text.Encoding.UTF8.WebName.ToString(); Type declarations can be made within namespaces’ declarations as well, providing an avenue of type grouping for user-defined classes, structs, interfaces, delegates, and other types. namespace AppendixC_proj { public class MyNamespaceClass1 { private string _myVar; public string MyVariable { get { return _myVar; } } public void DoSomething() { } } public class MyNamespaceClass2 { private int _myVar; public int MyVariable { get { return _myVar; } } public void DoSomething() { } } 400 Appendix C: C# .NET for Web Developers delegate MyNamespaceClass1 SpecialHandler(string var1, string var2); namespace InnerGrouping { class MyInnerNamespaceClass { public MyInnerNamespaceClass() { } } } } You’ll notice in this sample that the classes MyNamespaceClass1 and MyNamespaceClass2, along with the delegate type SpecialHandler, are defined within the namespace AppendixC_proj. Therefore, the fully qualified names of these types are AppendixC_proj.MyNamespaceClass1, AppendixC_proj .MyNamespaceClass2, and AppendixC_proj.SpecialHandler. Namespaces can also be nested within one another. At the bottom of the sample above, there is another namespace declaration, aptly named InnerGrouping. Declared inside of it is a class named MyInnerNamespaceClass. Since the two namespaces are coupled, the fully qualified name of this inner class is AppendixC_proj.InnerGrouping.MyInnerNamespaceClass. Namespaces can make type declaration names very long and unwieldy to use. If coders had to fully qualify every type instance, most C# code would be overly bloated and very difficult to read. As a convenient shortcut, C# programmers can utilize the using keyword to properly scope one or more namespaces within a page. The using keyword should be placed at the top of the code page, referencing the particular namespace containing types to be used throughout the page. As a result, programmers need only call a type by its name within the namespace. There is no need to fully qualify the type name. using AppendixC_proj; public class NamespaceScope { public NamespaceScope() { MyNamespaceClass1 m = new MyNamespaceClass1(); } } The above example is based on the previous code block and implements the using keyword to properly scope AppendixC_proj. So, rather than declaring the type used in the constructor using the fully qualified name like this: AppendixC_proj.MyNamespaceClass1 m = new AppendixC_proj.MyNamespaceClass1();) the namespace portion of the declaration is already scoped, allowing the much simpler: MyNamespaceClass1 m = new MyNamespaceClass1(); 401 Appendix C: C# .NET for Web Developers As you become more proficient in C# code, you’ll find that you need to implement the using keyword quite often to slim down your syntax and make your pages simpler to follow. The using keyword can also be used for scoping type instances with controlled object lifetimes. The using keyword in these examples does not apply this functionality. Object-Oriented Concepts C# is a strongly object-oriented (OO) language. Using it effectively means understanding the tenets of object-oriented design and how they apply to modern software development. Object-oriented programming is in no way a new concept. Developed in the early 1990s and later embraced by third and fourth generation languages, OO programming has become the fundamental paradigm in which most modern, tiered software is designed. Some languages, such as C++, have supported advanced OO for many of its own generations. Developers familiar with Microsoft Foundation Classes, or MFC, have been working with a strongly object-oriented SDK for almost 15 years. Yet, later versions of OO platforms have incorporated some important and interesting enhancements to otherwise established patterns. These enhancements have made object-oriented programming simpler to understand and design with, while cleaning up much of the syntax in the process. To this end, C# leverages many (if not all) object-oriented concepts and has built them right into the language syntax itself. Classes and Objects If you’re a seasoned web developer unfamiliar with object-oriented design, classes and objects represent a cultural, as well as paradigmatic shift for you. Most web applications run within the context of a web page. The page itself represents the vehicle through which your code is executed. C# runs by an entirely different model. All code in C# lives within a class. A class represents a sort of blueprint for an entity to be created at runtime. Classes can have many of the same programmatic elements you may be used to seeing in web pages, including variables, functions, and events. Different elements within a class can have different levels of scope and accessibility. Some functions might be public to outside calls, while others might be visible to other elements within the containing class. Classes should not be thought of as web page equivalents, however. Whereas web pages inevitably host executing code, the class is simply a definition of a type. With the exception of static elements, no code defined in a class executes within the class itself. Once a class has been defined, objects can be made from it. Objects represent virtual live copies of a class at runtime called instances. Object instances of classes are created by declaring a variable of the classes type and then using the new keyword to instantiate it. Take a look at the class definition here: class MyFirstClass { private string _var1; private string _var2; public MyFirstClass() { } public string Variable1 { set { this._var1 = value; } 402 Appendix C: C# .NET for Web Developers get { return _var1; } } public string Variable2 { set { this._var2 = value; } get { return _var2; } } public DateTime GetDateAndTimeOfDay() { return DateTime.Now; } } This class definition is deceptively simple. It begins with the type naming, following the keyword class, indicating to the compiler that this is a type definition. At the top of the class are two privately declared strings, aptly named using the preceding underscore. Common naming conventions use a leading underscore or “_” when naming private, local variables. These variables are accessible only to functions and properties defined within the class. The next two blocks of code define public string properties with set and get accessors, exposing the two private variables. The coupling of public properties and private variables is an object-oriented pattern known as encapsulation. We’ll discuss this concept in the next few sections. Finally, you can see a single public method named GetDateAndTimeOfDay, which appropriately returns a C# DateTime object containing the date and time when the method is invoked. What’s needed now is a means to run the class. Unlike web pages, there is no default server that runs the page. Even if this were saved locally like an HTML file, there would be no way to execute the code without an instance of the object and an application entry point. class Program { static void Main(string[] args) { MyFirstClass mc = new MyFirstClass(); mc.Variable1 = “Any value”; mc.Variable2 = “Another value”; DateTime d = mc.GetTimeOfDay(); } } 403 Appendix C: C# .NET for Web Developers The class seen here is also its own type definition with one distinct difference from MyFirstClass. The Program class contains a single method named Main, which marks the application’s entry point. Main is a static function, meaning that the code contained within it can be executed without an instance of the containing class. Every application, be it Windows Form app, a web app, or even a simple command line app, must implement static void Main(), or an equivalent entry point, somewhere in its code to mark the beginning of execution. Most web applications handle static void Main implicitly and abstracted from web developers. A client application requires its implementation. Inheritance Inheritance is the act of deriving one class definition from another. A class that inherits from another class automatically receives, or has immediate access to, all properly scoped features of the class. That is, if a class A exposes three public (or accessible) functions, properties, or variables, class B inheriting from class A automatically receives these attributes. Consider the following example: class A { protected string _firstName; protected string _lastName; public DateTime GetTimeOfDay() { return DateTime.Now; } public int CalculateSomeNumbers(int x, int y) { return (x + y) * Math.Abs(x-y); } internal decimal Rate { get { } set { } } } class B : A { private string GetTimeStamp() { this.GetTimeOfDay().ToString(); } } In these two class declarations, class A contains a series of functions, variables, and properties all appropriately scoped for accessibility. Class B is declared with the syntax class B : A, indicating that B inherits directly from A. B has only a single private function, GetTimeStamp(), which calls the function GetTimeOfDay from the this keyword. A commonly used convention when defining an interface is to proceed the name with the letter “I”. The keyword is a convention employed for reflexive class referencing. A call to an attribute using this indicates a reference to an attribute within the same containing class or entity. 404 Appendix C: C# .NET for Web Developers There is no other object reference or definition of GetTimeOfDay() within B, as none is needed. Since B inherits from class A, all of the accessible definitions within the sample class can be called as if they were locally defined in B. Advanced OO design utilizes strong inheritance models for the purposes of code reuse and abstraction. Separating code into parent classes reduces the amount of code that needs to be rewritten in inheriting classes (also known and child classes). Also, if a particular task or function uses reusable code features but only needs to be invoked once in a while, separating that function into an inheriting child class will keep the more heavily used classes leaner by design. Encapsulation Object-oriented design places a great deal of emphasis on the separation of code and patterns. Proper separation of code can facilitate the insulation of signatures and variables in a manner that reduces external dependencies. This process of separation and insulation is known as encapsulation. As a pattern, a well-encapsulated class hides its internal objects variables, and functions, scoping each as private (or sometimes as protected). Another set of functions or accessors then exposes the appropriate number of these features to calling classes. This provides a level of indirection that allows for changes to the class’s design with minimal impact on consuming entities. This code sample demonstrates a poorly designed class with no encapsulation, and following it is a well-designed class utilizing proper encapsulating techniques: Poor encapsulation: class PoorEncapsulation { //local varaibles are public, accessible to external calling classes public string _firstName; public string _lastName; public bool _isFemale; public DateTime _dateOfBirth; public string GetInformation() { string gender = _isFemale==true?”she”:”he”; string retVal = string.Format(“This person’s name is {0}, {1}. {3} is {4} years old”, _lastName, _firstName, gender, CalculateAge().ToString()); return retVal; } //single method used by both the local Getinformation function as well as external calling classes public TimeSpan CalculateAge() { return DateTime.Now - _dateOfBirth; } } 405 Appendix C: C# .NET for Web Developers Proper encapsulation: class ProperEncapsulation { //private variables are not visible/accessible to calling classes private string _firstName; private string _lastName; private bool _isFemale; private DateTime _dateOfBirth; //public write-only properties that set the private variables directly public string FirstName { set { this._firstName = value; } } public string LastName { set { this._lastName = value; } } public bool IsFemale { set { this._isFemale = value; } } public DateTime DateOfBirth { set { this._dateOfBirth = value; } } //public property returning the age separately from the Calculate age function public double Age { get { return CalculateAge(); } } 406 Appendix C: C# .NET for Web Developers //private function to calculate age internally private double CalculateAge() { TimeSpan ts = DateTime.Now- _dateOfBirth; return ts.TotalDays / 365.25; } //public function to get consumed class information public string GetInformation() { string gender = _isFemale == true ? “she” : “he”; string retVal = string.Format(“This person’s name is {0}, {1}. {3} is {4} years old”, _lastName, _firstName, gender, CalculateAge().ToString()); return retVal; } Both classes in this example ostensibly do the same thing — they collect demographic information about a person and return a variable containing the information collected. In the first example, the variables and methods used by the function GetInformation() are accessible to both internal and external elements. If the design of the classes changes by, say, altering the names of the demographic variables, any class consuming those variables will throw an exception when run (more likely, they simply won’t compile). The second class does the same as the first, with extra properties to separate the setting of the variables from the consumption of them. Since calling classes only reference the public properties mapped to internal variables, any changes to the internals will require handling only within the containing class. To this end, encapsulation plays a very important role in software consumption and component design. Polymorphism and Abstraction Have you ever bought a special extension for your hose to set up a lawn sprinkler? Ever bought special hub caps for your car with different designs or cool, spinning rims? Or maybe you’re an iPod nut who loves to snap on different covers or cool extensions? All of these are great examples of polymorphism. Polymorphism is a big, fancy word that really translates to one simple concept: one interface, many uses. A polymorphic model defines a minimal set of functions or features that must be present in order to be considered a thing. What an object does after meeting those minimal definitions is entirely up to the designer. Consider the example of the hose and sprinkler. The hose itself is fundamentally simple. It delivers water from starting point A to endpoint B. At the end is usually a screw extension where one can snap on different types of nozzles. Once the nozzle snaps on, the hose doesn’t care what happens to the water. It can be sprayed, fanned out, turned into mist, and so on. Once the nozzle meets the hose’s minimal requirement of accommodating the screw-on connector, it can do just about anything. The screw-on extension is what we would call an interface. It defines a set of requirements that must be met in order to properly and effectively work with the hose. Nozzles are polymorphic by design. They implement the required interface for the hose and then do a great many different things. In object-oriented design, the same polymorphic patterns can apply. Consider a class, A, defining a function named AddEmployee(). The AddEmployee function accepts a certain type of class, specific in design, that interacts implicitly with the internals of class A. Although any external class can call AddEmployee(), the item passed in needs to meet certain minimum requirements in order to work effectively with class A. To handle this minimal definition, an interface X is defined by the designer of class A, containing the names and signatures of functions, properties, and objects required to work with class A’s internals. Class B’s designer can then define another class that implements interface X, and add any other features he/she wishes. Note the following example code: 407 Appendix C: C# .NET for Web Developers /// /// polymorphic interface defining the Worker type /// public interface IWorker { string WorkerName { get; } int WorkerID { get; } XmlDocument GetCredentials(); } /// /// class consuming instances of Worker types. /// class Employees { IList _employees; Hashtable _workerNames = new Hashtable(); public void AddWorker(IWorker w) { XmlDocument xdoc = w.GetCredentials(); //...do something with the worker here _workerNames.Add(“worker:” + w.WorkerID.ToString(), w.WorkerName); _employees.Add(w); } } The first portion defines an interface named IWorker. As mentioned earlier, a commonly used convention when defining an interface is to proceed the name with the letter “I.” The interface is the definition of a type. That is, to be of type IWorker, an object must implement the properties WorkerName, WorkerID, and the function GetCredentials(). The second portion demonstrates a class consuming the Worker type. It defines a function named AddWorker, which expects an instance of the Worker type and invokes the expected properties and methods accordingly. As in the hose example, once the Worker instance fulfills its obligations (i.e., provides the properties and functions expected), the calling class is unaware of whatever else the instance may or may not be capable of doing. Now, observe the next example, which shows a class of type IWorker: 408 Appendix C: C# .NET for Web Developers class SpecialWorker : IWorker { protected string _workerName; protected int _workerID; /// /// This function is a constructor - it is called as soon as the class /// is instantiated with the “new” keyword. /// public SpecialWorker() { //initialize class here } public string WorkerName { get { return this._workerName; } } public int WorkerID { get { return this._workerID; } } public XmlDocument GetCredentials() { XmlDocument creds = new XmlDocument(); ///Create XML containing worker info and credentials SendWorkerDataToWebService(); return creds; } private void SendWorkerDataToWebService() { //Do something else here...like call a web service and poost the worker’s data } } The class is declared using the colon-type notation (class SpecialWorker : IWorker), indicating inheritance or implantation of a type. In this case, the class Special Worker indicates to the compiler that it is of type IWorker and should thus be checked for IWorker-required items. The class implements the properties WorkerName and WorkerID, satisfying the first two requirements of the IWorker interface. The function GetCredentials() is also implemented. Yet notice that another function, 409 Appendix C: C# .NET for Web Developers SendWorkerDataToWebService(), is also defined in the same class. Moreover, when the GetCredentials() method is invoked, the SendWorkerDataToWebService() function is also called implicitly. This is our first example of polymorphism. The SpecialWorker class meets all of the minimal requirements to be considered an instance of type IWorker. Yet when consumed, this instance of IWorker not only returns the requested XMLDocument but also sends worker data to a web service located completely outside of the scope of either the calling or consuming class. The class Employees doesn’t care (or better put . . . doesn’t know) exactly what happens when the GetGredentials() function is called. As long as the IWorker definition is met, every instance of IWorker can operate completely differently from any others, while still being able to be consumed similarly by the Employees class. C# and the Web SDK Developers using C# for web development should familiarize themselves with types in the .NET web-related namespaces. Some of these classes were covered in Appendix B however, the .NET SDK provides a vast multitude of classes, structs, and namespaces which can be used to enhance web-enabled programs for more advanced features. The documentation for the following .NET namespaces is part of the MSDN online reference guide. System.Web The System.Web namespace supplies classes and interfaces that enable browser-server communication. This namespace includes the HttpRequest class, which provides extensive information about the current HTTP request; the HttpResponse class, which manages HTTP output to the client; and the HttpServerUtility class, which provides access to server-side utilities and processes. System.Web also includes classes for cookie manipulation, file transfer, exception information, and output cache control. System.Web.UI The System.Web.UI namespace provides classes and interfaces that allow you to create ASP.NET server controls and pages that will appear in your web applications as user interface elements. This namespace includes the Control class, which provides all server controls, whether they are HTML server controls, web server controls, or user controls, with a common set of functionalities. It also includes the Page class, which is generated automatically whenever a request is made for an .aspx file contained in your web application. You can inherit from both of these classes. Also included are classes that provide the server controls with data-binding functionality, the ability to save the view state of a given control or page, and parsing functionality for both programmable and literal controls. System.Web.UI.WebControls The System.Web.UI.WebControls namespace contains classes that allow you to create web server controls on a web page. Web server controls run on the server and include form controls such as buttons and textboxes. They also include special-purpose controls such as a calendar. Because web server controls run on the server, you can programmatically control these elements. Although web server controls are rendered as HTML, their object model does not necessarily reflect HTML syntax. 410 Appendix C: C# .NET for Web Developers The System.Web.UI.WebControls namespace contains classes that are rendered as HTML tags, such as the TextBox control and the ListBox control. The namespace also contains classes that are not rendered on the web page but support data operations, such as the SqlDataSource and ObjectDataSource classes. Other controls, such as the GridView and DetailsView controls, support data display and editing. The WebControl class serves as the base class for many of the classes in the System.Web.UI.WebControls namespace. System.Web.UI.HtmlControls The System.Web.UI.HtmlControls namespace contains classes that allow you to create HTML server controls on a Web Forms page. HTML server controls run on the server and map directly to standard HTML tags supported by most browsers. This allows you to programmatically control the HTML elements on a Web Forms page. System.Web.Services The System.Web.Services namespace consists of the classes that enable you to create XML web services using ASP.NET and XML web service clients. XML web services are applications that provide the ability to exchange messages in a loosely coupled environment, using standard protocols such as HTTP, XML, XSD, SOAP, and WSDL. XML web services enable the building of modular applications within and across companies in heterogeneous environments, making them interoperable with a broad variety of implementations, platforms, and devices. The SOAP-based XML messages of these applications can have well-defined (structured and typed), or loosely defined parts (using arbitrary XML). The ability of the messages to evolve over time without breaking the protocol is fundamental to the flexibility and robustness of XML web services as a building block for the future of the web. To get started creating XML web services using ASP.NET, look at the WebService class, which XML web services can derive from to get access to the ASP.NET intrinsics, and the WebMethodAttribute class, which must be placed on any method that you want to programmatically expose over the web. System.Web.Security The System.Web.Security namespace contains classes that are used to implement ASP.NET security in web server applications. The Membership class is used by ASP.NET applications to validate user credentials and manage user settings such as passwords and email addresses. The Roles class enables you to manage authorization for your application based on groups of users assigned to roles in the web application. Both the Membership class and the Roles class work with providers, classes that access your application’s data store to retrieve membership and role information. Membership and role information can be stored in a Microsoft SQL Server database using the SqlMembershipProvider and SqlRoleProvider classes, in an Active Directory using the ActiveDirectoryMembershipProvider and AuthorizationStoreRoleProvider classes, or in a custom data source using implementations of the MembershipProvider and RoleProvider classes. 411 Appendix C: C# .NET for Web Developers You configure ASP.NET membership by using the membership element (ASP.NET Settings Schema). When an application using membership is accessed, ASP.NET creates an instance of the Membership class that you can use to query membership information. Provider-specific implementations of the MembershipUser class contain information about the user accessing the page. You can create custom implementations of the MembershipUser class for your application. You configure ASP.NET roles by using the roleManager element (ASP.NET Settings Schema). ASP.NET creates an instance of the Roles class that contains information about the role membership of the current user. ASP.NET provides server controls that interact with the Membership class and the Roles class. The Login, CreateUserWizard, and ChangePassword controls work with the Membership class to simplify creating an authenticated web application, and the LoginView control uses role-specific templates to customize web pages for specific groups of users. System.Web.Mobile Microsoft ASP.NET provides three namespaces that are used to implement the runtime and design-time behavior of mobile components and controls. These namespaces include the fundamental interfaces and base classes for implementing attributes, classes, controls, and elements. Listed here are the namespaces in ASP.NET for mobile controls and the classes that constitute them: ❑ System.Web.Mobile — Core capabilities, authentication, and error-handling classes. See the MobileCapabilities and MobileFormsAuthentication classes. ❑ System.Web.UI.MobileControls — Core ASP.NET mobile control classes. See the IObjectListFieldCollection interface, ITemplateable interface, AdRotator class, and DeviceSpecific class for some examples of interfaces and classes. ❑ System.Web.UI.MobileControls.Adapters — Core adapter classes that you can implement to create adapters for targeted devices. System.NET.Mail Namespace The System.NET.Mail namespace contains classes used to send electronic mail to a Simple Mail Transfer Protocol (SMTP) server for delivery. The MailMessage class represents the content of a mail message. The SmtpClient class transmits email to the SMTP host that you designate for mail delivery. You can create mail attachments using the Attachment class. System.Data The System.Data namespace provides access to classes that represent the ADO.NET architecture. ADO.NET lets you build components that efficiently manage data from multiple data sources. In a disconnected environment such as the Internet, ADO.NET provides the tools to request, update, and reconcile data in multiple-tier systems. The ADO.NET architecture is also implemented in client applications, such as Windows Forms, or HTML pages created by ASP.NET. The centerpiece of the ADO.NET architecture is the DataSet class. Each DataSet can contain multiple DataTable objects, with each DataTable containing data from a single data source, such as SQL Server. 412 Appendix C: C# .NET for Web Developers Each DataTable contains a DataColumnCollection — a collection of DataColumn objects — that determines the schema of each DataTable. The DataType property determines the type of data held by the DataColumn. The ReadOnly and AllowDBNull properties let you further guarantee data integrity. The Expression property lets you construct calculated columns. If a DataTable participates in a parent/child relationship with another DataTable, the relationship is constructed by adding a DataRelation to the DataRelationCollection of a DataSet object. When such a relation is added, a UniqueConstraint and a ForeignKeyConstraint are both created automatically, according to the parameter settings for the constructor. The UniqueConstraint guarantees that values that are contained in a column are unique. The ForeignKeyConstraint determines what action will happen to the child row or column when a primary key value is changed or deleted. Using the System.Data.SqlClient namespace (the .NET Framework data provider for SQL Server), the System.Data.Odbc namespace (the.NET Framework data provider for ODBC), the System.Data .OleDb namespace (the.NET Framework data provider for OLE DB), or the System.Data .OracleClient namespace (the .NET Framework data provider for Oracle), you can access a data source to use together with a DataSet. Each .NET Framework data provider has a corresponding DataAdapter that you use as a bridge between a data source and a DataSet. System.IO The System.IO namespace contains types that allow reading from and writing to files and data streams and types that provide basic file and directory support. System.Net The System.Net namespace provides a simple programming interface for many of the protocols used on networks today. The WebRequest and WebResponse classes form the basis of what are called pluggable protocols, an implementation of network services that enables you to develop applications that use Internet resources without worrying about the specific details of the individual protocols. System.Xml The System.Xml namespace provides standards-based support for processing XML. The supported standards include: ❑ XML 1.0 — www.w3.org/TR/1998/REC-xml-19980210 — including DTD support ❑ XML namespaces — www.w3.org/TR/REC-xml-names — both stream level and DOM ❑ XSD schemas — www.w3.org/2001/XMLSchema ❑ XPath expressions — www.w3.org/TR/xpath ❑ XSLT transformations — www.w3.org/TR/xslt ❑ DOM Level 1 Core — www.w3.org/TR/REC-DOM-Level-1/ ❑ DOM Level 2 Core — www.w3.org/TR/DOM-Level-2/ 413 Appendix C: C# .NET for Web Developers Summar y The Microsoft .NET platform is a powerful, flexible environment for building Windows-based and distributed software applications. The .NET SDK supports many different languages and language compilers, all of which can be used to build applications that run in the .NET runtime environment (also known as the Common Language Runtime, or CLR). Programming in .NET is markedly different from previous Windows SDKs. Memory management is built into the runtime environment via the use of a process known as garbage collection. Garbage collection allows developers to effectively ignore memory management and cleanup within their code, putting the responsibility of cleanup on the runtime environment itself. The .NET SDK replaces, both conceptually and in many cases physically, older programming models and libraries. Where once there were multiple development models available for software development, such as COM, MFC, ActiveX, ATL, and Win32, there is now one unified development kit for all things Windows. C# is a powerful .NET programming language with a rich set of code-based features and tools, which help programmers develop advanced applications. C# is object-oriented; with it, developers can create classes, structs, enums, and types conforming to all manner of object-oriented design patterns. Features such as properties, delegates, and events facilitate advanced object-oriented design, while also helping to keep one’s code clean and readable. .NET uses namespaces to separate types into logical groupings. Namespaces can be contained within a single .NET library called an assembly, or can span multiple assemblies for effective splitting of the group. An assembly can contain a single namespace or many namespaces at the same level or nested within one another. Namespaces are used as a naming convention for otherwise like-named types, wherein the fully qualified name with a leading namespace name properly identifies the entity. The using keyword can be used to scope a namespace to a page of C# code. Object-oriented patterns play an important role in .NET development. Many built-in .NET types require an inherent understanding of object-orientation to make use of their features. Principles such as inheritance, encapsulation, and polymorphism can be powerful allies when designing software using C#. Although there are a great many namespaces available in the .NET SDK, some of them lend themselves particularly well to web development. Namespaces such as System.Web, System.Web.UI, System .Web.Security, and System.Data are worth understanding before endeavoring to build large .NET web applications. 414 Index Index Symbols and Numbers & (ampersand) operator, 78 ⫹ (plus) operator, 78 (pipes) operator, 78 ⫺ (minus) operator, 78 " (quotes) operator, 78 ( ) (parentheses) operator, 78 3D images, Virtual Earth, 147–150 A tags, HTML, 338 Abstract keyword, C#, 396 abstraction, C#, 407–410 accounts Live Expo profiles, 193–194 personalization of Live ID accounts, 159–160 Action values, Live ID, 159 Active X controls, 280 activities, Live Messenger Activity API classes, 267–270 creating sample activities, 271 elements, 272–274 overview of, 265 running sample activity, 274–276 setting up for writing, 270–271 adCenter, Microsoft, 9 AddAPushPin, Virtual Earth, 123–126 Add-In API, Live Messenger, 266 AddUser method, Custom Domains, 303 administering Custom Domains, 319 administrators login as, 319–321 use of Custom Domains, 302 advanced Live Search queries, 77–78 advanced Virtual Earth features, 143–147 aerial view, 114 AES, 178 agents, Live Messenger, 265–266 AJAX (Asynchronous JavaScript and XML) defined, 22–23 invoking APIs and, 242 Live Search web page, 79 Virtual Earth and, 109 altKey property, MapEvent object, 128 AND operator, 78 APIs (application programming interfaces) AJAX for invoking, 245–247 Gadget API, 295 Live Expo, 201 Live Messenger, 264–265 Live Messenger Activities, 267–270 Live Messenger Add-in, 266 Live Search, 45–50 Live Spaces, 295 Live Spaces general, 243–245 Live Spaces photo, 247–248 Live Spaces profile, 248–257 Live Spaces social networking, 245–247 MetaWeblog, 239–240 Windows Live, 7–9 Appctx value, Live ID, 159 Appearance category, Live Spaces profile, 229–230 AppID property, SearchRequest object, 46 AppID property, SearchRequest object, 51 Appid value, src attribute, 158 applets, Live Gadgets compared with, 280 Application class overview of, 361–362 public properties and methods, 362–364 application key, for Expo API, 201 application name, registering websites with Live ID, 157, 160 application programming interfaces. see APIs (application programming interfaces) ASP.NET ASP.NET AJAX and, 22–23, 79 Application class, 361–362 Application class, public properties and methods of, 362–364 buttons, 377 calendar control, 379–383 Context class, 367–369 Context class, public properties and method, 370–372 defined, 21 drop-down lists, 378–379 event model, 372–374 file upload control, 388–389 list boxes, 379 Live Expo project, 201–206 Live ID project. see Windows Live ID, ASP.NET project login control, 383–386 objects, 348 overview of, 347 Request class, public properties and methods, 352–355 Request object, 348–351 Response object, 351–352 Server class, 355 Server class, public properties and methods, 357–358 server-side events, 375–376 Session class, 359 Session class, public properties and methods, 360–361 summary, 389–390 textboxes, 378 User Control and Web Control, 280 validators, 386–387 ViewState class, 364–366 ViewState class, public properties and method of, 366–367 Web controls and components, 376–377 assemblies, 400 Asynchronous JavaScript and XML. see AJAX (Asynchronous JavaScript and XML) authentication Custom Domains features, 300 Live ID. see Windows Live ID Authentication class, Live ID, 172–173 AuthLite.cs example, 181–189 416 B Berners-Lee, Tim, 333 binding element, 290 BlogIt method, 240–243 building control panel example for Live Spaces, 241–243 overview of, 240 parameters for, 241 blogs BlogIt method, 240–243 history of, 5 Live Spaces, 231–232 MetaWeblog API, 239–240 Body, 18 element, HTML, 334–335 brand awareness, 10 business model, Windows Live, 9–10 businesses, finding, 131–132 button controls, ASP.NET, 377 C C language, 393 C# adding C# class to Live ID project, 164 classes and objects, 402–404 creating C# project that calls Custom Domain web service methods, 318 encapsulation, 405–407 inheritance, 404–405 object orientation, 402 overview of, 393 polymorphism and abstraction, 407–410 properties, delegates, and events, 396–399 scope and declaration, 395–396 types and entities, 394–395 C#.NET classes and objects, 402–404 COM replaced by .NET, 393 encapsulation, 405–407 flexibility of .NET runtime environment, 392 garbage collection in .NET, 392–393 inheritance, 404–405 multiple language support in .NET, 392 namespaces, 399–402 .NET concepts, 391 .NET web-related namespaces, 410–413 object orientation, 402 overview of, 391 polymorphism and abstraction, 407–410 programming in C#, 393 properties, delegates, and events in C#, 396–399 scope and declaration in C#, 395–396 summary, 410–413 types and entities in C#, 394–395 C++ C# compared with, 393 object orientation, 402 caching, disabling browser caching, 287–288 calendar control, ASP.NET, 379–383 callbacks multiple location searches, 137–138 Virtual Earth searches, 132 Cassini, Live Gadgets and, 281 categories, Live Expo, 208 cell properties, HTML tables, 336 CERN (European Organization for Nuclear Research), 333 channel objects, Live Messenger, 267–270 events, 267–268 methods, 268 properties, 268–269 Chat, messaging tool, 262–263 cID, Live ID user identification, 159, 328 class keyword, 403 classes encapsulation, 405–407 inheritance, 404–405 instances of, 402 Live Search, 30, 46–47 overview of, 402–404 polymorphism and abstraction, 407–410 proxy classes, 56, 207–208 click events, map controls, 121 client scripts DHTML and, 340–342 scripted functions, 342 Web-based language services, 19–21 client software, 2 clients, Live Messenger location of, 271 overview of, 262–264 clients, Live Search, 50 client-side solutions, Live Gadgets, 280 clientX, MapEvent object properties, 128 clientY, MapEvent object properties, 128 Codeplex.com, Live-in-a-Box startup ket from, 270 tag, HTML, 336 tag, HTML, 336 column properties, HTML tables, 336 COM (Component Object Model), 393 command line utility, web proxy classes, 56 communication, Live Messenger for, 262 communities, Live Expo, 195 Component Object Model (COM), 393 Console Application exploring code, 56–64 Live Search sample, 52–56 Contact Info category, Live Spaces, 229–230 contacts, storing in Live Messenger, 263 Contains: keyword, 78 Context class overview of, 367–369 public properties and methods, 370–372 context value, src attribute, 158 control panel example, Live Spaces blogs in, 239–243 creating base framework for, 237–239 cookies, Clearcookie action in Live ID, 159 Count, SourceRequest object properties, 47 crawlers, 44–45 CreateMember method, Custom Domains, 306–307, 322 createResults, Virtual Earth searching, 132 credentials, centralized storage in Live ID, 180 CRM (customer relationship management), 10 cross-domain data access, enabling, 286–287 cryptography, Live ID, 175–178 CSS (Cascading Style Sheets) role in DHTML, 339–340 style value compared with, 158 ctrlKey property, MapEvent object, 128 CultureInfo Console Application sample, 58–59 defined, 46 WinForm application sample, 71–72 Custom Domains adding users, 321–322 administering, 319 417 Index Custom Domains Custom Domains (continued) Custom Domains (continued) code for, 324–327 creating C# project that calls Custom Domain web service methods, 318 defined, 26 enumerating domains, 323 how it works, 302 integrated with Live ID, 38–39, 189, 327–328 integrating, 316–317 listing registered domain members, 323 logging in as administrator, 319–321 methods in SDK 1.0, 303–306 methods in SDK 2.0, 306–312 open membership, 302 overview of, 299 personalization and, 328–330 retrieving member count for a domain, 323 retrieving member information, 324 SDK, 38–39 service features and details, 301 setting up, 313–316 summary, 331 what they are, 299–300 Windows Live ID and, 189 custom tiles, Virtual Earth, 146–147 customer acquisition, 10 customer relationship management (CRM), 10 D declaration, C#, 395–396 default disambiguation parameter, Virtual Earth searching, 132 Default.aspx, web page implementation, 82–91 Default.aspx.cs, web page implementation, 91–94 delegates, C#, 396–399 DeleteMember method, Custom Domains, 307 DeleteUser method, Custom Domains, 304 development, Windows Live, 10–11 development models, Live Messenger, 265 development process, Live Messenger, 270 418 DHTML (Dynamic HTML) client scripting, 340–342 CSS and, 339–340 DOM and, 340 events, 343–344 overview of, 340 scripted functions, 342 services, 19–21 summary, 345 direct monetization, 9 directions, getting with Virtual Earth, 138–143 DisableHostCollapsing, SearchRequest object properties, 71 DisableSpellCorrectForSpecialWords, SearchRequest object properties, 71 element, HTML, 337 .dll files, 400 DOM (Document Object Language), 340 domains custom. see Custom Domains purchasing, 300 registering domain names, 313–315 double click events, map controls, 121 downloading, Live Search samples, 50–51 drawing on maps, Virtual Earth, 143–146 drop-down lists, ASP.NET controls, 378–379 Dynamic HTML. see DHTML (Dynamic HTML) E elementID property, MapEvent object, 128 e-mail, Custom Domains, 300 encapsulation C#, 405–407 defined, 403 ENCRYPTION keyword, Live ID, 173 encryption/decryption, Live ID, 175–178 entities, .NET, 394–395 EnumDomains, Custom Domain methods, 305, 323 enumerating domains, Custom Domains, 323 EnumMembers, Custom Domain methods, 307–308, 323 EnumUsers, Custom Domain methods, 304 Envelope, 18 error object, Messenger Activity, 269 European Organization for Nuclear Research (CERN), 333 event model, ASP.NET, 372–374 eventName property, MapEvent object, 128 events C#, 396–399 DHTML, 343–344 EvictSquatter, Custom Domain methods, 305 EvictUnmanagedMember, Custom Domain methods, 308 Excel, Microsoft, 2 executeQuery function, 66 expo.org, 191 Extensible HTML (XHTML), 333 Extensible Markup Language. see XML (Extensible Markup Language) F Facebook.com, 228 Feed: keyword, 78 file info object, Messenger Activity, 269 file upload control, ASP.NET, 388–389 FileType property, SourceRequest object, 47, 68 filters request assembly, 67 SearchTags, 68 Find method by location, 132–135 locations, businesses, and landmarks, 131–132 multiple location search results, 137–138 nearby, 135–137 findType, Virtual Earth, 131 Flags SearchRequest object properties, 46 WinForm application sample, 71 element, HTML overview of, 335 for postbacks, 337–338 friends, Live Spaces, 233, 245 functions, scripted, 342 G Gadget SDK downloading, 282–283 overview, 36–38 gadgets. see also Windows Live Gadgets API for adding to Live Spaces, 243 defined, 26 Web-based language services, 19–21 garbage collection, .NET, 392–393 general APIs, Live Spaces, 243–245 GetCategories( ), Live Expo, 196, 209–211 GetDirections function, 138–143 GetDomainInfo, Custom Domain methods, 311–312 GetDomainState, Custom Domain methods, 306 GetListings( ), Live Expo, 211–214 GetLoginDataTemplate, Custom Domain methods, 303 GetLoginUrl, Custom Domain methods, 303, 318 GetMemberCount, Custom Domain methods, 308, 323 GetMemberInfo, Custom Domain methods, 308–309, 324 GetMemberNameState, Custom Domain methods, 309, 321–322 GetRoute method, 138–143 GetSites( ), Live Expo methods, 196–197 GetUserCount, Custom Domain methods, 304 GetUserState, Custom Domain methods, 304 Google, 5–6 guestbook, Live Spaces, 232 H Hailstorm, MSN history, 4 handling results, WinForm application, 72–77 Hash algorithms, Live ID, 173 element, HTML, 334 Headers, 18 Hotmail Custom Domains and, 38 MSN history, 3 HREF attribute, HTML, 338 419 Index HREF attribute, HTML HTML (Hypertext Markup Language) HTML (Hypertext Markup Language) element, 334–335 element, 337 events, 343–344 element, 335 element, 334 mixing elements, 338–339 navigation and postbacks, 337 overview of, 333–334 page links, 338 postback using elements, 337–338 primer, 150 summary, 345
|