Should a PWA be a SPA too? - progressive-web-apps

I was wondering that because my app does have an initial journey that is totally diferente from the behaviour of the app.
I would like to separate this initial journey into a different "HTML" due data transfer and load time. Even not using the same framework (Angular2) as the rest of the app.
But this way the app is not a SPA anymore.
Does this harms the "Connectivity independent" or "App-like" PWA principles?
Obs. We are trying this because our researches shows direct relation between user engagement and speed of the loading time of initial tour.

Following the single-page app pattern for your web app means that you'll have a smooth transition to handling navigations cache-first in your progressive web app, using an App Shell approach.
Following the App Shell pattern isn't the only way to build a progressive web app, but if you take a different approach, you'll need to put more thought into how you cache your HTML, and you might have a harder time using a service worker to respond to navigation in a cache-first manner. Some of these considerations are outlined in this "High-performance service worker loading" article.
If your web app is currently a hybrid of a SPA along with a few static pages, then you can take that into account when you respond to navigation requests in your service worker by examining the incoming URL. Assuming there's a well-known prefix or other way of identifying whether a given URL corresponds to the SPA portion of your web app or the basic HTML portion, you can respond differently inside your fetch handler:
// Not shown: install and activate handlers to keep app-shell.html
// cached and up to date.
self.addEventListener('fetch', event => {
if (event.request.mode === 'navigate' && event.request.url.includes('/spa'))
event.respondWith(caches.match('app-shell.html'));
return;
}
// Either do nothing, and your non-/spa URLs will go against the network,
// or use a runtime caching strategy to handle your non-/spa URLs.
});
Updated on 2018-06-21: For an additional perspective, you can read "Beyond SPAs: alternative architectures for your PWA"

The short answer is PWA need not be SPA.
If we look at the documentation website of Web Firm Framework you can see it is not an SPA but it is a PWA. If we refresh the page while offline it works. We can also do "Add to home screen" in mobile chrome to add it as an app which brings App-like experience.
So to get an App-like experience your home page and some of its links must be able to be cached.

Related

Django Rest Framework redirection after POST success

Is there a way to redirect a form POST to a specific page if the endpoint return a success ?
In my specific case, I'm using django-rest-auth to manage the users authentication, and the login endpoint (/rest-auth/login/) return a JSON with the response. I want to redirect the user to his dashboard if the authentication is successfull.
EDIT : As far as I understand, the REST api is only for backend. If I want to set a redirection after any form post, I have to find a way only with my frontend application. Am I right ?
In this case, is Django a good choice to develop the frontend application ?
I've seen many subjects where AngularJS is mentionned to build the frontend. Is it a good idea to build a client app with JS (I mean, for a one page web api, there is no back and next navigation possibility, I think this is not a friendly way to navigate) ?
If I build my frontend with Django, do I have to write my own view, call the backend rest endpoint in this view, process the result, and send an HTTPRequest (for exemple) from this view ? I don't really understand where is the gain with this method.
Well, answer to your question couldn't be only one solution.
You have two ways:
use full RESTful app, using Django Rest Framework and Single
page application
create your own auth views, where you decide
where to go after logging in
Everything depends on your needs.
If I want to set a redirection after any form post, I have to find a way only with my frontend application. Am I right ?
Yes, you need to do the redirection on the front-end.
In this case, is Django a good choice to develop the frontend application ?
Django is a framework for building web servers, and it has nothing to do with front-end.
I mean, for a one page web api, there is no back and next navigation possibility, I think this is not a friendly way to navigate)
There is. For example, here is the ui-router for angularjs. Here is an example of an actual working page. As you can see, the url changes accordingly, just behaves like traditional server-rendered static html pages.
When the browser sends a request to your server, django calls the corresponding view function to render a view, which is just an html file, and sends it back to the browser. Then the browser renders the page. Beyond this point, django has nothing to do with the html file anymore. It is the browser's job to parse the html, and render it accordingly.
So, to be clear, django is not for front-end. For your web application, you can use angularjs for sure. However, if you don't really want to write a lot of javascript code, I suggest taking a look at Polymer (polymer-project.org, oh my little reputation), which is really easy to use.

How to change Wicket behaviour on Page Expired

We have a wicket application for our main website. Lately we have implemented a mobile version of the site. The mobile version is special in that it is deployed inside a native app wrapper to some mobile devices and not connected to the rest of the page through links because it is not supposed to be normally visible to web users.
The mobile page makes use of ajax and is therefore prone to receive "Page expired" errors for example when we restart the application on the server.
Since that page is not connected to the rest of the application through links I do not want our standard "Page expired" behaviour. Is it possible to override or intercept this behaviour for the pages belonging to the mobile part of the site? For example I could like to be able to configure the pages to simply reload on a "Page expired" error.
Yes,
getApplicationSettings().setPageExpiredErrorPage(YourPage.class)
YourPage.class can then for instance be your HomePage or another Page that depending on it being a request from a mobile device does something else.
If you would like to reload the Page the user was one then it becomes a bit less trivial. Reloading the Page is not possible since you are not on the page anymore. You could have a look at IRequestCycleListener and overriding onException and handle PageExpiredException yourself but it is a dangerous road you travel if you simply reload your Page. Navigating to the home (or other) page seems more logical. I assume you are not restarting your server 100 times per day...

iPhone HTML5 website on homescreen with jQuerymobile offline splash page?

How do I go about loading a splash to the user if they are offline? I want it to show after the initial loading image, I have a page called gone-offline.jsp but how to detect if user is offline on mobileinit?
I'm not using phone-gap
You need to decide what offline means to your business scnenario. This may sounds silly, but it depends on what your app wants to do. For example:
Does your app want to go offline when it is actually offline and can't reach other websites, or does it want be in offline status when it can't access your webservice.
Assuming you want to test that there is no connection to your webservice I would recommend the following:
1) Make an ajax call every x number of minutes to your webservice to check if it is still online
2) make a common method that handles time outs if your application thinks its online and is offline.
3) make it so that when your application is offline, it is trying to get back online in the background by doing a similar step to step 1.
To do ajax with JQuery see: http://api.jquery.com/jQuery.ajax/
Note that if you require cross domain json (you may or may not) then you will need to investigate CORS/JSON-P/XSS with iframes.
it's very simple using javascript.
if(navigator.onLine)
{
//online code here
}else{
//offline code here
}
(done with jQ mobile)

Hosting password protected videos for my iphone app

I am building a paid iphone application which
- shows some premium content videos to the user.
- app loads a page from my webserver in UIWebView
- but the videos are hosted at some other video hosting site.
I realize that, in order for me to be keep this app paid, I need to keep the video links protected/secure (else if the urls are leaked, no one is going to want to pay for it).
I can easily password protect the webpage (pointing to the actual video) and make the user name and password available to the iphone app to access this webpage. But when the user selects the video link, the app will load that url. If user sniffed the packets on the iphone at this time, they could get access to the url and just run it from there directly.
I dont believe mod_sec_download or mod_xsendfile can work in this scenario because the video link is external. Right?
Is Amazon S3 a possible solution?
Would appreciate any insight/solution.
Thanks!
Don't point directly to a video file. That'll make it trivial to steal. instead, point at a proxy script that can check the source of the request and verify that it's coming from a registered purchaser.
With appropriate one-time tokens, tracking of usage, etc... you can keep most people from sucking your site dry. And of course, the best practice is to embed a watermark into the video as it plays, so that even if it gets stolen, you can track it back to the first person to release it.
You might want to take a look at the OWASP Top 10 and in particular, number 8 about failure to restrict URL access. This is effectively your scenario: you have resources which need to be secured at the server level. You can't just do this from the device end, the location of resources requested by the device is easily discoverable.
So it comes down to access controls on the resources, in this case, your videos. How you do this will depend in part on your server stack. For example, IIS7 has an integrated pipeline which can apply access controls to resources of any type such as PDFs, images and videos (more on this in OWASP Top 10 for .NET developers part 8: Failure to Restrict URL Access). Alternatively, you'll need some form of application proxy which can take responsibility for the authentication then delivery of the video content.
This is really more of a webserver issue than an iPhone issue. Focus on getting the access controls right on the server then the iPhone end will be a much more straight forward process.

How do I get the Twitter API to respect the callback parameter with OAuth?

I'm working on an iPhone app that ideally uses OAuth to communicate with Twitter. I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The problem is, Twitter has this whole scheme for working with desktop apps, using a pin number. When I register my app with Twitter, they have a web form asking me if I'm a desktop or web client. If I choose desktop client, when I try to have the user authorize, I can set the oauth_callback parameter but Twitter will ignore it after authorization and show a pin number. If, on twitter's form, I specify that I'm a web client, it requires me to enter a URL to redirect to after authorization. And, since I'm using an iPhone app-specific url scheme, their web form fails on validation as it only seems to accepts URLs conforming to the HTTP protocol.
So, it seems like I'm stuck - I can't say "desktop" because I don't want to bother with a pin, and I can't say "web" or I can't use an iPhone app URL. Any solution to this?
From your question:
I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The Pownce article suggests that quitting your application and opening Mobile Safari to perform the authentication step is problematic, and that they started receiving bad reviews from users for doing it that way. They also experienced a failure rate of around 40%.
Pownce's solution is to use a UIWebView within your application instead, so I have a feeling you may have misinterpreted their recommendations. That being said, they do label this as a "naive" solution and go on to suggest a bunch of theoretical "ideal" solutions.
Another point you might not realise is that desktop applications (using the "out of band" / pin number method) and web applications need to open the Twitter site in either an embedded or external browser.
So you've got two choices on the iPhone:
Open up twitter.com in a UIWebView, specifying no oauth_callback parameter or oauth_callback=oob to start the pin-based out-of-band flow. The user then needs to copy the pin using the iPhone's copy-paste functionality, manually close the UIWebView, and paste the pin into your application. The pin can then be used converted to an access token.
Do it how everyone else is doing it (UIWebView + custom-uri://foo.bar in the callback parameter).
For obvious reasons, the first option is pretty crap and really only useful on platforms where Twitter is unable to redirect to a custom URI.
A simple solution may be to create an HTTP page that always sends a 301 redirect to your custom URL scheme and then provide that HTTP URL to the twitter web API.
Aside from that, Nathan's answer is very complete.
Here's how I do it: tell Twitter you're a web app, and make up any old HTTP:// URL to satisfy Twitter during registration of your oauth client.
Then in your app, pass the URL you want to in the callback parameter. Twitter (in my experience) uses the one you give it.
You could use an intermediate website for the authentication. Your app creates a unique id (hardware based?) and stores it. It then records it has sent the user for authentication and sends the unique id to your website. It then redirects the user to your website. Your website then sends the user to Twitter using oAuth. The user returns to your website and you mark the unique id as authenticated and store the authentication information. The user restarts the app on the iPhone, it reads it has sent the user for authentication and contacts your website with the unique id - and reads in the authentication information.
Long winded and needs another website, but it should work.