This is all pretty easy, but the docs say you should only call initialize() once and my app is a bit complex, with multiple web components that are rendered in parallel, and two of them need to use the Teams SDK on page load. So how can I prevent initialize() from being called more than once while isolating code within my web components?
To prevent the multiple calls, I reached into my bag of geeky developer tricks and made this little function so it would only be called once:
Modern SharePoint is catching on, and sites are looking better than ever right out of the box. With mobile-ready pages and easier editing, customers and partners are starting to ask for it. And as SharePoint 2019 brings the modern experience on premises, the demand is likely to grow even more.
Yet even as sites look better than ever “out of the box”, there are constraints on how they can be customized. Partners and customers who want to completely change the look sometimes run into these boundaries and get frustrated.
Traditionally, our collaboration tools have been divided into silos based on the mode of communication. In the Microsoft space, we’ve used Outlook and Exchange for persistent messaging, Skype for Business for real-time communication, and SharePoint to provide a place to share documents and other information.
These tools work together to provide for our communications needs, whether they’re real-time, message based, or documents and other content. They work well together, but they’re still separate programs we have to run, and constantly flip between. As we do, the information is organized differently in each tool: most of us view email by date, Skype by person, and SharePoint by project or team. That’s a lot of context switching. Of course we’re all used to this, and probably don’t even notice how much of our attention goes into it.
This article could be useful to any Office 365 developer who wants a quick reference to the recorded sessions from Microsoft Ignite, but it’s also intended as a companion to my opening talk at the Office 365 Developer Bootcamp on October 27, 2017, in Burlington, MA. The talk is intended to show you all the ways you can develop for Office 365. Office 365 includes the Office client programs, such as Word, Excel, and Outlook, as well as the online services, such as Exchange Online, SharePoint Online, etc.
There was a ton of great content at Ignite on Office development and, thankfully, most of it is available online. Here are links to the sessions that are available as recordings, so you can dive into whatever areas you like.
This week Microsoft mapped out a bold new plan for SharePoint. Microsoft is investing heavily to modernize the product to make it work as well in the Device and Cloud era as it once did in when the Web was still shiny and new. This article will explain how these changes could affect your organization’s SharePoint plans and how you can start preparing.
In economics, a widget is a name for a generic gadget or manufactured good; on the web, a widget is a generic piece of web functionality running on a page. What makes widgets special is that, unlike controls in ASP.NET or directives in AngularJS, widgets are generally released separately from the web page that hosts them, and are often deployed by end users.
If you’re reading this blog, you probably know something about Microsoft SharePoint, and this might sound familiar. A widget is a lot like a web part, only much lighter weight. In fact, widgets can easily be hosted in content editor web parts, on a list form, in a SharePoint add-in, or outside of SharePoint. If you’re careful, you can reuse the same widget in all those contexts!
NOTE: For more on this topic, please check out this episode of the Office 365 Developer Podcast where I discuss these topics with Microsoft’s Jeremy Take; it was a great discussion!
For many years, Microsoft and others in the SharePoint community promoted SharePoint as a Platform. The idea was to develop business applications within SharePoint sites, and thus to gain access to all the rich services SharePoint brings to the table such as document management, search, user profiles, enterprise content management, and more. Another promise of this approach was that IT could support one big application (SharePoint) and deliver may smaller applications to business users, and thus deliver on the “long tail” of application needs.
Microsoft invested in features like Business Connectivity Services and the Secure Store (identity mapping) service to make SharePoint a capable platform for building business solutions that integrate with other Line of Business applications. Yet this approach wasn’t all we had hoped it would be. Continue Reading
This article is reposted from my old MSDN blog. Please post comments here as I am no longer able to publish or respond to them on MSDN. Thanks!
Microsoft is cleaning house. Now that it has to maintain SharePoint for thousands of enterprises and millions of users in Office 365, Microsoft is working to clean up all the odd and messy bits of its flagship collaboration product. In a recent training course on Microsoft Virtual Academy, Microsoft urged developers to change the way they package and deploy their code in order to clean up a mess that has been building since 2003.