…ission-phone into react_navigation_new_onboarding

Instead of using Ionic's tabbing implementation, we're going to use `BottomNavigation` from RN Paper, included in a central App component.

This App component will have an AppContext, which can include any app-wide variables/functions the tabs need to share, including the loaded dynamic config - this way we can just load it once and use it everywhere.

So App.tsx is replacing main.html, as well as the logic that was in MainCtrl.
The metrics tab is only shown in 'MULTILABEL' configurations (same as the implementation was in MainCtrl).

Onboarding hasn't been implemented yet; so there is a placeholder for it right now

By default, the active tab at the bottom of the screen shows in secondaryContainer color, which for us is a light yellow/orange.
For this app, it makes more sense for this to be light blue. primaryContainer is close, but it can be lightened a bit more to match the lightness of secondaryContainer.

Because we use primaryContainer for TimestampBadges, these now sort of blend into the background because they're lighter. A better idea for this is to give an small outline that is 'primary' color.
If we replace the Badge component with a View we can add this outline, and we also don't have to worry about the warnings that we got before with the Badge component.

Also added some comments describing the style, color/height overrides for BottomNavigation

to increase reusability of the privacy policy element, we need flexibility of how the component is formatted, achieve this by having the title and scrollview (with all the text) as one component, and the container as another.

Chose to keep buttons with the container -- this allows for custom options between profile and onboarding -- policy is view only and can be "closed" from profile, but must be explicitly accepted or rejected in onboarding

in an attempt to keep the blame, I'm renaming and moving this to then cut it down to just the controls, and will re-establish the modal to hold the controls elsewhere

to increase flexibility, we need to separate the permissions modal from it's contents. SettingsScope is also no longer a needed argument

we need to show the appStatusModal whenever the overallStatus is false

now that the controls are split from the modal, we need to have central access to the overallStatus

usePermissionStatus controls all the permissions from a central location. overallStatus can be easily extracted to show the modal in AppStatusModal

in PermissionsControls, we now extract the checkList, overallStatus, etc from usePermissionStatus in order to control the UI

in updateCheck, we should also update the statusIcon and statusColor as we replace the check in the list, this way the indicators stay in sync with the status

this eliminates a lag I was observing between the checks updating and the icons showing, as well as prevents infinite looping observed when replacing the checks to update UI when checkList changes

no longer need a scope to listen for updates, as we are using usePermissionStatus to show the modal, and updating based on useAppStateChange

… into react_navigation_new_onboarding

Additional changes needed to resolve merge conflicts and restore functionality.

This file is replacing the angular service DynamicConfig - several of the functions have been rewritten, preserving the same function while modernizing the code.

The only notable differences with the new version are that there are no longer any `saveAndNotifyConfigChanged` or `saveAndNotifyConfigReady` functions, and routing is not handled here.
These were things that relied heavily on Angular. This is no longer an Angular module - and this file should strive to be fairly agnostic of the framework.

So the routing, and the handling of what to do when the config has updated, will be handled in the components that _use_ dynamicConfig's functions by checking the result of the returned promises.

This sketch of the new Join page is fairly rudimentary, but it includes the same text as the old one, and a text popup to enter an OPcode.
It uses `initByUser` from the *new* dynamicConfig.ts file, not the old dynamic_config.js file.
Qr scanning has not been implemented yet

We will derive onboarding state from the result of StartPrefs.getPendingOnboardingState - if it is null (no pending state) then we can route to the rest of the application.
If there is a string value, it specifies which screen should be shown in the OnboardingStack.

Currently, only JoinPage is implemented in OnboardingStack

Because Unix systems are case-insensitive to filenames, and Typescript is insensitive to file extensions when dealing with imports, we had a conflict between app.js and App.tsx.
This was causing autoreload to not work for the App.tsx component.

I'm going to rename the old app.js file, which is the Angular entry point, to ngApp.js. Soon, we will not need it anyway!

This will replace getPendingOnboardingState from the StartPrefs service.
The new implementation will be typed according to the OnboardingState type and congruent with what OnboardingStack expects.

We don't have any Angular UI elements to be displayed anymore, but we still need Angular for the services.

So we'll keep the initialization logic that is happening in ngApp.js, but remove <ion-nav-bar> and <ion-nav-view> from index.html.
Instead we will have an #appRoot element, and at the end of the Angular init logic in ngApp, we'll inject the App.tsx component into this #appRoot.

At this point, we shouldn't need to angularize / embed React views into Angular views, because there _are_ no Angular views anymore!

This is called on logout and if the user declines consent. It cleared the stored config, but it didn't clear consent.
It should clear everything, so let's implement a new version on the rewritten version of dynamicConfig, which uses clearAll instead of clearing just the config.

This is a temporary ConsentPage with just 2 buttons: accept/decline.
On accept we execute the logic that was in intro.js - it calls `login` and attempts to register the user via CommHelper.
On decline, we clear data and force refresh

rewrites from server_conn - the function in serverConn for setServerConnSettings does the same as `init` from server_conn did, and will be called from App.tsx any time the dynamic config changes

Because the entire App component is now injected into a SafeAreaView in ngApp.js, we no longer need these offsets

Instead of including the AppStatusModal individually on the tabs, we can include in in the entire App component and have it appear any time permissions are incorrect.

However, it should only show if the user already consented

was mistakenly exporting this component as PrivacyPolicyModal (the wrapped component used in ProfileSettings)

add PrivacyPolicy for users to accept

needed flex:1 on the page style to enable scrolling

previously, the summary (in a list of three lines) was presented after entering an opcode and before showing the longer privacy policy for consent

To simplify slightly, we add the summary to PrivacyPolicy

Also moved scroll from PrivacyPolicy to it's containers to keep the consent button at the bottom of the scroll -- users have to at least scroll past what they're agreeing to

previously named JoinPage

'getConfig' in dynamicConfig.ts is a replacement for the old DynamicConfig.configReady. Once loaded, the config is cached in dynamicConfig.ts as storedConfig, so it doesn't have to be retrieved every time.

The useAppConfig is now aware of config changes and will update accordingly - it does so by watching the `configChanged` variable which is exported from dynamicConfig.ts.

So anything in React will use the useAppConfig hook. Anything not in React (the remaining Angular services) will need to call `getConfig` directly from dynamicConfig.ts.
Eventually, when we have no Angular code, we should be able to just keep the config in the App context, and use it downstream anywhere we'd like

- 'loading' has been removed from useAppConfig - instead, the loading state of the config will just be represented by it being null. This way we do not have to watch 2 variables to determine if the config has been loaded

This function in enketoHelper replaces `loadPriorDemographicSurvey` from EnketoDemographicsService.
It is only used for demographics survey, but I rewrote it more generically to accept any datakey as a parameter.

instead of using the old Angular service, EnketoSurveyLaunch, to edit a demographic survey reponse, we can utilize the EnketoModal React component. We just have to make sure we retrieve the previous response and store it as state before we make the EnketoModal visible

This page will show if the user has consented, but intro has not been marked as done yet.
It will look for a previous response for the user. If it finds one, it will ask them whether they wish to edit it or skip.
If it doesn't find one, it will open the demographics survey to be completed.

if the permissions are broken, the app won't work, so we should force the users to enable them before they can move on. We'll trap users in the modal until they resolve all the permissions bu making it only dismissable iff overall status is true.

the state for platform and osver was not updating in time to set up the checklist.

Rather than rely on state, we can get the information directly from window. We know it will exist because setup is not called until window[device] exists

see discussion:e-mission/e-mission-docs#956 (comment)

Since we have an AppStatusModal, and we have an AppContext to share variables throughout the component tree, we don't need a separate AppStatusModal in ProfileSettings. The "App Status" action can just control the state of the AppStatusModal in the App component.

We also now don't need the extra code about `window.appStatusModalOpened`. This was to prevent two modals from being open at the same time, but since we only include the modal in one place now, we don't have to keep track of this.

The SaveQrPage, where we prompt users to save their OpCode by downloading the QR image, needs to show after the user consents but before the demographics survey
This required adding another option for the onboardingState and a flag to signify whether the SaveQrPage is marked done or not.
The SaveQrPage component itself currently just has some sample content - later we will actually show the QR code with an option to save it

Instead of the login function being called when the user consents on ConsentPage, we should login only once the permissions are sorted and we are on the SaveQrPage.
This prevents the possibility of so-called 'ghost users' who downloaded the app, consented, but quit before giving permissions. We'd prefer to not have a buildup of these empty opcodes registered on the server.

To do this we have a new flag in onboardingHelper, 'registerUserDone', and we listen in SaveQrPage for appStatus to be true. If it is, and we haven't already registerUserDone, we call the login function to register.

When usePermissionStatus is first invoked, checkList is an empty array. Later on it is populated with the necessary checks. But initially there are no checks.
In this case, overallStatus would mistakenly be true on the initial load.

But if there are no checks, this should return false.

We're going to use this function for the onboarding flow. And besides, we don't need it cluttering up ProfileSettings anyway. Probably best to extract it to a general location, and work with any input message.

This builds out the SaveQrPage so it actually displays the qr code, with all the text from the old version, and buttons to save/share the qr code and to continue

- "rest" / "rest.style" was added to the QrCode component so that it can be styled

We present a pair of buttons: it's often best to give one contained and the other outlined.
In this case, the 'recommended' action is to save/share the QR code, so we put this one in a 'contained' style.

On SurveyPage, we look for existing surveys for the user. If any exist, we take the most recent one and ask the user if they wish to edit it.
This commit fills in all the text explaining this, unifies the button styles with the previous page, adds icons to the buttons, and adds a text field showing the date of the previous response to be edited.

-Several common styles moved to OnbaordingStack as onboardingStyles, instead of being duplicated on each page
-ConsentPage now uses contained / outlined buttons, matching the other pages
-Content of SurveyPage is now centered, not cramped towards the top of the screen

On the other pages, we have the button/action that takes us forward in the flow placed on the right side, and noted with a 'right chevron', so it's a bit weird to see "Accept" on the left here.
(side note- to my understanding the ordering of action buttons in UXD is something that can often go either way, and sometimes different platforms have different recommendations, so for our purposes I suggest we just try to stay consistent within the app and demonstrate the purpose of buttons as clearly as we can through text and style)
I think since "Accept" is colored ('contained') style, it is already conveyed as the preferred or 'recommended' action - so including it second does not diminish its presence compared to "Refuse"

To avoid the JoinPage potentially being confused with the study "join page" on the NREL website, this is being renamed to WelcomePage.
The onboarding state values are also renamed accordingly.

This way we can unambiguously refer to the "join page" as the web page, and this "welcome page" as the in-app landing page.

Based on the wireframe posted in this issue, e-mission/e-mission-docs#956 (comment), the Welcome page has been styled and touched up to be more inviting and comprehendable.
Text has also been made more user-friendly.

The change in webpack.config.js is necessary to be able to load the app icon as an image.
Since the icon.png is in 'resource' directory, not in the 'www' directory, webpack did not know to treat it as an asset. By adding 'resources' to the 'include' paths, the image gets bundled correctly and can be imported in WelcomePage.tsx

- center the 'make sure to save your opcode' text and the 'cannot retrieve' text
- prevent the opcode from overflowing by giving a max width, and allowing it to break lines at any point, not just at spaces/hyphens
- some padding around the opcode

Noticed while testing on a device with a smaller screen that these buttons can start to leak off the page if the text is too long and the screen isn't big enough.
We should allow these to wrap if necessary. If they show on one line, they will appear centered because margin: auto. If they show on separate lines, they will be left-aligned with each other, but still horizontally centered against other content because margin: auto.

…ission/e-mission-phone into react_navigation_new_onboarding

adapted the old Scan code, with the cordova plugin, to work with the React join screen -- needs some more error handling

tested with devapp on test phone, successfully scanned code

…JGreenlee/e-mission-phone into react_navigation_new_onboarding

using the cordova plugin to scan the qr code, then format the result to the loginWithToken -- needs error handling

works in the devapp on my test phone!

Once we're on the SaveQrPage (ie successfully past the ConsentPage) and permissions are sorted out, we can register the user- and immediately after that we should start preloading the previous demographics response. Since this takes some time, we don't want to wait until we're on the SurveyPage to start loading it.

We'll store a value called `preloadedResponsePromise` at the root level of SurveyPage.tsx, along with a function called preloadDemoSurveyResponse. preloadDemoSurveyResponse will be called on SaveQrPage after user registry, so that promise is already initiated by the time we need it on SurveyPage.

If for some reason it was not already initiated on SaveQrPage (like we opened the app straight to SurveyPage) it will be initiated on SurveyPage.
But either way it's only initiated once, and log statements confirm this.

-added clarifying comments

…JGreenlee/e-mission-phone into react_navigation_new_onboarding

Adds an optional 'undismissable' option to EnketoModal. If this is true, then the "Dismiss" button is hidden and the user must complete the survey to close the modal.

This is the desired behavior for initial responses to the demographics survey -- taking the survey is mandatory on the first time installing the app, but updating the response on subsequent installs is mandatory.
So, the value of `undismissable` depends on whether prevSurveyResponse is truthy or not.

intro.js has been completely replaced by the new onboarding flow. The states 'root.intro' and 'root.reconsent' do not exist anymore.
intro.js can be removed altogether, removed as a dependency from ngApp, and functions in startprefs.js that handled the routing logic of the old intro can be removed

Note that while ionic.app.scss is not used and can be removed, we must still keep './manual_lib/ionic/css/ionic.css' in index.js for now.
In particular, there are a few things that still use the old Logger service, which uses ionicPopup to show errors, and this needs the ionic CSS to show correctly.

This is replaced by AppStatusModal and usePermissionStatus

Since everything is being rendered as React Native Web now, we no longer use raw HTML anywhere. We can remove all templates!

The emission.main.control module is removed from main.js. A couple module dependencies had to be put here since they won't be included by extension of emission.main.control anymore, and they aren't already included elsewhere in the app

These services are replaced by dynamicConfig.ts and serverConn.ts. We track down all the places the old services were used and substitute in their equivalents.

So everywhere we used to call configReady() from the old DynamicConfig, we'll instead call getConfig() from the new dynamicConfig.ts.

We haven't used FontAwesome for a while; we're just using Material Design Icons now

We removed Bower a while ago; all packages are managed by npm now

Safe to remove as it has been fully replaced by useImperialConfig.ts. emission.config.imperial was not included anywhere

Nothing needs to be angularized to be embedded in an Angular view anymore, because we no longer have any Angular views to embed into.
So any uses of angularize are unnecessary now, and instead of defining propTypes we're going to be typing our components with TypeScript.

Since being converted to Typescript, the Typescript linter picks up on a few things

In LeafletView
- 'accessibilityRole' is deprecated; just use 'role'
- We don't have a type definition for Leaflet maps so we'll use Set<any>

In QrCode
- For the QRCode style, force type as any. Typescript doesn't believe us that we can style the QRCode component. We definitely can, as changing the style affects the UI, so there must be an error in the typings of the underlying component.
- Use the object['property'] way of accessing properties instead of object.property in situations where we don't have typing for the object

This module has already been removed

These components don't need to be injected into the angular view anymore, so they don't need to be added as module dependencies

StateProvider is not needed anymore because we handle routing in React, between the App component and the OnboardingStack component

JoinCtrl is not needed because the new onboarding flow has re-implemented all this functionality

The EnketoSurveyLaunch and EnketoSurvey services have been replaced.

The EnketoModal component (EnketoModal.tsx) and the enketoHelper.ts file handle all the survey responsibilities that EnketoSurveyLaunch and EnketoSurvey previously handled

enketo-preview.js is not used anymore, nor is survey/external

We were running into an issue where the AppStatusModal showed in situations where it shouldn't. This is because if there are no checks loaded yet, overallStatus is false- so if AppStatusModal is initiated before the checks are ready, it will see that overallStatus is false and trigger the pop up.

We will add extra criteria: for the popup to show, overallStatus must be false AND there must be at least one check in checkList

I realized I used the wrong function from the BEMUserCache plugin; there is no such thing as getRWDocument; the function is just called getDocument.
Also, when we get a config doc from native storage, we should not just make sure it's truthy but we should also ensure that it is not empty. So it must have >0 keys.

Lastly, when a config is not found from KVStore nor user cache, this does fall in the realm of unexpected behavior (like upon the user logging out). We don't need to popup an error to the user. instead let's just log a warning to the console

restoring error messages to scanCode, using the "displayError" method from logger, as used by other parts of login in "initUser"

Tested in the devapp, code scans and logs in properly, and if I scan a random qr code it throws an error popup

Despite being an image, this file used to be inside the /templates folder, which was deleted in e-mission@c5fbad4.
The image is used by EnketoModal, so we need to add it back - this time, it will be located in /img.

in trialing in the devapp, I was getting errors when I tried the popOpCode modal - I resolved by adding the same style prop present in the SaveQR page where

Since 5e7a50c, we have React versions of ControlCollectionHelper and ControlSyncHelper that we include right here in e-mission-phone. So we no longer need any extra scripts to download these from other repos, and we do not need to include them in index.js anymore.

We had combined the study summary and privacy policy into one component. We're splitting them back up.
They will both be located in js/onboarding.

StudySummary is now its own component separate from PrivacyPolicy. It uses the text that was previously in the first section of PrivacyPolicy. And PrivacyPolicy is now just what used to be the second section.
These components share the function getTemplateText - the function is located in StudySummary, since the summary comes first, and imported in PrivacyPolicy to be used there too.

getTemplateText was also defined on ConsentPage, but it doesn't need to be there as it's not handled there.

We split off the summary to be separate from the privacy policy, so the summary will now show on a separate page preceding the privacy/consent page.
We will use a boolean flag in onboardingHelper, summaryDone, which is false initially, so after welcome is done, `getPendingOnboardingState` returns 'summary'.
Once the "Proceed" button is clicked on the SummaryPage, summaryDone is true and `getPendingOnboardingState` will return 'consent'.

- have "Proceed" button show at the bottom by having the page take the full height and marginTop: auto on the button row
-adjust spacing between text by grouping summary lines together and adding gap of 16 pixels on the SummaryPage Surface
-make "Proceed" button 'contained', not 'outlined'

…ission/e-mission-phone into react_navigation_new_onboarding

While merging this, I resolved some conflicts. On the current branch, usePermissionStatus was split off from AppStatusModal.
But changes were made to AppStatusModal on the incoming branch. I had to carefully re-apply those changes to usePermissionStatus and AppStatusModal.

The important consideration here is that we allow overallStatus to be undefined when any permissions status has not yet been determined.
So in AppStatusModal, we explicitly check that `overallStatus === false` before showing the modal, rather than just checking that `!overallStatus`.

Since e25a4ff, 'osver' and 'platform' are not used anymore. We switched to accessing these directly from `window['device']` as `window['device'].version` and `window['device'].platform`.