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.
Design Patterns in Symbian
This article outlines some of the key architectural patterns, design patterns and coding idioms used in Symbian programming.
Design Pattern Categorization
The patterns are categorized to make the finding of a suitable pattern easier. The categorization may be done with respect to scale, including architectural patterns, design patterns, and idioms. Architectural Patterns define high-level relationships and structures and are modeled with component diagrams. Idioms provide implementation of a specific pattern in a specific environment. They may, for example, implement a mechanism to avoid memory leaks in software. Design patterns are scaled between architectural patterns and idioms. They are modeled with class diagrams, representing the roles and relationships of each class in the model.
Another categorization of design patterns is based on purpose. This categorization includes creational, structural, and behavioral patterns. Creational patterns encapsulate instantiation of concrete classes. Structural patterns compose larger structures from classes and objects, and behavioral patterns describe object communication patterns.
|Purpose||Architectural Patterns||Design Patterns||Coding Idioms|
|Creational||Abstract Factory||Factory Method(Singleton)||Two-Phase Construction|
|Structural||Microkernel||Class Adapter||Thin Template|
|Behavioral||Active Objects||Template Method(Observer)||Exception Handling(Iterator)|
Design Patterns in Symbian
Symbian OS as a whole follows the microkernel which can easily be extended and adapted to the changing requirements and new environments because of its high modularity. The microkernel separates the core functionality from extended and user-specific parts.
The Model–View–Controller (MVC) design pattern provides the ability to vary different software components separately. The pattern improves the software robustness and reusability. The MVC pattern helps the software designer to fulfil the object-oriented design principles, such as the Open Closed Principle(OCP).The idea of the OCP is that developers must decide early on in the analysis or design phase which parts of the system will be expanded later and which will stay fixed. According to the OCP principle, the design is extended by adding new code and classes by inheriting existing base classes rather than modifying the existing ones. Completed and tested code is declared closed, and it is never modified.
- Model:Contains and manipulates the data in the program.
- View: defines how the data of the model is presented to the user; the
view forwards received commands and requests to the controller.
- Controller:Defines how the user interface reacts to received
commands and requests.
Using MVC Pattern in S60
Components of a MVC-like software
The Model contains and manipulates the data. Its most important part is the data structure or we can say the algorithm of the application. The View is the graphical interface. It reads the Model and retrieves the data that must be shown to the user. The Controller manipulates the data in the Model and updates the View. All are inter-related to eachother by some ways.
Why MVC is important
It allows the developer to design his application in according to the fundamental laws of the object-oriented programming. First of all, the OCP (Open Close Principle) that is based on the idea that the developer has to decide before the implementation phase which part of the application will be expanded and which not. After the design phase, the code will be developed starting from some base classes that will be extended by adding new specialized classes. The MVC is coherent with the OCP.
Use of MVC
The use of MVC on Symbian S60 is based on the Avkon GUI framework, that provides the base classes to implement the Model, the View and the Controller. These classes will be extended by the application designer.
Avkon base classes :
- CAknApplication, the base class for Application
- CAknDocument, the base class for Model (the Document)
- CAknAppUI, the base class for the Controller.
The "parent" View is not provided by AVkon but is directly inherited from CONE environment. The "parent" class for view is CCoeControl.
Adapter is a very common design pattern. It provides software developers with a way to adapt to changing requirements without changing the structure of the original design. That is why adapters are used more often in the implementation phase than in the design phase. The adapter design pattern is also called a ‘wrapper’ as it wraps some existing functionality into new environments. The adapter is essential in the design of the portable applications.
It uses aggregation rather than inheritance (used by the class adapter) to control the adaptee’s behavior. The client uses the adapter via interface, defined by the target. The adapter takes care of translating the client calls to the corresponding adaptee’s methods. The adapter is transparent for the client.
The object adapter enables a single adapter class to be used with all adoptee type objects. The adapter can also add functionality to all adaptees at once. However, the object adapter has no way of overriding the adaptee’s behavior.
The observer defines a one-to-many dependency between collaborating objects. The observer enables the partitioning of a system into observers that react when their subjects change state. It is used in many event-based systems to separate the event source from the event monitors. The concrete observers attach themselves to the subject in a way that the subject knows which observers to notify when its state changes. The observers register themselves to the subjects in which they are interested. A subject may have multiple observers, and an observer may listen to several subjects. The update method may contain a flag, indicating which subject changed state in the case of a many-to-many relationship.
The intent of the state pattern is to provide an entity with the possibility of altering its behaviour when its internal state changes. The state pattern also lets us vary the state-based behavior by modifying the state transitions and to reuse the behaviour separately.