What is the difference between androidx.transition and android.transition?
From https://material.io/develop/android/theming/motion, it says that androidx.transition is AndroidX Transition library, while android.transition is Android Transition Framework.
So I guess the former is part of the new AndroidX and the latter is part of the Android Support Library?
But my key questions are:
What are the differences between the two in terms of features?
Which one should I be using?
Related
How do your write Xamarin platform specific code in a .net standard library?
I want to use namespaces like Xamarin.Forms.Platform.iOS in a .Net Standard Library..
Use case: I want to develop a .net library for my apps which includes a video player for the various platforms. This video player also has to interact with other code in the .net library.
Or is the answer I need to use a shared project or portable library?
You should not include platform specific code or use namespaces like the one you mentioned in your .NET Standard Library, the reason is that .NET is just a runtime environment.
It’s not the the main runtime environment that you would use on iOS or Android. These platforms use Mono - not .NET. Check this or this to see more details for how its structured.
If you need to execute something from your .NET Standard project which is related to platform-specific behavior, use Dependency Injection or Custom Renderers.
On making a new project solution in XAMRIN, there are 3 projects were created
1. ProjectName.Portable
2. ProjectName.Android
3. ProjectName.IOS
Can I add widgets in the Android project and on running the app, will that added widgets added in Android be showing in the IOS and WINDOWS apps? The purpose is only that I am familiar with Android development but in Portable project, the development is a bit different than Android.
Short answer, no.
Longer answer:
Depending on what project type you choose you define your views differently.
If you choose Xamarin.Forms, typically you would define all your views in the Portable project and changes will be reflected in both your Android and iOS project.
If you choose a classic Xamarin app, you need to define views per platform. So you would define Views, Activities and Fragments on Android.
On iOS you would similarly define Views and ViewControllers.
In short terms, Xamarin apps are native apps, written in C#. Hence, unless you add abstraction, you won't automatically get write once run anywhere functionality.
You should not reference code from different platforms. Instead, reference portable project from every platform. In portable project place some cross-platform code that is independent from where it runs. And place platform-dependent code in platform projects.
Use Xamarin.Forms in your portable project to build cross-platform UI. If you need to, use Xamarin.Android to operate Android-specific UI elements with Renderers. Do last step for every platform you need.
I have been developing an app for Android, Ios and UWP.
Since I need a socket connection, I used DependenyService to access the "platform specific" code and started to implement my interface in all 3 projects.
The problem is that the implementation is exact the same in all 3 projects, because they all use System.Net.Sockets.Socket.
However I can't simply put the implementation code in my PCL and use it for all 3, because I can't reference System.Net.Sockets.Socket in my PCL. (doesn't exit there)
This picture shows the targeting section of my PCL
I think the problem is that my PCL targets ASP.NET Core 1.0, which doesn't contain an API for System.Net.Sockets.Socket.
However, I can't tell my PCL to stop target ASP.NET Core 1.0, because it gets targeted automatically.
So has anyone an idea how I can share code only between Android, Ios and UWP, or make my PCL only target them?
If the app should only support iOS, Android and UWP, you can switch to the PCL of the year 2016 and the future called .NET standard (>= 1.3).
In the properties of your PCL click Target .NET Platform Standard and select 1.3 or higher. If you don't have this option, you have to install/update some stuff. Requirements are listed here: https://learn.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries
After you have done that, you are ready to use Sockets without using patterns like factory or dependency injection (which are the alternatives).
Or you use the Sockets plugin: https://www.nuget.org/packages/rda.SocketsForPCL
I am starting to develop a scientific software that I hope I will be able to run on multiple platforms. My plan is to use OpenTK for the rendering of the scientific models and plots. As of the moment I have a prototype that runs on Windows using OpenTK 1.1 libraries from http://www.opentk.com/ (a simpler version just with OpenTK and a more complicated one with OpenTK + WindwosForms). I am trying to port that prototype to Android.
It seems that the syntax using by the Xamarin.Android OpenTK library is nearly identical to the one that I am currently using for Windows (with the only difference that OpenGL -> OpenGL ES and GameWindow -> AndroidGameView) so the porting shouldn't be an issue. However, I was hoping that I could avoid a copy-paste method and get a more permanent solution having a shared OpenTK code between the Windows and the Android version.
I have read trough the Xamarin documentation about the shared vs PCL methods for cross-platform development. However, I still struggle to figure out how to set-up a Visual Studio solution with an Android and Windows project and a shared code that will include OpenTK. Is that even possible and can someone give me an example of how to do it? I did explore an example I found for rendering a rotating cube using OpenTK for a shared Android/iOS project (http://developer.xamarin.com/content/TexturedCubeES30/) but in my case I need to use a different OpenTK library for the Windows and for the Android project.
I also found this Do the Android and iOS versions of OpenTK have the same API? discussion. It is very similar to what I would like to do but in my case I am trying to setup a project for Windows and Android (for now).
Can I use only one OpenTK library (which one?) that is being called from both the Android and the Windows project and what will be the right way to set-up both projects so they share the same OpenTK code. This is the first time I am dealing with writing a cross-platform code so I am a bit lost.
Edit: I was able to get a prototype running using Shared Xamarin project and compiler flags as proposed below. Code was indeed not very pretty at places but I got over 70% code re-usability between the two platforms so it was worth the effort. This is how I used the compiler flags in case someone is looking for the same thing (credit to SKall from the Xamarin forums):
#if __ANDROID__
using OpenTK.Graphics.ES11;
#else
using OpenTK.Graphics.OpenGL;
#endif
I used the #if syntax similarly where there were small differences between the syntax of the routines.
It does not seem like OpenTK has its logic inside of a PCL in the first place, so your plans on putting it there are going to get hard to achieve.
However, if you split out your code, such that most of it is contained in classes, which are not highly dependent on the underlying platform, you will be able to create a Class Library Project for each platform and link your files between the platform specific projects. Inside of the classes it contains you will use #if definitions to choose whether to use AndroidGameView or GameWindow and the same goes for other platform specific types. It will make the code ugly, but this is the alternative to PCL.
You could try to see how much of the OpenTK code compiles inside of a PCL and inject the platform specific stuff at runtime, but it will require considerably more work from you. However, it will make the code a lot more cleaner to look at.
To ease the file linking, you could make one of those Shared Projects and chuck in all of the logic in there.
Some more info about code sharing here: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/
Dependency injection: https://en.wikipedia.org/wiki/Dependency_injection
To what extent, if any, is MEF a replacement for PRISM?
Today I would say Prism and MEF complement each other. Just as Prism and Unity. Prism introduces a set of specific services like RegionManager, DelegateCommand, and EventAggregator which aid in building composite apps. MEF on the other hand is a more general composition mechanism for extensibility of applications and frameworks whether they are composites or no. The key distinguisher about MEF is it's discoverability which means that it can go out and discover all the available parts dynamically.
You might be interested in checking out the MEF contrib project (mefcontrib.codeplex.com) which contains an integration layer for Unity and MEF. With that extension, Unity manages MEF behind the scenes, so you are not contending with two contianers. The advantage is it allows you to use Unity for general Pocos, and MEF for discovery of extensions. Thus as Prism is currently built on Unity, you can use it to leverage MEF. To use the contrib project, you'll have to make some slight changes to your Unity Bootstrapper, but it should be fairly trivial.
There is definitely some overlap. The place where it's the most prominent is with regard to modules. Prism uses an IModule as a means of discovery. In MEF, any component can be a part and can be dynamically discovered. This means with MEF you have modularity from top to bottom, wheras with Prism, modules are more granular units. Composite applications is definitely an area we are conerned with on the MEF time. Over time it is quite likely you will see more and more support for building those types of apps within MEF itself. We're working with p&p to ensure that as that happens, there is a smooth transition.
Edit: Do not read this answer. It is embarrassingly wrong. I am fail. Read Glenn Block's below.
It's not obvious, but this is the same question:
Managed Extensibility Framework (MEF) vs. Composite UI Application Block (CAB)
Consensus in the duplicate post is that MEF and Prism provide the same basic set of functionality in different ways, except that Prism provides the Event Aggregator, which is a pub-sub means of communication between application components. You can use this with MEF, however. It's pretty much up to preference, really.
Take a look at this Sparkling Client podcast on MEF and Prism.
MEF will never replace prism
MEF is a dependency injection manager.its not a dependency injection container.
MEF provides ability to assign exports and imports delclaritively using attributes.
Prism with MEF gives you ability to ability to auto discover dlls and ability to add and remove plugins by adding or deleting dlls.
Where as prism framework gives event aggregator, region manager, service locator.
You can use prism without MEF. There are various other options like ninject, unity and other DI containers.
You can use MEF with prism for building plugin based extensible applications.