This commit is contained in:
@@ -21,6 +21,34 @@ Ensure all modern best practice security is properly enabled on helloayanova.com
|
||||
CODING WORK
|
||||
+++++++++++
|
||||
|
||||
DEVELOPMENT SCHEDULE
|
||||
--------------------
|
||||
WEEK OF 2018-10-22 - Learn Vue, select a UI framework
|
||||
|
||||
- Make a basic PWA app code against RAVEN server a throwaway initial stab at RAVEN for learning what is needed to learn
|
||||
- Document areas needed to focus on for learning and then do them
|
||||
- Try the various UI frameworks / stylers and get a feel before making a selection
|
||||
- Examine on phone, ipad, all desktop browsers, low bandwidth test, no bandwidth test
|
||||
|
||||
|
||||
WEEK OF 2018-10-29 TO NOV 12th - RAVEN shell start work.
|
||||
- Plan out the shell basic requirements
|
||||
- Make a widget view/list/enter/edit
|
||||
- Login, logout, notification, localized text, status
|
||||
- Graph / Readonly UI component
|
||||
- Widget: List, search, edit, localized WIDGET UI components
|
||||
- At the end of the two weeks re-assess and see what needs to be the focus going forward and if anything is amiss
|
||||
- Plan out the next phase
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
IMMEDIATE ITEMS:
|
||||
================
|
||||
|
||||
@@ -59,6 +59,24 @@ and VUEX allows that easily, plus it's fairly straightforward to use.
|
||||
Here is an example of how to structure a non trivial application with VUEX broken into modules:
|
||||
https://vuex.vuejs.org/guide/structure.html
|
||||
|
||||
SERVICEWORKER = WORKBOX
|
||||
=-=-=-=-=-=-=-=-=-=-=-=
|
||||
For offsite PWA use, works well and is simple to implement
|
||||
https://developers.google.com/web/tools/workbox/guides/advanced-recipes
|
||||
|
||||
|
||||
- Serviceworker push notifications
|
||||
- INITIAL THINKING: avoid it for now until the dust settles, rely on email notification or other established means for now and in app popups perhaps as well
|
||||
- This is also part of service workers api but is radically different than above as it's to do with integrating device notifications with web servers.
|
||||
- requires permission, works with browser closed, messages go from server to intermediary such as google or microsoft or apple who then push it to the device.
|
||||
- User can block and say no and then app can never after that re-request push notifications (as far as I can tell, maybe there's a workaround but not sure)
|
||||
- It's main advantage is browser can be closed but still receive timely messages (i.e. new mail in rockfish would be an ideal use-case)
|
||||
- Alternatives would be user must stay in web page to get notified via polling like how rockfish works now for mail.
|
||||
- If I enable notifications via email then it kind of roundabout covers this use-case
|
||||
- as of now 2018-10-22 15:23:49 iOS Safari (mobile apple devices browser) does not support push notifications, only dekstop Macs and you need to jump through many hoops to get approval
|
||||
- This means basically that it would be a pain in the ass for apple devices but easier for others. Hmmm...
|
||||
- SERVER SIDE: https://www.tpeczek.com/2017/12/push-notifications-and-aspnet-core-part.html
|
||||
|
||||
|
||||
PWA VERIFICATION TOOL = https://developers.google.com/web/tools/lighthouse/
|
||||
"You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more."
|
||||
|
||||
Reference in New Issue
Block a user