Recently i got a project which was build on Xamarin on Mac.Now, when i try to open this project on visual studio for MAC (As you all know Xamarin is now visual studio for MAC) it shows some errors regarding Monotouch.
The question is : Do i really need to convert app to unified API ? i know there is tutorial on official Xamarin doc to change app to unified API, but if there is any other way to open app without migrating to unified api.And what will be advantages and disadvantages of migration?
There are quite a few reasons why you might consider updating, but I will highlight some of the more important ones. Firstly consider that Apple as a manufacturer of hardware and software have always striven to keep their devices upto date, as such lagging behind as an iOS app developer can absolutely effect the demand for your app.
Firstly it already became a push or jump situation, as Xamarin stopped updating or supporting feature additions to their 'classic api' (As of writing we are on iOS 10.3).
The complete removal of classic support is scheduled for next fall
with the release of Xamarin.iOS 10.0.
Secondly the unified API is required to meet apples desire to support 64bit architecture:
The new Unified APIs are required to support 64 bit device
architectures from a Xamarin.iOS mobile application. As of February
1st, 2015 Apple requires that all new app submissions to the iTunes
App Store support 64 bit architectures.
As to your concern regarding the dissadvantages, I will simply say that the migration can either go smoothly, or not so smoothly. It's worth bearing in mind that the 'unified api' uses different native data types which may require some work arounds depending on the current structure of your original code.
The biggest point is what I mentioned earlier, in Apples App Store if you linger behind in terms of keeping your app up to date with the latest SDK, API, or anything else Apple decide to upgrade, then it is akin to giving up on that application.
I've put together some links below that may aid you in the migration process:
Native Types - Describes the new native data types that you will need to use in a Unified API app.
32/64 bit Platform Considerations - Considerations in choosing 32-bit and 64-bit modes for your application.
Updating Existing iOS Apps - Follow these steps to update an existing Xamarin.iOS app to use the Unified API.
Binding Objective-C Libraries - This document describes the process used to create C# bindings of Objective-C APIs and how the idioms in Objective-C are mapped to the idioms used in .NET.If you are binding just C APIs, you should use the standard .NET mechanism for this, the P/Invoke framework.
Binding Definition Reference Guide - This is the reference guide that describes all of the attributes available to binding authors to drive the binding generation process.
Updating UI Components - This is a guide to the process for updating UI componenets to the latest versions within the unified api.
Related
Is it possible to write a mobile app using .NET 6 but still maintain platform specific implementation of UI
So this would involve still using UIViewControllers for iOS and Activities for Android without taking the MAUI approach of writing the UI in a cross platform manner.
If this is possible could you point us at some documentation around how this is achieved.
I haven't tried to follow the instructions yet but the links provided by #Paramjit in the comments to my original question seem to provide the answer I was looking for, namely that MAUI isn' the only mobile option in .NET 6:
https://www.andreasnesheim.no/converting-xamarin-android-template-to-net-6/
https://www.andreasnesheim.no/converting-xamarin-ios-template-to-net-6/
We are developing a cross platform mobile application using Xamarin. I have noticed there are different ways of structuring your code using Shared code or PCL/.net standard.
I attempted to use .net standard and what i have found is that it doesn't include all the libraries such as using ado stuff , datatable/datasets using system.data. Or using system.net for example. Other functions have less overloads and seems that its a stripped version of .net to work across platforms. Is there any way to add this functionality or use a broader range of .net?
You are correct - .Net Standard and .Net Core are stripped down versions of the full .Net framework. They contain only features that can be used on all platforms (Mac, Android, iOS, Linux, Windows, etc.)
The full .Net framework only needs to work on Windows, so there are additional things that you can do based on the fact that there is less complexity in implementing and that the code base is more mature (cross platform is still pretty new by C# standards). To the best of my memory, System.Net should work if you have your references correct, but System.Data will not (or at least direct database access is not possible)
You can regain some functionality through NuGet packages, but it won't be the same as using WinForms or something like that...
My best advice would be to program against an API. You can use a web server that runs on the normal (full) .Net framework, and does all the heavy lifting using all the .Net features that you are accustomed to. Your Xamarin app would send and receive data from the API and basically provide a mobile front end for whatever you are doing. This approach makes sense for most apps anyway, and is generally what you would be doing anyway if you used Swift and Java to create separate iOS and Android apps.
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
Write the model in C#
Write the views for each OS in their own native way
Xamarin promises that the new functionality in libraries is added the same day
Telerik Native script
Write in javascript and call native script's api that then calls the separate OS javascript apis?
Write the view in html5 and css which is re-usable for all OSs as they now all support html5 and css front ends?
Telerik simply states... and I paraphrase 'it does not have this problem'
If the above is so, how is Telerik any better than Xamarin as it states on its website:
"When using NativeScript the new additions to the native platform are
available immediately. This is not the case in neither Xamarin or
Appcelerator, where there are technical limitations and wrappers needs
to be created when new native platform features are added."
I am confused at how Telerik is being penned as being better than Xamarin when Xamarin comes with strong type language without using TypeScript's slightly loose thing going on. And also that Xamarin does in fact sit in exactly the same boat as Xamarin apart form the view part... which is actually supposed to be a benefit?
Question:
- What's the difference between them apart from the two I have denoted?
- Why would Telerik claim such a thing?
[Disclaimer: I work for Telerik.]
Telerik NativeScript and Xamarin are solving similar problems in different ways. Both frameworks are focused on enabling developers to create cross-platform mobile applications with native UI and shared, common code across all platforms.
For NativeScript, we're focused heavily on the web developer skill set. We want anyone that is comfortable today writing HTML/CSS/JavaScript to feel instantly at home creating native apps using NativeScript.
The only thing that is a little different is that views are defined in an XML-based markup. This markup is parsed by NativeScript and rendered as native UI on all target platforms. (NativeScript modules encapsulate the platform-specific renderings.)
The capability you highlight is also something unique to NativeScript's approach for exposing underlying native platform APIs. NativeScript effectively uses (build-time) reflection to make ANY native API available to the JavaScript proxy. That includes 3rd party native libraries. You do not depend on Telerik (or the open source community) to update NativeScript to take advantage of these new APIs. You simply execute a command and auto-discover the new APIs.
Of course, we don't expect a lot of people to write against the raw native APIs using JavaScript, so that's where modules again help encapsulate the different native APIs and expose a single, clean, cross-platform JavaScript API. Anyone can create NativeScript modules.
There's a great post that explains how all of this works in much more detail on the Telerik Developer Network (TDN):
http://developer.telerik.com/featured/nativescript-works/
NativeScript's public beta will be available this week, and v1 will ship in May.
UPDATE [Feb 2016]
Since this was originally posted, NativeScript has shipped and is now in v1.6. It is also now integrating heavily with Angular 2. You can track the project progress on GitHub: https://github.com/NativeScript/NativeScript
UPDATE [June 2016]
There are now performance metrics comparing NativeScript and Xamarin. Please find them here:
https://github.com/NativeScript/sample-iOS-Profiling/tree/performance-tests
Telerik is a UI component and it has some beautiful control for designing in xamarin forms,MVC. Net and etc, but xamarin forms is a technology that helps deveopers to make mobile application using c#
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.