I'd like to use CGDisplayStream API using Xamarin for MacOS, however it seems that there are no bindings for it yet.
I browsed the code in https://github.com/xamarin/xamarin-macios/tree/main/src/CoreGraphics and didn't find any references to CGDisplayStream, the only place where I could find trace about this type was Wiki on Bindings: 1, 2, 3, but I'm not really sure how to read these pages.
Are these bindings currently missing?
If so, is that because there was no prior demand to incorporate those APIs, or is there something special about CGDisplayStream that makes it hard to bring into Xamarin?
If it's just about lack of demand, could someone guide me on how to potentially contribute adding such bindings?
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.
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.
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.
I am trying to develop an application for the mac however I am having issues trying to make multiple windows such as when you click cmd+N on safari.
I have tried looking for tutorials on how to do it however the closest I have got to be able to do this is just by creating a separate window by using this tutorial here: https://www.youtube.com/watch?v=Z1Erw7aP0EQ
If anyone knows how I can make unlimited windows using Xcode I will highly appreciate it!
Just write a NSDocument-based app, as described in Apple's docs. BTW, Apple's docs are always worth visiting together with the various tutorials you can dig up with Google.
That said, the document architecture works best if your window is going to contain something that can be viewed as a document. If the Open... (and maybe Save...) menu items make sense for your data, then you'll likely be fine with the document architecture, otherwise you should be prepared to jump through a few hoops to tweak the architecture to your needs.