First beta testing version #804
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Includes all changes until: e-mission/e-mission-docs#680 (comment) These are primarily: - bump up the version number - bump up the SDK to API 30 - bump up android to 10.1.0 - bump up ios to 6.2.0 - bump up versions of all non-OpenPATH plugins required, including switching to new repo hosts if needed. + add barcode scanner + add badge plugin manully (to get the most recent version and support the new android gradle plugin) - bump up versions of gradle and cocoapods - remove temporary workaround to uninstall tools 31 since we have upgraded to android 10
to be consistent with havesource/cordova-plugin-push#83 (comment) This seems to fix the error in e-mission/e-mission-docs#680 (comment)
Instead of the old apk. This is consistent with requirements that all new apps must be built using aab e-mission/e-mission-docs#680 (comment)
It is still auto-installed as part of the local notification package e-mission/e-mission-docs#680 (comment)
…installed And without this, the RUBY_PATH is incorrect, so cocoapods are not found and the build fails.
Closed
3 tasks
This should fix the pending iOS build error e-mission/e-mission-docs#680 (comment)
Check in the initial version of the long-awaited status screen.
- Create a new directive for status checks
- Move the `sensor_explanation` code out of the intro file
- Change the `sensor_explanation` template to include status checks
In the new directive:
- create sections for location and fitness (so we can design properly)
- create config options for location (settings and permissions) and fitness
(permissions)
- add explanations of why we need the sensors and what the settings need to be
- add status fields for each of the sub-sections and the overall section
- provide options to fix issues and to recompute the status
- display the error if the fix did not work
Testing done:
- turned off the location in the settings
- refreshed, location settings turned red
- fixed, location settings turned green
- turned off the location in the settings
- refreshed, location settings turned red
- tried to fix, but rejected instead of accepted settings
- settings stayed red and displayed an error
|
@kafitz @ericafenyo @jf87 @PatGendre @asiripanich Video showing what the new status screen (29d2d85) looks like
Note that I am still working on it, get the beta testing version set up so that you can try it out when it is ready! |
|
Here's how the location permissions work on android 10, where similar to recent versions of iOS, you need to launch the app settings for users to provide background location permission. location_permission_fix.mp4 |
Will revert this check in the next commit since it is not very relevant right now e-mission/e-mission-docs#680 (comment)
This reverts commit 2b0cf26. Consistent with e-mission/e-mission-docs#680 (comment) We can enable the functionality later using a UI-only change if needed
To be consistent with e-mission/e-mission-docs#680 (comment) Update the README to indicate that we need to install java 11 Update the github workflow to set the JAVA_HOME to java 11 before building
7 tasks
Fairly straightforward change similar to prior changes for location and motion activity. The one "special" difference is that we move the buttons out of the directive and into the top level intro, which is where it makes sense in the long term anyway. We should have separate top level directives for the individual sensors that we use.
This is the complement to e-mission/e-mission-data-collection@61a7b8b It primarily changes the instructions displayed to the user to be consistent with the actual operations they need to do. TODO: Do something more sophisticated than just displaying the error message. Return an error code in addition to the message and use it to look up the UI displayed message.
|
Deny code now works properly, even if the user chooses "don't ask" deny_enable_in_app.mp4 |
- Read state params in addition to the target state - fix foreground check - handle notifications on both android and iOS
…orrect - Define an "overallstatus" variable - pass it in from the permission check directive - change the directive to accept it - add a new `recomputeOverallStatus` method that is called from each of the recompute methods - add a disabled flag to the "I agree" based on the overallStatus Since there is a bi-directional binding between the parent scope and the directive scope, changing the directive scope updates the parent and enables the "I agree" button.
agree_disable_enable.mp4 |
- Declare the app status modal - write functions to show and hide it - hook up the show to the profile UI - hook up the hide to a successful fix of the permissions The status modal is very similar to the intro screen, down to the shared `overallstatus` scope and the enable/disable based on it
…ings screen
- define the `launchAppStatusModal` as a param object so we won't expect it in the URL
- check for the `launchAppStatusModal` both on load and on enter and launch the modal
- ensure that we reload the page if we are already on it so the load check gets invoked.
Testing done:
- click on notification while currently on profile screen
- popup on whether we want to handle it
- saying "yes" opens the screen
- click on notification while currently on label screen
- popup on whether we want to handle it
- saying "yes" goes to the profile screen and opens it
- close app and then click notification
- goes to `inf_scroll` and stops **NEED TO INVESTIGATE**
- background app and then click notification
- goes to profile screen and opens it
This is primarily in the newly created `remotenotify.js` which listens to push notification events emitted by the plugin interface and handles two new types of push notifications: - popup: which displays a short text-only popup - website: which displays the specified website in a separate IAB Related server commit is: e-mission/e-mission-server@c52611f Testing done: - Sent popup and website pushes - Ensured that they are displayed on android - Still need to test on iOS, which requires a physical phone
|
Testing done for the new push notifications:
Related server change: e-mission/e-mission-server#840 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Includes all changes until:
e-mission/e-mission-docs#680 (comment)
These are primarily:
new repo hosts if needed.
android gradle plugin)