Why you need technical consultants involved in the sales process

David Meego - Click for blog homepageWhen I worked in the partner channel, I decided it was very wise to have a technical consultant present in all sales meetings.

Or better still make sure that your sales consultant has a technical background with the application.

At least then you are less likely to end up with the problem where the sales consultant has oversold what the application can do or what customisations are possible.

Many people in the Dexterity Development world know me for my work as a pioneer of Cross Dictionary Dexterity Development. The driving force behind the development of the techniques involved was over selling of customisations.

 

Recently, this video was released which shows the commercial pressures placed on the technical expert.

The Expert (Short Comedy Sketch) (Direct Link)

(Please visit the site to view this video)

 

Enjoy

David

ENTERPRISE RESOURCE PLANNING – April 2014 Readiness Update

Save the date for Convergence 2014 Europe: November 4-6, Barcelona

Join other members of the Microsoft business community to network, learn, and meet with industry experts. You’ll also get to see how opportunity and innovation meet to deliver real business value. Save the date on your calendar for this upcoming Convergence and visit the event website for more details. Questions?  Contact MBS Events Inbox.

Microsoft Dynamics will be at WPC 2014

Microsoft Dynamics will be part of this year’s Worldwide Partner Conference coming up in Washington, DC July 13-17, 2014. Build credibility and strengthen the Microsoft Dynamics partner channel, share best practices, and choose to attend Dynamics-focused sessions. Visit the WPC event website for more details. Questions around the Microsoft Dynamics presence at WPC 2014? Visit PartnerSource or email the MBS Events Inbox.

Microsoft Dynamics AX 2012 R3 readiness and launch portal

Get ready for the upcoming Microsoft Dynamics AX 2012 R3 release. There is a vast amount of new readiness content now available, including Getting Ready Guides and preview session recordings; more content continues to be added as the release draws near. 

.NET Native Performance

This post was authored by Xy Ziemba, the Program Manager for .NET Native performance, and Andrew Pardoe, Program Manager on the .NET runtime team.

In our previous blog post introducing .NET Native, we talked about how .NET Native gives you the performance of C++ with the productivity of C#. Putting that in quantitative terms, Windows Store apps compiled with .NET Native start up to 60% faster and use up to 25% less reference set compared to when the apps are compiled with NGen. This means your users get into your app even faster after a tile tap!

While developing .NET Native, we made a number of design choices to allow for better optimization and a refactored .NET stack. Let’s go through some of those choices and how they allow Store apps to perform better on .NET Native.

Optimized Runtime

The .NET Native runtime (MRT) is a refactored CLR tuned and optimized for static compilation. It still includes all the core features including type safety and automatic memory management (yes, even with static compilation!) We even moved non-core runtime features into the compilation tool chain and libraries so that you only have the runtime functionality that you use in your app. The end result is that Store apps get a substantial performance boost.

Optimized and Converged Libraries

The framework libraries shipped with .NET Native Preview are also refactored and layered, which allows us to separate out the library code that our program uses from the parts that it doesn’t. Whereas the .NET that ships in Windows includes libraries for many scenarios, a .NET Native app only links against the smaller library contracts that it needs. Removing code that isn’t used for the scenarios .NET Native targets—currently Windows Store apps—improves both app speed and memory footprint.

Unused Code Removal

The .NET Native compiler analyzes your app at multiple stages for all code that can be removed—even parts of library contracts. This gives your app a smaller memory footprint too because every memory page loaded by the operating system has a higher density of useful code.

Whole Program Optimization

After linking your app with both framework library code and library code included with your app package, the Microsoft C++ optimizer does global analysis of your app and optimizes the whole program as a single unit. This means that apps get better inlining of function calls and optimizations performed across the whole program scope. The C++ optimizer writes the app executable to disk with its functions arranged so that Windows can load the program as quickly as possible!

Better and Faster Windows Runtime Interop

In .NET Native, all interop code is generated at compile time and linked into the app itself. This removes the need for the app to read Windows Runtime metadata, create marshaling stubs, and JIT code when making an interop call. Also, the compiler is able to analyze and optimize these stubs at compile time. All this makes calling your favorite Windows API faster!

Pregenerated Serializers

Similar to what’s done with interop code, .NET Native generates serialization code during compile time, instead of at runtime, when you use a serializer provided by .NET Framework. This shaves off CPU cycles when your app first deserializes an object. This directly translates to faster app startup because most apps deserialize state information at launch.

Pay-for-Play Reflection

.NET reflection is a powerful tool but it requires metadata about the types you want to inspect. All the app and framework metadata is kept around in .NET Framework that ships in Windows. In .NET Native, the app developer controls how much metadata is kept in the app. Our compiler keeps the metadata used by your code, but removes most of the metadata for the .NET Framework code. Using Runtime Directives, you can fine-tune our compiler’s choices by specifying what types and members your app reflects on. Our default improves memory density of .NET Native code over Desktop .NET code, but you can push this further by customizing your Runtime Directives. We’ll talk a lot more about these directives in a set up upcoming blog posts.

Try It Out

We really want you to try .NET Native on your apps. The current preview only supports Windows Store apps written in C# and running on x64 or ARM machines, but we’re hard at work adding support for other scenarios.

Download the tools at http://aka.ms/dotnetnative and measure your app’s performance. We would love to hear what kind of performance improvements* you see. Shoot us an email at dotnetnative@microsoft.com.

*If you don’t see performance improvements, we really want to hear from you. We want to investigate what’s going on and fix it.

Quick news: Microsoft Press wins awards at international competition of STC

You all might remember that back in the winter, a handful of our books were recognized by the Puget Sound chapter of the Society for Technical Communications. (See blog post http://blogs.msdn.com/b/microsoft_press/archive/2014/01/22/quick-news-microsoft-press-picks-up-six-awards-at-last-night-s-stc-ceremony.aspx.)

Today, we’re happy to announce that three of those books were sent to the international judges and have received recognition at the top level of competition. Here are the winners. Congratulations to the authors and editors who produced these high-quality books.

Award of Excellence

STC’s description: An entry that wins an Award of Excellence consistently meets high standards in all areas. The entry might contain a single major flaw or a few minor flaws. The entry demonstrates an exceptional understanding of technical communication principles.

cover for CLR via C# 4th Edition

CLR via C#, Fourth Edition

Author: Jeffrey Richter

Editors: Devon Musgrave, Carol Dillingham

cover for Software Requirements 3rd Edition

Software Requirements, Third Edition

Authors: Karl Wiegers, Joy Beatty

Editors: Devon Musgrave, Carol Dillingham


Award of Merit

STC description: An entry that wins a Merit Award consistently meets high standards in most areas. The entry might contain a small number of major or minor flaws, but it still applies technical communication principles in a highly proficient manner.

cover for Windows 8 Plain and Simple

Windows 8 Plain & Simple

Author: Nancy Muir

Editor: Kenyon Brown

Version 9.04.0013 of the RML Utilities for x86 and x64 has been released to the download center

 

clip_image001 

clip_image002

 

 

X64: http://download.microsoft.com/download/0/a/4/0a41538e-2d57-40ff-ae85-ec4459f7cdaa/RMLSetup_AMD64.msi

X86: http://download.microsoft.com/download/4/6/a/46a3217e-f523-4cc6-96e9-df73dd0fdd04/RMLSetup_X86.msi

 

This build encompasses previous features, fixes and enhancements designed from recent case work. 

 

·         SQL Server 2014 compliant

·         SQL Server 2012 and 2014 XEL input to ReadTrace compliant (sample .XEL capture script shipped with help documentation) no need for .TRC anymore. (PSSDiag updates align with XEL capabilities as well)

·         Microsoft Azure SQL Server Database (formally WASD) connectivity compliant

·         OStress true replay of MARS connections

·         Addition of client (OStress Expressions) allowing client side Sleep, Repeats, Identity and Guid generation to craft additional scenarios

·         Tuned for larger memory and cpu systems

·         Updated compression libraries for formats such as RAR5

·         Enhanced TVP capabilities

·         Custom CLR Expression capabilities

·         Additional filtering options

·         Workarounds for some .XEL capture bugs such as invalid packet size captured in Existing Connection events

·         … and more …

Bing Translator Plugin for WordPress Enables Webmasters and Developers to Localize Site Content

Microsoft Open Technologies, Inc. has released a new Bing Translator plugin that lets you apply the power of Bing Translator to any WordPress site running version 3.8 or later.

Using the plugin, visitors can translate a site into any of the 40+ supported languages in one click without leaving the page once this light-weight, cross-browser plugin is installed. This plugin also provides options for a setting a color scheme, as well as an option to allow visitors to suggest translations.

The Bing Translator plugin should be installed from within the WordPress Dashboard by clicking on Plugins >Add New and search for “Bing Translator” and works on any WordPress site. A site developer can also manually install the plugin by downloading it from WordPress.org, then adding the “bing-translator” folder in the “/wp-content/plugins/” directory.

Using Bing Translator Plugin for WordPress Video

More Links to Get Started

Congratulations to Microsoft Open Technologies, Inc team for their great work on the Bing Translator Plugin for WordPress! 

Using Office 365 APIs in your MVC and Windows 8.1 Applications – Part II

In last month’s blog post, we announced the Office 365 API Tools – Preview add-in for Visual Studio 2013. By using Office 365 APIs, developers can access users’ data in the Office 365 cloud, e.g., reading calendar information, storing documents, or sending emails on behalf of users. The Office 365 APIs are an open platform that is available across a variety of languages and technologies. If you’re developing Model-View-Controller (MVC) web projects or Windows 8.1 applications, our Office 365 API Tools for Visual Studio will make it that much easier to add Office 365 APIs to your solution.

The previous post focused on getting started with the tooling and the Office 365 APIs – going through the registration piece and exploring the sample code. This post continues from where the previous post left off, going from using the generated sample code to authoring your own. If you haven’t already done so, I highly recommend reading the previous post before continuing with this one.

Note A couple of weeks ago (April 7, 2014), we released an updated (1.1) version of the Office 365 API Tools – Preview, which offers some reliability improvements to the tool, along with some slightly modified sample code (particularly in relation to SharePoint). Today’s blog post assumes you are using the latest version of the tools and the accompanying samples.

Recap of the Project Structure

In last month’s blog post, we took a look at the files that are added by the Office 365 API Tooling. If you have not already, I would encourage you to read the “Exploring the project structure” section of that post – including the diagrams that show which files are added to the MVC Web Application and the Windows 8.1 app. In a nutshell, after registering an app with the Azure Active Directory, the Office 365 API Tools make the following modifications to a project:

  • Add NuGet packages for Active Directory Authentication Library and Json.NET.
  • Add a set of common helper files (files whose names start with “Office365*,” such as “Office365ServiceInfo”) that are common across different services.
  • Add a set of service-specific sample files (for example, ExchangeSampleController and its accompanying View folder for MVC, or ExchangeSamplePage.xaml and its accompanying code-behind for Windows 8.1).
  • Modify Web.config or App.xaml to include the Client ID (and, in the case of web apps, the Password) for the app.

The NuGet additions and the Web.config/App.xaml modifications are fairly straightforward, so in terms of new files added to the project, we’re left with the helper files and the service-specific sample files. The helper files are designed to be fairly transparent to the developer, as they encapsulate functionality that you shouldn’t need to worry about. The one exception is error-handling, where you may want to customize the experience by customizing the UI or writing the errors to a log or database. We’ve left a TODO flag in the Office365Helper and Office365CommonController files to make it clear where such error-handling logic should be implemented. For the rest of the helper-class implementations, you can treat those files as library files and generally avoid peeking into them, except to satisfy your academic curiosity.

Instead of exploring the underlying plumbing of the helper files, this blog post will focus on showing you how to use the files to accomplish your business needs.

A note on the differences between MVC Web Apps and Windows 8.1 apps

No doubt, every developer has faced the frustration of learning to do something one way – and then needing to re-learn a completely different approach for a similar scenario.

When designing our helper classes, we worked hard to ensure that much of the individual differences between platforms and services are abstracted away. Using our helper classes, accessing Exchange from a Windows 8.1 app feels no different than accessing SharePoint from an MVC web app. For example, authentication on Windows 8.1 apps has different caching mechanisms than web applications, but our helper classes handle it transparently for the developer in either case. Likewise, accessing OneDrive for Business in SharePoint requires an extra discovery step, whereas accessing Exchange does not; but again, this is not be something that a developer needs to remember. By using our helper classes, the code that you author will be similar both in spirit and structure, no matter which project type and which service you choose to target.

So, what does the sample code look like when the individual differences are abstracted away by helper classes? Let us take a function that retrieves calendar events from Exchange and take a look, step by step.

Performing a GET request

Step 1: Obtain information for communicating with the service

To use the helper functionality, first you need to create an object to represent the service. The object type is one of the helper classes, Office365ServiceInfo. This class encapsulates information about a service’s API endpoint, resource ID, access token, error handling, and more (generally speaking, much of this information should be transparent for your code). All you need to do is obtain an instance of the service, and then pass it around to other helper functions.

To construct an Office365ServiceInfo instance, the Office365ServiceInfo file offers a number of static methods that construct an instance of a particular service type:

MVC Web App

Office365ServiceInfo serviceInfo =
    Office365ServiceInfo.GetExchangeServiceInfo();

if (!serviceInfo.HasValidAccessToken)

{

    return Redirect(serviceInfo.GetAuthorizationUrl(Request.Url));

}

Windows 8.1

Office365ServiceInfo serviceInfo = await
   
Office365ServiceInfo.GetExchangeServiceInfoAsync();

if (!serviceInfo.HasValidAccessToken)

{

    return null;

}

By necessity, this preamble to get the Office365ServiceInfo object is somewhat different between the two project types – but it does stay identical between services (merely substituting GetExchangeServiceInfoAsync for GetOneDriveServiceInfoAsync, GetActiveDirectoryServiceInfoAsync, etc).

As a side note, the reason for the difference is that a web project must redirect to a login page and then back to itself in order to show a login UI, whereas a Windows 8.1 project is able to display the login screen as an overlay dialog. Thus, whereas the MVC code needs to redirect to the authorization URL if no access token is retrieved, the Windows 8.1 code does not. The difference also accounts for the need to “await” the dialog in Windows 8.1 (though certain services, like GetOneDriveServiceInfoAsync, still need to be async even in the case of an MVC Web App, as they first require a call to a Discovery service).

Step 2: Create a URL for retrieving the data

The next step is to construct a URL to call into the service. This code is completely the same across project types (though it is different for different service types).

How do you know which URL to use for the service, and which query parameters to pass in? In the MSDN Office 365 APIs Preview documentation, choose an appropriate section for your service type, such as the article on Using the Mail, Calendar and Contact REST APIs. For this example, the “Work with calendar items” section describes the format of the query to retrieve calendar data and even suggests a filter that you can apply, which is part of the standard ODATA syntax.

GET https://outlook.office365.com/ews/odata/Me/Calendar/
Events?$filter=Start le 2014-02-14T05:00:00Z and End ge 
2014-02-10T05:00:00Z HTTP/1.1
Accept: application/json

Armed with the example above, we can create our own query. In the case of the sample code that the tool produces, this query will retrieve the top 10 upcoming calendar events (and minimize data sent over the wire by doing only a select on a few fields):

Both MVC and Windows 8.1

string[] queryParameters =

{

    String.Format(CultureInfo.InvariantCulture,

         “$filter=End ge {0}Z”, DateTime.UtcNow.ToString(“s”)),

    “$top=10″,

    “$select=Subject,Start,End”

};

string requestUrl = String.Format(CultureInfo.InvariantCulture,

    “{0}/Me/Calendar/Events?{1}”,

    serviceInfo.ApiEndpoint,

    String.Join(“&”, queryParameters));

Note that to reduce error, the code above substitutes serviceInfo.ApiEndpoint into the beginning of the query, so that you don’t have to type out the same API endpoint (“https://outlook.office365.com/ews/odata”) every time. In addition to saving on typing, this pattern also makes calling different services consistent, whether the API endpoint is static (as it is for Exchange and Active Directory Graph) or dynamically discovered (as in the case of OneDrive for Business).

Step 3: Prepare the HTTP request

Now that the URL for obtaining the data is prepared, the next step is to create HttpClient and HttpRequestMessage objects. While the sample code creates a new HttpClient object every time, you may instead choose to keep it around for easy reuse. The code is the same across project types and fairly similar across service types as well. Differences worth noting are things like substituting odata=verbose versus odata=minimalmetadata for the Accept headers, depending on the service type. For such things, the MSDN documentation gives guidance on which Accept or ContentType headers the REST calls expect.

For the case of doing a simple Get on Exchange, the following will suffice:

Both MVC and Windows 8.1

using (HttpClient client = new HttpClient())

{

    Func<HttpRequestMessage> requestCreator = () =>

    {

        HttpRequestMessage request = new HttpRequestMessage(

            HttpMethod.Get, requestUrl);

        request.Headers.Add(“Accept”, “application/json;odata=minimalmetadata”);

        return request;

    };

 

    <Upcoming code here>

}

You may wonder, why do we create a lambda (e.g., a function that returns an HttpRequestMessage) rather than just creating the appropriate HttpRequestMessage object? The reason is that a request could fail because of an expired access token, in which case a new access token would need to be created and a new request dispatched to the service. Because an HttpRequestMessage object cannot be used more than once, the procedure for creating the request is captured as a lambda.

The whole business of retrying a request sounds tricky, but fortunately our helper code handles it for you. All you need to do is use the helper, and then you can just read the data. The only difference between the MVC code and the Windows 8.1 code is the name of the helper: Office365Helper vs. Office365CommonController.

MVC Web App

using (HttpResponseMessage response = await Office365Helper.

    SendRequestAsync(serviceInfo, client, requestCreator))

{

    <Upcoming code here>

}

Windows 8.1

using (HttpResponseMessage response = await Office365CommonController.

    SendRequestAsync(serviceInfo, client, requestCreator))

{

    <Upcoming code here>

}

Step 4: Read the response and de-serialize the data

With the response received, it’s time to read the response object; and, in case of failure, to use the common error-handling function to parse out the human-readable error from the response and display it to the user. As mentioned before, the error-handling implementation has a basic default behavior, but you can customize it to suit your needs. The code is the same across service types, and only mildly different between platforms (redirecting to a special error view in the case of MVC, versus displaying an error dialog in the case of Windows 8.1)

MVC Web App

string responseString = await response.Content.ReadAsStringAsync();

if (!response.IsSuccessStatusCode)

{

    return Office365CommonController.ShowErrorMessage(

        serviceInfo, responseString);

}

Windows 8.1

string responseString = await response.Content.ReadAsStringAsync();

if (!response.IsSuccessStatusCode)

{

    await Office365Helper.ShowErrorMessageAsync(

        serviceInfo, responseString);

    return null;

}

Finally, if the response was successful, you typically want to perform some action based on the response. For GET operations such as retrieving mail, calendar, or files, this may involve de-serializing the data. For POST operations, you may still want to de-serialize the data, or you might be content to know that the operation succeeded.

If you do need to de-serialize the data, using a library such as Json.NET (which is added automatically to the project when you add an Office 365 service) makes it possible to work with the returned data as if it is a .NET object. First, however, you need to define the shape of the data that you expect to receive over the wire. The same MSDN documentation as before will show the shape of the returned data. Thus, continuing with the previous example, the section on Work with calendar items defines not only the query format, but also the entirety of the object that you will get back.

Trimming for brevity, the MSDN documentation shows something like this:

{
  "@odata.context": "https://outlook.office365.com/EWS/OData/$metadata#Me/
Calendar/Events",
"value": [
    {
      "@odata.id": "https://outlook.office365.com/EWS/OData/Users
('sadie@contoso.com')/Events('AAMkAGI3...')",
      ...
      "Subject": "Lunch",
      ...
      "Start": "2014-02-13T20:30:00Z",
      "End": "2014-02-13T21:00:00Z",
      ...
    },
    {
      "@odata.id": "https://outlook.office365.com/EWS/OData/Users
('sadie@contoso.com')/Events('AAMkAGI3...')",
      ...
      "Subject": "Test new REST API",
      ...
      "Start": "2014-02-13T16:00:00Z",
      "End": "2014-02-13T17:00:00Z",
    }
  ]
}

Tip While MSDN can be great for initial familiarization with the data step, sometimes you want to experiment with the data against live data in real-time. A common technique is to dispatch the request and then watch the response using a debugging proxy such as Fiddler. In fact, if you run the sample code, you can use Fiddler to intercept the request (Access Token and all) – and then use the Composer tab in Fiddler to re-issue the request with minor modifications.

In any case, once you know the JSON shape, you can create a plain C# class with properties that match the names of the JSON fields. In the case of the sample files, this class is defined towards the top of the files. Alternatively, you could also extract it into a separate file, for example, to reuse across your project.

Both MVC and Windows 8.1

public class CalendarEvent

{

    public string Subject { get; set; }

    public DateTime Start { get; set; }

    public DateTime End { get; set; }

}

With the data structure defined, all that remains is to de-serialize it. The exact call can differ slightly between service types, depending on how nested the JSON structure is. For Exchange, it looks like this:

Both MVC and Windows 8.1

var events = JObject.Parse(responseString)["value"].

    ToObject<SampleModel.Exchange.CalendarEvent[]>();

Also depending on the service, you may need to do additional post-processing on the results. For example, Exchange does not yet support ordering events on the server, so the sample sorts them locally:

Both MVC and Windows 8.1

events = events.OrderBy(e => e.Start).ToArray();

With that, you have successfully accessed data from the Office 365 cloud. From here, the samples display the data in a basic MVC view or a Windows 8.1 page – but for authoring your own code, the sky’s the limit.

Performing a POST request

The sample code produced by the Office 365 API Tools shows only GET requests. Now that you’ve seen how a GET request works, how do you go about authoring a POST request? The answer: Follow the exact same pattern!

To demonstrate that the patterns are in fact the same, I will round off this article with an example of issuing a POST request, such as adding a new contact to Exchange.

As before, we start with looking at the MSDN documentation to see the prototypical way to create a contact. In the Create a contact section, we see:

To create a contact, send a POST request to the Contacts property of the contacts folder with a JSON representation of the new contact in the payload. The following example creates a new contact in the default Contacts folder.

 

POST https://outlook.office365.com/ews/odata/Me/Contacts HTTP/1.1

Accept: application/json

Content-Type: application/json;odata.metadata=full

Expect: 100-continue

 

{

  “@odata.type”: “#Microsoft.Exchange.Services.OData.Model.Contact”,

  “GivenName”: “Mara”,

  “Surname”: “Whitley”,

  “EmailAddress1″: “mara@fabrikam.com”

}

First, ensure you have appropriate permissions by going back to the Services Manager dialog. For this example, select Exchange, then Configure, and then Have full access to the users’ contacts.

With this done – and having added an entry point (such as a method off of a button click, with appropriate error handling) for invoking the action – you would follow the same steps as before. In broad strokes:

  1. Obtain information for communicating with the services.
  2. Create a URL corresponding to the ODATA request – and, in the case of a POST request, prepare a data structure for transmitting the data.
  3. Prepare the HTTP request.
  4. Send the request.
  5. Read the response and handle errors.

The biggest difference is in step #3, when preparing the HttpRequestMessage object:

  • The request must be a POST rather than a GET.
  • The Accept header may need to be adjusted, depending on what the documentation prescribes.
  • A Content header must be added.
  • The request content must be set to the serialized JSON.

Here is the code in its entirety, for a Windows 8.1 app:

private class Contact

{

    [JsonProperty("@odata.type")]

    public string EntityType { get; set; }

    public string GivenName { get; set; }

    public string Surname { get; set; }

    public string EmailAddress1 { get; set; }

}

 

private async Task AddContact() {

    // Obtain information for communicating with the service:

    Office365ServiceInfo serviceInfo = await

       Office365ServiceInfo.GetExchangeServiceInfoAsync();

    if (!serviceInfo.HasValidAccessToken)

    {

        return;

    }

 

    // Create the data structure and the URL corresponding to the ODATA request

    Contact contact = new Contact()

    {

        EntityType = “#Microsoft.Exchange.Services.OData.Model.Contact”,

        GivenName = “Mara”,

        Surname = “Whitley”,

        EmailAddress1 = “mara@gabrikam.com”

    };

    string requestUrl = String.Format(CultureInfo.InvariantCulture,

        “{0}/Me/Contacts”,

        serviceInfo.ApiEndpoint);

 

    // Prepare the HTTP request:

    using (HttpClient client = new HttpClient())

    {

        Func<HttpRequestMessage> requestCreator = () =>

        {

            HttpRequestMessage request = new HttpRequestMessage(

                HttpMethod.Post, requestUrl);

            request.Headers.Add(“Accept”, “application/json;odata.metadata=full”);

            request.Content = new StringContent(

                JsonConvert.SerializeObject(contact));

            request.Content.Headers.ContentType =

                new MediaTypeHeaderValue(“application/json”);

            return request;

        };

 

        // Send the request using a helper method, which will add an authorization header to the request,

        // and automatically retry with a new token if the existing one has expired.

        using (HttpResponseMessage response = await Office365Helper.SendRequestAsync(

            serviceInfo, client, requestCreator))

        {

            // Read the response and deserialize the data:

            string responseString = await response.Content.ReadAsStringAsync();

            if (!response.IsSuccessStatusCode)

            {

                await Office365Helper.ShowErrorMessageAsync(serviceInfo, responseString);

                return;

            }

 

            await new MessageDialog(“Contact added successfully!”, “Success!”).ShowAsync();

        }

    }

}

For an MVC project, the code would be largely the same. For real-world applications, though, the one important difference between Windows 8.1 and MVC code is the initial authentication piece. Whereas a Windows 8.1 app will display a dialog box that prompts the user to enter credentials – and which the code can just “await” – an MVC web project must do a redirect to an authentication provider (e.g., redirect to https://login.windows.net/) before getting redirected back to the MVC controller. As such, if the action is state-full (e.g., you’re adding a contact based on information submitted by the user), you will need to ensure that this information is persisted when the login page returns. You can do this in a variety of ways – for example, storing a cookie, encoding the information as a query parameter on the URL passed to serviceInfo.GetAuthorizationUrl, or ensuring that even a blank form requires the user to log in first.

I hope this blog post has helped you to get started with authoring your own Office 365 APIs code. To learn more, I invite you to read the MSDN documentation on Office 365 APIs, and – if you’ve haven’t already – to watch The Office 365 API Tools for Visual Studio video on Channel 9 that touches upon many of the points in this post.

image

Video: Office 365 API Tools for Visual Studio

- Michael Zlatkovsky, Program Manager on the Office Developer Tools team at Microsoft

Smart Watch: I give up, switching to making a device using the Raspberry Pi

Yep.  I give up.  So I am ordering a Raspberry Pi from Amazon with some extra stuff, like an LCD screen and so forth. Then I will make my own time display or something else.  But the Gadgeteer, Pebble Watch, MetaWatch, Sony Watch and TI Watch, all generally look horrible and the start up for me will take too long. Besides I can just copy Steven’s stuff.  Don’t tell him though….(read more)