Search Extensibility for Windows Phone Mango Apps

Posted: September 26, 2011 in Mobile

Sifting through some Mango documentation the other day, I realized that I had not enabled App Connect & Search Extensibility for my Windows Phone Mango applications. So, some research followed which indicated that it is not that difficult a mechanism to turn on .. & so I did. I think this is a brilliant way to promote your apps, with every relevant Bing Search your users perform. While the official documentation/samples were clear enough, I just wanted to expand on enabling Search Extensibility in a real Mango app & my experience with it. Still have your attention? .. good, let’s read on 🙂

But first, the official documentation here is a must-read.

So, App Connect allows your app to augment the user’s Search experience & provide a rich interactive feel by carrying search results/criteria directly into an app, which can be launched from Bing results. If you search Bing for things which fall under the categories of Products or Places or Movies, the search results include what’s called Quick Cards. This is very handy & much more user-friendly than a list of links, since each Quick Card contains contextual specific information based on the Search performed. Quick cards are presented in a Pivot & your app, if it can do anything with the Search results, gets the opportunity to feature in the Apps pivot. Here’s an architectural view of how things work:

Search Extensibility: via MSDN

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Here are the four things we need to do to enable Search Extensibility for our Windows Phone Mango apps:

  • Update WMAppManifest.xml — This is your way of telling the Windows Phone OS that you’re app is interested in/can handle the following categories of Search results.
  • Create an Extensions/Extras.xml file — This essentially dictates what information about your app appears in the Apps pivot for Quick Cards.
  • Configure URI Mapping so that you control which page of your App receives the deep-linked App-launch request from Quick Cards.
  • Perform any special logic with the URL parameters off the deep-link.

Now, I have a simple Shopping List app called ShopTillYouDrop that has been recently “Mangofied” .. so why not try to turn on Search Extensibility for it? Here are the steps I took, sequentially to address the four things required for App Connect:

  1. First, the WMAppManifest.xml had to updated, to declare to the OS that I am interested in a few Bing Search result Extensions, a specific category of Quick Cards. Here’s how my WMAppManifest.xml looked like:

                          
       <App>
          .... other stuff ..
          <Extensions>
               <Extension
                  ExtensionName="Bing_Products_Arts_and_Crafts"
                  ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5661}"
                  TaskID="_default"
                  ExtraFile="Extensions\\Extras.xml" />
               <Extension
                  ExtensionName="Bing_Products_Baby_and_Nursery"
                  ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5661}"
                  TaskID="_default"
                  ExtraFile="Extensions\\Extras.xml" />
              ..
              .. other Extensions ..
          </Extensions>
        </App>
    

    You’ll notice that the only thing that you need to change is the ExtensionName, associating your app with the specific category of Bing Search results; other property values can be left the same. For a complete listing of Bing Search Extensions & what parameters you could get from a Quick Card, please look here.

    So, you essentially get to pick which categories of Search results your app wants to handle. Since mine is a generic Shopping List app, I can take some liberties. Word of caution here: there will be some Marketplace Certification scrutiny on the type of Search Extensions you want to associate your app with .. you just cannot select categories of Products/Places/Movies that have nothing to do with what your app does in general. So, common sense .. right folks?

  2. Next up, the Extras.xml file .. this by convention has to be in a folder called Extensions. This helps us specify how our app looks like in the App pivot of Search results. You could specify an App Title & a separate Caption for every Extension you support .. best of all, you can localize the strings right in the file using specific caption strings for given culture-info (like “fr-FR”)! Here’s a glimpse of my Extras.xml content:

     
     <?xml version="1.0" encoding="utf-8" ?>
     <ExtrasInfo>
    
      <!-- Application title-->
      <AppTitle>
        <default>ShopTillYouDrop</default>   
      </AppTitle>
    
      <!-- Search-related captions -->
      <Consumer ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5661}">    
        <ExtensionInfo>
          <Extensions>
            <!-- Specific Caption for each Extension or Group of Extensions -->
            <ExtensionName>Bing_Products_Arts_and_Crafts</ExtensionName>
            ...
            ...
          </Extensions>
          <CaptionString>
            <default>Add to Shopping List!</default>        
          </CaptionString>
        </ExtensionInfo>
      </Consumer>
      
     </ExtrasInfo>
    

    That’s it .. we have enough configuration to give this a spin. With my updated app deployed, if I now Bing for XBox, which is a Product Extension I have subscribed for, my app gets listed in the Apps pivot in the Quick Cards. How nice is that?

    Search Extension

  3.  

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  4. Now, for configuring the URL Mapping, I do nothing more than what’s described in the official sample here. We essentially define a URIMapper as an Application Resource & tie it to the default app Rootframe. The mapped URI in the Resource allows us to specify where to go in our app, when the user launches the app from the deep-linked Quick Card.
  5. The last piece of the Search Extensibility puzzle lies in your app making sense of the deep-linked URL parameters coming from the Quick Card; this provides a rich user experience as it all seems seamlessly integrated to the end user when their search context is carried straight into an app. Once we have the URI Mapper bringing the user to a certain page in our app, it is upto us to make sense of the Query parameters coming from the Quick Card launch to tap into the Search context of the user or a specific product. Here’s some code from my landing page:

     
     private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)
     {
         string selectedShoppingListName = string.Empty;
    
         if (this.NavigationContext.QueryString.ContainsKey("ProductName"))
         {
            // If coming from App Connect ..
            // Create a "General" Shopping List & Add "ProductName" as list item.
            ShoppingList generalList = new ShoppingList();
            ShoppingItem searchItemToAdd = new ShoppingItem();
            searchItemToAdd.ItemName = this.NavigationContext.QueryString["ProductName"];
            generalList.Items.Add(searchItemToAdd);
            generalList.Name = "General";
                  
            App.Current.ShopLists.Add(generalList);
    
           // Other stuff ..
          }
     }
    

    So in my case, I care about the ProductName of the product the user searched for & clicked on a Quick Card. Once I have it, I choose to add it to a generic shopping list, as below:

    Using Search parameters from Deep-Link

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    As you can see, for the end user this is well-integrated — I searched for XBox, picked a product for review/prices & now it’s in my Shopping List! One thing to be wary of is that you are not guaranteed the Query String parameters from a Quick Card .. so prepare for optional/missing parameters.

Another interesting way to integrate your app with Bing results is called App Instant Answer. Here, as the user searches for something, the appropriate App is presented ahead of the Search results, without the app having to register for specific Extensions. As you can imagine, this leads to high visibility & sort-of affects Bing’s search quality .. so I am not surprised that there are no explicit ways to influence this. Not even the search keyterms in the Zune Marketplace (from your app metadata) can affect this .. I’ll be curious to know if someone found any round-abouts. As for my Shopping List app, I could make the App Instant Answer promote my app only when the Search criteria matched my exact app name, as below!

App Instant Answer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The App Instant Answers simply launch your app without giving you the flexibility to declare a landing page; however, the deep-linked URI does carry one Query String parameter called bing_query, which should give you the user’s Search context. Ways to integrate your app better with the App Instant Answers can be found here.

As you can see, integrating & making our apps visible through Bing Search results has obvious benefits of high visibility. Great & easy way to promote your apps, right?

Thoughts much appreciated.

Adios!

Advertisements
Comments
  1. […] Read original post by Samidip Basu at Windows Phone Love & .NET Ramblings […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s