Merge generic code (primarily stats) from tripaware/ceo_ebike to master

[shankari]

Let's keep track of them here without mucking up the current merge.
e-mission/e-mission-phone@7836019

Make the km vs. miles configurable
e-mission/e-mission-phone@22d38af

Adjust card size (currently cutoff after merge from master)

                <div id="diary-card" ng-class="tripgj.listCardClass" ng-style="{height: '355px'}">

e.g. https://www.geeksforgeeks.org/how-to-dynamically-get-the-content-height-of-a-div-using-angularjs/

[shankari]

I have implemented the first two, but the third one seems much harder to work with.
It is somewhat non-trivial to figure out how to hook into the loading callbacks to figure out the final item height.
But more seriously, it seems pretty challenging to resize list items on the fly even when we actually have the final size.

There are two hardcoded height entries - we set the item-height for the collection-repeat, and we set the height for the cards in the items.

        <div collection-repeat="trip in data.displayTrips" item-height="'160px'">
                <div id="diary-card" onload="fixSize()" ng-class="trip.listCardClass" ng-style="{height: '150px'}">

I can change the card heights using jquery, but without changing the item-height, it just makes the text be invisible.

$(".list-card").css("height","300px")

Before change	After resize

[shankari]

The item height was introduced in e-mission/e-mission-phone@e110f3f#diff-e694b32469d49b6682b8a207844dab1a6950a61c487d58216b109e9a0c1ccc85R34 and like most code by @krisma, has a hardcoded value and no documentation.

We didn't have it before, so I am not even sure the item-height is required.

[shankari]

Removed <item-height>; we have some gap between entries, probably due to the start and end tags.
However, changing the card size still doesn't work.

Before resize	After resize

[shankari]

Looking at this further, this is because the collection-repeat has a transformation appended to it. Without fixing the transformation, the items will just overlap each other.

<div collection-repeat="trip in data.displayTrips" style="transform: translate3d(0px, 3570px, 0px); height: 211px; width: 393px;">
            <div class="start-time-tag-inf-scroll ng-binding">9:20 AM</div>
            <div style="padding-left: 19%;">

			 <ion-item id="diary-item" style="background-color: transparent;" class="list-item item">
                <div id="diary-card" ng-class="trip.listCardClass" ng-style="{height: '150px'}" class="list card list-card bg-light list-card-lg" style="height: 300px;">
        </div>

[shankari]

The transform is due to the use of collection-repeat
https://ionicframework.com/docs/v1/api/directive/collectionRepeat/

Using standard angular ng-repeat works fine wrt resizing, but ends up with all the start and end tags at the every top and the very bottom. This is probably due to the lack of transformation in ng-repeat.

Before	After

[shankari]

Going back to collection repeat, and then changing the actual transform values did work, but that seems a pretty complicated calculation to make, and one which will basically reproduce the code in ionic. And we are not even going to stay with ionic over the long term.

So here's my proposal to fix that:

• Bump up the default size for CanBikeCO
• if it works:
  • make the size be configurable via a scope variable
  • provide a button to change it manually

Let's see if the hack works

[shankari]

The hack works. Yay!!
It is pretty manual, and the card doesn't get appear to be updated on the first resize, but if you press it enough times, it works 😄

[shankari]

One more issue: report from a user on a Motorola G-Power that they cannot see the map.
They can see the map in the diary, but not in the label screen.

[shankari]

The map in the diary screen has a height (derived from the item height, as we just saw).
The map in the label screen has

height="isAndroid? '50%': '600px'" width="100%"

We explicitly added the fixed value on iOS because the map is completely hidden otherwise.
e-mission/e-mission-phone@089797e

I wonder if motorola has a custom webview that behaves more like iOS. Let's just remove the android hack and see if it fixes the problem.

[shankari]

While implementing the fix to fill in additional fields (e.g. user_input) for unprocessed trips, it looked like we were reading unprocessed trips for subsequent days as well. Need to investigate further.

[shankari]

Loaded diary trips for 4th august 2016.

Seemed to process all trips - 4th, 5th, 6th, etc.

Processing trip starting at 2016-08-04T10:03:51.235000-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T10:41:32.136385-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T13:10:38.739684-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T13:40:36.959000-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T13:46:26.561801-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T14:06:52.592000-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T14:18:35.840464-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T14:39:38.288795-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-04T16:34:45.744782-10:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-05T04:55:09-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-05T07:26:36-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-05T17:23:23-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-05T17:51:41-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-09T18:04:30-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T09:54:31-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T11:07:23-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T17:43:53-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T18:11:17-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T19:28:28-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-10T19:32:48-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-11T09:20:41-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-11T11:23:09-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-11T11:45:20-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2016-08-11T14:08:04-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}
Processing trip starting at 2021-10-13T21:20:04-07:00 {data: {…}, start_place: {…}, style: ƒ, onEachFeature: ƒ, pointToLayer: ƒ, …}

[shankari]

Ah the error is because

DEBUG:about to query for unprocessed trips from Thu Aug 04 2016 19:38:38 GMT-0700 -> Sat Oct 16 2021 23:59:59 GMT-0700

On going to the next page...

DEBUG:about to query for unprocessed trips from Fri Aug 05 2016 17:25:52 GMT-0700 -> Sat Oct 16 2021 23:59:59 GMT-0700

It looks like we are reading all trips until the end of today, not that day. This is likely to be particularly problematic in the case where the user has a significant history and goes way back in it, and may be at least a partial contributor to "diary loading is slow".

Just to confirm, this code has been unchanged since the unprocessed trip functionality was first implemented.
e-mission/e-mission-phone@d97b474

[shankari]

Ah, although this particular code was unchanged, the restructuring in e-mission/e-mission-phone@f3ea875 was a bit sloppy, and meant that for

    var addUnprocessedTrips = function(processedTripList, day, completeStatus) {

day and completeStatus were both undefined.

Since complete status was undefined, we read unprocessed trips, and since day was undefined, moment(day) became moment(undefined) which is today.

[shankari]

First round of fixes:
e-mission/e-mission-phone#800

Second round of fixes:
e-mission/e-mission-phone#801

[shankari]

The new resize icon

on some phones, causes overlaps with the existing tabs.

And there are cases in which there were overlaps even before, which this will only exacerbate.

We should really remove the clutter on the top bar, and change the filters to be icons, or a dropdown.