Layered UI or how to reuse UIs with MonoTouch and Silverlight

by ManniAT 29. March 2010 12:23

When we started the development of TTMoney one of our main goal was a “UI Designer” which should enable the User to change the look of his UI.
Think of it like “dynamic Themes”. Themes mean – I choose one and my colors, fonts, backgrounds, … change their style.

We wanted to go a step further an let the user compose his UI using a web interface.
Due to our skills we decided that this designer should be built using Microsoft Silverlight.

Since we use MonoTouch for our iPhone applications it is not really hard to share a lot of code.

The only challenge is the UI itself. For the iPhone we use (could use) the interface designer and for Silverlight we got Microsoft Expression Blend.
Sounds good – but it is unfortunately totally different. Not only from “how to use” – the output is the problem.

So one idea was to build a XIB – File parser (XIB files are what the Interface Designer generates) or a XAML (Blend output) file parser.

We decided NOT to build such a thing. Instead we designed our UIs to use a layered design.
This means: we have a “native UI layer” which mimics for an example the differences between a UIImageView (iPhone) and an Image Control (Silverlight).
This layer has to be changed when we transfer an iPhone UI to Silverlight.

Such techniques are well know form DALs (Data Access Layer). Using generics and some abstract methods and extensions it was not really hard to do this.
The only limitation is that MonoTouch has to compile all the .NET code (no Generic Methods and things like this) to native iPhone code.

Anyhow – this was not really a stopper. Especially Generics work very well and the rest is nothing more than to avoid some C# (.NET) elements.

Most of the “basic layer” work by translating controls (UIView becomes a Canvas for an example) and Property setters.
myUIView.AddSubview(ControlX) becomes myCanvase.Children.Add(ControlX).
And instead of setting the Frame (iPhone) we set “CanvasLeft, CanvasTop” and so on.

The abstract methods enable the framework to do enhanced things like animating something or things like this. While I start a storyboard in Silverlight I add a transition or something like this for the iPhone.

Above that layer a set of Generics are implemented. For an example – it’s an often asked question “how to have a background image in a UITableView…”. We have BackGroundViewController<TableViewController> for this.

We build our UIs completely in (reusable) code.
Negative: No rich UI designer.
Positive: It is more or less “platform independent” and it enables the things to be driven by a database.

Last not least Microsoft has Silverlight for Windows Phone 7 – and that means (with very little work) that our application will also run on this platform.

A simple example is this (very basic) Silverlight implementation of the “UI Themer”:
SLDesigner

A note about this “designer” – we’ve used the Telerik Silverlight Controls for it. And that shows how independent you could be if your “UI Layers” are well done.
We could have done the same thing using native Silverlight controls – but why if we have an easy way to use these enhanced Telerik  things.

We made this framework for TTMoney but while building this project we had the need to build another app.
This is Sticker and uses the Framework built for TTMoney.

Which brings me to my answer to Shawn Burke's great Blog Series.

I like what he wrote – except the “code line counting”. I fact most of the code is there to make the things work.
And if I calculate how much money you have left it does not matter if this is Windows Mobile 7 or iPhone code.
Building Sticker was about 200 Lines of UI code – the rest is “business logic”.
And for TTMoney we have ration of about 8.5 BL to 1.5 UI.

Of course – in both cases we have several hundred lines of code for the “UI Framework” – but this is totally reusable and will work in future projects also.

From my point of view the more important thing is how to handle “mobile specific” things in Windows Mobile 7 / iPhone.

Just as an example – Sticker allows you to send your “existing / missing lists”.
In MonoTouch the code looks like this:

Snippet created with CBEnhancer
void m_hbDoSendMail_Click(object sender, EventArgs e) {
        if(MFMailComposeViewController.CanSendMail) {
            MFMailComposeViewController mail = new MFMailComposeViewController();
            mail.SetMessageBody(m_strLastText + m_strStickerLink, true);
            mail.Finished += HandleMailFinished;
            this.PresentModalViewController(mail, true);
        }
    }
    void HandleMailFinished(object sender, MFComposeResultEventArgs e) {
        e.Controller.DismissModalViewControllerAnimated(true);
        if(e.Result == MFMailComposeResult.Sent) {
            Globals.MessageBox("Info", ULocalizer.ULOC["ZS_MailSent"].TheText);
            CloseDialog(false);
        }
        else {
            Globals.MessageBox("Error", ULocalizer.ULOC["ZS_MailSendError"].TheText);
        }
    }

 

I hope Shawn Burke will keep on extending his iPhone SDK vs. Windows Phone 7 Series SDK Challenge.

A last note – of course I’m not comparing with Objective-C – I talk about MonoTouch – but it is an existing technology – so why don’t use it.

Manfred

Tags: , , ,

iPhone | MonoTouch | Silverlight | telerik

Powered by BlogEngine.NET 2.0.0.0