In part 1 of this Chained Update lab, we demonstrated how to download several updates
at once and then automatically apply them one after another. We also developed a
customized user interface for discovering and downloading the updates. However,
when it came time to actually apply the updates, we used the default AppLife Update
engine user interface. This results in a usable, but non-optimal user experience
as three separate update windows open and close during the process. With the new
custom update UI feature in AppLife Update 3.0, we can replace that series
of update windows with a single UI that shows a unified overall progress window
for the update chain.
The chained update UI consists of three parts:
- A shared update UI application that displays progress.
For this solution lab, we’ll display progress for both the entire chain of updates
and the current update being applied. This application is started before the first
update is applied and remains running until the last update finishes.
- A custom update UI that is included with each update
and replaces the default AppLife Update UI. This custom update UI does not display
anything directly to the user, but communicates with the shared update UI to inform
it about the status of the update currently being applied.
- A set of classes used to communicate between the shared
and custom UIs.
In order for each update to communicate with the shared update UI application, we’ll
use .NET Remoting. To enable communications, both applications must reference a
common assembly that contains the types used for communications. In this lab, these
types are contained in the custom update UI assembly. This makes it very easy for
each custom update UI to reference the types.
The shared update UI is launched by the host application just before the first update
is started. The host application provides it with information about the number of
updates that are going to be applied in the chain. This information is used to display
total progress as the update chain is applied. At startup, the shared update UI
opens a Remoting server channel. This channel is used by the updates being applied
in the chain to instantiate communication classes within the shared update UI process.
As each chained update is started, the shared update UI resets the “current update”
progress bar and updates the overall status to indicate how far along in the chain
we are. As an individual update is executed, the shared update UI receives progress
events and updates the individual update progress bar. After all the updates have
finished (or if an error occurs), the main application is restarted by AppLife Update
and it then closes the shared update UI using Remoting.
The custom update UI is included with every update to the host application. It consists
of an implementation of the IUpdateUI interface, and is used by AppLife Update
while an update is being applied. Instead of a traditional visible UI, our implementation
uses the Remoting channel created by the shared update UI to send progress information
whenever an interface method is called. The shared update UI provides visual feedback
to the end user.
The AppLife Update Controller API makes it very easy to prepare and apply a chain
of individual application updates together. This process was implemented in Part
1 of this solution lab. By using the new custom update UI feature included
in AppLife Update 3.0, we can extend the chained update process to provide a smooth
end user experience while chaining multiple updates together and sequentially applying
them.
For answers to questions about this example, please contact Kinetic Jump tech support.
techsupport@kineticjump.com
Download AppLife Update Here
