WebView home screen

[trvbr]

Just leaving this here... :)

Major enhancement if you get a chance to add this in a future version. Opens a lot of possibilities.

Main components

• WebView home screen loaded from: http://kzfr.org/api/app/home-screen
• Completely left up to this API and Creek to supply the HTML and JavaScript for this WebView. Hopefully no native code needed to alter or enhance the elements inside the WebView. Creek will have an interface to edit this home screen.
• The app would provide JavaScript that allow home screen links to views in the app. Example: <a href="viewOpen("schedule")>See the schedule</a> Here is the documentation on this: Binding JavaScript code to Android code
• Links to regular URLs will open the browser. This will have limited usage, like a banner for an upcoming event or sponsor. Also, these links will be labeled with an "external link" icon.

  Smoothing it out

For dealing with network delay with loading a remote page, rather than rendering natively:

• Inventive caching?
  • Expiration time included in API
  • Expiration header in response? One hour?
• Graceful animation or background color usage on the page itself?
  • Initial color of background provided in Station API data?
  • Images and elements fade in on load (handled by JavaScript/CSS of page itself, rather than in Android/WebView)
• Page refreshed on:
  • app launch
  • once per day: for when app is left open?
  • when user explicitly requests home screen from side drawer

[trvbr]

Updated this to add the documentation link, and some more explanation.

Thinking about the best strategy for updating the WebView data. That's a bit hazy.

I want to potentially have JavaScript on the page that polls the server for current track and current show data.

But I don't want it sitting in the background asking for data every 10 seconds. But then again, maybe that won't be that bad, since if they are streaming then it will be using data anyway.

Maybe one option is to reload the WebView data when the home screen is visible, and release the WebView when it's not visible. Though that would make for a long delay each time they view the home screen. Ideally the home screen would be loaded once, and then update only when necessary.

One thing I think about -- a Twitter developer told me that their app was wasting the phone batteries because their analytics code was constantly pinging the server. That would make the phone's cell network radio stay on, rather than let it turn off while idle to conserve power. They fixed the problem by making analytics queue up the data until the user was actually using the app. Then it had a good window to send the data, when the radio was already turned on. Just an anecdote -- maybe not useful here.

[trvbr]

In other words, I just want this idea to be as simple to build as possible. :)

No pressure, haha

[px-amaac]

So the ping once every once in a while is a little overkill. You also do not want to keep the webview loaded in the background.we should let the OS take care of doing garbage collection when it needs to. Have the page reload on resume so every time the user rotates the screen or pauses the activity it will reload. This should be sufficient enough I do not imagine users will be looking at the webview on the phone long enough to require an update.

[trvbr]

Yeah, that makes sense! They'll only spend like 8 seconds on the home screen usually anyway. Not much need to update it. I could see them opening the app and leaving the screen on to display the current track or something, but that seems rare.

[px-amaac]

Even if they opened the app and left it on the phone will sleep and screen will go off. when they come back to the phone the webview activity will resume and update.

On Wed, Jul 15, 2015 at 10:30 PM, trvbr notifications@github.com wrote:

Yeah, that makes sense! They'll only spend like 8 seconds on the home screen usually anyway. Not much need to update it. I could see them opening the app and leaving the screen on to display the current track or something, but that seems rare.

— Reply to this email directly or view it on GitHub https://github.com/px-amaac/KZFR/issues/64#issuecomment-121835966.