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.

[simplezz]

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.

JIT compliation occurs at runtime by its very nature, thus a native binary doesn't already exist. Whether or not Xamarin caches JITs I can't say. It will almost certainly have an impact on application performance though compared with an AOT precompiled native binary.

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.

Interesting. I know Java has type erasure because I recently came across the problem of recreating a typed list at runtime with it. I ended up having to use a non-typed list:

public List readCollection(Class type) {
    List collection = new ArrayList();
    int count = readInt();
    while (0 != count--)
        collection.add(readObject(type));
    return collection;
}

Whereas in C#, I was able to instantiate the same list by its generic type:

public IList readCollection(Type t) {
    IList collection = (IList)Activator.CreateInstance(t.GetGenericTypeDefinition().MakeGenericType(t.GetGenericArguments()[0]));
    int count = readInt32();
    while (0 != count--)
        collection.Add(readObject(t.GetGenericArguments()[0]));
    return collection;
}