Forum Xamarin Xamarin.Forms

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

JohnHardmanJohnHardman GBUniversity admin
edited June 2017 in Xamarin.Forms

@DavidOrtinau - Lots of people make use of @JamesMontemagno 's various plugins. I haven't checked the others, but the Contacts plugin page at 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?


  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    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.

  • JohnHardmanJohnHardman GBUniversity admin
    edited June 2017

    @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?

  • N_BauaN_Baua INMember ✭✭✭✭✭

    @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: .

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    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.

  • rookiejavarookiejava KRMember ✭✭

    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.

  • JamesMontemagnoJamesMontemagno USForum Administrator, Xamarin Team, Developer Group Leader Xamurai
  • rookiejavarookiejava KRMember ✭✭

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

  • JohnHardmanJohnHardman GBUniversity admin
    edited July 2017

    @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:

    In-App Billing

    Of other plugins listed at 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)
    Microsoft Band

    And other assorted Nugets:

    MobileCenter (when stable, and/or HockeySDK until then)

    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.

  • Amar_BaitAmar_Bait DZMember ✭✭✭✭✭
    edited July 2017

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

  • JohnHardmanJohnHardman GBUniversity admin

    @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)

  • ShantimohanElchuriShantimohanElchuri USMember ✭✭✭✭✭

    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...

  • JohnHardmanJohnHardman GBUniversity admin

    @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 ;-)

  • rookiejavarookiejava KRMember ✭✭

    @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.

  • wallymwallym USInsider, Beta ✭✭✭

    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.

Sign In or Register to comment.