Can mvvmcross be used without dependency on Xamarin? - windows-phone-8

Being familiar with mvvmlight, I'm now starting to look into using mvvmcross instead given the nice ability to use it with Xamarin to eventually also support my code on ios and android. However, I'm not there yet and would like to avoid taking a dependency on xamarin as long as I'm not actively targetting platforms other than WP8.1 and Win8.1.
Question: can mvvmcross be used without dependency on xamarin? (From my research so far my understanding is that mvvmcross is closely linked to usage with xamarin; even to the extent they share libraries? Would love to understand to what extent there's a hard dependency.)
As an alternative approach is there anyone successful in using mvvmlight for cross platform dev?
Kind regards

Yes it can - the core of MvvmCross is PCL - it's portable.
Xamarin is used only for Xam.Android, Xam.iOS and Xam.Mac - you can use WP, WinRT, WPF, MonoMac, Unity, etc without any Xamarin products.

Related

Can ELMAH be used in Xamarin solutions?

Reading this today, and probably embarking on a Xamarin solution very soon (the other possibility is "going native" with just Android, using Android Studio), I got to wondering:
Can ELMAH be used in Xamarin solutions?
And, in fact, if the road less taken (Android Studio) is chosen, what tool is there for Android/Java projects that that most closely resembles ELMAH's advantages?
It does:
Although the Elmah.IO NuGet's latest release doesn't support
Xamarin.Forms cross-platform logging, I have used it in my
Android/iOS/UWP projects' exception handling separately by following instructions here.
Here you can find out descriptions about the
pre-release elmah.io for Xamarin and Xamarin.Forms.
No. ELMAH is very specifically targeted for ASP.NET.
Error/crash logging solutions for Xamarin include Raygun, Crashlytics, and TestFlight.

Using MVVMCross IoC with Link All Assemblies

I'm just reading up about the inbuilt IoC of MVVM Cross and how it makes heavy use of reflection. Just wondering, does this cause issues with Xamarin linking? What are people finding best practise in this area? Using "Link SDK assemblies only" or perhaps configuring IoC in a way that avoids reflection?
Thanks in advance :-)
Both MvvmCross IoC and MvvmCross binding rely on Reflection.
Because of this, users often use "Link SDK assemblies only" and often use "LinkerPleaseIgnore" files.
You can read more about this on:
https://stackoverflow.com/questions/10224376/mvvmcross-experiences-hindsight-limitations/10225623#10225623
Problems with mvvmcross Binding on IOS (Works on Simulator, but some properties doesn't work on the Device)
... and many more https://stackoverflow.com/search?q=[mvvmcross]+linker
The MvvmCross nuget packages ship with default "LinkerPleaseIgnore" files - e.g. https://github.com/MvvmCross/MvvmCross/blob/v3.1/nuspec/TouchContent/LinkerPleaseInclude.cs.pp

Confusion regarding PhoneGap/Cordova

I have a webapp developed (game), based on HTML5 + CreateJS, but since Android lacks of standards, I've run into unsolvable issues for my webapp. That's why im recurring to PhoneGap.
Yet my confusion lies in the fact that I need to make this game into a phonegap app that runs on Android/iOS, using for each platform native specific stuff.
So, should I build 2 apps (one for each platform), all over again, or use the one I have and try to deploy it into different devices using phonegap?
The truth is I don't know how to approach this problem... can anyone help?
Best Regards.
Yes, you can use Cordova (PhoneGap) to create a cross platform mobile app. Basically, Cordova (PhoneGap is Adobe's version of Cordova) is an open source project that provides JavaScript API's for accessing native device functionality (like the Accelerometer or Camera.) Cordova also lets you package your app in the native application shell, so you put your app on the app store. Please see my other answer here about Cordova and hybrid apps: Beginning with Apache Cordova
If the game runs completely in HTML5, I think it would be easiest to just use that one codebase and integrate it with Cordova and then deploy to the various platforms - why rewrite the app twice if you don't need to?
However, if you are using native device functionality, you may need to develop your own Cordova/Phonegap plugins for use. This way, you can call regular Android/iOS code (Java or Objective-C code) that you write from your web app code with JavaScript. This might be more work, especially if you have never written in these languages.
Personally, since you already have a working HTML5 app, I'd just try to get it working with Cordova and see how it performs. If you really need some native specific stuff, then I'd try creating that "stuff" as a plugin. Rebuilding the app twice, once for Android and once for iOS seems like a pretty big waste of time to me.
The answer here is either yes or no.
Yes if you want to use some specific feature of the native code. For instance, iOS's default objects is beautiful itself, you can easily drag and drop it to build your application. However, it takes lots of time to rebuild for another platform. Specially, if you intend to create app/game for multiple platforms, it would be a nightmare.
HTML5 is much faster for you to approach several platforms. However, you can't get the best result on all platforms and all devices. I mean, it is really difficult to bring the max performance of the app on all devices. For this solution, I suggest HTML5 with some libraries such as LimeJS, Crafty, Impact, etc. or some tools such as Construct 2, etc. I used to use HTML5 with all those libraries but found out that Construct 2 is much better.
Instead of using phonegap, I recommend cocoonjs. Specially if your targets are iOS and Android platforms.
Hope that help.
Yeah, even the simplest game such as bubble buster would be difficult to make cross platform with different version of android webview and you need cross platform? I would suggest looking into something like Unity3D.

building the interface of an eclipse plugin with JavaFX or HTML5?

I am looking for an alternative to swt for building the interface of an Eclipse plugin I want to develop.
Is it possible to build the interface of the plugin with JavaFX or HTML5 instead of swt ?.
I am targeting Eclipse Juno 4.2 or later.
Eclipse 4 defines an application model, i.e. a model of all the parts forming the application UI. The application model is decoupled from its presentation.
This means that different UI toolkits (SWT,XWT,JavaFX,etc.), can be used to implement the model. Theoretically you can build a UI using any presentation technology you want.
That said, Eclipse 4.2 (the IDE) still relies on good ol' SWT for it's UI. Which means, your plug-in will require some additional dependencies to be able to use a different toolkit.
e(fx)clipse (already mentioned by jewelsea), provides the necessary Eclipse tooling to build your plug-in. Among other things it plugs a JavaFX ViewPart plug-in template, which creates an example plug-in and adds the necessary bundle dependencies for you.
Imho, this would be your best bet.
There are lots of things going on, Eclipse versioning can be a bit confusing nowadays (at least for me), you can take a look at E4 but it is not widely used. It has the ability of desining UI with Eclipse RCP/CSS.
An other posibility is XWT. I've seen some business ready application using XWT so it seems to be mature enough. Even WindowBuilder can be used to build UI with XWT. Which is actually declarative UI constructing with XML. If you want to have only the OSGi "goodies" you can take a look at Apache Felix or Eclipse Virgo (Spring-powered). They are application servers based on OSGi so you can build module based enterprise applications.
Last but not least if you are OK with SWT/JFace but want to have web application, take a look at RAP. I have seen a full RCP application converted to RAP running in a regular browser.

winrt application framework

What is the better framework for development Windows Store application?
I have used http://metroprism.codeplex.com/ but now I want to use Caliburn.Micro or MVVM light for another project.
I have looked through several application examples for these frameworks but they were not complicated enough for me to estimate usage in bigger projects.
These two ones are completely documented but the problem I think is that documentation for winrt mixed with WP7, Silverlight and WPF and I doubt a bit in supporting all features and practices of using exactly for Windows Store application.
Could you give me advice what is the better one? Or what are the good practices in development for Winrt with modularity supporting like in Prism for WPF and Silverlight.
Thanks.
MVVM Light and Caliburn.Micro basically do the same thing but they do it using opposing "philosophies of development" in MVVM.
MVVM Light is a "view first" approach. In this approach the ViewModel is instantiated in by the View. In MVVM Light this is done via something called the ViewModelLocator, a static class that binds a public property directly to the DataContext of the View.
Caliburn.Micro is a "viewmodel first" approach. Here you find that the viewmodel and view are created by an IOC mechanism that binds the two together. You navigate from viewmodel to viewmodel, with the views being generated in response to the navigation to a ViewModel.
They both have different features:
MVVM Light has a really nice messaging system for allowing view models to communicate with each other in a loosely-coupled way.
MVVM Light has a really simple mechanism for injecting design-time data into your views. Basically it swaps out your runtime services with design-time services that feed data to your viewmodels and, in turn your view. This makes design time data really easy to use.
Caliburn.Micro has an amazing data-binding setup, where it handles most of your databinding scaffolding for you. Basically, it maps the names of methods and properties to the names of controls in the view and autowires them. This saves lots of code and is a really, really nice feature.
Caliburn.Micro uses a "Convention over Configuration" mechanism to map views to viewmodels. MainView maps to MainViewModel, etc. This means you've got no configuration, you just need to make sure that you've got your naming conventions sorted out.
I've used both frameworks (Caliburn.Micro for WP7 and MVVM Light for Windows 8 Store Apps) and like them both for different reasons. MVVM Light is easier to start using but Caliburn.Micro is probably more powerful. I've found them both more than adequate for writing moderately complex applications quickly.
Caliburn.Micro gives you clean XAML at the cost of some magic. MVVM Light is a clean and simple framework that is easy to understand and works well. Prism seems to be a bit heavier than MVVM Light and more business app oriented - it does more than just MVVM. There are many things to consider. Choosing what you already know will let you focus on adding features, but learning a new framework can certainly be a good learning experience helpful in future choices - so you could pick something you haven't used before if you want to learn. You could also write your own framework and only include what you need. I usually go somewhere between roll your own and MVVM Light because that is what I know, though if I were to build a bigger enterprise app - Prism might be better suited for the task. I haven't used Caliburn.Micro because the novelty of different MVVM approaches wore off for me and I just want to create apps. With WinRT a roll-your-own-framework approach is easier than with any platform before because the basic project templates already give you some foundations as I wrote in my Minimalistic MVVM blog post. I would recommend that approach if you already tried MVVM and want to use only the pieces you need - the framework will grow with your app. You can just grab pieces of code from other frameworks if you need them or write your own implementations of the patterns you need.
To summarize
If you want to learn - try something you haven't tried before or write your own framework
If you want to create an app quickly and it is not a huge app - use what you know or go minimalistic and don't use anything but what you get from the templates
If you are building a big app with lots of features - consider Prism or rather first think whether Windows Store is the right target platform for you since it seems to be focusing more on simple in and out tablet apps