locked
James Montemagno's plugins - will Xamarin support them going forward? RRS feed

  • Question

  • User89714 posted

    @DavidOrtinau - Lots of people make use of @JamesMontemagno 's various plugins. I haven't checked the others, but the Contacts plugin page at https://github.com/jamesmontemagno/ContactsPlugin now says "THIS PLUGIN IS NOT UNDER DEVELOPMENT AND NOT SUPPORTED".

    I know these are not official Xamarin things, but given their history they probably ought to be treated as such (IMHO). Can you clarify their status please - with Tizen, Mac etc support being added to Xamarin.Forms, will anybody at Xamarin be updating these plugins to support the new target platforms? Also, will anybody at Xamarin update them if new o/s updates make a code update necessary? If not, will code contributions from users be merged in a timely fashion?

    Or, are we all supposed to migrate from using these plugins to something else?

    Friday, June 30, 2017 1:47 PM

All replies

  • User130 posted

    You are right, lots of people make use of them, and with the ever increasing popularity of Xamarin and Xamarin.Forms, the workload to maintain them increases.

    It's primarily up to @JamesMontemagno, so I don't want to put words in his mouth. We have talked briefly about updating them for macOS.

    Friday, June 30, 2017 2:24 PM
  • User89714 posted

    @DavidOrtinau @JamesMontemagno - I would have thought the workload to support those plugins is tiny compared to the XF core, or even compared to things such as Xamarin.Auth (for which @moljac seems to be the only maintainer/developer, leaving everybody using Xamarin.Auth exposed to significant Key Person Risk). On the other hand, the number of people using those plugins, as they have been recommended so often in the past, is significant. I'm not suggesting @JamesMontemagno should be responsible for keeping them updated single-handed, but the XF team should be collectively responsible. That way, the Key Person Risk is managed.

    For those plugins, the priority should clearly be ensuring they keep working as o/s updates come out for the existing platforms. But as new XF target platforms are announced, the new target platforms should get equal priority. Whilst I know most Xamarin insiders seem to love all things Mac, that doesn't help anybody targeting the other platforms for which XF support is being added, otherwise Xamarin may as well kill off those targets before they even hit the stable channel.

    If Xamarin will not be adding Tizen support for those plugins, is there somebody at Samsung who will do so? Do you have a name you can share?

    Friday, June 30, 2017 2:41 PM
  • User318788 posted

    @DavidOrtinau said: You are right, lots of people make use of them, and with the ever increasing popularity of Xamarin and Xamarin.Forms, the workload to maintain them increases.

    It's primarily up to @JamesMontemagno, so I don't want to put words in his mouth. We have talked briefly about updating them for macOS.

    Can Xamarin provide some of such plug-ins as in-built API or feature which provides core features like accessing contacts or reading messages or making a phone call /sharing application content etc. I've seen people facing issues with the every versions changing and new things are not easy to keep track of.

    It feels better to hold Swiss Army Knife :wink: .

    Friday, June 30, 2017 2:44 PM
  • User130 posted

    The Samsung Tizen team has expressed interest in contributing more, though we haven't discussed community plugins specifically. I'll reach out to see who might want to consider and comment on that. Again, don't want to put words in the mouths of others.

    I'm not suggesting the workload of maintaining a plugin or even set of plugins rivals XF core. I'm just saying that more plugins, more users, more platforms to support, more issues, more PRs... all means more work. It's not nothing.

    Key Person Risk - I understand your concern. Maybe I'm putting too much faith in Open Source, but these plugins and components such as Xamarin.Auth are all fairly simple and I've tweaked one or two for my own needs when it suits me.

    All that said, I'm open to discussing the support and development of these popular plugins. I would like @JamesMontemagno however to drive or at least start that part of the conversation since he's the steward of these plugins.

    Friday, June 30, 2017 3:10 PM
  • User25759 posted

    I think there are a couple of things here to remember. Plugins are just like any other NuGet package or library that you consume that are also open source. Some are backed by companies and some are backed by individuals. Some have one person working on them, while others have several, or maybe even hundreds of them. As a developer you need to decide specifically if pulling in any library is what is best for you. This is for every development language and is across all platforms, just look at npm and the packages there, they are the same. I think your Key Person Risk is pretty much on any library out there though to be honest.

    Plugins are a lot of work. They may not seem like it, but they are and I pour tons of hours in to the ones I create all throughout each day of the week and often late nights and weekends when something is discovered. I spend hours each day just responding to GitHub issues, which are usually just from someone not following instructions or asking questions about the plugin or sometimes a legit bug or documentation issue. I do all of this in addition to documentation, video, blogs, app creation, testing, etc that I generate from them (and then I still have my full job to do too). This week alone I purchased additional Android devices just to triage a bug that someone had submitted. I am not alone, as all plugins and library creators are this way. It is a big responsibility when pushing code and packages up to NuGet.

    I would recommend reading through my blog on my move to .NET Standard and adding additional platform support where I could: http://motzcod.es/post/162402194007/plugins-for-xamarin-go-dotnet-standard. It is a good breakdown of my plugins, their future, and their structure that I hope is adopted by all.

    I do this because I love Xamarin, I love Plugins, and I want to help developers create awesome apps even faster then they could when I started six years ago. Today, I start a new project, type jamesmontemagno into NuGet, and my app is off to an amazing start. When kick started this initiative a few years ago I would have never imagined them growing so big, so fast, and so many awesome developers creating their own for people to use and learn off of.

    As I create more apps on more platforms and .NET goes more places I have brought my plugins to them where I can and where I can test and support them myself. It is really hard for me to official support something like Tizen when I have no devices to possibly test on and NuGet itself still haven't really figured out the packaging, but I do plan on adding more platforms in the future to plugins where it makes sense. If I don't support your platform yet, with .NET Standard you can simply implement the interface yourself and use the plugin where it is supported.

    The beautiful part here is that plugins themselves are open source, all under MIT. Fork, send PRs, create your own based off of it, go for it.

    In the larger scope of Plugins in general I have done a lot of thinking on them, unifying them, and long term support of them. The .NET Foundation is an interesting option, unifying under a GitHub organization is also interesting. All of this is more time, energy, and resources.

    Finally: I will comment on my Contacts plugin, which I have officially retired. For one, it never left a pre-release state, it was never fully working nor recommended for production use. Additionally, what I found is that more developers wanted a contact picker than a contacts api, which is what I am going to be working on next.

    Saturday, July 1, 2017 12:31 AM
  • User328433 posted

    Can someone priortize the plugins in terms of usability and popularity? We'd love to contribute it for Tizen step by step. This will help us to planning and making its strategy.

    Monday, July 3, 2017 4:59 AM
  • User25759 posted

    @rookiejava you can find a list: https://github.com/xamarin/XamarinComponents#community-provided-open-source-plugins

    Monday, July 3, 2017 7:21 AM
  • User328433 posted

    @JamesMontemagno Thank you for sharing. What I mean is, set a prioirty among them.

    Monday, July 3, 2017 7:37 AM
  • User89714 posted

    @rookiejava - This is my own prioritisation of some of the plugins produced by @JamesMontemagno (and associates where applicable). Settings and Permissions are the two highest priority. After those two, it's more subjective, but this is the list I came up with:

    Settings Permissions Connectivity Geolocator In-App Billing Share Contacts Vibrate CurrentActivity DeviceInfo Notifier

    Of other plugins listed at https://github.com/xamarin/XamarinComponents#community-provided-open-source-plugins that I use, the followings is my prioritisation. Xamarin.Auth is the highest priority, but is marked as Xamarin supported, so you may want to liaise with Xamarin (@moljac) for that one:

    Xamarin.Auth (Xamarin supported) Toast Calendar Cryptography Microsoft Band

    And other assorted Nugets:

    Newtonsoft.Json Microsoft.Azure.Mobile.Client Windows.Azure.MobileServices sqlite-net-pcl SQLitePCL MobileCenter (when stable, and/or HockeySDK until then) modernhttpclient NUnit Validation Xam.Plugin.Badge

    My Tizen test device was delivered to a contact in India today. It should be delivered to me in the UK within a couple of weeks, so I'll be ready to test some time after that.

    Monday, July 3, 2017 8:58 AM
  • User74518 posted

    @JohnHardman you forgot Media, it should be in the top 5 IMHO. And MS Band is dead.

    Monday, July 3, 2017 2:24 PM
  • User89714 posted

    @nadjib - Those weren't comprehensive lists, just based on some of the bits that I use. For Microsoft Band, I did put it bottom of that particular list due to its deathbed position.

    (Personally, I hope that if MS can sort out the MS Band durability issues, they will bring it back next year - the 2nd version was/is actually rather good, subject to the durability caveat. I'm not hopeful though, so stocked up on a few while I still could)

    Monday, July 3, 2017 2:35 PM
  • User42522 posted

    I know @JamesMontemagno , you might have spent some considerable time while writing your response post above. Some times writing logically takes more time than logical coding.

    40 years back, when there was no internet accessible, I also used to spend lot of time designing, coding, debugging,.. And also imagine the hardship by those mainframe programmers who get to know of a small bug in the bunch of cards submitted for processing after 3 days...

    But I wonder sometimes even after so much development of faster machines and large memories, it still takes long time to do any reasonably useful coding. And also I keep wondering, whenever I see James in the conferences, how this guy could cope up with so much work... James, do take some vacation...sincerely...

    Monday, July 3, 2017 2:54 PM
  • User89714 posted

    @ShantimohanElchuri - Noooo, don't suggest @JamesMontemagno take vacation, not until somebody can hold the fort in terms of applying updates etc to the various plugins whilst James is biking in far flung places, far, far away from mobile reception ;-)

    Monday, July 3, 2017 3:25 PM
  • User328433 posted

    @JohnHardman, @nadjib - Thank you for your prompt reply, in which you gave me some important picese of advice. I will dicsuss with my team and contribute it as soon as possible.

    Tuesday, July 4, 2017 12:09 AM
  • User125 posted

    yes, I know I am late to the party on this discussion and everything has already moved on. :-) This is an issue that I am really passionate about, the status of the components that make my projects go.

    Open source is cool and all that, but it causes too many problems. Yes, I know about the free love of the OS community. If someone wants to create a product and freely release the source code, keep it up to date, I'm all for it. If they want to put it on nuget, I'm all for it. If someone wants to charge money for the source code/component, I'm all for it. If someone wants to walk away from a component, I get it, but I can feel stuck by this, and trust me, I've been stuck before.

    I'm a business. My code is how I make money. I will occasionally use a third party component. However, with XF, to make things work at something approaching real world, I have to have add a bunch of third party components. Now, I have tried to limit this to only the absolutely most necessary components, so I have stayed to James' components and some others from Xamarin employees. Long term support, bug fixes, support for new OS versions, these things are important. Keeping these components up to date takes time and effort, which translates to money and business time to do this. Basically, people have to be paid to provide these components. There is no free lunch.

    When one person is the holder of the code, there is a danger that something can happen to that one person. James is the face of his components, and this scares me, not his face but the one person part. :-)

    For the safety of the community, xamarin, and my projects, it makes a lot of sense for Xamarin to purchase the rights to a lot of these third party components and include them in the XF "software package" that we get access to.

    Thursday, February 8, 2018 2:57 PM