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#
Related
I'm about to start a new project in Xamarin, since we need to create a mobile app for Android and iOS. But we require that both platforms look exactly the same.
Is it possible to do this using Xamarin or is it only possible using something like Cordova?
Thanks!
require that both platforms look exactly the same
It depends upon what you mean by that statement.
In regards to Xamarin.Forms, "native" widgets are used on each platform so the "same" app's UI, deployed to a different platform, will look different (the difference can be slight or vary greatly based upon the controls used).
Web based / Hybrid apps tend to render fairly the same on each platform. Each platform does have its own HTML/CSS rendering engine so there are differences, and thus the CSS can vary from platform to platform to obtain the desired "sameness".
There are GUI frameworks that render their own controls/widgets and do not use the platform "native" ones. While a lot of these tend to be game related UI frameworks, there are many options available depending upon want you requirements are.
i.e.
OmniGUI : A Xamarin.Forms friendly cross-platform that renders its own controls and thus looks the same on each platform.
Flutter : Google's mobile UI framework that renders its own "widgets". While there are widget collections that have Material Design and Cupertino styles applied, you can use the basic widgets and style them in a "CSS" like analog using Google's Dartlanguage.
Many others...
The most fundamental feature of Nativescript is that it converts different platforms' languages and API:s into Javascript (or another given single language e.g. C#), e.g. for iPhone it's the Objective C language and the iOS API:s, and for Android phones it's the Java language and the Android API:s.
Nativescript's "build-time reflection to Javascript proxy" is central here.
Reading through various "Nativescript vs. whatever" pages online, it's clear to me that the authors of those pages not really discuss that exact aspect, so those articles cannot be used to get an overview of that situation at all.
Therefore I want to ask you here:
What projects out there are there that provide that fundamental feature - a language+API binding from different smartphone (and possibly desktop) platforms, to Javascript (or another single language such as C#)?
ALL WebView/HTML rendered UI-based solutions are DISQUALIFIED here. Only native UI component solutions qualify. Do feel free to list the DISQUALIFIED solutions also, for everyone's reference, and mark out carefully that it is disqualified.
Hence I understand that Apache Cordova (https://cordova.apache.org/docs/en/latest/guide/overview/) is DISQUALIFIED.
I prefer Javascript, however let's enumerate all projects independent of which language is used at the unification layer, therefore Xamarin is qualified in this thread.
Also for those respective qualified solutions, are they really as holistic / complete as Nativescript is, in support, or how do they compare?
For the respective solution, do they also provide an runtime that integrates the underlying different UI API:s into one single coherent UI API that spans the multiple platforms? (For Xamarin I understand the answer to this question is NO - different code is needed for the different platforms.)
Also what are their primary difference in approach?
Some names I picked up that could be qualified, are "React Native", "Appcelerator Titanium", and "Electron" (https://electron.atom.io/).
This question is important for any app creator or startup, like me, that will rely on the solution a lot, and also hopefully contribute a lot, so it's a long term choice.
So, for each relevant solution I want:
* NAME, URL: Its name, with URL
* DISQUALIFIED?: Disqualified or not
* AUTO-REFLECTION: Has automatic build-time reflection or not, any details
* LANGUAGE: Unifying language (e.g. Javascript)
* UNIFIED UI CODE: UI code same between platforms
* PLATFORMS: Platforms supported
* CODE TRANSFORMATIONS: Any notes about how the app sourcecode is managed, e.g. is it run as Javascript on the device, is any code transformation applied to the Javascript code (e.g. to parse out custom tags which are actually not in themselves valid Javascript), any kind of compilation applied on the Javascript, etc.
Please let me know.
This is extremely valuable for overview.
Thanks again to Telerik and the Nativescript team for making this fantastic tech!!
Mobile:
Cordova/PhoneGap/Ionic - https://cordova.apache.org/ - Disqualified - Unified UI - JS/HTML/CSS - Basically a wrapped webview with the ability to make native bindings that you can call from it. In once sense you access the native platform via plugins you create. In fact Microsoft has a project called Project Ace https://microsoft.github.io/ace/ which allows you access to the Native API inside your Cordova/Phonegap application. The application code is running inside a webview; and everything is thunked out to the OS and plugins that you build into your app. Despite the "marketing" speak (ionic is really bad about attempting to confuse the market here); Cordova/PhoneGap/Ionic is NOT truly a native application. It might use some native controls, but the engine is running in a webview.
Flutter - https://flutter.io/ - Disqualified - Unified UI - Dart - This is another interesting entry in the market; it is fully compiled code on all the platforms, so it is can be more performant than JS based engines. In addition it was written to be a very performant UI (separate thread for UI). To access the native api's on the platforms, you need to create plugins with the interface the compiled dart will be expecting and the iOS or Android API's.
Fuse - https://www.fusetools.com/ - Disqualified - Unified UI - JS - This is a interesting project; it actually compiles the markup into compiled code. I believe the JS engine is running on its own thread and the Fuse runtimes handle the GUI thread. To my knowledge all thunking/reflection has to be done via plugins.
NativeScript - https://www.nativescript.org - Qualified - Unified UI - JS/XML/CSS - Uses the same markup language for screen layout on both devices, has its own builtin system to marshal calls into the OS on both platforms. No extra plugins needed to access any API resource, everything on iOS and Android is accessible from plain JavaScript. Runs a Javascript engine on the Main thread of the Application, which can cause performance issues if you make the main thread busy. Because of its design it can re-use pretty much all Android AAR/JAR plugins and iOS cocoapod plugins unmodified, bringing a wealth of Native controls that you normally would only get to use if you were using ObjC/Swift/Java. It also is the only one that has zero day access to new API's because reflection is resolved at runtime.
React Native - http://www.reactnative.com/ - Disqualified - Unified UI - JS - It is also a JavaScript engine based system, but it has no built in reflection. Pretty much all access to the device API's needs to be ran through compiled plugins that give access to the native api's. One thing to note is that this JS engine runs on its own thread and the main thread is reserved for the GUI. This can make apps be more performant out of the box as anything blocking will occur on a separate thread, but makes GUI related plugins much harder to do.
Xamarin - https://www.xamarin.com/ - Qualified - ??? - C# - It has sorta built in reflection. When they release the new versions they basically create a thunking library with the current reflections. So when new versions of the OS comes out, they have to regenerate the C# thunkings before you can use it. Application is compiled on iOS, on Android I believe it is using Mono to run the app. So you cannot do certain things at runtime on iOS, like eval('console.log("hi"); /* even more JS code */') as you can on the JS based engines.
Desktop:
Electron - https://electron.atom.io/ - Unqualified - Unified UI - HTML/CSS/JS - This is a desktop based environment that merges node and chrome. So you can access any of the Node api (which is pretty large) and any of the chrome api and create an application. However, anything lower level you will need to create a plugin.
NW - https://nwjs.io/ - Unqualified - Unified UI - HTML/CSS/JS - Basically the same notes as Electron.
A couple notes:
All JavaScript based engines DO NOT compile the code; they all run the JavaScript code at runtime.
You can use Cordova/PhoneGap/ionic to share an app between desktop (using electron/nw), web and mobile fairly easily. But it is still a web app on all platforms.
You can also use NativeScript with Angular to create app that shares probably 98% of its code base between a mobile, web, and desktop(electron/nw) application. Basically the only differences in some applications is just the screen layout as you need div/input tags for Web, and StackLayout/TextInput for the Mobile side. But the rest of the code and logic can be generic and access the elements as normal.
I want to introduce 'Zendesk' chat support in my application. I have tried to search but not get the process of including. Please suggest any idea. Thanks in advance.
Zendesk documentation appears to only indicate native support for Android and iOS. Xamarin can link the SDKs individually for each build -- see Xamarin documentation for this (links included but not summarized due to length), but won't handle bridging the difference between the two. Windows will not be supported by this option. If you only want to target Android and iOS, you can use these options and create wrapper classes with a common interface.
Alternatively, if you badly need Windows support and are comfortable with web technologies, the web sdk offers a full api. Xamarin forms supports a webview in which you can load the web sdk, and either build a GUI in the webview or make api calls via the web sdk.
Links detailing including native libraries:
https://developer.xamarin.com/guides/android/advanced_topics/using_native_libraries/
https://developer.xamarin.com/guides/ios/advanced_topics/native_interop/
Note -- above link is specifically for native libraries, which I believe is correct for Zendesk's SDK. If not, there is also a guide for objective-c libraries on the Xamarin website.
So, I have been developing an android app for some time, and I was requested to try porting this app to windows phone too. In order to reduce the hassle in trying to maintain two separate versions of the same app, I decided to try to port this app into xamarin, because I have heard that its performance is better than hybrid apps. These are my questions with regard to xamarin:-
I want to maintain the same look and feel which I had in my original app into my cross platform app, and at the same time, make it distinct in the windows version. What are the things I can do to achieve this effect?
Is it rather better for me to port this app to windows phone native, because of added problems in trying to create a common app?
Are there any restrictions with regard to Windows store when publishing xamarin apps?
Xamarin doesn't really cover Windows UWP apps, only in the notion that they have the UI Framework Xamarin.Forms running on that platform. Meaning, that what you are making is a native Windows UWP app.
What Xamarin is great at is when you start targeting more than one platform and you have structured your code in a way that it can be reused on the supported platforms. This could for instance be done by putting most of your logic and behavior into a Portable Class Library/NETStandard library and consume it in your apps.
A Typical pattern for making platform agnostic logic and behavior for your apps, is the pattern known as Model-View-ViewModel, where the View is platform specific, while the Model and ViewModel usually are platform agnostic. The ViewModel is where the behavior resides and it is what ties the Model together with the View.
Usually the ViewModel wouldn't directly know the View, but there would be a layer in between (glue), such as XAML or a binding engine from MvvmCross, MvvmLight or ReactiveUI to name some MVVM libraries.
What Xamarin provides is the ability to write C# code for Android and iOS, which greatly enables you to share code between those two platforms, but also all the Windows platforms. Hence, UI, is very much dependent on each of the platforms on their own.
You can, of course, use Xamarin.Forms as a UI abstraction layer, which produces a native UI using the native UI controls to get a similar app on all the targeted platforms.
First of all you need to know there are different styles of Xamarin development, who will share more or less content.
If you use Xamarin Forms you have a Main project non-related to any platform (where you create the views and clases), and specific platform projects who adapt the controls to each native style.
If you develop using Xamarin Classic, you have a Shared project where you only develop data-related classes, and specific platform project with their own views and classes with native-friendly controls and native similar functions, but I think, there is no direct Xamarin Clasic Windows Project.
So if you only want to have two apps who look native both, but with same structure and functionalities Xamarin Forms will be the best option for you, cause you only develop "one single app" who becomes native-style like this:
If what you want is to have different apps, with different functionalities and diferent content, then you need to go for Xamarin Classic. What I recomend you to do then is develop the windows phone in native, but put all of the code you can in a shared library. Then you can create a Xamarin classic Android app and use the shared library. You will still need to mantain two different apps, but you will only need to change the "core" code only one time.
If you use Xamarin Forms to do a UWP windows app I don't think you have any problem to publish it, think Xamarin is from Microsoft.
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]