Question

In a Xamarin solution, a typical grouping of projects is as follows:

SOLUTION
    CORE Project (shared non-UI code, referenced by all the other projects)
    Android Project
    iOS Project
    Windows Phone Project

With this solution architecture, you need to write platform-specific UI code for each (non-Core) project.

Wouldn't it be easier to just have two projects, like so:

SOLUTION
    CORE Project
    HTML5/CSS/jQuery/jQuery Mobile Project

What are the disadvantages? The HTML5/jQuery Mobile "clothing" doesn't look just like the native apps, perhaps; the performance may be not quite as good.

But would it be a viable option? I'm tempted to try this based on this statement: "...overall, Web applications are much easier to develop and maintain than multiple native applications in different languages" here.

I kind of see PhoneGap as a lowest-common-denominator GUI with separate native code, and Xamarin as a lowest-common-denominator subset of APIs with separate GUIS, and this proposal as a lowest-common-denominator of both GUI and APIs. But as a recompense for "slumming it" on both ends, the code is (partially) shared and all the GUI is shared (albeit tweaks and shims for various browsers would doubtless be necessary).

The main problem I can see is for those areas when platform-specific code would need to be written, such as for dealing with barcode scanning and peripheral device (belt printer) printing - where would it live?

UPDATE

Based on what I see in "Xamarin Cross-platform Application Development.pdf" by Doogie Howser, it seems the solution folderama should actually be like so:

SOLUTION
    FooeyBar.Core
        . . .
    FooeyBar.Core.Droid
        . . .
    FooeyBar.Core.iOS
        . . .
    FooeyBar.Droid
        . . .
    FooeyBar.iOS
        . . .

Thoughts/affirmations/refutations?

Was it helpful?

Solution

It is definitely possible to wrap a web front-end inside a native app. One of the headaches you'd get with Xamarin alone is that your UI will have to be almost completely rewritten for either platform you target (good business logic separation can reduce that pain).

One way to use web UI inside a native shell that integrates hardware is by writing a thin communication layer between the two that works by injecting javascript and custom protocol handlers, I've applied this strategy successfully on a project - it works and it lets you develop your UI once and then style it per device. The good news is you wouldn't need to depend on browser detection - your native apps can load their WebView with specific URL and the back end can determine which styles to use or even provide UI versioning and functionality changes between devices.

If you do take that approach make sure you write your native app comm layer as thin and generic as possible to reduce the need to update the native apps in the future.

OTHER TIPS

If you are going to be writing all of the UI in your app in html/javascript, why even use Xamarin? This is the main advantage that MonoTouch provides - a 100% native UI experience on each device (with a shared code base). If you want to go that route, just go with Phonegap or Titanium.

As for your example, it is not necessarily "easier", it is just a matter of what you want to accomplish or what you want your app to look like. I find the first approach with the separate projects to be "easier" for me. I also like the native UI that it provides on their respective platform.

The main thing is to find the tool that best suites what you need. I would not recommend trying to make one of these tools work like the other. This approach will get you sup-par results than if you would have just gone with either approach.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top