Dudu Mimran Blog

Easily develop cool UI in native client applications

For a long time I was contemplating on the best strategy for client application development, mobile clients or desktop client applications. The problem with native client application development is usually the difficulty of building the UI and applying changes to it over time. Since I did both web development and client development I am accustomed in the web area for the ease of UI creation as well as applying changes to it. In web development all you have to do is have a good designer create something very cool for you, turn it into XHTML/CSS/JS and you have got your UI ready. If you have changes then just modify the HTML/CSS and you are done. For native clients it is a whole different story. Although UI frameworks and libraries have evolved greatly over time still programming the UI in a structural or object oriented 3rd generation language is slow and cumbersome needless to say about changes. And I have to add that it never comes out so lovely as web based designs.

Adobe Air have introduced a new programming pattern with their ability to make a web application behave as a native client application while all the UI hassle is taken away. Basically they provide a window frame and inside of it you have a special web browser (I guess webkit) and within the web view you can have all your beautiful web stuff while integration to the logic and general native application capabilities is easy. This development pattern can be applied to many other development frameworks including QT which has an embedded webkit capabilities, Android Java, Windows Mobile IE view and others.

The idea is to have all your UI in local resource files (for high response times) of course based on web standards - XHTML/CSS/JS - and to connect the browser events to your core logic. Most of the platforms allow you to expose logic into the browser via Javascript functions. This approach can provide the best of two worlds, highly responsive UI with all native application capabilities while keeping an easy way to create and modify the UI look and feel.

Another cool thing you get with this approach is ease of platform porting where the UI is already compatible with other platforms since it is based on Web standards.

Firefox my new operating system

Firefox recently reminds me of MS Windows. Everytime it starts up it checks for updates. Then it checks for updates for the plugins. Then it loads some of the plugins. Eventually it takes around 10-20 seconds for the first page to appear and if this is not the sign browsers are the new operating systems I am not sure what is.

Thoughts on application development and setup in windows vs. linux

After many long years of development to both MS Windows platforms and Linux platforms and especially lots of frustration in recent days trying to install/uninstall software on my WinXP to solve a problem I have few conclusions on proprietary vs. open source development.

One of the nice things about development in Microsoft world (or at least seems so until you get into trouble) is that everything wraps up so nicely as if you were in a candy store. There are very nice tools for development and there sophisticated mechanisms for code reuse such as DLLs and libraries as well as well documented APIs and examples. Microsoft as a sole owner of the MS Windows platform has created a complete eco-system of dev tools to enable you as a developer to rapidly develop your own applications. One simple MS-Windows application usually relies on many, many dependencies such as other products installed/service packs/specific operating systems/DLLs and actually when you wrap your application as a setup package you usually rely on these to exist in the target computer and to be (hopefully) compliant with your specific application requirements. To package all dependencies into your application is not relevant and some do package unique extensions that are required but most just deliver their own app relying on Microsoft to handle dependencies.

This mechanism works very nice in a controlled environment world where you fully control the setup of your test machines but once you go into the wild where the variety of combinations of configurations are enormous, things usually break. Especially after few install/uninstalls of few apps where each one leaves its trails of broken dependencies. Actually as I see it a MS-Windows PC that has received a normal "dosage" of installs/uninstalls becomes actually chaotic in terms of what is actually residing in it. Here the lack of awareness to what your application actually needs and depends on works to your worst.

On Linux/Open Source world when you develop you usually know what you are depending on and the approach is more minimalistic in terms of depending on too many components to already reside on the target computer unless it is a specific runtime platform like perl or python. This approach makes your dev/packaging process seem at first more "dirty" and requires hands-on experience but the end result is a way more stable deployment then what you could achieve in MS World. Usually install/uninstall of software on Linux does not affect the rest of the system and the instructions on how to make your software work can become very clear. This is attributed to the way Linux and open source in general has been developed by different independent minds who found an effective integration approach unlike MS "integrative" one.

I am not sure whether it is MS goal to achieve perfect automatic/transparent platform but still eventually the more hand-on approach seem to work better. This opens up some thoughts on APP store like approaches for iPhone for example where there a similar simplistic approach to handle deployment automatically is being taken. Currently in the App store frontier with the low amount of software packages and low complexity of available apps nowadays the problem does not seem to exist but still time will tell how it will deal with complexity similar to MS variety.

That is also why people like web apps a lot where no "apparent" setup happens though this environment goes also through changes that make it "stickier" to te target platform such as Google Gears and native code implementations.  Actually within browsers the setup happens on demand and new code deployment happens automatically where dependencies are minor since the browser separates automatically dependencies between domains.