I'm fairly new to Xamarin development, but I've started doing some experiments with Xamarin.Forms and I'm really liking it.
Now, I've discovered MVVMCross, and it sounds interesting for developing apps that have separated UIs for each platform, but I'm trying to find updated information regarding how (and if / why) it may tie in with Xamarin.Forms (mvvm's docs has a page for this, but it's empty ATM).
Is there any currently-relevant information I'm not being able to find? (all results I'm finding seem to be too old and not really helpful, please correct me if my google-fu is just not strong enough)
Well, for lack of better replies. From this blog post:
(...) it is crucial to understand that neither MvvmCross nor Xamarin.Forms is a replacement for one another. While both of them provide infrastructure modules that help developers in their mobile application projects, Xamarin.Forms is a UI technology stack that enables common XAML declarative UI implementation for target platforms; MvvmCross is a framework that enforces clear distinction between the UI elements and core logic implementation. Either of them alone or together can increase the shared amount of code in cross platform projects.
Related
I apologize if this is somewhat too open-ended of a question, but I'm still parsing everything about the Xamarin framework and it's hard to know even what to ask.
Everything I've read claims it's possible to, in theory, write a Xamarin app that has the same views and view controllers for both Android and iOS. The app I am developing has a very comprehensive design that uses almost no native look and feel, so I understand I will need to override the default platform's L&F. Because of this, it seems an ideal candidate to reuse everything for both device platforms, and Xamarin.Forms seems the ideal candidate.
However, I've yet to find a good example that does this. Even all of Microsoft's official examples of Xamarin.Forms (such as https://github.com/xamarin/xamarin-forms-samples/tree/master/BoxView/BasicBoxView) use ViewControllers/AXML files for iOS/Android. Huh? Isn't the point of Forms so I don't have to do that? Why are they mixing Forms and the native Xamarin in an example targeted towards Forms? Is this a sign it's not really possible?
Xamarin seems very flexible, which is great, but I'm also finding it confusing determining what will work together and what will not, plus how to determine the best solution.
Thanks.
I'm on the cusp of beginning a Xamarin project. I have been doing loads of research on what the best starting point would be and i have come to the conclusion that i need to learn the Android framework and begin by building a native Android app in Xamarin instead of Xamarin.Forms.
However, looking to the future i would want to be cross platform for this app. I have searched high and low on any information about what it would take to take a Xamarin.Android app and migrate it into a Xamarin.Forms app so that i can then build out the iOS app for my project.
Does anyone have any information on if this process is easy or hard to do? Can you take a Xamarin.Android app and someone migrate it to a Xamarin.Forms project? And if not would the approach be to rebuild the apps under a Xamarin.Forms project? Is there a easy approach to this?
Any info on this would be greatly appreciated.
With more than two years of experience with Xamarin (Native and Forms), I have never seen a tool or anything of any sort that will help you with migration but I can give you my personal opinion on this and maybe help you a little. Let's begin.
I have been doing loads of research on what the best starting point would be and I have come to the conclusion that I need to learn the Android framework and begin by building a native Android app in Xamarin instead of Xamarin.Forms
I would say this was a good decision Since my personal experience tells me that it is crucial for you to know either Android or iOS before you start working with Xamarin Forms otherwise there will be points in time where you will be lost af seeing the code, thinking how did you get yourself into this mess ;)
I have searched high and low on any information about what it would take to take a Xamarin.Android app and migrate it into a Xamarin.Forms app so that I can then build out the iOS app for my project.
There is no direct way of doing this you will have to do it the old fashioned way...
Converting(Manually) Android XML to XAML is quite easy so the design won't be an issue.
The C# part might be a problem as a native Android code is quite different to forms, But you can do it with ease with time.
Note: That there will be a lot of stuff that you would want to keep in mind for eg how Xamarin.Forms works. Because when you start doing the changes you will face a lot of issues finding equivalents and stuff but it will get easier
Does anyone have any information on if this process is easy or hard to do?
It's not about hard or easy it's about time taking or not and trust me it takes time.
Can you take a Xamarin.Android app and someone migrates it to a Xamarin.Forms project?
I am a little bit confused by this part of the question but if you mean is it possible yes it is.
My comments:
You will need good knowledge of how Xamarin.Forms work and by that I mean you should at least go through all the Xamarin.Forms guides in Xamarin University which can be completed in a week or so with proper understanding.
Going forward I would say use an MVVM framework for your Forms app, it will help you have a well-structured code and will keep you up to date with the industry standard.
Also, note that MVVMCross for a beginner in MVVM is too complex, so avoid it if you have no idea what MVVM is, going with Prism or FreshMVVM would be comparatively easier.
Don't depend too much on Xamarin.Forms NuGet's for doing certain functionalities.
Rather write your own code using Plugins for everything is too much dependency and becomes a problem at crucial times.
The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3
I want to print the current UI of a Xamarin.Forms cross-platform application. Are there any plugins or libraries available which support both android ios and uwp projects to do this? I'd really appreciate being pointed in the right direction to get started on implementing this kind of feature in my application.
I would approach this in two steps. Firstly you need to convert the current visuals into a printable file type. So assuming we are working with primarily mobile devices then we should make use of the 'screenshot' mechanisms.
There is a very good answer to another stack overflow account HERE that guides you through setting up screenshots in xamarin forms using dependancy injection. The chaps answer is straight forward and easy to follow.
Once you have that screenshot as a png or jpeg etc. It's time to print it. There are a lot of threads on xamarins developer forums dedicated to the issues around printing from xamarin, a collection of these can be found HERE.
So to start with it's worth mentioning that every platform xamarin forms (XF)supports has it's own mechanism for printing. XF does not provide any abstractions for printing in a cross-platform manner. You will need to write printing logic for each layer and expose it to XF using DependencyServices.
Android Printing - this is a link to printing in android.
iOS Printing - this is a link to printing in iOS (Heres a sample app to help you as well.)
As I previously mentioned, because xamarin hasn't created a simple cross-platform mechanism for this in Forms, it's not quite as simple as you'd think and does require some work to implement. But none of the work is overly complicated, it uses standard dependancy patterns, it's really just the bulk of code required that can seem a bit daunting.
What I want to create is a Silverlight app with a few tabs/modules that will all be separate DLLs.
I see PRISM has the Shell/Module concepts that seem directed towards doing UI and I find a nice demo (showing how to search digg/twitter).
But it sounds like MEF will be included in VS2010 so I would like to go with that option.
Can anyone somehow clearly explain the differences? (I am not a advanced programmer)
MEF and Prism serve two very distinct goals.
Prism is basically guidance for designing composite applications - where you have a shell and "regions" that are dynamically assigned, and integrated. It includes an IoC container (Unity) that it uses for it's injection.
MEF is a dependency injection framework - it's main goal is to "fill in" depedencies at runtime for an application. In this respect, it's filling the same goal as Unity does within Prism (and, in fact, you could pretty easily rework Prism to use MEF instead of Unity).
Prism fills a broader scope, in some respects, but is also really limited to GUI applications. MEF is just doing one thing (Dep. Injection), but geared to be more general purpose, for any type of application.
As for the lifetime of these products -there is no answer here, but this is kind of how they're being developed:
Prism was developed by the Patterns and Practices team. The goal isn't to necessarily make software, but to provide guidance. As such, they update (although somewhat infrequently) the Prism library and sample, but Prism isn't a core part of the framework shipped by Microsoft. It's really a third party library (even though MS funds a lot of it, most of the P&P people aren't MS FTE).
MEF, from the blog posts, sounds like it is planned to be integrated into the framework, and be used directly inside of MS projects. As such, it's getting heavy development, directly from Microsoft, and being used in their products.
I, personally, have read through the Prism documentation (and have the book), and have gone through the samples. It is very helpful to understand how to break apart an application, but it really is guidance more than a complete, usable framework. The samples are very good at doing what they're designed to do - educate an architect in how to design a composite application.
If your goal is to just keep a clean separation of concerns in a silverlight application, I'd focus more on learning MVVM than necessarily just using Prism.
If you want to use MEF, there are other good options. For example, the WPF Application Framework is an entire MVVM framework built on top of using MEF, and fairly nice.
Basically, MEF is a general-purpose extensibility framework:
If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.
whereas Prism is mostly for building GUIs:
The Composite Client Application Guidance is designed to help you more easily build modular Windows Presentation Foundation (WPF) and Silverlight client applications.
So MEF and Unity are basically the same...
Well, not exactly. MEF is more focused on extensions which aren't known at compile time, while IOC containers generally focus on dependencies which are known at compile time. The top answer to this question gives a good explanation of the differences.
Yes. Check these two posts for more:
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
http://blogs.msdn.com/dphill/archive/2009/12/09/prism-and-mef.aspx