DNL UIQ

In the MultiView1 application, we switch from the list view to the details view by calling the iQikAppUi.ActivateViewL(KViewIdDetailsView). While this successfully changes views, an important piece of information required by the details view, which item we are required to display, is not communicated.

There are several ways to achieve this; all have advantages and disadvantages.

The details view could have addressability to the list view’s list box, thus ask the list box which entry is the current item. Unfortunately, obtaining the list box handle is not that easy. Even if it were, this approach relies on the list view maintaining the list box even when the view is deactivated. This solution is probably the least desirable.

Alternatively, the list view’s current item index could be stored in a global variable (available in applications since the advent of Symbian OS 9), or preferably in an object common to both the list and details view, such as an engine.

Finally, the current item index can be passed from the list view to the details view by packaging the parameter into a descriptor and using the ActivateViewL(TVwsViewId&, TUid, TDesC8&) variant of the ActivateViewL() method.

The process of communicating parameters between views and causing the target view to be displayed has been given the name Direct Navigation Link (DNL). One view is said to DNL to another. Our application only switches between views in the same application but the underlying DNL mechanism allows applications to switch between any views in the system. For example, the detail view in Contacts can navigate directly to the New message view in messaging.

Using DNLs appears to be the most attractive option; however, we must take in to account that a view can be activated for a number of different reasons.

In the MultiView1 example application, moving from list view to detail view is not the only way in which the details view can be activated. In the emulator, if you click the Applications button you will jump directly to the application launcher. Similarly, on phones there are numerous ways in which you can jump out of the current application, for example using the task manager option. If you now come back to the MultiView1 application from the application launcher (or task manager on a phone) the details view is activated. Not surprisingly, the application launcher knows nothing about your application-specific parameters, so these are not passed to your application ViewActivatedL() method

---

Sending Parameters to Views

The code snippet below demonstrates how you can package and send a parameter to the view. We define a simple class, TListDnlInfo, to contain the parameters we wish to send. In the example a single integer is sent.

The definition and usage of the TPckgBuf is really a piece of syntax to enable the software to convert between a class and a byte stream in a type safe way without needing to use casts or manually create the byte stream.

When the information is delivered to the view, we need to convert the byte stream back into the original data structure and extract the parameters that have been packaged up. The following code demonstrates this happening:

At its simplest level, this code fragment shows how to implement the ViewActivatedL() method and accommodate both ways in which it can be called.

When called by the application launcher the aCustomMessageId value will be zero. For this reason you should not define any application-specific aCustomMessageId value to be zero; in our example we define it to be the value one.

In the example code does not perform any meaningful tasks with the passed parameter set: we do not set the view to display anything other than the UI component default values. In a real application, any values displayed should be synchronized with the internal state of the item defined by the passed parameters.

If a view is not actually passed any parameters, it needs another mechanism to determine which item is being referenced. Unfortunately, the solution to this problem varies depending on individual circumstances.

If a view is displaying read-only information, you may allow each of the UI components in your view to retain state value. When such a view is ViewActivatedL() and is passed some parameters, it will set up the UI components. When it is not passed any parameters, no action is required since the UI components retain the correct state value. This approach assumes that you do not destroy components on a ViewDeactivated() and attempt to re-create on the ViewActivatedL(). Unfortunately, this solution is of limited value since it is rare that a view contains just read-only information.

If your view displays modifiable content, you need a way of knowing to which item the details belong. Otherwise, your application is not be able to associate any changes with the correct item. If the ViewActivatedL() method is called with some parameters, that information is normally provided in those parameters. However, when no parameters are passé, that information is missing. Therefore the view and/or an external object needs to record which item is being displayed.

Again, there are numerous solutions for this problem. For example, when parameters are passed to the view they could be stored. When no parameters are passed, the view would use the previously stored parameters.

using previously stored parameters in the ViewActivatedL() method

This solves the problem but it is not a particularly elegant solution for the majority of applications.
If an application publishes the message IDs and parameters with the intention of allowing other applications to run the view, then it must have functionality similar to that described above.

Pramod

---