locked
How do you persist data for an Office 2013 Task Pane App RRS feed

  • Question

  • Hi,

    I want to offer convenience and personalization for my Office 2013 task pane app, so I want to persist some information about the user. In a traditional app, this is done via cookies or request parameters. Neither seem to be possible with an Office 2013 task pane app.

    It seems my only other option is to embed the data in the document, but I want the information to persist across documents.

    Can someone provide some guidance on this?

    Thanks,
    Jayson

    Thursday, February 28, 2013 3:29 PM

Answers

  • Cant you use license token as user information that would require to link specific user to specific settings in your webservice?

    Look at the license token and its schema here. Look at cid: this hould be the user specific information that you require to be able to store user data. Your app should get loaded with the et parameter in URL, which you can base64 decode and then you sohuld get the cid. (for security reasons you can also varify the token)


    Anze Javornik

    • Edited by Anze Javornik Wednesday, March 6, 2013 8:34 PM
    • Marked as answer by JaysonGo Wednesday, March 6, 2013 8:55 PM
    Wednesday, March 6, 2013 8:33 PM
  • Anze you are right there are no RoamingSettings on document apps, for now, they only apply to mailbox apps. Those settings are stored in the server and are valid for all the app instances on that server.

    Document DO support settings (plain settings) which are persisted  per document per app instance. (this is true for Excel, Word, PPT )

    this functionality is available on the Office.context.document.settings object.

    And yes, one way of enabling roaming settings now in document is to host a service to store and retrieve them from there.

    Wednesday, March 6, 2013 12:09 PM

All replies

  • Hi

    Look at this and Romaing Settings (Maybe something similiar is for other then Oulook apps)

    http://msdn.microsoft.com/en-us/library/fp123509.aspx

    Else i think cookies should work...after all its a browser. Are you sure you are setting the cookies the right way?


    Anze Javornik

    Thursday, February 28, 2013 3:41 PM
  • That is exactly what I needed (referring to the URL you included). Thank you very much.

    And yeah, for the record for anyone else interested, cookies *do not* work. I am setting them correctly.

    Thursday, February 28, 2013 3:54 PM
  • I dont think documents have roaming settings. If cookies dont work what you can try is to use some web service to load the settings with the et (token) parameter.

    You create a webservice which returns a json object with persistant options then on Office.initialize you can call that web service with et parameter, then read the settings from database and return them.


    Anze Javornik

    Thursday, February 28, 2013 4:02 PM
  • Anze you are right there are no RoamingSettings on document apps, for now, they only apply to mailbox apps. Those settings are stored in the server and are valid for all the app instances on that server.

    Document DO support settings (plain settings) which are persisted  per document per app instance. (this is true for Excel, Word, PPT )

    this functionality is available on the Office.context.document.settings object.

    And yes, one way of enabling roaming settings now in document is to host a service to store and retrieve them from there.

    Wednesday, March 6, 2013 12:09 PM
  • I wanted to circle back on my earlier response. It wasn't exactly what I needed since document.settings stores the data in the document, and as Anze and Juan indicated, there are no roaming settings in a document.

    The settings that I would want to persist are per user, so having a service provide me user-specific settings is not doable without anyway to persist something about the user. Cookies do not work. I double-checked it with Fiddler and saw my server response with a cookie in the header, but subsequent requests did not include them. Big bummer.

    The other traditional way to maintain state is to use query string variables. However, that doesn't work well with O2013 Apps since the landing URL is fully baked into the manifest; everyone gets the same URL. I suppose, I could generate the manifest per user but that's too much work at this point and would only consider that as a Plan C.

    Does anyone know if HTML5 Local Storage works?

    Thanks for all the responses, although I would like concrete validation that what I'm finding above is true.

    Wednesday, March 6, 2013 2:53 PM
  • Cant you use license token as user information that would require to link specific user to specific settings in your webservice?

    Look at the license token and its schema here. Look at cid: this hould be the user specific information that you require to be able to store user data. Your app should get loaded with the et parameter in URL, which you can base64 decode and then you sohuld get the cid. (for security reasons you can also varify the token)


    Anze Javornik

    • Edited by Anze Javornik Wednesday, March 6, 2013 8:34 PM
    • Marked as answer by JaysonGo Wednesday, March 6, 2013 8:55 PM
    Wednesday, March 6, 2013 8:33 PM
  • Thanks Anze.

    That's exactly what I would need, however, after reading deeper into, the documentation has the following note:

    "The app license framework applies only to apps acquired directly from the Office Store or apps from the Office Store that are made available in an app catalog hosted on SharePoint 2013. Apps made available in other ways—such as from a file system location, or uploaded directly to a app catalog hosted on SharePoint—cannot use the app license framework."

    Source: http://msdn.microsoft.com/en-us/library/jj163257.aspx

    The app I'm building is currently designed for internal use only within my company. My initial deployment strategy was to use a file share, which consequently eliminates the possibility of using the licensing framework.

    That is a great thought, though, and that is absolutely what I would need. Perhaps, I will rethink my deployment platform. Any other ideas? I still have yet to test out HTML5 local storage.

    Thanks,

    Jayson

    Wednesday, March 6, 2013 8:55 PM