Is This A Good Use Case for Xamarin?

[tompkin]

I have a new mobile app idea and I need the app to run on both iOS and Android.

The user can enter data (such as registration information) from their phone or tablet, and send this information to a database in the cloud. Other than for the database administrator, the database will not need to be accessed by the user in any way other than by their phone/tablet app. 

I was thinking of using C# with Xamarin to make these apps. My question: Is Mono the "way to go" in order to make these apps and specifically do the 'sending and receiving' of the information from the phone app to/from the cloud database?

Thanks.

[Bamsebjørn]

Xamarin is a way to go, but it's pretty pricey. If you're willing to spend (at least) 25 dollars a month, then yes... Xamarin is a really good way to develop multi-platform. The sending/receiving information is deeply integrated into .NET/Mono so it's going to be easy...

[tompkin]

Xamarin is a way to go, but it's pretty pricey. If you're willing to spend (at least) 25 dollars a month, then yes... Xamarin is a really good way to develop multi-platform. The sending/receiving information is deeply integrated into .NET/Mono so it's going to be easy...

Xamarin is a way to go, but it's pretty pricey. If you're willing to spend (at least) 25 dollars a month, then yes... Xamarin is a really good way to develop multi-platform. The sending/receiving information is deeply integrated into .NET/Mono so it's going to be easy...

I'm not sure what happened to the above quotes. I only hit the quote button once.

Great! Thanks Bamsebjorn. I can handle the $25/month, etc. Just wanted to make sure it would do what I need. 

[tompkin]

I just realized that since it is a subscription, that if you let your copy of Xamarin expire, you no longer have any usability of Xamarin although your current apps will still work.

This is a deal killer for me because in the old days, before Visual Studio Community Edition, if you paid for a copy of Visual Studio you could still use it from then on. You didn't get upgrades but at least you could still use your old copy.

With the way Xamarin is, your at a a dead standstill if you no longer pay up. In my particular case I can't do that.

[DevTech]

https://xamarin.com/starter

* Apps must meet size restrictions(128k of compiled C# or F# code), include only managed code (not Objective-C/Swift, Java, or C/C++ libraries), and use Xamarin.iOS/Xamarin.Android, not Xamarin.Forms.

If your app is simple enough, it might fit within the free starter edition limits which despite the name appears to have no time limit.

http://unity3d.com/get-unity

The free version of Unity appears to be a better deal than Xamarin in some ways although you have to use their startup splash screen. Like Xamarin, Unity uses the mono C# runtime.

I have always speculated that a 3D gaming engine can make a more compelling non-game app than the traditional method if used in a low key artful manner. There are various UI libs available for Unity and again depending on your app there may be less code to use Unity since the UI surface would be identical in this case across all platforms.

Visual Studio 2015 has strong support for both Xamarin and Unity 3D.

There is also VS 2015 support for Apache Cordoba which probably has no cost or restricions other than putting up with the annoying Javascript as the programming language.

 

 

 

[+Biscuits Brown MVC]

Don't forget, Visual Studio 2015 Community Edition does ship with Xamarin so if your company is small enough to meet the licensing restrictions of VS 2015 Community, it may be a good choice to at least experiment. 

[DevTech]

Don't forget, Visual Studio 2015 Community Edition does ship with Xamarin so if your company is small enough to meet the licensing restrictions of VS 2015 Community, it may be a good choice to at least experiment. 

It uses the free Xamarin Starter Edition which limits the App code to 128K. That can be a lot of code so I'm not sure roughtly how one would illustrate the types of Apps that are not practical to be that small. Anyone know?

 

[+Sledge Subscriber²]

Just be aware that the startup times of mono on Android \ iOS can take a while and make your app look really slow in starting.

If you need a performant snappy app your best bet is native. If this is for enterprise users you can probably get away with it.

The learning curve for Xamarin is pretty low if you already know C# \ Xaml however you'll spend 80% of your time struggling to find why something won't work to find it's directly related to their implementation.

[PGHammer]

https://xamarin.com/starter

* Apps must meet size restrictions(128k of compiled C# or F# code), include only managed code (not Objective-C/Swift, Java, or C/C++ libraries), and use Xamarin.iOS/Xamarin.Android, not Xamarin.Forms.

If your app is simple enough, it might fit within the free starter edition limits which despite the name appears to have no time limit.

http://unity3d.com/get-unity

The free version of Unity appears to be a better deal than Xamarin in some ways although you have to use their startup splash screen. Like Xamarin, Unity uses the mono C# runtime.

I have always speculated that a 3D gaming engine can make a more compelling non-game app than the traditional method if used in a low key artful manner. There are various UI libs available for Unity and again depending on your app there may be less code to use Unity since the UI surface would be identical in this case across all platforms.

Visual Studio 2015 has strong support for both Xamarin and Unity 3D.

There is also VS 2015 support for Apache Cordoba which probably has no cost or restricions other than putting up with the annoying Javascript as the programming language.

 

 

 

And VS Community (both 2013 and 2015) supports it all - including Apache Cordoba.  The equivalent-to-the-old-VS Pro range and feature support is *exactly* why Visual Studio Professional went away.  You can also install Unity 3D (and everything else) from within VS Community via the Options pane (Tools->Options).  And as far as dealing with Java/JavaScript, if you are going to develop for Android, Java is something you will have to deal with anyway.  If you are serious about multi-platform, make sure your host has Hyper-V support, for two reasons - Hyper-V has better performance as far as emulation goes (especially for WM - I'm waiting on a W10M emulator, though), and (at least for Android development) it's safer than Genymotion (Hyper-V is better isolated than OVB, which is the core of Genymotion).  My only quibble is the lack of ES OpenGL support in Hyper-V - I'd like to see an add-in for Hyper-V similar TO Genymotion, so you can leverage ES OpenGL in Android development in VS Community (right now, you can't).

[simplezz]

http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html

[DevTech]

http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html

That is a simplistic system that has no ability to target Windows Phone or Windows Tablets.

You make Apps in Javascript or Java and deploy only to IOS or Android.

Might as well use Cordoba and get all the targets included.

 

[greenwizard88]

+1 for Apache Cordova. Xamarin is just too expensive for overly basic apps that could run from a web browser.

[Mathachew Veteran]

The learning curve for Xamarin is pretty low if you already know C# \ Xaml however you'll spend 80% of your time struggling to find why something won't work to find it's directly related to their implementation.

This!!

[DevTech]

+1 for Apache Cordova. Xamarin is just too expensive for overly basic apps that could run from a web browser.

The OP never actually said the App was basic or simple.

tompkin - you could try AppStudio as a prototyping tool:

http://appstudio.windows.com/en-us

It will generate a well structured C# project you can download and convert to something and you can run it on your Win 10 machine to test it out without needing to learn anything at all.

It might be possible to get a sense of how you app will work by doing this.

Azure has a simplified mobile data store and other typical stuff that doesn't need much coding for the normal things apps do:

http://azure.microsoft.com/en-us/services/app-service/mobile/

None of that will get you an Android an IOS App but the Azure stuff works with Android and IOS and the AppStudio code can be converted to Xamarin.

It seems totally imperative for a single developer to come up with a path through the mobile mess that maximizes the value of the effort you put in. So I'm quite interested in seeing what you decide and/or kick the tires on in the process of your interesting journey...

 

 

[simplezz]

http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html

That is a simplistic system that has no ability to target Windows Phone or Windows Tablets.

You make Apps in Javascript or Java and deploy only to IOS or Android.

Might as well use Cordoba and get all the targets included.

 

The OP made no mention of Windows or Microsoft platforms:

I have a new mobile app idea and I need the app to run on both iOS and Android.

The mobile framework makes use of popular and standardised languages and technologies such as Java, Javascript, and Html5; The kind of skills that are easily transferable. Unlike Xamarin, which is basically a hack to make an unpopular mobile language (c#) work on the the dominant platforms (Android/iOS). Putting all one's eggs in the c# basket is analogous to Nokia's exclusivity decision. And look how that turned out.

It's well worth investing in Java and other standardised web technologies because they have a built-in longevity. C#, and Microsoft platforms on the other hand are on the decline.

[greenwizard88]

The OP made no mention of Windows or Microsoft platforms:

The mobile framework makes use of popular and standardised languages and technologies such as Java, Javascript, and Html5; The kind of skills that are easily transferable. Unlike Xamarin, which is basically a hack to make an unpopular mobile language (c#) work on the the dominant platforms (Android/iOS). Putting all one's eggs in the c# basket is analogous to Nokia's exclusivity decision. And look how that turned out.

It's well worth investing in Java and other standardised web technologies because they have a built-in longevity. C#, and Microsoft platforms on the other hand are on the decline.

I don't think you get "it" very well. Xamarin is not a hack, it's a native compiler, and it allows developers to develop an app once instead of 3+ times. It's built off of a language that's open source and easier to program in than Java. The only downside of Xamarin, at all, is the price.

[simplezz]

I don't think you get "it" very well. Xamarin is not a hack, it's a native compiler, and it allows developers to develop an app once instead of 3+ times. It's built off of a language that's open source and easier to program in than Java. The only downside of Xamarin, at all, is the price.

Regardless, it uses a JIT compiler, thus it's not a real native compiler. ART java applications are compiled to native executables. You don't get that with Xamarin:

• Ship native Android packages.

  Xamarin.Android uses just-in-time compilation for sophisticated runtime optimization of your app’s performance, meaning your app is a native Android APK.

Notice it says native APK, not a native application. A lot of people are under the assumption that you get the same performance as a native ART app. According Xamarin's own description, you don't.

This is how it really works:

On iOS, Xamarin’s Ahead-of-Time ( AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code. On Android, Xamarin’s compiler compiles down to Intermediate Language ( IL), which is then Just-in-Time ( JIT) compiled to native assembly when the application launches.

http://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/#How_Does_Xamarin_Work

As you can see, compilation occurs every time the Xamarin app runs. That's a lot slower/resource demanding than a one-time on-install natively ART compiled Java application.

Another problem with Xamarin is, you'll need to redesign your UI on both Android and iOS. There isn't a single unified UI library. So the claim that you can write once and run on three different platforms is a lie.

As for being easier to program than Java, that's complete hogwash. I've written programs in both languages, and there's little difference in the syntax itself. Mainly because C# copied most of its syntax from Java. Where it really differs is in its Library. The fact that Java is truly universal (runs everywhere) gives it a massive edge. I can take a piece of domain logic written on the desktop (Linux, OS X, Windows) in Java, and drop it straight into an Android app that compiles and runs natively. You simply can't do that with C#.

[greenwizard88]

JIT compiled native assembly is cached, so it isn't compiled for each launch, just the first one. That's why Android apps sometimes have a slow startup the first time, but not on subsequent startups.

Another problem with Xamarin is, you'll need to redesign your UI on both Android and iOS. There isn't a single unified UI library. So the claim that you can write once and run on three different platforms is a lie.

 

Interestingly enough, I do just that at my company. It's the Xamarin.Forms UI toolkit.

[DevTech]

 

 

Another problem with Xamarin is, you'll need to redesign your UI on both Android and iOS. There isn't a single unified UI library. So the claim that you can write once and run on three different platforms is a lie.

As for being easier to program than Java, that's complete hogwash. I've written programs in both languages, and there's little difference in the syntax itself. Mainly because C# copied most of its syntax from Java. Where it really differs is in its Library. The fact that Java is truly universal (runs everywhere) gives it a massive edge. I can take a piece of domain logic written on the desktop (Linux, OS X, Windows) in Java, and drop it straight into an Android app that compiles and runs natively. You simply can't do that with C#.

It is hard to tell if you are being serious or just promoting a favorite tech product of some sort.

There are only 3 programming languages that allow you to have a significant base of common code in an App and reach all targets:

1. Javascript running in a browser for which the browser is hidden behind the scenes in the case of various App packaging techniques.

2. C++ using OpenGL

3. C# via Xamarin on IOS (native) and Android (JIT) , Windows 10 API native compile, .NET JIT Windows Desktop, Mono JIT Mac OSX.

4. A possible 4th candidate is Objective-C which Microsoft is making open source for Windows and somebody might port to Android

Some real App developers have reported up to 80% common C# code with 20% spread across the UI for various platforms.

Java simply does not have this kind of reach and despite it's original aim of "run everywhere," it simply does not. That's just a fact no matter how much I might like to see it otherwise.

 

[tompkin]

I didn't realize this thread had been active.

 

Since my original post, my thinking has evolved and I will include some additional information.

 

When I wrote my OP I was trying to figure out what the best way might be to be able to "easily" create the UI for my apps on iPhone, Android, and Windows Mobile. Xamarin seemed like a good choice until I saw the price.

What I didn't include in my OP is that I will be using a backend that is pretty much a Java world. It's possible that I could use C# but it would take a lot more work on my part to get that part to work because there hasn't been as much support on GitHub.

Because the backend would require so much more work in C#, I decided to do the Android UI myself, and get someone else to do the iPhone UI.  I had not heard of the Oracle Mobile Application Framework but would be hesitant about that until I looked at their licensing. I remember looking at their Application Developer Framework (ADF), and loved it until I saw the licensing.

 

When Windows Mobile "takes off" I will just get someone else to do the UI because at that point I will be too busy to do it and will need someone else anyway.

I call my idea an "application" because it actually uses two separate mobile apps. If you imagine a company who has vendors, the vendor would have one app and the company would have another app. They both access the same backend but each app enters different information. So this is not a "basic app" in the sense that someone mentioned earlier.

 

I'm doing my "proof of concept" with an Android (because that's what kind of tablet and phone I have) but it will have the other UI's as soon as I verify that there is a market for the idea.

 

Since my Java is rusty and I haven't done any Android development before, I decided to buy the Java/Android course through Neowin when it was on sale. It was $27.00 at the time and so it was a great deal. So that's what I'm going through right now.

The course uses both Eclipse and Android Studio, although Eclipse is no longer supported by Google.

 

So far, I've gotten a "hello world" app working on my tablet from Eclipse so that's the first step.

 

Technically, I think that this is a very interesting application and will posting back in the forum, from time to time,  for topical discussions.

[simplezz]

JIT compiled native assembly is cached, so it isn't compiled for each launch, just the first one.

Perhaps. It's still not a native executable like AOT compliation java apps.

That's why Android apps sometimes have a slow startup the first time, but not on subsequent startups.

That hasn't been the case since Lollypop (Kitkat technically, though not by default). ART performs an AOT compilation when a Java app is installed, creating a native executable. There's no JIT involved any more. Xamarin on the other hand still uses JIT. Consequently, performance is degraded and the battery life of the device is adversely affected.

[simplezz]

Some real App developers have reported up to 80% common C# code with 20% spread across the UI for various platforms.

Java simply does not have this kind of reach and despite it's original aim of "run everywhere," it simply does not. That's just a fact no matter how much I might like to see it otherwise.

Yes it does. As I said earlier, A lot of Java code (domain logic/persistence logic) will run across all platforms, including Android. iOS is also possible via Oracle's ADF framework as mentioned earlier, Google's J2OBJC, and a few other frameworks flying around.

Xamarin's write once run anywhere claim is vapourware. It might work for a quick simplistic demo, but I've yet to see any serious developers using it. There's a reason for that.

[DevTech]

Yes it does. As I said earlier, A lot of Java code (domain logic/persistence logic) will run across all platforms, including Android. iOS is also possible via Oracle's ADF framework as mentioned earlier, Google's J2OBJC, and a few other frameworks flying around.

Xamarin's write once run anywhere claim is vapourware. It might work for a quick simplistic demo, but I've yet to see any serious developers using it. There's a reason for that.

Seriously, there is nothing wrong with saying you like a certain technology or vendor because it suits your own personality or whatever.

But to spread serious technical dis-information to support your own technical fantasy world seems out of place in this type of discussion where tompkin was looking for some ideas.

Miguel de Icaza has worked for years on cross platforn .NET and his company has over 1,000,000 developers using this technology to make Apps. That by no stretch of anyone's imagination is "Vapourware"

https://en.wikipedia.org/wiki/Xamarin

If you think Oracle makes the best products on Planet Earth, well that's just fine. But I strongly suspect they don't have 1,000,000 ADF users. Correct me if I'm wrong, I always like to be accurate.

Unity 3D also uses Miguel's C# Mono framework to run on 21 different platforms:

https://en.wikipedia.org/wiki/Unity_(game_engine)

That adds another 1.3 million cross-platform C# developers.

C# really does run everywhere and Gosling should be proud of this bastard grandchild of his original conception....

 

[Andre S. Veteran]

Perhaps. It's still not a native executable like AOT compliation java apps.

That hasn't been the case since Lollypop (Kitkat technically, though not by default). ART performs an AOT compilation when a Java app is installed, creating a native executable. There's no JIT involved any more. Xamarin on the other hand still uses JIT. Consequently, performance is degraded and the battery life of the device is adversely affected.

In both cases the intermediate language is compiled only once so I fail to see how battery life is affected? And how does a cached JIT-compiled executable differ from an AOT-compiled executable and how is it less "native"? You know, assembly code doesn't care what technology was used to generate it, it always has the same performance.

[simplezz]

In both cases the intermediate language is compiled only once so I fail to see how battery life is affected? And how does a cached JIT-compiled executable differ from an AOT-compiled executable and how is it less "native"? You know, assembly code doesn't care what technology was used to generate it, it always has the same performance.

How do you know it's only compiled once? As for the difference, JIT increases startup time, memory usage, and battery drain significantly. ART's AOT compiles in the background without impinging on the app's performance.

[Andre S. Veteran]

How do you know it's only compiled once? As for the difference, JIT increases startup time, memory usage, and battery drain significantly. ART's AOT compiles in the background without impinging on the app's performance.

I was just going by what greenwizard88 stated above. If the compiled code is cached after JIT then the next startup is basically as fast as AOT since there's no compilation taking place again. Still not sure what you mean by JIT-compiled assemblies not being "native" like AOT ones. The only differences are the moment at which they're compiled, and on which execution environment they run (Mono for C#, ART for Java). Both are assembly code, neither are "native" in the sense of not needing a VM.

Looks like Xamarin on Android is adding support for AOT anyway.

It's worth noting that AOT poses particular challenges to the CLR because it supports both reified generics and value types. Because instantiations of generic functions cannot be shared for different value types (since value types have different sizes in memory), a separate function must be compiled for each one. This is not an issue when code is compiled Just-In-Time, but for AOT you'd need to somehow predict every possible instantiation. Not entirely unfeasible, but with limitations (for instance https://developer.xamarin.com/guides/ios/advanced_topics/limitations/ ). Java doesn't have this issue because it has neither of those features, which makes Java easier to compile ahead of time, but unsuitable for the kind of fast generic numerical code that can be achieved in .NET (or in C++ with templates). Just an example of how JIT compilation enables performance optimizations that are otherwise impractical.

 

Edited September 12, 2015 by Andre S.