Does MvvmCross work in Xamarin Studio? - xamarin

I'm having a time getting a straight answer on this, I've done a lot of searches and reading, and tried a lot of stuff. It sometimes sounds possible and other times only sounds possible by doing linking and what-not, which is something I'm trying to avoid. I'm a big fan of PCLs.
I've created a solution using Visual Studio 2012, Xamarin, and MvvmCross which works great, I can deploy to an iOS device, a Droid device, Windows --- what have you. Visual Studio can build working applications that I can deploy to specific platforms.
However, I was informed recently that our company requires that when we go to deploy, the code must be built on a Mac using Xamarin Studio by their build server. So since then I've been working on trying to open and build everything using Xamarin Studio, and I'm close, but the infamous ICommand issue is my final hurdle.
Is there, or is there not, a way to get ICommands and the System.Windows library ported in correctly in Xamarin Studio? Am I truly stuck until Xamarin releases their PCL support?

Does MvvmCross work in Xamarin Studio?
Yes
To prove it:
quite a few of the N+1 videos show this being used.
lots of the samples (all of the non-nuget ones) build and run from XS
Is there, or is there not, a way to get ICommands and the System.Windows library ported in correctly in Xamarin Studio?
The problem currently is that on the Stable branch, the xamarin compiler doesn't like the PCL import of MvxCommand which inherits from ICommand
A hard way around this problem is:
rewrite the Xamarin tools to support PCLs - this is what the brilliant, lovely and very clever Xamarin monkeys are currently doing :)
Or... a slightly easier way around this problem is:
replace the nuget references to the PC-built libraries with references to the Xamarin-Mac-built libraries instead - these Xamarin-Mac-built libraries are available in https://github.com/slodge/MvvmCross-Binaries/
Or... a really easy way around the problem is:
instead of using MvxCommand in your view models, just implement your own MyCommand class to implement System.Windows.Input.ICommand (e.g. use the implementation at http://www.lines-davies.net/blog/?p=24)
Am I truly stuck until Xamarin releases their PCL support?
I don't think so - but where you do hit problems:
please do come back to sites like StackOverflow with one specific problem at a time - this site is great for finding solutions one at a time :)
talk to Xamarin support - they are generally very helpful in trying to resolve issues.
What's more, even if you were stuck waiting... then Xamarin have already released their PCL support to the Alpha channel - so the wait is almost over already :)

Related

How do you compare (ReactNative, NativeScript) to Xamarin?

Since [ReactNative/NativeScript] uses JavaScriptCore/V8 JIT interpreters and not compiling it so, is it strong enough for building all types of apps e.g. (Mediaplayer, Photo Editing, etc…)?
And how do you compare it with Xamarin?
I heard Xamarin uses AOT; is it similar to (JavaScriptCore/V8) JIT interpreters?
And how often Xamarin uses AOT for all of the app or it compile the part of code to native and uses AOT for rest of it?
Many Thanks in Advance.
Xamarin does AOT for its C# code, which will be run by open source port of .NET -Mono in non windows platforms like Android and iOS. Here are some limitations on Xamarin AOT
In comparison, Nativescript with Angular 2+ can take advantage of the Angular AOT for performance boot. More details here.
Here is a detailed comparison from Progress, the company that backs NativeScript and also provides UI elements for xamarin.
With more traction towards JS open source community, JavaScript virtual machine growth vs Mono for .NET, current benchmarks, I would bet on NativeScript/React native more than Xamarin.
NativeScript / React Native is a good bet, including your media player kind of app.. here is a sample you can give it a try.
Hope it helps.

Should I choose Xamarin native or Xamarin.Forms for existing Android app?

We have an android application and want to recreate it for cross platform.
What are the facts for or against Xamarin native and forms?
The advantage of native would be, we could reuse all the xml-layouts while we have to recreate the iOS view in either XAML or XIB?
Is there anything what is really a blocker?
I'll comment based on Giorgi's answer with some actual insight and refer to the copied bullet points:
This is a resume of the experience i've gathered in the past 6 months:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Wrong. With DI you can use any device functionality you could possibly want. Check out XLabs on GitHub if you doubt this.
Apps where code sharing is more important than custom UI
Kind of nonsense really. You can write your own renderers to represent controls of each platform in the way you want. I've also written more difficult renderers for custom controls such as a SideDrawer. In android i was done in 2 days, iOS about 2 weeks (android renderer was just a wrapper for the native control)
Developers comfortable with XAML
well yeah and anyone who enjoys convenient UI development. Mind you that there is a learning curve with xaml (which i already knew at the time i started from WPF development). But from what i have seen it's not that different from android.
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
While hacking your solution up natively is certainly faster you can instead be done rather quick if purchase good controls / know a good native implementation and mirror it in C#, since the API in C# is very similar to the native one.
Apps that use many platform-specific APIs
Not sure why Xamarin is doing anti advertisement against forms. I had little trouble with it so far
Apps where custom UI is more important than
code sharing
Probably true, but it's also harder to keep UI functionality inline and you will need more manpower.
Things to consider about forms:
Forms seems to be stabilizing at the moment and i am sure Microsoft will do their best to turn it into a solid, reliable product (build issues have been a nightmare in the past sometimes, but it has gotten better over time)
The XAML for Xamarin is less developed compared to WPF XAML, though very similar. Recent nuget updates however provide mirrored functionality at an impressive rate. The vast majority of features you expect and love about XAML are present.
List performance is bad if you don't do your research (here). Performance increased loads in that area.
If i had to make the choice again i'd still go for forms. While there are sometimes things which seem flawed / bad you can usually figure out a clean fix somehow, while spending most of your time actually developing the app. (sometimes you will still find things which just make you frown why something isn't implemented, like the Margin property being implemented only just after microsoft purchased xamarin)
If you end up having a requirement of nested lists, make sure to have a look at embeded native controls in order to achieve the maximum performance - this was essential for a product i was working at. See this
According to Xamarin.Forms main page:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
Developers comfortable with XAML
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
Apps that use many platform-specific APIs
Apps where custom UI is more important than code sharing
Giorgis answer is the right one, but since you added some more constraints here are my thoughts.
I would analyze the current app. How much code is business logic which can be shared? How customized is the UI, should it look more native or more the same and how will it change in the future? If you plan to change a lot in UI and platforms should look similar, it might be easier to switch to forms.
Also consider if are you planning to develop for Windows Phone? If yes, you might save a lot of time just for this third platform.
After all there is one thing which I would also keep in mind. Developing in Xamarin.Forms does not mean, you cannot develop native. It is just an additional framework. In worst case you can still do everything natively.
Personally I use Xamarin.iOS & Xamarin.Android with MvvmCross, that way I can keep full control of the native UI on each platform while maximizing code reuse.
From Xamarin website (who knows better than them?):
Xamarin.Forms is best for:
Data entry apps
Prototypes and proofs-of-concept
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
[https://developer.xamarin.com/guides/xamarin-forms/]
With Xamarin.Forms at runtime, each page and its controls are mapped to platform-specific native user interface elements.
With Native Xamarin.Android and Xamarin.iOS apps leverage platform-specific hardware acceleration, and are compiled for native performance. This can’t be achieved with solutions that interpret code at runtime.
"Xamarin.iOS - The best way to build native iOS apps."
Ship native app bundles on the App Store. Our Ahead-of-Time (AOT) compiler compiles Xamarin.iOS apps directly to native ARM assembly
code, meaning your app is a native platform binary.
Access any iOS API. We bring 100% of Apple’s iOS SDK to C#, enhancing Objective-C APIs with stronger types and .NET naming
conventions so you feel right at home.
Call existing Objective-C code from C#. Use your existing Objective-C code, frameworks, and custom controls in your Xamarin app
using our automatic binding generator.
Build WatchKit apps. Use Xamarin Studio or Visual Studio to build new Watch Apps, edit Watch user interfaces in the iOS Designer, and
debug Watch apps in the iOS Simulator.
Stay up-to-date with Apple. We released same-day support for iOS 5, iOS 6, iOS 7, and iOS 8 so your apps can take advantage of the
latest iOS features as soon as possible.
[https://www.xamarin.com/platform]
"Xamarin.Android - The best way to build native Android apps."
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.
Access any Android API, including new form factors. We bring 100% of Google’s Android APIs to C#, enhancing Java APIs with async support
and .NET naming conventions so you feel right at home.
Call existing Java code from C#. Use your existing Java code, frameworks, and custom controls in your Xamarin app using our
automatic binding generator.
Build Android Wear apps. With access to 100% API support for Android Wear, create full-featured applications capable of running on
Android Wear devices. Stay up-to-date with Android. Xamarin stays
up-to-date with the most current APIs from Google, so you can always
use the latest features in your apps.
[https://www.xamarin.com/platform]

Xamarin & Visual Studio, Windows Phone & ASP.NET: Is a true single class library possible?

I've currently built a service layer and API which I'm consuming from an ASP.NET website, Windows Phone app, and a Windows 8 metro app - the key to all of them being a project containing model classes which is a portable class library project, and is shared as a reference between all of them. This architecture works fine and without any issues.
However, I've recently started experimenting with Xamarin - specifically the iOS functionality (with a view to moving onto Android later). My initial assumption was that I would be able to utilise this model library as I do with the other projects - however, I've since realised this this isn't the case.
When I first added a reference to my model class library to my Xamarin.iOS project (in Visual Studio), I was greeted by the error:
'The current project does not support references to Portable Library projects'.
Strange - as I thought this would be a scenario that would be supported. I found a post here which suggested a fix that forced Visual Studio to detec the Monotouch (Xamarin) framework as supporting Portable Library Projects. Seemed to be exactly what I needed - but no. When I added the reference again, I was greeted by a different error:
'The current project's target framework is not compatible with that of the Portable Library project'.
And it suggests I change the target framework in the project properties. Except I can't, as the Xamarin iOS project needs to support Monotouch (and I can't change it to anything else from the GUI anyway). So I tried to change the model library's properties instead - maybe I can do something there. And it looked like I could. I can check Monotouch (Xamarin) as a supported platform here (where Windows phone, Windows store, etc are already checked), but it won't let me save. It just shows the message:
'There is no additional functionality that is supported by the target frameworks you have selected'
After some research, I discovered that the only way Xamarin suggest to share code is to use separate projects with linked code files (so in effect, a pseudo-single code base. Which I have tried and works - but it seems a hack. See here:
http://docs.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options
So is this the only option? Or is there any way to have a true single class (model) library across all platforms, including Microsoft and Xamarin?
It is currently possible to use Portable Library Projects - e.g. profile 104 - across all of .Net4.5, WP, WinRT, Xamarin.Android and Xamarin.iOS
It is also currently possible to use the output binary assemblies across .Net4.5, WP, WinRT and Xamarin.Android - but not current against Xamarin.iOS.
This situation is changing 'very soon' now with Xamarin adopting full PCL support - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html and listen to http://hanselminutes.com/362/ios-and-android-apps-with-xamarin-studio-20-and-miguel-de-icaza
I personally deliver MvvmCross (and a lot of apps that use MvvmCross) using PCLs - and have done for the last 6 months - but there is some setup pain involved in this currently. For some info see my blog:
http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
http://slodge.blogspot.co.uk/2013/03/xamarinios-with-mvvmcross-in-vs2012.html
I do hope to provide an update on this in the very near future - it should work 'out of the box' soon.
The future is bright on Xamarin side, as it is going to support .NET 4.5 profile on all its platforms,
http://blog.xamarin.com/brave-new-async-mobile-world/
The only problem as far as I can see comes from Microsoft side, who refuses to unify its own platforms to a common profile (Windows 8 and Windows Phone 8 are still messy tailored versions no better than CF or Silverlight in my own situation).
Portable class libraries are out there, but as a library author (#SNMP) I rather build separate project files for my own projects as Xamarin suggests.

Xamarin and Mono compared to ADT

I'm a developer, with years of experience in C# as well as Java.
I have developed a few ADT projects for my Nexus One Android 2.23 phone.
I am considering further mobile development and I heard of Mono for Android/iOS and Xamarin. At first I thought Mono would recode to Java, but now I understand that it compiles to native C code and runs over mono libs.
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being > 1MB)
If there is someone here who uses Mono I would love to hear from your experiences.
I understand there is a Visual Studio 2010 Plugin for Mono. Do you recommend it?
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being >1MB .... )
Monodroid apps are usually somewhat around 5 Megabytes (if Linked) because the runtime is embedded in the app.
If there is someone here who uses Mono I would love to hear from your experiences.
All in all i'm pretty happy with Monodroid. Java tutorials on Android are easy to translate or if too big you can create Bindings. I've only done one project on Mono so my experiences are limited but thus far i've expected nothing that would make me regret my choice. On the other hand, if you're familiar with Java (and like coding in Java) their is no reason to switch over except for Cross Plattform apps (see Monocross).
The VisualStudio plugin is necessary to develop in VisualStudio. The new version comes with a Layout Designer like the Android Eclipse plugin. I'd recommend you download the trail version from Xamarin and try it (the trail has no expiration date, it lets you only deploy to an emulator)

Tutorials for Writing Common Code for use on Windows, OS X, iOS, and potentially Android

I'm looking at writing an application that I would like to use on Windows, OSX, and iOS (maybe pushing into Android if other people want to use it). I want to duplicate as little work as possible and I'm having a hard time finding information on the best way to do this.
From what I've found so far I can't use a framework like QT because iOS doesn't support QT so it looks like I'm stuck recreating the interface for each target. I'm looking at writing the business logic in C++ because it seems to be supported by the native tools (Visual Studio and xCode).
Has anyone had experience with a setup like this and if so can you point me towards a good reference for this kind of development?
Really there it not a lot of choice right now. Qt is certainly coming to iOS and WP7 so C++ is a good solid evolving platform.
However there is also the mono project which offers C# across platforms.
http://xamarin.com/monoforandroid
From my understanding, you write in c# and it compiles to the platforms preferred language.

Resources