Namespaces

Variants
Actions

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.

Revision as of 02:39, 25 January 2012 by hamishwillee (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Design Patterns in Symbian

From Wiki
Jump to: navigation, search

This article outlines some of the key architectural patterns, design patterns and coding idioms used in Symbian programming.

Article Metadata
Article
Created: eswar_illuri (09 May 2007)
Last edited: hamishwillee (25 Jan 2012)
Featured Article
27 Dec
2009

Contents

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.

Microkernel Architecture: Microkernel Architecture.GIF

Model-View-Control Pattern

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.

MVCPattern.GIF

  • 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

MVCPattern Series60.GIF


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 Pattern

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.

The adapter can be implemented either as a class or as an object adapter. However, a class adapter is not interesting in Symbian OS because it requires the use of multiple inheritance. Adapter Pattern.GIF

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.

Observer Pattern

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. Oberver Pattern.GIF

State Pattern

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. State Pattern.GIF

This page was last modified on 25 January 2012, at 02:39.
390 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×