After you have an application
in the store, keeping track of any issues and problems people are
having with it and submitting updates to add new functionality or
correct any issues is very important. It is generally well understood
that a popular application in any ecosystem often has a responsive
developer who is assisting customers with issues they are having and
releasing updates to fix common issues. Additionally, customers love
buying an app and then seeing ongoing value delivered through regular
updates and feature additions.
The Seller Dashboard gives app publishers some tools to assist with the life-cycle process:
- Metrics about your apps
- App update process
These tools are discussed at length in the following sections.
Using Seller Dashboard Metrics
The Store captures a number of helpful
metrics that can help with giving you insights into how your app is
being used and whether any issues are occurring. The following are a
few of the metrics that are gathered:
- Downloads
- Purchases
- Trials
- Purchased seats
- Installs
- Uninstalls
- Runtime errors
Figure 1 shows an example of the metrics overview page showing all your apps in the Seller Dashboard.
Figure 2 shows an example of the detailed metrics for a given application in the Seller Dashboard.
Capturing additional information and metrics to
help you run your apps is also highly advisable. You can use tools such
as Google Analytics to monitor usage of an app because app pages and
App Parts are Web pages.
Gathering information about crashes or errors
that occur in an app is also extremely important so that you can make
further diagnoses. Having a customer complaining about an app crashing
and not having any visibility into why it might be happening can be
infuriating to a developer. Capturing more information than you think
you need is often the best plan. Following on from that, monitoring
your error logs and proactively getting in touch with customers who are
experiencing an issue often goes a long way toward keeping a happy
customer.
Upgrading Apps
From time to time you will either want
to release a new feature in an app or release a new version to fix a
found bug or issue. To update an app, simply submit a new version of
your app package using the same Product ID (in the app manifest file).
Doing this signifies that it is an update and not a new application.
In many cases, however, you might not need to
submit an update. For Provider-hosted apps, the only time you need to
submit an update is if the components in the app package change, not if
the back end of the app changes. The reason is that with a
Provider-hosted app, you can change the back end of the app, any pages,
code, databases, and assets without needing to touch any of the parts
that are deployed to SharePoint. This capability can be extremely
helpful when resolving issues, can be done quickly, requires no input
or effort from the customer, and can be controlled by you. However, in
some instances this capability can cause issues. Think about the
scenario when you do update the SharePoint components of an app and
change its behavior for some reason. Now your back-end code must
support those who have installed version 1 of the application and also
version 2! Be careful not to make breaking changes to the back end code
without thinking through the ramifications of doing so.
When you do submit an app update to the store or
app catalog, the user will see a visual indicator beside the app that
an update is available and will be prompted to update it.
After the update starts, SharePoint locks the
application while the update is in progress. This stops people from
inadvertently trying to launch the app while the update is happening.
What happens during the update depends on the application type. The following summarizes at a high level what occurs for each:
For Provider-hosted and SharePoint-hosted apps (apps with a WSP in them):
- A backup of the application’s SharePoint site is taken.
- The update is applied to the backup.
- If the update succeeds, the update is applied to the primary application’s SharePoint site.
- SharePoint executes the PostUpdate Web service, if one is provided.
For Autohosted apps:
- SharePoint updates the SQL Azure database if the app contains a DACPAC.
- SharePoint then runs the same steps as for Provider-hosted and SharePoint-hosted apps (see the preceding bulleted list).
The PostUpdate
Web service referenced in the earlier steps is one of several events
that are raised in the life cycle of an application. These are calls
that are made by SharePoint to remote Web services that you as an app
developer host and run, which means you are notified when these events
occur. These events include the following:
- App Installed (InstalledEventEndpoint node in the app manifest)
- App Uninstalling (UninstallingEventEndpoint node in the app manifest)
- App Upgraded (UpgradedEventEndpoint node in the app manifest)
You can use these events to do things such as:
- Set up data when a customer installs an app.
- Remove data when a customer uninstalls an app.
- Change data when a customer upgrades.
- Record the version a customer is using when he upgrades.
How to use these events is up to the
developer. Even if you only use them to record what installs have taken
place and what version customers are running, this information might
come in handy for debugging and diagnosis purposes.
