wxMobile
Julian Smart
I'd like to propose an addition to wxWidgets called wxMobile, to help
with writing mobile applications using wxWidgets.
You can read and update this page:
http://wiki.wxwidgets.org/Development:_wxMobile_Proposal
This has links to screenshots, a Windows demo binary, the current source
snapshot, and Doxygen-generated documentation which includes an
overview. The overview should answer most questions about the thinking
behind wxMobile, but here's a summary.
Developing for small, touch-screen devices such as the iPhone is
sufficiently different from regular desktop development that inevitably,
you need to use different controls and usually a different approach to
the structure of the GUI. You also need a particular development
environment, such as a Mac (for iPhone app development) or a Windows
machine (for Windows app development). The motivation of wxMobile is to
smooth out differences between different mobile platforms, and also
provide for app simulation on any desktop machine. It should be possible
to use familiar wxWidgets RAD tools for developing mobile apps, reducing
(though not eliminating) the dependence on vendor-supplied tools and
environments.
My thinking is this: I _don't_ think it's possible to come up with some
magic, generic, mobile API that maps automatically and authentically to
each device such that you'd never know it wasn't written natively. The
devil is in the details and the result of such an approach would be
unsatisfactory. I don't think you could ever abstract sufficiently to
accomodate all native APIs. For example, it's hard to see how you would
iron out the difference between a menus-and-dialogs UI versus the richer
table and window-stack-based approach of the iPhone.
Instead, my approach is to see how far we can get by basing the wxMobile
API mostly on the wxiPhone port that Stefan Csomor is developing.
Manufacturers are already being influenced by the iPhone UI, as can be
see by the Touch Flo GUI layer provided by HTC on top of Windows Mobile,
which makes it more practical to use the touch screen without a stylus.
While perhaps being less native, our wxMobile WinMobile apps could end
up more usable than a straight native app. However, we may find ways to
add native UI with as little additional programming as possible.
So, wxMobile is a start at an evolving mobile API that favours an
iPhone-like UI but that can be adapted to more native behaviour by
providing platform-specific functionality (again, using
wxWidgets-friendly classes to make this an entirely acceptable
compromise). Of course, there's absolutely nothing to stop people
writing mobile apps natively without using wxMobile, so we're not taking
anything away. And you might choose to use wxMobile simply to write
wxiPhone-only apps, with the ability to develop on non-Mac machines.
Currently wxMobile only exists as a simulation to be run on a desktop
machine, since wxiPhone is in development. Obviously I've made a lot of
assumptions about the actual wxiPhone API but it shouldn't be hard to
resolve API conflicts given that the functionality is basically the
same. Some things could be teased out into common headers. Before
wxiPhone is done, we could work on a wxWinCE version that mixes native
and generic controls. We can also investigate the up-and-coming Maemo
OS, assuming they're still supporting GTK+ and therefore wxGTK, and see
how wxMobile can be adapted to that (probably needing some additional
work on wxGTK/Maemo).
Anyway I would be interested in what people think, and also help with
fiddling with configure, bakefiles etc. if we decide to add wxMobile to
wxWidgets trunk.
Regards,
Julian
--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.dialogblocks.com
Blog: www.juliansmart.com