I work i a company which basically likes to have it’s own GUI and tools framwork to work with for both java and c++ codes.
They first create the basic code, set up interfaces to work with “shared code” and then “platform code” is created to support different platforms (windows\linux\symbian etc…)
The real advantage used to be that:
1. we had some great (well relatively 
) GUI when you compare it to the native GUI (on WM 6.5, old symbian devices and J2ME deices)
2. our applications looked the same on all platforms, major plus if you are used to our application and change your phone to a new platform.
3. most ports are easy enough.
It all looks pretty pinky on the horizon, only times have changed.
To be honest i think that even J2ME have prettier GUI these days and if not you can still use LWUIT which is open source.
Basically today when things like ‘Palm pre’, iPhone and Android devices are around using your own GUI framework is a waste of time and money, I’ll list the major reasons from my experience shortly, i hope all of you out there will learn and avoid them!
Native platforms such as symbian, windows and moblin also have their own GUI, but among them i must say only symbian can pass regarding normal GUI, the rest do ned some kind of graphics framework even today, though roomer say that WM7 comes with silverlight framework, which also means, GUI is inside, waste of time to create your own!
When i say GUI i mean – menus, list screens, tabs, forms, everything that got to do with displaying and retriving data, including pop ups, alerts, image views and the like.
However in some applications, mostly games, there is the mandatory part that has nothing to do with those objects, luckily in most cases, for a game you ned the following interfaces to work :
1. 3D or 2D graphics object which allows you to draw on (canvas) you should supply more then the basics usually, only rects, lines and text wont do…
2. sound player interfaace that allows to set up a player for a stream\a file and play it on demand.
3. event handling mechanism that can handle touch events, keys events and maybe external events as well (such as sensors).
So as you can see game developers should ave their interfaces set up and need to port to a new platform.
The plus side is , one you’ve finished the port all the game screens will work ‘out of the box’.
The minus is the porting of course .
The lesson i’ve learned from my company porting policy is this:
1. Always work in MVC mode and test yourself that your controller is indeed ‘view free’. it’s so easy to fall for a tightly coupled GUI with controller, don’t do it it il cost you dearly in the future!
2. Once you have an MVC take into account that for every new platform you most likely need to define a product and create new screens for your whole app. You wont have consistent view over all platforms, but not all platforms GUI is the same, you better have an app that looks like native apps so users can intuitively enjoy them,also the time you think will be wasted in the near future is time you save for future new products on that platforms that will need your bug fixes because you used your GUI and made ugly hacks to make it work…
3. for the parts that can’t be written in the platform native code like the games screens, you interfaces and factories, and lots of them, the more you’ll use the easier the porting will be, strange as it sounds, the more interfaces the more flexibility you’ll have in the design and implementation later for example sounds player can have ISoundPlayer interface you can implement tat can contain Play(File), stop(), isPlaying() init() etc.. but it can also have IMixer that can help control the volume or join sounds, ISoundManager to help convert sounds formats and streams etc.. the factory to return those interfaces can always return null for empty implementation and the main implementation can make sure not to use it on null. Better that then not having the ability to do it or use hack to solve it…
That’s it.
I think i will post some interfaces examples in the near future maybe with android implementation and maybe with QT 4 as well. If i’ll have the time
