Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.
Front End Processor (or FEP) acts as a interface between the user and an application. It intercepts the events and then processes them according to our own logic and then sends one or more events to the application underneath. FEPs are polymorphic DLLs that implement the FEP interface. They typically use the control framework defined in the UI Control Framework to intercept key and pointer events. These are processed as necessary, and the output is sent to the application. Applications receiving this do not need to be aware that a FEP is present. By default there is one FEP(AknFep or T9) running in the mobile. But third-party developers can also develop their own Feps and install them. At any point of time there can be only one Fep running. As soon as the mobile is switched on only the AknFep will be running in the background.
Situations where Fep can be used:
- Characters that the user is likely to input do not actually occur on the mobile device’s numeric keypad, or
- There is no keyboard/keypad at all.
The above figure explains how the FEP fits into the architecture. Classes prefixed with Xxx should be written by the person who develops the FEP while others are provided by the system components like CONE, FEPBASE and WSERV.
The FEP interface must conform to the interface defined by CONE. The definition of this interface can be found in epoc32\include\COEFEPFF.H. The first exported function of this interface is a “factory function,” which returns the address of a fully constructed instance of a CCoeFep-derived class. This object typically owns a control, which is added to the control stack at a high priority, enabling it to intercept key events before the application gets them. This method is called during the construction process of CCoeEnv, i.e., during the initialization of every application. CONE supports the notion of a default FEP and installed FEPs. The installed FEP concept is used to provide the client code (such as UI components) with a list of the FEPs that are available to a device. In the absence of any installed FEPs, CONE attempts to load the default FEP on application startup. AknFep(T9) is determined to be the default FEP for the S60 platform.
Support for FEPs is built into the heart of Symbian OS. The FEP architecture is implemented across a number of components. CONE manages the creation, ownership, and destruction of FEPs. It also provides support for some of the advanced features mentioned in Section 3.5: Advanced Features of the FEP Architecture. FEPBASE provides some key base classes, as well as several utility classes of potential use to FEP authors. ETEXT provides support for inline editing (see Section 3.5.1).
In order to allow components that do not explicitly know about one another to communicate with each other, a number of interface classes are defined in CONE and FEPBASE, enabling this communication in an architecturally clean way. Thus by using these interfaces, applications can interact with FEPs and vice versa, without either knowing the details of the other. In almost all of these interactions, CONE acts as the broker for objects of classes that implement these interfaces.
Features of FEP Architecture:
- Inline Editing: Those situations wherein the text being composed on the Fep does not appear on the floating window of the FEP but instead appears directly on the target window, usually a text editor which lies underneath the FEP.
- Context Retrieval: If the focused control underneath the FEP is a text editor then FEP has the capability to retrieve the length of the text in the editor, the actual portion of the text, maximum length of the text in the editor and the insertion point (cursor position). This feature of the fep is known as context retrieval.
- Capabilities: In order to control the input correctly, the FEP needs to be aware of the context in which the device is operating. For example, if the focused control is a number editor, it makes little sense for the FEP to attempt to send anything but numbers to it. The most efficient mechanism to do this is to enable the FEP to obtain information about the current input requirements and capabilities of the control that currently has focus. CONE provides support for the FEP to inquire about the capabilities of the target control; it can then behave accordingly. The FEP needs to operate in a different mode for each of the different input types and also provide support to enable input in each of those modes. It also needs to catch keys to determine if there is a special input requirement for that particular key press, and has several functionalities to cover ancillary functions such as managing cursor position, launching UI controls, etc.
- Notification of changes in the environment: It is important that FEP is aware of the changes that occurs in its environment such as when focus shifts to different target control or when the application goes to foreground/background etc. Such events are reported to FEP through deriving from various observer classes. For example MCoeForegoundObserver class should be inherited by your FEP if your Fep wants to be aware of the foreground background changes.
On how to write a fep, refer to the “How to write a FEP” page available in Archived:S60 3rd Edition Help. You can just search with this title in the SDK help documentation.
You can download the FEP Example S60_Platform_FEP_Example_v2_0_en.zip from Nokia Developer Examples.