ASP.Net Calendar and mobile devices

ASP.Net 2.0 and above supposedly adds to ASP.Net 1.1 Mobile Controls and extends mobile support to all of its regular controls. It does that with ControlAdapter and some other facilities. Mobile Controls are still there, but are no longer being developed.

That's all well until we try to use the Calendar control. On the client side, the calendar control is little more than a table with links. The links call a JavaScript function (__doPostBack). Some mobile devices don't support tables; most have problems displaying them well. JavaScript is poorly supported on most feature phones. Altogether that excludes the regular Calendar control for most phones. But what about the mobile Calendar control?

On capable devices the mobile Calendar control displays a normal Calendar, but on other devices it falls back to a multi-form selection process. Not a bad idea on its own, though a mid-way solution that avoids JavaScript would be preferable for most devices. The problem with the multi-form selection is that some of the interface is non-localizable, leaving us with a half-local half-English calendar.

With no other solution in sight I rolled up my sleeves and went on to create a tabular non-JavaScript Calendar control. If it ever becomes professional grade I just might open-source it.

The biggest problem so far is how to make the custom control "play ball" with other controls on the same page. I'm using query parameters to control the month displayed and I'm trying to keep the state of other controls (what is usually referred to as ViewState, but is actually ControlState).

My current version is intrusive - it doesn't "play ball" - and it's enough to fit my current needs. I hope I'll get the chance to make a better one.

What I found in J2ME, and what I didn't

J2ME follows the 80-20 rule. It has 80% percent of everything any application needs:

• It has third party extensions, such as J2ME Polish.
  
• It has an established developers community.
• With NetBeans it even has a UI designer.
• There are ways to update an application.
• And a standard way to connect over HTTP.

Problem is you can't make an 80% application. What I needed for J2ME to be relevant is:

• A way to launch the browser.
• Some facility to handle incoming calls.

• And a standard way to control outgoing calls. You what - nevermind standard, I would have taken anyway that actually works, even on a per-phone basis. MIDLet.platformRequest() doesn't let you control the call.

I'm on my way to explore Symbian. Will report news from there soon.

StackOverflow.com

I'm begining J2ME programming and the generous community at stackoverflow.com has helped my a lot.

See all Q&As StackOveflow has on j2me here.

See all my Qs and As here.