Components development for bada (Part 1)
While working my way through sample bada projects I have come to notice an interesting thing regarding the design of components in bada. Under “components” I means first of all the separate forms, popups and other predefined or custom UI controls and containers including their view/controller code. In my opinion the implementation of those is not very flexible (at least not in the examples) and the code is therefore somewhat difficult to be reused in other projects. There are workarounds though and this is something I want to take a closer look at in this post.
Imagine a simple application for drawing with the following classes/components:
- Application class
- Board Drawing Form class
- Brush Picking Popup class
Now, let’s say you are working on a drawing game at a later date. You might want to reuse the brush picking popup, right? But what does this imply? This implies that the brush picking component must be ideally like a black box: it doesn’t have to know in what environment/app it is implemented. It must be fully function-able on its own. Reusable components must be independent of the contexts of their use.
Unfortunately this is not something you would see in the bada examples as they are today. A component usually references directly the controller/logic class of the app – making the component itself fully dependable on the use within that context only.
The first and most important thing you need for independent components is a solid messaging system with its environment. A component must be able to send a message to the outside world basically saying “This thing happened in here, decide yourselves out there how you want to handle it “. Now, you can solve this with a fully-fledged event based system. I needed a simpler thing in my project though: a simple messaging system that is able to send messages “upstream” to the parent.
For that purpose I created a universal class: InheritanceContainer which handles the messaging children-to-parent between any classes that might be:
- reusable
- in a hierarchic dependence with each other
/**
* Name : InheritanceContainer.h
* Version : 1.0.0
* Vendor : badadev.com
* Description : Container object used for communication between parent-children
* Lincense : This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The Fuck You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details.
*/
#ifndef INHERITANCECONTAINER_H_
#define INHERITANCECONTAINER_H_
class InheritanceContainer
{
protected:
InheritanceContainer *parent_;
public:
// PREDEFINED ACTIONS
const static int ON_CLOSE_ACTION = 1;
InheritanceContainer();
~InheritanceContainer();
void setParent(InheritanceContainer &parent);
void sendContainerActionToParent(const int actionId);
virtual void receiveContainerActionFromChild(const int actionId,
InheritanceContainer &child);
};
#endif /* INHERITANCECONTAINER_H_ */
/**
* Name : InheritanceContainer.cpp
* Version : 1.0.0
* Vendor : badadev.com
* Description : Container object used for communication between parent-children
* Lincense : This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The Fuck You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details.
*/
#include "InheritanceContainer.h"
InheritanceContainer::InheritanceContainer(){}
InheritanceContainer::~InheritanceContainer(){}
void
InheritanceContainer::setParent(InheritanceContainer & parent)
{
parent_ = &parent;
}
void
InheritanceContainer::sendContainerActionToParent(int actionId)
{
if(parent_)
{
parent_->receiveContainerActionFromChild(actionId, *this);
}
}
void
InheritanceContainer::receiveContainerActionFromChild(const int actionId,
InheritanceContainer &child)
{
// DO NOTHING
// This one is meant to be overriden by those Inheritance Containers
// that serve as parents
}
The idea is simple. Each class derived from InheritanceContainer can send simple numeric messages upstream to its parent (if one is provided) or receive messages from its children. The InheritanceContainer class itself already defines one message “ON_CLOSE_ACTION” that could be used for almost all UI containers.
So, as soon as a Brush Picker object is done with its task it can simply send a message to its parent:
sendContainerActionToParent(InheritanceContainer::ON_CLOSE_ACTION);
And the receiving part of the parent could then decide if it has to be redrawn and if further action (that is associated with this event) must be performed.
void
SimpleDrawing::receiveContainerActionFromChild(const int actionId,
InheritanceContainer &child)
{
switch(actionId)
{
case InheritanceContainer::ON_CLOSE_ACTION:
ReDraw();
drawingBoard_->setBrush(brushPicker_->getBrush());
break;
case DrawingBoardForm::ON_SELECT_BRUSH:
brushPicker_->SetShowState(true);
brushPicker_->Show();
ReDraw();
break;
}
}
This simple conststellation serves its purpose. As long as the corresponding sides implement the InheritanceContainer, the Brush Picker can be taken “as is” and used in another project. All it has to worry about is sending the messages – regardless of whether there is a parent listening or reacting.
I am sure there are a thousand other ways to do it, if you find a better way you may want to post it at the forums perhaps?
Right now I am trying to find out how to pack components into libraries (static or shared) that could be used in various bada applications. Tips are much appreciated!
Related posts:
the Flagship of independent news, reviews and resources for Developers and Users of Samsung's mobile platform Bada 



9 Responses to “Components development for bada (Part 1)”
By comment01 on Jan 4, 2010 | Reply
Nice. But why not use something like boost::signal2 or boost Function?
Such an interface would be so much smaller, then having a class for this purpose.
By Wit on Jan 4, 2010 | Reply
Oh, that’s a nice one! I am not familiar with the boost library, but I will definitely take a look at it! Let’s see if it works for bada. Thank You!
By Nooa on Jan 4, 2010 | Reply
Does this technique consume more memory and resources?
advanced OOP is not recommended for mobile devices, as far I know…
By wit on Jan 6, 2010 | Reply
I guess that throwing another library into the app will add some overhead to the performance as well as some KBs to the filesize.
Honestly, I’d rather keep a small & clean solution of my own.
1. I have complete control over it and can modify it / debug it as I please
2. It is very small and straight-forward. Who knows what “boost” can do to your app. So why the headache?
By kassel on Jun 24, 2010 | Reply
Clear, and Simple.
Will be an tutorial of extending controls, and make rehusabel sef controls?