Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create the iOS version of the status screen #812

Merged
merged 6 commits into from
Feb 23, 2022

Conversation

shankari
Copy link
Contributor

  • Replace placeholders with appropriate text
  • Add scope.setupIOSLocChecks and scope.setupIOSFitnessChecks
  • For notifications, we re-use the android settings
  • For background restrictions, we disable them since they don't exist (or at
    least, are not user controllable) on iOS

- Replace placeholders with appropriate text
- Add `scope.setupIOSLocChecks` and `scope.setupIOSFitnessChecks`
- For notifications, we re-use the android settings
- For background restrictions, we disable them since they don't exist (or at
  least, are not user controllable) on iOS
@shankari
Copy link
Contributor Author

Screen top Screen bottom
Simulator Screen Shot - iPhone 13 - 2022-02-10 at 15 56 04 Simulator Screen Shot - iPhone 13 - 2022-02-10 at 15 56 11

shankari added a commit to shankari/e-mission-data-collection that referenced this pull request Feb 11, 2022
- End-to-end implementation of the "check" parts of the interface
- Code structure similar to the existing android code for simplicity
- checks defined in `TripDiarySensorControlChecks`
- interface with the plugin in `SensorControlForegroundDelegate`
- interface with the background code to generate error notifications in `SensorControlBackgroundChecker`

Testing done:
With the UI changes in:
e-mission/e-mission-phone@d69f3a5
the plugin -> foreground delegate -> checks pipeline works

e-mission/e-mission-phone#812 (comment)

TO DO:
- Background checks need to be tested
- Implement the "fix" methods in addition to the "check" methods
@shankari
Copy link
Contributor Author

shankari commented Feb 23, 2022

on testing, the iOS version of the dashboard is missing the footprint. It works on android. The issue seems to be that the date range is 3 lines - it is 2 lines on android and works fine there.

It also used to work on iOS through the UI update but it doesn't today. When I launched the production app, I briefly saw a correctly formatted dashboard, which was then displayed incorrectly.

Android iOS iOS with dates commented out
Screenshot_1645574268 Simulator Screen Shot - iPhone 8 - 2022-02-22 at 15 55 46 simulator_screenshot_3CB18488-973F-40ED-BA1C-74022471CEF4

@shankari
Copy link
Contributor Author

Digging a little deeper:

  • on android, the width is 206px for the date range and 120px for the "change dates" button
  • on iOS, the width is 195 for the ng-if div and 105 px for the metric-second-half div, it is 195px for the change dates parent and 120px for the actual button

Why is there such a large margin?

<div ng-if="uictrl.showSummary" style="width:50%; float:right; padding-top: 10px;" class="">
      <div class="metric-second-half">
      <div class="ng-binding"> Feb 16, 2022 ➡️  Feb 23, 2022 </div>
      </div>
    </div>

Ah it is because the metrics-second-half class has a width of 105px

/*Change later*/
.metric-second-half {
  width: 105px;
  margin: auto;
}

Apparently that hardcoded width is large enough on android but not on iOS?

@shankari
Copy link
Contributor Author

Setting an explicit % width (90%) for the range seems to fix it, but let's see why we had a hardcoded value to begin with.

      <div class="metric-second-half">
      <div> {{ selectCtrl.fromDateTimestamp.format('ll') }} ➡️  {{ selectCtrl.toDateTimestamp.format('ll') }} </div>
      </div>
    </div>
    <div ng-if="uictrl.showChart" style="width:50%;float:right; padding-top: 10px">
      <div class="metric-second-half">

Ok, let's go ahead and change it.

@shankari
Copy link
Contributor Author

Changing it to 90% fixed it on iOS without breaking on android.

iOS Android
Simulator Screen Shot - iPhone 12 Pro - 2022-02-22 at 21 30 01 Screenshot_1645594188

If they are too narrow, they cause the actual footprint to be hidden.
There is no known reason why they are an absolute, instead of a relative value.
They are only used in this one place, so changing them should not break anything else.
So we just change them back to a relative value

More details:
e-mission#812 (comment)
e-mission#812 (comment)
e-mission#812 (comment)
e-mission#812 (comment)
@shankari
Copy link
Contributor Author

Making some final wording changes since we don't have any fallbacks.

For my future reference, if not for others :)
This allows the Spanish and French groups to incorporate the changes as well
+ Modify some of the text at the same time to make it more clear
For example, after opening the app settings page to change settings and then
coming back to the app.
- Bump up overall app version
- Also bump up versions for the following plugins:
    - data collection: bulk of the changes, bump up a full minor version
    - server sync: move the fitness permission init code into the new permissions module
    - unified logger: add a new method to generate plugin compatible
      notifications so we can tell the user when their status is bad and automatically open the page to fix it.
    - usercache: includes code that calls the local notifications, so needed to
      change method signature to match the notification state.

This pretty much concludes e-mission/e-mission-docs#680
@shankari
Copy link
Contributor Author

shankari commented Feb 23, 2022

This finally fixes e-mission/e-mission-docs#680

@shankari shankari merged commit fbb30e9 into e-mission:master Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant