Google Cloud Next 2017 is an immersive event that brings together executives, customers, partners, developers, IT decision makers, and Google engineers to build the future of the cloud. See what's coming from the Google Cloud Platform, G Suite, Maps, and Devices teams.

What was once considered impossible is now being rewritten. Innovation is accelerating because of what cloud can already do — it’s now your imagination that will drive what’s next. Engage with the foremost minds leading the cloud revolution and learn how the modern enterprise is benefiting from the latest in cloud technology in unprecedented ways. Join community of visionaries, developers, tech advocates, enterprise partners, and global customers to build for tomorrow. Now has arrived, at Next.

GDG Benin will be sharing the experience.

Date: Saturday, 29th April 2017 (tomorrow)

Time: 9am

Venue: Blue Meadows (Basement) - University of Benin

BE THERE

DevFest Ado Ekiti is a large, community-run event which is organised as a collaborative cluster event among several GDGs in the south-western region of Nigeria. Last year, this cluster recorded huge success during a similar event tagged: DevFest Akure. This year’s cluster Devfest is proposed to be a way better. You are invited to attend. Please click this link to register: Devfest Ekiti registration link

what are Progressive Web Apps, exactly?

Native app store apps do things like send push notifications, work offline, look and feel like an app (as Apple and Google have imagined them), load on the homescreen, and so on and so forth. Mobile Web Apps accessed in a mobile browser, by comparison, historically haven’t done those things. Progressive Web Apps fix that with new Web APIs, new design concepts, and new buzzwords.

To be clear, I’m talking about browser mobile web apps. Hybrid apps, like Ionic with Cordova, run uninhibited in the native app environment, with all the features we expect of any native app. But pull out the web content from a hybrid app and load it in a mobile browser, and the app is thusly constrained by the features of the browser (for a variety of good security and API standardization reasons).

Progressive Web Apps bring features we expect from native apps to the mobile browser experience in a way that uses standards-based technologies and run in a secure container accessible to anyone on the web.

On the whole, Progressive Web Apps describe a collection of technologies, design concepts, and Web APIs that work in tandem to provide an app-like experience on the mobile web. Let’s walk through some of the core tenets of Progressive Web Apps.

Service Workers are an incredibly powerful, and equally as confusing, technology behind a Progressive Web App. They power offline functionality, push notifications, background content updating, content caching, and a whole lot more.

At a high level, a Service Worker is a worker script that works behind the scenes, independent of your app, and runs in response to events like network requests, push notifications, connectivity changes, and more.

I’ve heard Service Workers described as a “proxy,” which I think describes them nicely. We can listen for events like fetch that happen any time a network request occurs. We can handle that event with full control, checking for cached data and returning immediately, or allowing the request to continue to the remote server. Our script acts as a proxy, or middleware, for the request.

The sheer power and flexibility of Service Workers makes them very complicated, and generally, developers will want to use pre-made “recipes” for common service worker use cases, such as offline mode. Mozilla has a great reference for service worker recipes that demonstrate the myriad applications with reusable code. For example, here’s how to do a simple offline mode that intercepts fetch events and returns data from a cache if the network request fails. Google also has a slew ofService Worker Samples.

Main takeaway: Service Workers are just a JavaScript file like any other, running in the background and triggered via events, and it’s up to you to write code to handle caching, push notifications, content fetching, etc. Since developers end up using the same “recipes” to do common tasks (like offline support), we will most likely want to use existing recipes to make our lives easier. Service Workers are available on Android with Chrome 50 and not currently supported by other major mobile browsers.

The App Shell model is a simple design concept whereby the initial load of a mobile web app provides a basic shell of a app UI, and the content for the app is loaded after. App Shell isn’t a Web API or a framework, but rather a design approach that developers can choose to adhere to that is enhanced by the caching abilities of service workers. You might find that it’s a pretty straightforward, obvious approach, made more dramatic by a buzzword.

With the App Shell model, we focus on keeping the shell of our app UI and the content inside of it separate, and we cache them separately. Ideally, our App Shell is cached such that it loads as quickly as possible when a user visits and returns at a later date. Having the shell and the content load separately theoretically improves the user’s perception of the performance and usability of the app.

Putting this in the context of Ionic, we can load our Ionic app layout immediately (tabs, navigation controller, side menu, etc.), cache it through a service worker, and then fetch and update the content through JS after the app shell has loaded.

As we start to add more PWA support to Ionic, you can expect an App Shell approach to come out-of-the-box for all Ionic apps that are deployed as mobile web apps, with pre-made Service Worker recipes for caching, offline support, and background content refreshing.

Historically, mobile web apps were not installed like an app to the homescreen. Sure, a user could “pin” a mobile website to their homescreen on iOS and Android, but the experience was second-rate, and the app still did not come with the local features we expect out of native apps (plus, does anyone actually do that?).

This is changing. Recently, Chrome on Android added support forinstalling web apps to the homescreen with a native install banner, just like the native app banners we’re used to.

To tell Chrome our mobile website is installable as an app, we write amanifest.json file and link to it from our main HTML page (see the second link above for a full example).

Currently, iOS doesn’t have any additional features here beyond Pin to Homescreen, so the experience won’t be as fluid, but here’s hoping Apple gives us some goodies this year .

Progressive Web Apps are equal parts new Web APIs, design patterns, and marketing fluff. The mobile web comes closer to parity with installable app store apps through app manifest and homescreen install support, background worker functionality with Service Workers, faster load time with App Shell, and a renewed belief that web developers, too, can build amazing mobile app experiences.

At Ionic, we believe the web is the future of apps: It runs everywhere, it’s the most widely known technology stack, and it powers a rapidly increasing number of apps. Today, web technologies are used by millions of app store apps, but so far, the mobile web has been a stripped-down experience driving people to the app store for the Real Thing. Progressive Web Apps change that.

In the coming months, we will be releasing new features for Ionic apps that enable developers to get the best of both worlds: cross-platform app store deployment on iOS, Android, and Windows, along with deployment to the mobile web as a Progressive Web App with the same code. Soon, Ionic developers will be able to benefit both from native app store distribution, and immediate access to the billions of mobile web and Google search users. No more clunky app store interstitials, and no more building separate native and mobile web apps. Stay tuned! 

article source: http://blog.ionic.io/what-is-a-progressive-web-app/