Home/ Questions/Q 1083925
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T22:29:50+00:00

I’m currently implementing a Monotouch application that will eventually be ported to Monodroid. The

  • 0

I’m currently implementing a Monotouch application that will eventually be ported to Monodroid. The application is just a client to an OData Web service. Nothing too fancy or performance critical.

The challenge is to reuse as much code as possible. I’m aware that the UI APIs for Monotouch and Monodroid are quite different, but I’m hoping to to reuse the data data abstraction and business layers.

Since my UI layer follows the MVP pattern, I also hope to reuse UI controllers by coding an abstract representation of each view. However, I can only guess if this will work since I am not yet allowed to the Monodroid beta.

Now my questions:

  • What do you think about this approach? Is this a good idea, or will it just lead to a mediocre application because of differences in the UI concept between IPhone and Android?

  • Can you offer any hints on how to structure the application to maximize code re-use?

Thanks,

Adrian

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What do you think about this approach? Is this a good idea, or will it just lead to a mediocre application because of differences in the UI concept between IPhone and Android?

    I would say the latter, but you can definitely re-use a large portion of your business and domain objects. The same Mono Sqlite is used in Monodroid, so the data persistence part of your app (if it uses that) is re-usable.

    I wouldn’t bother creating a middle layer UI – the two are completely different. For example on Android apps you have the bottom menu, which can contain 6 buttons on screen. On the iPhone you are more than likely not to have 6 buttons in a tab bar or toolbar. To make a common pattern for that won’t help you much.

    Another example is ListViews (UITableViews). They’re completely different. As you’d expect the Monodroid implementation is faithful to its ugly Java sister. On Android you don’t have to use the huge tangle of indirection that Apple force upon you, but just a simple ArrayAdapter as the data source – subclassed for more complicated layouts.

    Another important thing to note is Android doesn’t have one screen size. You create images for 3 different screen densities. Font sizes aren’t absolute.

    Android provides you with layout mechanisms similar to XAML and the web, on the iPhone you’re not so lucky (or more fortunate, depending how you view it) as everything is generally absolutely positioned (they can do this as it’s always 320×480).

    Can you offer any hints on how to structure the application to maximize code re-use?

    I think you’ve got most of covered with separate layers for the data and sticking to controllers. Without seeing your app it’s hard to say how easy it will be re-use the controllers (whether you use UITableViews or custom uis), but Android is so much faster to develop with I think it should be a quick task.

    (I’m on the Monodroid preview and also have a MT apps out)

    • 0