Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (12)
Similaire à PWA - ADT Magazine Webinar
Similaire à PWA - ADT Magazine Webinar (20)
Plus de Sandeep Adwankar
Plus de Sandeep Adwankar (20)
Dernier
Dernier (20)
PWA - ADT Magazine Webinar
- 1. © 2018 Sencha Inc. Progressive Web Applications -- Are They Ready for the Enterprise? Sandeep Adwankar Sr. Product Manager Sencha Twitter: @adwankar
- 2. © 2018 Sencha Inc. What will be covered • Why Progressive Web Apps? • Key Capabilities of Progressive Web Apps • Enterprise Considerations in PWA • Sencha Platform • Building PWA Service workers • Service Workers Caching Strategies • Modern Tunes PWAApp Demo
- 3. © 2018 Sencha Inc. Internet growth is huge! Global Internet Users > 3.6B Source: Internet Trend Report 2018
- 4. © 2018 Sencha Inc. Majority of Internet Usage is across Multiple platforms Multiplatform users average across markets of 46% of the total population Source: ComScore Global Digital Future in Focus 2018
- 5. © 2018 Sencha Inc. Internet user behavior is not the same on mobile web vs. app Mobile apps have a higher concentration of time spent in the top 10 and a significantly smaller long-tail than desktop and mobile web Source: ComScore US Mobile App report 2017
- 6. © 2018 Sencha Inc. Native Mobile Apps showing slower discovery and download A majority share of smartphone users don’t download any apps in a month
- 7. © 2018 Sencha Inc. Key Capabilities of Progressive Web Apps Better Discovery and Bringing Mobile Native like Capabilities to Mobile Web
- 8. © 2018 Sencha Inc. Progressive Web Apps Are… Fast EngagingReliableIntegrated Source: developer.google.com
- 9. © 2018 Sencha Inc. Time is Money. 58% 13% 20%
- 10. © 2018 Sencha Inc. Progressive Web Apps Are… Integrated EngagingReliableFast
- 11. © 2018 Sencha Inc. Integrated Experiences • Launch from Home Screen • Visible in task list
- 12. © 2018 Sencha Inc. Integrated Experiences • Integrates with other APIs
- 13. © 2018 Sencha Inc. Integrated Experiences • Integrates with the device
- 14. © 2018 Sencha Inc. Progressive Web Apps Are… Reliable EngagingFast Integrated
- 15. © 2018 Sencha Inc. Service workers enable reliable performance Web server Service worker Client side proxy written in JavaScript Cache
- 16. © 2018 Sencha Inc. Progressive Web Apps Are… EngagingFast ReliableIntegrated
- 17. © 2018 Sencha Inc. Web Push Notifications
- 18. © 2018 Sencha Inc. Enterprise Considerations in PWA Most enterprise software stays in production for 5 to 10 years – or more!
- 19. © 2018 Sencha Inc. Incredible pressures distort the typical development process
- 20. © 2018 Sencha Inc. Key considerations in building enterprise PWA apps • Support for multiplatform using single code base • Using Best Practices Code • Architect for future • Unit and functional testing • Enterprise security Single Code Base • Comprehensive: no need to source, assemble and maintain third-party components • Develop once in a single code base for multiple platforms and devices • Integrate into enterprise developer workflows • Seamlessly design, develop, troubleshoot, test, and deploy Developer Efficiency • Rapidly Iterative • Optimized and Performant • High performance widgets • Designing for visually compelling applications • Visually Inspirational • Powerful analytics, components Platform for Future
- 21. © 2018 Sencha Inc. Selecting a Web Platform for the Future 21 View System Interface Elements Logic & Data Server i/o • Create appealing themes and styles for interactive elements • Present complex data using structured presentation elements like grids and charts • Create a standard visual vocabulary across apps • and more... • Dynamically lay out screen elements in response to different screen sizes and resizes • Detect and respond to touch gestures beyond simple taps • Swap in local language strings, handle RTL languages and keep everything accessible • Animate content and more... • Update the screen when data changes and vice versa • Remember application states to enable undo/redo as well as navigation • Search, sort, filter, group and validate data • and more... • Handle asynchronous calls to the server-side • Parse and convert serialized data • Call out to server-side code • and more...
- 22. © 2018 Sencha Inc. Key Components of Enterprise PWAs 22 View System Interface Elements Rendering, DOM, fonts, parallelism, security, media decode, sensors, printing, network i/o...Base Services Basic Widgets (buttons, bars, text fields...) Containers & Windows (panels, cards, modals...) Themes Compound Widgets (trees, grids, gauges...) Visualizations (charts,infographics) Styles Layout Manager (absolute, flex...) Templating (iterations, conditionals.) Visual Effects (animations, filters...) Accessibility (focus manager, ARIA...) Drawing (vector, bitmap...) Localization (RTL, locale libraries) Interactions (gestures, drag & drop) Theming (computed styles) State Manager (history, undo, routes...) Modularity (components, modules ) Data Binding (1-way, 2-way) Testing (IOC, test hooks) Data Objects (queues, hashtables...) Persistent Data (cache & sync) Data Models & Stores (group, sort, validate) Multi-Media (3D, Audio, Video) Logic & Data Server Calls (asynch, conversion) Sockets Server Method Invocation Server Notifications Server i/o PWA Libraries sw-precache, sw-toolbox workbox
- 23. © 2018 Sencha Inc. FEATURES Platform Choices Core/Foundation UI Components Layouts Theming Package Management Build Testing Deployment Support Training Raw CSS Minify, Concat, Uglify Third-party help Third-party training
- 24. © 2018 Sencha Inc. Sencha Web Platform
- 25. © 2018 Sencha Inc. Technical Facts Over 350 man-years of engineering and development expertise in web technologies Leaders in modern web technologies (HTML5, JavaScript and CSS) Market leading Ext JS framework Background Facts Founded in 2007 Austin, TX Headquarters Part of Idera, Inc. Customer Facts 60%+ of the Fortune 100 as customers 10,000+ enterprise customers 2M+ worldwide developer community Billions of dollars transacted and hundreds of thousands of employees supported Sencha Overview
- 26. © 2018 Sencha Inc. Market Leaders Rely on Sencha Software Automotive Government & Contractors Financial Services Healthcare & Pharma Communication, Media & Entertainment Computer, Networking & Telecommunications Aviation, Transportation & Logistics Gaming
- 27. © 2018 Sencha Inc. Sencha Web Application Platform Design Mockup | Prototype Test Tools Develop Frameworks | Tools Enterprise Workflow Integration IDE | Backend Connectivity | Build/CI Education&Support Implementation& CustomizationServices
- 28. © 2018 Sencha Inc. FEATURES Platform Choices Core/Foundation Ext JS UI Components Over 200 UI components built-in Layouts Built-in Theming Built-in, Sencha Themer Package Management Hosted npm Build Open tools – ExtGen Testing Sencha Test Deployment Sencha Cmd, ExtBuild Support Sencha Support Team Training Sencha Training Team Raw CSS Minify, Concat, Uglify Third-party help Third-party training
- 29. © 2018 Sencha Inc. FEATURES Platform Choices Core/Foundation Ext JS UI Components Over 200 UI components built-in Layouts Built-in Theming Built-in Package Management Sencha Cmd Build Sencha Cmd Testing Sencha Test (Q4) Sencha Inspector Deployment Sencha Cmd Sencha Web Application Manager Support Sencha Support Team Sencha Professional Services Team Training Sencha Training Team Official training partners worldwide Raw CSS Minify, Concat, Uglify Third-party help Third-party training
- 30. © 2018 Sencha Inc. Getting Started with Ext JS using Community Edition
- 31. © 2018 Sencha Inc. Ext JS App – Modern Tunes App using Open Tooling
- 32. © 2018 Sencha Inc. Building PWA Service Workers
- 33. © 2018 Sencha Inc. Service worker Cache Web server Service Workers: Client-side JavaScript proxy
- 34. © 2018 Sencha Inc. Service Workers: A Foundation for Push example.com onpush = function(event) { var data = event.data.json(); self.registration .showNotification(data.title, data.options); }; ServiceWorker.js Push Subscription End Point
- 35. © 2018 Sencha Inc. Service Worker Life Cycle • Adds app-like lifecycle to a page • Wakes up only when the OS says • Only responds to system events Activated Error Idle Active Terminated Install Register Source: developer.google.com
- 36. © 2018 Sencha Inc. • Adds app-like lifecycle to a page • Wakes up only when the OS says • Only responds to system events Activated Error Idle Active Terminated Install Register Service Worker Life Cycle
- 37. © 2018 Sencha Inc. • Adds app-like lifecycle to a page • Wakes up only when the OS says • Only responds to system events Activated Error Idle Active Terminated Install Register Service Worker Life Cycle
- 38. © 2018 Sencha Inc. • Adds app-like lifecycle to a page • Wakes up only when the OS says • Only responds to system events Activated Error Idle Active Terminated Install Register Service Worker Life Cycle
- 39. © 2018 Sencha Inc. Life Cycle of a Service Worker Installing the Service Worker 1st Page Load install idle
- 40. © 2018 Sencha Inc. Life Cycle of a Service Worker Installing the Service Worker 2nd Page Load activated check for update
- 41. © 2018 Sencha Inc. Life Cycle of a Service Worker Installing the Service Worker Close Page idle terminated activated
- 42. © 2018 Sencha Inc. Life Cycle of a Service Worker Updating a Service Worker Load Page with Service Worker activated check for update
- 43. © 2018 Sencha Inc. Life Cycle of a Service Worker Updating a Service Worker Load Page with Service Worker activated check for update install idle
- 44. © 2018 Sencha Inc. Life Cycle of a Service Worker Updating a Service Worker Load Page with Service Worker activated check for update install idle
- 45. © 2018 Sencha Inc. Service Workers Caching Strategies
- 46. © 2018 Sencha Inc. Cache, Falling Back to Network Source: developer.google.com
- 47. © 2018 Sencha Inc. Network, Falling Back to Cache
- 48. © 2018 Sencha Inc. Cache then Network
- 49. © 2018 Sencha Inc. Generic Fallback
- 50. © 2018 Sencha Inc. Cache and Network Race Cache and Network Race
- 51. © 2018 Sencha Inc. Modern Tunes PWA Demo 51
- 52. © 2018 Sencha Inc. Q&A
- 53. © 2018 Sencha Inc. Poll Question: What would you like to do next? • Schedule a demo of the Sencha Platform • Download Modern Tunes PWA Github app • Register for Ext JS Community Edition • Learn more about Sencha Platforms for Angular and React 53
- 54. © 2018 Sencha Inc. Thank You! Try Ext JS Community Edition https://www.sencha.com/products/extjs/communityedition/ The Modern Tunes PWA App Github https://github.com/adwankar/moderntunes-pwa-app Google Developers https://developers.google.com/web/progressive-web-apps/
Notes de l'éditeur
- The growth in global internet usage is continuing - Now around 50% of internet users are accessing web apps
- Multi-platform users (those who access online content via desktop and smartphone / tablet in a month) remain the majority overall, with an average across markets of 46% of the total population. Mobile only usage now averages just above desktop only consumption with a cross-market average of 30%, driven heavily by large share in APAC markets, versus 24% for desktop only.
- As you can see – there is no desktop native, As desktop web is enhanced and capable as native desktop apps. Mobile apps have a higher concentration of time spent in the top 10 and a significantly smaller long-tail than desktop and mobile web One way to think of the differences between native and web apps is on the capability - native apps have the ability to start up reliably when you tap their icon. They boot up quickly, they tend to work offline (who here has opened a web browser to use a web app when they KNOW their device is offline?), they can send push notifications, and sync in the background, they have access to sensors like microphone and camera...by contrast, the Web is safer, and more respectful of privacy, but doesn't have those capabilities, does it? Instead the web excels in reaching users.
- According to a recent comScore study, A majority share of smartphone users don’t download any apps in a month, and the average user downloads two App discovery is down across several channels, including the app store, word-of-mouth and advertising. Is interest in new apps waning? By contrast, mobile users visit over 100 web sites per month. This is the power of URLs and the ephemerality of the web. They meet one-off needs.
- So what if we could add the capabilities we need, and the web could meet those UX expectations? We could have the best of both worlds. This is what Progressive Web Apps represent - a user experience good enough, integrated enough, to earn a place on the home screen and in the notification tray, without having to give up reach to get it. In order to do that, we need to focus on four things. Making the web FAST. Making experiences more INTEGRATED. Ensuring that they are RELIABLE. And keeping users ENGAGED. Let’s take a look at each of these properties in a little more depth.
- Users don’t expect janky scrolling or slow load performance. The web has a bad name for slow performance, particularly on mobile; although in-page performance isn’t my focus today, that’s fixable. But Fast also means fast loading - supporting the reliable point; loading an app has to be invisible.
- We all know time is money. This data from SOATSA shows just how much that's true. After only a little more than three seconds, 20% of your users have abandoned the experience
- Users shouldn’t always have to reach through a browser tab to access your app. In fact, the user shouldn’t even think about the fact that they’re on the web, just that they’re using the phone, tablet or desktop to complete the task.
- Users should be able to interact with your app in the same way that they do all other apps on their device. They expect to launch it from the same place they launch all of their other apps. They expect to see it in the task list. They expect it to have all of the capabilities and hardware access that other apps have. Web Payments - something we’ll cover in a bit more depth later - is a good example of keeping a user in your flow, while using some interesting device functionality to complete a payment. Instead of requiring the user to fill out a complex checkout form, the Payment Request API simplifies it down to a few taps, and can even integrate with other payment apps on the users device like PayPal or Android.
- Web payments - is a good example of keeping a user in your flow, while using some interesting device functionality to complete a payment. Instead of requiring the user to fill out a complex checkout form, the Payment Request API simplifies it down to a few taps, and can even integrate with other payment apps on the users device like PayPal or Android.
- Another good example - media playback. With the media session API, you can provide metadata about what’s currently playing, and even handle media related events from the user. If the screen is locked, the user can quickly see what song is playing, and maybe skip to the next song.
- Users don’t expect the web to work without a network connect, and often don’t even bother to try when it’s a slow or intermittent connection. We need to change that perception. Web apps must be reliable. When a user taps on a home screen icon, they expect it to load instantly and reliably. Launched from the home screen, it should never show the downasaur.
- But what if you didn't need to traverse the network every time for every asset? What if you could intelligently cache assets locally, reliably? That's what Service Workers do. Service Workers enable you to implement caching with the Cache API, not just by hoping to rely on browser caching. This means that after the first visit, sites and apps can be reliably fast.
- An engaging app goes beyond functional, but ensures that the whole experience is delightful making it easy for the user to do what they need to do. Using features like Web Push, it’s always up to date, and Notifications keeps users informed. It uses the right capabilities, at the right time, in a beautiful way.
- While mobile push notifications have existed for a while, I’m really excited we finally have access to them as web developers - even when your web application isn’t currently running, and the browser isn’t even open! On mobile devices, notifications are a fundamental part of turning a monthly active user into a daily active user; they truly unlock re-engagement, and a bunch of new use cases.
- One of the things that has stuck with me is how their applications can stay in production for a really long time – as long as 5 or 10 years! At the same time, the browsers considered “modern” today will be considered “legacy” tomorrow… so it’s unlikely they will be supported 5 years from now There is a high cost associated with the long-term maintenance of enterprise applications, so I think it’s absolutely prudent to choose the webapplication stack very carefully.
- Longevity Enterprises need to think of creating web apps that last for 5-10 years. Creating maintainable apps is much easier when you have a single code base across multiple devices. You use latest Javascript standards, use full unit and functional testing. Enterprises need to think about security, access control, compliance with privacy rules, along with containment and isolation of business data from personal data when the data is available for offline use. Also, enterprises need to deal with the management and provisioning aspects of deployment. Additional security can be enforced by implementing Content Security Policies to identify legitimate sources of assets (images, etc.), and protect PWAs from attacks. To remotely manage data sitting on a user's device, the cache can be named and a remote wipe method (invoked by the service worker) can be created. A background synchronization can be implemented as a one-off or a periodic sync to ensure data integrity. Developers have been using progressive development methodologies for years. It enables them to provide the best experience on fully-capable browsers and an acceptable experience on less-capable browsers. By detecting browser features, developers can drive specific application behaviors, even for enterprise applications. And to ensure that the UI fits for different form factors, developers can use media queries, layouts, viewport, and other responsive design building blocks. For many such capabilitues, there is really no new technology required specifically for PWAs. For long running applications, it is important to be “functional” – by providing rapid iterative capability, optimization within apps and making apps performant. It is best to use key software plarforms to accomplish that
- Most web applications have a set of common challenges. The first challenge is how are you going to create the user interface elements - the widgets and charts and grids and the look of the application The second challenge is how are you going to manage the layout and interactivity of your screen elements, and how are you going to do things like display your data in a high-contrast theme for accessibility, or adapt it for right-to-left languages like Arabic? And the newest problem: how are you going to build applications that work on both desktop screens with mouse input and mobile screens with gesture interactions. The third challenge is how are you going to manage your local data. How are you going to update the screen when the data changes, and update your data when the user gives you input. And finally, there’s the challenge of managing server communications.
- But before we go into how you choose the best framework for your apps and your organization. It’s important to flesh out the basic geography of the most popular frameworks and libraries, because without a map it’s easy to get lost.
- Lightning bolt - Functionality gap is mind boggling HTML5 but CSS3 even more so require fundamental changes
- Within our 8000 worldwide enterprise customers, applications developers are using Sencha to build business critical applications that drive global commerce and the world’s governments.
- A Service Worker is a client-side proxy that you write in JS; after the first visit, the SW is installed and can respond to network requests. The SW can cache the resources you need for the page; this bit of proxy code is then loaded up whenever the subdomain is requested. The SW enables a developer managed cache that frees you to decide when to use the cache and when to hit up the network.
- One of the cool things is that Service Workers can do more than just service network requests, they can service other system-level notifications - [CLICK] like push messages sent from an end point. The push notification is just another request that the SW services - it’s just a request from the outside, not from the web browser. It wakes up the SW, calls its onpush handler, and it’s done.
- I'll say it again, because I think it's important, a Service Worker doesn’t consume any system processing resources until it’s woken up to handle an event. In fact, even if the browser is closed, the OS can wake up a service worker. We're no longer limited to the model where an “app must be loaded in an active tab” to be useful. This is important because it introduces an app-like lifecycle for the web.
- When a service worker is first registered, it fires an "install" event which you can then use to pre-fetch and cache the resources your app needs. In effect, you’re running a fully scriptable install, much like a native app; but there are no bulky zip files and you have file-level control over what is fetched, how its cached and how it is updated.
- Once the service worker has been activated, you now have full control over how the system services your app’s resources. You can inspect network requests, rewrite them, get a response from the network, respond with one of the resources you pre-fetched and cached when the service worker was installed. You can even synthesize your own responses.
- All of this is completely transparent to the user - in fact, a well-constructed Service Worker can function as just a very smart caching system; a progressive enhancement of the network and cache, choosing smarter ways to respond to requests. It gives you the ability to make your apps reliable, even when the network isn't because you have full control over the response. On the topic of “Service Worker as a progressive enhancement”, it’s important to understand that the FIRST time you load the page, it’s still going to be loading from the network - the index page has already been retrieved from the network, of course, and the page’s resources will kick off downloading normally. The Service Worker will come into play on subsequent loads, not the first load. Though, there is one caveat to that, I'll cover that in a moment.
- Let’s walk through an example. When this page is first loaded, it registers a service worker for a specific scope, we'll get into scopes in a few minutes, but for now, think of it as the set of pages the service worker will handle. [CLICK] An install event is fired, and the code in your install handler is executed. [CLICK] Then, the service worker goes to idle, essentially sitting there quietly.
- When the page is reloaded, or you hit another page covered by the service worker, the service worker becomes activated, ready to handle all of its events. At the same time, [CLICK] the browser also makes an asynchronous request to the server to see if the service worker has changed since it was last retrieved.
- Once the service worker has handled all of the events, [CLICK] it goes to idle, and eventually it's terminated, ready to spin up again when any new events come in.
- Let's keep going with our previous example and see how a service worker gets updated. Since we've already been to the page, the service worker is already installed and is immediately activated. [CLICK] Then, just like before, the browser checks with the server to see if the service worker has changed, and this time, it has.
- The new service worker is downloaded and installed - but it goes to idle and the original service worker is still activated. Our original service worker is still handling requests. In fact, our original service worker will remain active and serving requests until all of the clients using it have been closed.
- This is an important point to remember as you're working on your own service workers. You may find yourself in situations where you have multiple service workers installed and waiting, because the original one, hasn't been terminated yet. There are ways to work around this but we’ll cover those a bit later.
- The cache first with network fallback strategy we’ve laid out is pretty straightforward - always go to the cache first. If the request matches a cache entry, respond with that. Otherwise try to fetch the resource from the network. This option is good for resources that don't change, or have some other update mechanism. It will give you a very fast response - since objects come out of the cache directly - but it doesn’t update. On the negative side, if an item isn't in the cache, it's not automatically added after its retrieved from the network.
- The network, falling back to cache strategy means you give online users the most up-to-date content, but offline users get an older cached version. If the network request succeeds you'll most-likely want to update the cache entry. However, this method has flaws. If the user has an intermittent or slow connection they'll have to wait for the network to fail before they get the perfectly acceptable content already on their device. This can take an extremely long time and is a frustrating user experience.
- Cache, then network requires the page to make two requests, one to the cache, one to the network. The idea is to show the cached data first, then update the page when/if the network data arrives.
- You could also do a generic fallback solution where a request is made first to the cache, then the network, and if both of them fail, a second request is made to the cache for a generic page.
- Or have the cache and the network race…