i was just wondering what the benefits are in using PCL with Xamarin.Forms.
I mean you share the Code between each Platform anyway.
In Xamarins native approach it is quite clear.
So maybe anybody can tell me why to use PCL in Xamarin.Forms?
PCL allows the maximum in code sharing across platforms. PCL will by it's very nature limit you to using only those API's that can be shared from platform to platform.
While you can use Shared Projects, you will find yourself using compiler directives and making coding sacrifices that can lead to bad coding practices across anything but the smallest of projects.
Using the Xamarin Forms 2.3.3 or later you can of course embed Platform Specific Controls in your Xamarin Forms pages in your PCL and they will only render when run on the platform.
In addition of maximum code sharing, it allows you to follow best practices like SOLID.
Also, please remember that there are 3 choices (not only 2):
Portable Class Library
Shared Library
.NET Standard Library
.NET Standard Library is still an ongoing work in process, so it's not there yet. But, it will be the way to go!. So, PCLs today can give you an excelent migration path to the .NET Standard Library way tomorrow.
Hope this helps.
Related
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.
I am new to Xamarin. Can someone point me to a way to read existing SMSs using Xamarin Forms.
I know we can do it using Android specific libraries (and probably with iOS specific libraries as well). But, I want to use a library that will help me avoid using platform specific library.
You will have to use platform specific code for this. Remember; all libraries out there actually are platform specific code but just offer you an abstraction. This includes Xamarin.Forms itself.
As mentioned by Jason in the comments, you aren't going to be able to do this on iOS altogether, they do not allow to read or sends texts directly. So you should probably rethink what you are trying to do.
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]
I learnt that Xamarin.mobile provides single set of APIs across platforms. But implementing in a cross platform app, how does it look like?
A cross platform architecture consists one project containing shared codes (core project) and other project consisting the UI codes per platform. So, as Xamarin.mobile provides a single set of API, how can we utilise it to write once and use everywhere? Eg: implement mediapicker.TakePhotoAsync in one class and use it in multiple platforms without writing the same code in other platform. Because, the sample app i downloaded from Xamarin.mobile consists of apps developed for different target individually (not cross), though i see they use the same media picker, geolocation and contacts namespace across different platforms.
Thank You!
Xamarin's 'traditional' approach to cross-platform apps has been to use file-linking.
I believe this is currently changing to a dual approach of recommending either:
file-linking
or
Portable Class Libraries (PCL)
The first version of Xamarin PCL support is due very soon (any day now).
When that becomes available and stable, then I expect you may see new versions of xamarin.mobile which are available for PCL. Also, they have indicated that they may open source xamarin.mobile. As it stands today, I don't think xamarin.mobile is a very active development - I don't believe it's changed/grown much in the last year.
Until these changes happen, then if you want to use xamarin.mobile from portable code, then your best bet may be to either follow the file-linking route, or to use PCL libraries but use some form of facade to wrap the native xamarin.mobile libraries inside an injectable interface
Currently I am working in a project that uses MFC a lot, but it seems to me that MFC technology is not widely used nowadays. How deprecated is MFC? What are the alternatives for it? I am using VS2010 on Windows.
Thank you for your answers.
Windows Forms and WPF are becoming more and more popular these days,
but seeing that a new version of MFC was released just a few months ago (see here) I wouldn't call it deprecated just yet.
Yes, MFC is not what you would call state-of-the-art. If you are starting a new (UI) application from scratch, you should come up with really strong reasons to use MFC (for example, you have already existing code). There are many disadvantages, for exeample the document/view archtiecture, which is only suitable for small UI applications or the high amount of customization you need to put in, if you want controls that are not included in this framework (and you certainly will at some point). Additionally, it is not that easy to test MFC classes, which you should have in mind as well.
Widely used are approaches with a MVC (model-view-controller) architecture. You can read more about these two archiectures here:
Document / View as used in MFC
Model View Controller
As you are considering MFC, I assume you already have knowledge in C++. Therefore, the Qt Framework from Trolltech / Nokia might be interesting for you. It supports MVC architecture, is cross-platform compatible and still actively developed.
MFC is not so bad. The problem is that most of the components (windows/widgets) are pretty bad or more precisely very inflexible. As Hans said it's 18 years of backward compatibility and therefore every clock cycle and memory byte counted. This hurts today.
I'm using it because Windows Forms and WPF is just not useable for cross platform GUI development where the lingua franca of the backend is C or C++ (if Java is not an option for your project for whatever reason).
Depending on what you want to do and how important a very native looking GUI is, MFC might be the only choice, especially when you can afford to buy third party components and use the feature-pack or Ribbons.
I not commenting on QT/GTK/FLTK or other toolkit as long as you don't tell us more about your project