Anti-Activity Pattern

Image via Wikipedia

Are we ready to really do quality UI Application design yet? You do realize that most Android Training houses/firms do not cover it right? I should know I went through some interviewing for Andriod Training positions recently. Not that Android Training houses/firms are bad..its just that if the goal is designing Mobile Applications for Consumer and Business users than lets bring to bear all the skills and knowledge areas required rather than just code.

Here is the deal. You want to cover Android OS versions from the newest one that was released to the old ones. But, the  APIs are in flux. What that means is we do an anti-pattern because we still have stable not changing much control of view animation, transitions, etc rather than guess what activity transitions we may or may not have control of on a given android OS version.

Thus, we put a whole bunch of activities in activity class and use the view visibility setting and some other code to make views visible and invisible as the user is using the different areas of the application. You will end up, for example, coupling the application dashboard you might design with the PreferenceActivity  and SplashActivity as one big activity class as user case wise they are related tasks in that they can share the same data, etc.

It eliminates worrying about which OS version has activity transitions right as far as developer apis to control allows you to focus on the behavior of the application UI being as close to as possible the same on all Android versions. At the most you will end up with just two activities in your application code but a very cool application user interface that behaves the same way on all android versions and allows you to innovate with within that application user interface to brand that UI as your firm’s own UI.

Okay back to code, samples coming this weekend.

Perfect Continuous Integration Server

Last year, 2008 or 2007,  I had the idea of integrating Tiddlywiki with Eclipse to somewhat drive the build/development process. However, for whatever reason that is just too brittle of a combination. But, picture this an Eclipse Continuous Integration Server.

You start with e4 project as the front end combined with RCP. Than of course part of e4 extends towards the backend but also inclduing say jetty, Sqlite, Eclipse BiRT, and etc. Than you take the API Modular principes of the Glean project and  move that form in pure ANT to say groovy. enable the Dashboards as Groovy/grails integrated with e4. It would be aprefect test of e4.

Now for the engineering part, how does one talk Motorola into doing a Mobile Application version that targets an Eclipse Continuous Integration Server for Android developers? Damn it I want one.