Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-10-09 Thread Nils Dagsson Moskopp
This seems quite simple to me: Use URLs to convey app state.

Zac Spitzer <zac.spit...@gmail.com> writes:

> But what do end users or developers expect in terms of browser behavior in
> this situation?
>
> The history api (or saving state to indexedDB) aren't going to solve the
> problem of reinitialization everytime the user switches back to a web app.
> Users expect them to behave like a native app.
>
> The early iPads were low powered devices and many app developers used to
> ship content as  images because they couldn't render complex layouts
> quickly, but newer tablets are far more powerful and can handle this.
>
> Chrome handles this as users and developers expect, web apps get paged out
> and require a reload depending on memory etc. Safari does it every single
> time
>
> This is a massive barrier against web apps competing against native apps.
> On 10 Jun 2015 6:21 am, "Domenic Denicola" <d...@domenic.me> wrote:
>
>> I'm pretty sure it's out of scope. That's really asking to specify how
>> OS-level task switching works. I imagine that Safari-wrapper or whatever
>> has decided that when the OS switches back to it it will do a reload, just
>> like when I switch back to my mail app it does a sync, and other stuff like
>> that.
>>
>> > -Original Message-
>> > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac
>> > Spitzer
>> > Sent: Monday, June 8, 2015 21:10
>> > To: wha...@whatwg.org
>> > Subject: [whatwg] Persistent state for homescreen web apps (without
>> > reloading each time)
>> >
>> > Is it within the scope of the spec to specify whether home screen web
>> apps
>> > should retain their loaded state when switching from foreground to
>> > background and back to foreground again?
>> >
>> > Chrome behaves exactly as expected, however, iOS reloads the web app
>> > each time
>> >
>> > http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-
>> > ios-home.html
>> >
>> > --
>> > Zac Spitzer
>> > +61 405 847 168
>>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-10-09 Thread Ryosuke Niwa

> On Jun 9, 2015, at 3:55 PM, Zac Spitzer  wrote:
> 
> But what do end users or developers expect in terms of browser behavior in
> this situation?
> 
> The history api (or saving state to indexedDB) aren't going to solve the
> problem of reinitialization everytime the user switches back to a web app.
> Users expect them to behave like a native app.

That seems like a very platform/product specific issue to me.  I don't think we 
want W3C to be mandating how Web browsers should interact with the rest of the 
system.

> Chrome handles this as users and developers expect, web apps get paged out
> and require a reload depending on memory etc. Safari does it every single
> time

By Chrome, do you mean Android?  Again, this is really about the 
platform-dependent behavior we shouldn't be spec'ing in W3C.

Please file a new bug on our bug tracker at http://radar.apple.com

- R. Niwa

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-06-09 Thread Domenic Denicola
I'm pretty sure it's out of scope. That's really asking to specify how OS-level 
task switching works. I imagine that Safari-wrapper or whatever has decided 
that when the OS switches back to it it will do a reload, just like when I 
switch back to my mail app it does a sync, and other stuff like that.

 -Original Message-
 From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac
 Spitzer
 Sent: Monday, June 8, 2015 21:10
 To: wha...@whatwg.org
 Subject: [whatwg] Persistent state for homescreen web apps (without
 reloading each time)
 
 Is it within the scope of the spec to specify whether home screen web apps
 should retain their loaded state when switching from foreground to
 background and back to foreground again?
 
 Chrome behaves exactly as expected, however, iOS reloads the web app
 each time
 
 http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-
 ios-home.html
 
 --
 Zac Spitzer
 +61 405 847 168


Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-06-09 Thread Glenn Maynard
On Mon, Jun 8, 2015 at 8:10 PM, Zac Spitzer zac.spit...@gmail.com wrote:

 Is it within the scope of the spec to specify whether home screen web apps
 should
 retain their loaded state when switching from foreground to background and
 back to foreground again?

 Chrome behaves exactly as expected, however, iOS reloads the web app each
 time


 http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-ios-home.html


If you want to more reliably store state, for home screen app bookmarks as
well as for regular web pages, take a look at the history API.  That gives
the browser a clear, self-contained block of data to store and restore,
unlike the state of the page itself which isn't always possible to restore
cleanly.  The History API also means that state can be cleanly restored
after browser forward/back, even across session restarts.

I seem to recall this works on iOS for homescreen apps, but it's been a
while since I've tested it.  It'll definitely store the URL (so you can
encode state in the hash, as usual), but you should be able to store data
using the data argument as well, for more complex persisted state.

-- 
Glenn Maynard


Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-06-09 Thread Zac Spitzer
But what do end users or developers expect in terms of browser behavior in
this situation?

The history api (or saving state to indexedDB) aren't going to solve the
problem of reinitialization everytime the user switches back to a web app.
Users expect them to behave like a native app.

The early iPads were low powered devices and many app developers used to
ship content as  images because they couldn't render complex layouts
quickly, but newer tablets are far more powerful and can handle this.

Chrome handles this as users and developers expect, web apps get paged out
and require a reload depending on memory etc. Safari does it every single
time

This is a massive barrier against web apps competing against native apps.
On 10 Jun 2015 6:21 am, Domenic Denicola d...@domenic.me wrote:

 I'm pretty sure it's out of scope. That's really asking to specify how
 OS-level task switching works. I imagine that Safari-wrapper or whatever
 has decided that when the OS switches back to it it will do a reload, just
 like when I switch back to my mail app it does a sync, and other stuff like
 that.

  -Original Message-
  From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac
  Spitzer
  Sent: Monday, June 8, 2015 21:10
  To: wha...@whatwg.org
  Subject: [whatwg] Persistent state for homescreen web apps (without
  reloading each time)
 
  Is it within the scope of the spec to specify whether home screen web
 apps
  should retain their loaded state when switching from foreground to
  background and back to foreground again?
 
  Chrome behaves exactly as expected, however, iOS reloads the web app
  each time
 
  http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-
  ios-home.html
 
  --
  Zac Spitzer
  +61 405 847 168



[whatwg] Persistent state for homescreen web apps (without reloading each time)

2015-06-08 Thread Zac Spitzer
Is it within the scope of the spec to specify whether home screen web apps
should
retain their loaded state when switching from foreground to background and
back to foreground again?

Chrome behaves exactly as expected, however, iOS reloads the web app each
time

http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-ios-home.html

-- 
Zac Spitzer
+61 405 847 168