Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a O365 Sydney - Hybrid Dev
Similar a O365 Sydney - Hybrid Dev (20)
Más de Elaine Van Bergen
Más de Elaine Van Bergen (9)
O365 Sydney - Hybrid Dev
- 5. Experiences ManagementExtensibility | Server | Server ManagementExtensibilityExperiences | ServerHYBRID Team Sites Portals Search Enterprise Content Mngt BI
- 7. Connecting to SharePoint from an Office App
- 8. Demo - Napa
- 9. Fundamentals
- 15. Hybrid Provisioning Sample from Vesa #BRK3170
- 16. Authentication
- 18. Microsoft Azure Active Directory Samples and Documentation Fiddler Oauth Inspector
- 21. Azure AD Demo
- 22. ADAL CORS Sample by Andrew Connell Azure Active Directory Proxy blog post by Kirk Evans Dynamic Groups Blog Post by Wictor Wilén
- 26. API Sandbox
- 29. Wrap Up
Notas del editor
- If you are still developing the same way you did 2 years ago , almost everything ! Get on-board with all the great new changes In fact even since we drafted this presentation Apps have become Add-Ins. This change has been done to assist end users as having apps within office apps is confusing. As developers I am sure you will give us a little leeway if we use the old term accidently in the presentation.
- Where we have been is needing to create specific code per clients/platform Deployment and maintenance for all these versions can be hugely time consuming and difficult , hence also expensive.
- As we move into the new Add-In world it is becoming increasingly possible to have a single version that works across both Client and Online versions of office. Moving forward this is also even extending in to the iPad versions. At the server end the same thing is happening where instead of having to use separate API sets for exchange, lync and SharePoint we are moving towards a single set of API’s that work across the entire platform. This is an ongoing process that is progressing very quicker and makes it significantly quicker to write and maintain add-ins.
- With all these changes as developers we need to make sure that we also shift our mindsets. At a high level we need to make a shift from thinking about being a developer who only works on one part of the stack and uses the specific best practices for that piece to creating code that works across the stack. My background is SharePoint so I will use that as an example. In the past I have seen a lot of SharePoint development done in a very tightly coupled manner where all the code runs right within SharePoint. Now we want to try to shift to being what I call a SharePoint Adjacent developer where all the code that does heavy lifting like business logic or integration runs alongside the SharePoint platform with the minimum possible amount for what I need to achieve running within SharePoint. Keeping this code outside of the SharePoint platform then also makes it easier to interact with other platforms such as Exchange.
- With all the changes that have occurred and will continue to occur it is very important that for any development project you know exactly what versions you need to interact with. If you are dealing with an environment that has Office 2010 or does not have a regular patching cycle for their SharePoint environment you will be limited in some of the newer api sets and techniques. Many of the items we talk through you will still be able to use, however some in a limited manner. Several of the CU’s for SHarePoint have updated API sets to help keep them inline with the O365 versions. Equally the version of your dev tools makes a huge difference as well. Where the newer your visual studio version is the easier it typically will be to interact with the newer API’s or authentication mechanisms. You can still use the older versions just typically involves lots of manual wiring up.
- With every type of Add-in that we are developing there are some fundamental techniques that you should consider.
- The first item is of course getting an environment setup that matches what you need to deploy to. Depending on what you need to create there can be a lot of steps to go through. If you are working on-premises this means you need to setup an entire SharePoint farm and the steps to configure apps for that environment involves a few moving parts that some developers are not familiar with. There was an entire session on this earlier in the conference if you missed that catch-up on the recording. Things are a lot easier for Office 365, you can now sign up to the developer program and get free access to
- What I have seen happen to many developers who have become specialized in a specific part of the platform whether that is SharePoint or part of the Office stack is that over time they move away from traditional development best practice. That’s not the case for all developers however certainly the number of SharePoint webparts that I have seen with 1000’s of lines of code of business logic all in a single code file indicates that it is a fairly wide spread problem. Hence just a quick reminder to think about your layers for any solution you are creating. Also especially when dealing with older versions of Office or on-prem versions of SharePoint we need to write platform specific code in most cases. What we want to make sure is that the platform specific code is as minimal as it can be for the solution you are writing. This makes it easier to make you application work easily as a hybrid solution or to switch it to entirely online. Later we will show an example
- Getting up to speed with a lot of the new stuff can seem daunting the samples in the Developer P and P really helps. These are updated frequently by both Microsoft and community contributors. The scale of the amount of code makes it unlikely you will have enough time to deep dive into every piece. Once a month triage it to see what has changed and then whenever something new needs to be done in a project or a major refactor , quick check is there something in PnP that I can use.
- Cloud ready – Claims Headless