Transition effects

Transition effects are a feature introduced in S60 5th Edition SDK. Transition effects decorate application changes, including start, switch and exit cases.

In general, an application developer does not need to care about transition effects, apart from the few issues discussed here. First of all, as effects are implemented in the framework, they assume certain things about application behaviour. Thus an application has to "behave well" in order for it to be interoperable with effects.

Second, this section also shortly describes the use of the GFxTranstionEffects API (at gfxtranseffect.h) for fullscreen effects. The GFxTransitionEffects API has plenty of functions, but for fullscreen effects only two of them are used:

AknTransitionEffects (at akntranseffect.h) defines used paramenters for the API.

aContext hints to effect engine at occasion of transition. Some aContext values have a special use in engine, for example when application start effect is ongoing, application activation effects are not allowed. Thus aContext value should describe effect event as well as it can. However in application internal effects a own aContext value can be used (a value greater than EAppSpesificEvent).

aEffectArea is area which is redrawn during an effect. If the area is fullscreen, it can be just TRect().

aType is parameter type and should be EParameterType.

aParams is created using GfxTransParam function. For example:

GfxTransEffect::BeginFullScreen ( aContext, TRect(), 
AknTransEffect::EParameterType, 
AknTransEffect::GfxTransParam(aUid, flags));
AknTransEffect::GfxTransParam(const TUid& aNext, const TUid& aPrev, TInt aFlags)

aNext is an UID of target application and aPrev is source application (that is, the current application). If transition is application internal, aPrev should be AknTransEffect ::KNotDefinedUid. The flag should always be AknTransEffect ::EFlagNone.

There are basically two types of effects: 1-phase and 2-phase. The 1-phase effect starts after EndFullScreen is called, and lasts until its specified runtime has elapsed (unless aborted before that). The 2-phase effect is started when BeginFullScreen is called and its first phase is run until EndFullScreen is called, after which it continues as a 1-phase effect. The 2-phase effect can be used when the needed effect runtime is not known. For example, in general we cannot say how long an application start takes. However a switch between applications is a fast and coherent operation and thus the 1-phase effect is appropriate here.

When a BeginFullScreenEffect is called, a snapshot of the current screen state is taken. If there is a 2-phase effect, its first phase is started, otherwise the screen is not updated until a EndFullScreen is called, or effect is aborted. The Effect can be aborted using a AbortFullScreen function or by effect engine. The effect engine may force abort e.g. when another application get focus. After EndFullScreen call, an effect can mix application drawing to the effect so that the application is continuously drawn during the effect, but the effect has control over how it is presented on screen. When an effect ends (or its aborted), the effect engine refreshes the screen.

Asynchronously starting applications

Application start effects starts before an application process is initiated. It is a 2-phase effect and the second phase is started when the application has most probably drawn itself. The application framework assumes that the second phase can be started after the redraw event has proceeded. There are some applications which do their drawings delayed (for example, for shortened startup time), and this assumption can fail. If the problem is irritating, CAknAppUiBase::EAknExplicitStartupEffectCompletion flag is provided as CAknAppUi::BaseConstructL parameter. When this flag is used, the application has to call EndFullScreen explicitly in its startup sequence to notify when the second phase can be started.

Application exit issue

An application is not allowed to change its window ordinal (that is, change its position in window stack) after exit has been called.

Some applications move themselves to the background as their closing sequence may take a long time. However, the framework interprets this as an application switch (as a new application gets a focus) and not as an exit. And the exit effect is not viewed as the application is not visible. If application has to switch before exit, it should call GFxTranstionEffects::BeginFullScreen on its own before the window is sent to the background.

Note that in EApplicationExit context aNext UID refers to current application! (not to next application as in other cases).

MyApplicationExit()
	{
	
	GFxTransitionEffect::BeginFullScreen(AknTransitionEffects::EApplicationExit, TRect(0, 0, 0, 0), AknTranstionEffects::EParameterType,
	AknTransEffect::GfxTransParam(KMyUid));
	
	SendToBackground(); //send application to background
	DoExit();  //do actual exit
	
	}
© Nokia 2009.