February 20th , 2016
Is It Right Time to Go for Progressive App DevelopmentMobile App Development | Web Development
Extreme Ends of Mobile ExperiencesToday we have two extreme ends for mobile application experiences. The one end is, the native mobile application itself with all native hardware, features, and functionality. Another end is the mobile friendly website displayed in the browser or a mobile web app functioning the same way as the websites do.
Hybrid SolutionsSome intelligent developers have invented “A hybrid” solution. They have used the modern HTML, CSS, and scripting technologies to create an app and then wrapped the entire bundles of code with native properties into mobile OS systems. Unfortunately, both approaches, i.e., native and hybrid mobile app development end up with the downloadable products on the thin mobile clients. The accumulation of such apps on home screen is confusing users to select frequently that, which should be kept and which should leave for the sake of mitigating mobile constraints like storage, CPU, and screen estate. Moreover, cross-platform hybrid apps are not competent with ever-changing mobile OS versions and technologies to offer exact native-like experiences.
Mobile App Development At Tech Point of ViewAt tech point of view, the updates of mobile apps are hardly possible in real-time and automatic. Moreover, changes are not consented with the needs of users in bespoken ways or for the sake of personalized experiences. Perhaps this the biggest failure of the current technologies to address the actual user experience need in the development and the iteration processes taking place along with the progressive usage. It is not easy to comprehend without a relevant example so let’s think of location-based personal experiences. For instance, you want to deliver location oriented push notifications considering all personalized choice made before by the user. Keeping the cache, history of surfing, activities were done, and all blend with location data is hardly possible with encapsulated web app or natively residing mobile app. In fact, these all demand enough time, interactions, and choices to make. Take as examples, some applications:
- Adobe AIR Applications
- Chrome Packaged Applications
- Firefox OS Packaged Applications
- Windows Store Apps
- Cordova/PhoneGap and Crosswalk Apps
- BlackBerry WebWorks Apps
- WebOS Apps
- W3C Widgets
- And many others in the line
The Birth of Progressive Web Apps & Progressive App Development TechnologiesTherefore, Google engineer Alex Russell in June 2015 has espoused an idea first and coined a term, “The Progressive Web Apps” for comprehension.
It Starts with WebsitesAccording to the concept, the process of the progressive web app formation begins as tabs in the Chrome. A website with a valid URL turns into a mobile app progressively.
Prospective Candidate SitesThe websites, which you chose or allow, sending you the important and useful notifications, can be good candidates for your progressive web apps over the time. Similarly, websites or shopping carts/e-commerce stores, which are residing on the home screen of your mobile devices as your favorites and frequently used sites, have rights to be your progressive web apps with the pace of time.
The Formation of Progressive Web AppSince these websites have all right vitamins, they ask you for your permissions to reside on the home screen, in your taskbar/task switcher, or in your notification tray. These potential websites, which are going to be progressive web apps, ask your permissions on each addition of the new capability and your personal choices/likes/dislikes etc. Thus, your progressively converted websites into web apps are highly personalized, not customized by any developer. It will cost you nothing and saves your frequent visits of the mobile app marketplaces at all. The most beautiful thing with the progressive web app is that it is the combination of (1) The URL and links, which are the core part of the web and for the search engines/bots. (2) The native-like user experiences for the human users. It has markup & styling for maximum accessibility, rich UIs, and system capabilities through the functional core Amazingly, all is available without spending a single penny in mobile marketplaces, and implementation is possible without any permission like license.
Technicality behind the Progressive Web AppIf we look at the recently developed progressive web apps or websites for the purpose, have some distinguish attributes those make them fit for the intended purposes. Those attributes are:
- Responsive web design fit for all screens, large to tiny
- Offline capability achieved through “Service Workers” in a progressive manner
- Native app like experiences and interactions possible through adoption of a Shell as well as Content application model, particularly for apps like navigations and interactions
- Always Updated because of Service Worker processes for continuous updates
- Safe and secure because TLS like service requirements due to Service Worker and preventing application from snooping
- Index-able or searchable on the web thanks to W3C manifests and registration scopes for Service Worker
- With re-engaging properties like Push Notifications and other UIs accessibility
- With installation properties to select users the browser options to keep or let go options when asked for
- Power of URL makes progressive web apps linkable, and social share is the desired characteristic
Manifest Concept in Progressive App DevelopmentIt is JSON file to depict useful Meta Data regarding the app like name and icon, launch and configuration, etc. so it can give more native app-like experiences. Therefore, its coding is crucial. For the detailed properties, you can visit W3C Web App Manifest Draft and realize how it can be powerful when implemented righteously.
Service Workers Concept in Progressive App Development
Why we need service workersUnlike native mobile apps, the HTML documents of a mobile friendly website start loading over the subsequent HTTP requests. Thus, web content is not loading at a time or with a single request and may interrupt when the Internet connectivity is. In order to redress this issue, the Service Worker is designed with Web Worker context, which is starting by a runtime when navigations are about to occur.
Mechanism of Service WorkersIn its mechanism, the events, which are corresponding to the Internet or network requests redirected to the worker and responses generated by the workers that might over-ride default network stack behavior. Thus, Service Workers stay in between the Internet/network and the document renderer/device and supplement the content needed for the documents even the device is offline. However, the same attributes present in the HTML5 Application Cache, but its unrecoverable errors are leading it to the failure. Therefore, services workers are designed such a way that the errors are always recoverable.
Useful Properties of Service WorkersApart from these, Service Workers have many other distinguish properties such as:
- Service Workers always triggered and kept alive by their relationship to events, not by the documents
- Service Workers are generic
- They are event-driven and with the time-limited script contexts, which are running at an origin
- They have natural endpoints for a range of runtime services that may outlive the context of a particular document
- Handling the Push Notifications
- Background data synchronization
- Responding to resource requests from other origins
- Receiving centralized updates to expensive-to-calculate data like geolocation or gyroscope
- Script URL
- Containing service worker registration
- An ID or a UUID
- Lifecycle events
- Script resource map
- Skip waiting for flag
- Imported scripts updated flag