Add bikeshare support

[barbeau]

There is now a General Bikeshare Feed Specification (GBFS):
https://groups.google.com/forum/#!topic/transit-developers/Mhf8pmw9WTU

Official spec yet to be published. We should look at supporting this in OBA - I think this is a client-side issue, although we may need a new set of fields in the Regions API that define the bikeshare API endpoints for a region.

See related issue for OTP:
opentripplanner/OpenTripPlanner#2181

From that issue:

Copy of the specification draft: https://docs.google.com/document/d/1ff9uv7z3rVdOSBAseY9v0CQphY5PzEGlmfpHqxLJoXE/edit#heading=h.ic7i1m4gcev7

[barbeau]

We now have GBFS support in our OTP fork, http://maps.usf.edu/. OTP consumes GBFS and offers the data up via a REST API call, very similar to what OBA does with real-time transit info.

Here's the bike rental API call to OTP:
http://maps.usf.edu/otp/routers/default/bike_rental

HTTP request header:

GET /otp/routers/default/bike_rental HTTP/1.1
Host: maps.usf.edu
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://maps.usf.edu/?module=planner&fromPlace=(CUTR)%20Center%20for%20Urban%20Transportation%20Research%3A%3A28.0586%2C-82.4161&toPlace=28.067852756687433%2C-82.4082326889038&time=10%3A41am&date=05-06-2016&mode=TRANSIT%2CWALK&maxWalkDistance=482.8032&wheelchair=false&arriveBy=false&showIntermediateStops=true&itinIndex=1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

And the OTP bike rental API docs:
http://dev.opentripplanner.org/apidoc/0.15.0/resource_BikeRental.html

It seems they support geographic bounds, so we could use the same StopOverlay design that we currently use for bus stops.

Sample response:

<BikeRentalStationList>
<stations>
<stations>
<id>bike_3584</id>
<name>B-1183</name>
<x>-82.4096</x>
<y>28.058726666666665</y>
<bikesAvailable>1</bikesAvailable>
<spacesAvailable>0</spacesAvailable>
<realTimeData>true</realTimeData>
</stations>
<stations>
<id>bike_3563</id>
<name>B-1162</name>
<x>-82.4171</x>
<y>28.066873333333334</y>
<bikesAvailable>1</bikesAvailable>
<spacesAvailable>0</spacesAvailable>
<realTimeData>true</realTimeData>
</stations>
<stations>
<id>bike_3564</id>
<name>B-1163</name>
<x>-82.40966</x>
<y>28.060715</y>
<bikesAvailable>1</bikesAvailable>
<spacesAvailable>0</spacesAvailable>
<realTimeData>true</realTimeData>
</stations>
...
</stations>
</BikeRentalStationList>

[barbeau]

For parsing the response with Jackson, we should be able to leverage the POJOs in our opentripplanner-pojos library:
https://github.com/CUTR-at-USF/opentripplanner-pojos/tree/master/src/org/opentripplanner/routing/bike_rental

This is how OTP Android parses the response, which can be seen in this code:
https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/blob/master/opentripplanner-android/src/main/java/edu/usf/cutr/opentripplanner/android/tasks/BikeRentalLoad.java#L69

[barbeau]

In OTP Android, I believe we make the assumption that all returned entities are bike stations. At USF (including maps.usf.edu) and other locations, there are floating bikes w/ embedded GPS that aren't fixed to stations. So we might need to update the POJOs project to reflect this difference.

[barbeau]

Note that there is now a new GBFS implementation in OTP as part of TriMet's Mobility On Demand Sandbox project. Here's the GBFS branch - we should plan to use this implementation on this branch instead of our USF Maps project code.

Here's a sample OTP bikeshare API endpoint for the above GBFS implementation:
http://trimet.dev.conveyal.com:8001/otp/routers/default/bike_rental

Here's a snippet of a sample response:

<stations>
    <id>"bike_5987"</id>
    <name>0487 BIKETOWN</name>
    <x>-122.67217666666667</x>
    <y>45.52323666666667</y>
    <bikesAvailable>1</bikesAvailable>
    <spacesAvailable>0</spacesAvailable>
    <allowDropoff>false</allowDropoff>
    <isFloatingBike>true</isFloatingBike>
    <networks>
        <networks>default</networks>
    </networks>
    <realTimeData>true</realTimeData>
</stations>

Note that we should configure more than one GBFS endpoint per region in OTP - Tampa currently has two, one for Coast Bikeshare and one for USF Share-A-Bull.

[barbeau]

For the initial "Layers" UX to show bikeshare floating bikes and stations on the map, I'd like to do something similar to what the Transit App is doing.

When zoomed out, the bikes just appear as tiny dots on the map:

However, when you zoom in further, they appear as tappable markers when zoomed in:

The existing SVG files for the vehicle map icons for OBA Android are located in:
https://github.com/OneBusAway/onebusaway-android/tree/master/icons/vehicle_markers

We can copy/edit these for our bikeshare map marker icons. Material design icons are available at https://material.io/icons/. You can use this tool to generate the various resolutions and copy into project - https://romannurik.github.io/AndroidAssetStudio/icons-generic.html.

[barbeau]

For adding bikeshare to trip planning - Check out OpenTripPlanner Android to see how this is implemented there. We'll need to add icons for bikeshare modes - these should be added as black and tinted. Material design icons are available at https://material.io/icons/. You can use this tool to generate the various resolutions and copy into project - https://romannurik.github.io/AndroidAssetStudio/icons-generic.html.

[barbeau]

Here's our wiki page for 2017 Google Summer of Code project that will be working on bikeshare integration for OBA Android:
https://github.com/OneBusAway/onebusaway-application-modules/wiki/Google-Summer-of-Code-2017

[barbeau]

The existing VehicleOverlay used to show the real-time bus locations on the map (when tapping on arrival time and then "Show route on map") is probably a good model for what an implementation of a bikeshare overlay would look like, although it can be much simpler as we only need one version of icon (i.e., we don't have directional arrows for bikes).

Thinking more, a better model is probably the StopOverlay. This is because the call to the server for stops includes a bounding box to pull back only what's currently visible on the map - we want to do something similar for bikeshare, so we're only pulling back bikes that are currently visible to the user on the map (and caching them in a HashMap after they are retrieved to avoid flickering when the user moves the map).

[barbeau]

To summarize the above comments, full bikeshare support in OBA Android would include two things:

1. Enhance existing usage of OTP /plan endpoint to include bikeshare as supported mode in trip plans
2. Add a map layer showing bikeshare locations on map using OTP bike-rental API endpoint.

[carvalhorr]

Just to confirm. On item 2, the bike stations and floating bikes will be displayed together with the bus stops?

[barbeau]

Yes for now. We may need to look at a "layers" concept, but for now let's just show all bikes and stations when you zoom in far enough.

[barbeau]

From @carvalhorr:

when a bus stop is clicked the information about the stop appears in the bottom of the screen ... for the bike stations, should I do something similar?

I think it's best to show as pop-up balloon from marker, like we currently do with transit vehicles after tapping on arrival time and selecting "Show route on map":

Transit App does something similar:

Only problem with this display is that you can only have one click listener for the entire balloon. So, when we tap on the vehicle marker, we take the user to the trip status activity. For the bike/station marker balloons, I think tapping on them should ideally deep link to that bike/station on the bikeshare vendors website or app. However, deep links aren't currently provided in GBFS, so this feature would require the adoption of MobilityData/gbfs#25. So for know, I'm not sure if tapping on the balloon should do anything, although I'm open to ideas.

[barbeau]

Here's what the marker balloon looks like on SoBi (bikeshare vendor)'s website:

I like this design in general, although it would need to be smaller on mobile. And, for now, the only data we've have would be available bikes and available racks.

[carvalhorr]

Should the markers be different for a bike station and a floating bike? What about marker size at different zoom levels?

At the moment I'm showing Google Maps default marker, but I was planning to show something specific for bikes. Is there any guide for UI so I don't create something completely different? Or is there someone who could help with the UI?

[barbeau]

Yes, I would recommend different markers for station vs. floating bike, at least at closer zoom levels. See #402 (comment) for some info on markers, and let me know if you have more questions. Take a look at the material design icons and see if you can find a good one for bike and station/rack - feel free to comment with examples in this issue.

[barbeau]

From @carvalhorr:

There is a "default" router when I make requests to the "bike_rental" api. I am not sure how a region is selected to be the default. I set up 2 different regions to work with GBFS, but one of them was automatically selected as default. But assuming there is only one region per server will work. It probably needs to be further investigated. Since the server supports multiple regions, if in the future someone deploys a server with more than one, it could cause problems.

If you’re talking about the OneBusAway region from the OBA Regions API:
http://regions.onebusaway.org/regions-v3.json

…the logic to select this region is in org.onebusaway.android.region.ObaRegionsTask – it sets the global app state with the currently selected region via Application.setCurrentRegion() with an ObaRegion object. (Hint – in Android Studio, use “Ctrl-N” to search for a given class name).

The ObaRegion object contains the OTP base URL from the Regions API, which is accessible via ObaRegion.getOtpBaseUrl(). To look at how this is used for the current “Plan a trip” HTTP request - if you click on the text for this method in Android Studio and do “Alt-F7”, it will show you usages of this method. You can see one of the existing usages is in …directions.util.TripRequestBuilder.execute(). This URL gets formatted and then passed into the constructor of TripRequest around line 269. TripRequest is an AsyncTask, so when it’s executed the doInBackground() method executes, which calls requestPlan() method in the same class. The key line of code is in TripRequest.requestPlan() at line 154 – this is what constructs the URL used to make the trip plan request. You can see we have a legacy API URL structure for older versions of OTP (i.e., if useOldUrlStructure is true), otherwise we construct the URL for the newest OTP servers using the “prefix” variable, which was earlier assigned the value of FOLDER_STRUCTURE_PREFIX_NEW, which is /routers/default (this is assigned in TripRequest.doInBackground(), and then passed into requestPlan() as the prefix.

So, for the current trip planning feature we assume there is a single OTP server per region (in both the OBA Regions API and OBA Android app), and that the correct router will be the default router. You’re fine sticking with these same assumptions for OTP bike share API.

[barbeau]

@carvalhorr After rereading your question, I think I may have misunderstood it. Can you configure OTP so that more than one GBFS feed appears under the default router? If not, then that's a problem we'll need to address somehow.

For example, in the Tampa region, we currently have the USF Share-A-Bull Bikeshare system, and the City of Tampa has Coast Bikeshare, and each has their own GBFS API endpoint. We'd want both to be shown in OBA Android, so we'd need to consume both GBFS feeds in the OTP server for Tampa.

[carvalhorr]

I may not be using the right terminology, so let me explain what I did. In OTP: I created two directories under otp/graphs. One called "tampa" and other called "portland". In each of these directories I downloaded the corresponding OSM file for the region (I think I got the OSM from Mapzen, but not sure). I also configured the GBFS for each of these directories in the corresponding files "router-config.json". This mean I have two routers, right? With this configuration now I can hit the OTP server in two different routers: /opt/routers/tampa/ and /otp/routers/portland/ in my localhost. In OBA (using tampa region): When I get the getBaseOtpUrl() from thecurrent ObaRegion (which I get from Application.get().getCurrentRegion()) I get https://otp.prod.obahart.org/otp/ ... and I still have to add /routers/{router_id}/bike_rental/ ... I could not find a router_id that matched "tampa" in the ObaRegion, so I used 'default" for the router_id. For some reason, my OTP server maps requests to the default router to tampa, but I don't remember to have configured this anywhere. Is the router_id anywhere in the ObaRegion? There is a getRegionName, which do not seem to be the router_id. This is working fine so far, but I am just pointing out that if an OTP server happens to have more than one router (like I have tampa and portland) I am not sure what would happen.

[barbeau]

This mean I have two routers, right?

I believe so, though to be honest most of my use of OTP servers came before the concept of multiple "routers" emerged.

Is the router_id anywhere in the ObaRegion? There is a getRegionName, which
do not seem to be the router_id.

No, we don't have any concept of router_ids in OneBusAway. We only have a single method related to OTP, the ObaRegion.getBaseOtpUrl() method which gives you the base URL for the OTP server (well, there is a otpContactEmail email too, but that's not used for API calls). So far we've only used this OTP base URL for trip planning, and we have the default router hardcoded (in TripRequest.FOLDER_STRUCTURE_PREFIX_NEW). So it's trivial to use this same base OTP URL for bikeshare, but we'd be restricted to hard-coding the router_id to default as well.

Are you able to configure OTP to consume more than one GBFS feed per router (for example, have "tampa" as the default router, which includes both the Share-A-Bull GBFS feed and Coast Bikeshare GBFS feed)? If so, the same above design in OBA used for trip planning should work fine for bikeshare - we'll just make the assumption for now that the default router can be configured for all GBFS feeds for the OBA region.

If we can't configure OTP to consume more than one GBFS feed per router, then we'll need to change the design of the OBA Regions API to provide more information related to router_ids - perhaps a list of valid router_ids for the region that have GBFS feeds.

[carvalhorr]

I don't know at this moment. I will have to check it or ask someone who knows OTP better. Let me get back to this once I complete displaying the bike information on the map. Is that alright?

[barbeau]

Sure, that's fine.

[carvalhorr]

I'm attaching some screenshots of how the bike support on OBA looks like right now

There is a new item in the drawer for bikes:

When selected it will display the bikes on the map:

When a bike station is clicked it shows its info:

I'll create a docker image of an OTP server with GBFS enabled and put it on Google Cloud so that you can see it in your environment too.

[barbeau]

@carvalhorr Glad you got this working! Looks like all the mechanics are in place.

Docker image for OTP would be great - do you have a Windows environment to test this in? For some reason I've had issues with Docker images created in Linux and running them on my Windows machine.

[barbeau]

As far as the layer UI, I think the bikeshare layer control would fit better outside of the navigation drawer.
For the general map layer control (which would include bikeshare for now, potentially others in the future), I had in mind another action button above the "My location" button - something like this:

When tapped, it would expand to show a picture and text for each layer, like this animation from the Material design - Components - Buttons: Floating Action Button -> Speel dial example:

For now this would just contain the bike image and text (and maybe a toggle control like a checkbox or swtich to turn on/off?), but in the future we could add Uber, Lyft, etc.

Unfortunately I don't know if code to actually implement this already exists in a format we can use - I would hope it's in the Android support library or another open-source Google project. You might need to do some digging around.

Here's the link to the material design layers image:
https://material.io/icons/#ic_layers

[carvalhorr]

Cool. I'll take a look at how to implement this. The bike option in the drawer like I implemented did not feel right. This is why I want to create the docker so that others can see how it is progressing and give feedback. Should the bus stops also have an option to switch on/off? As for the transition, do you prefer this one that you showed or the toolbar (I could not find a gif for it, but take a look here <https://material.io/guidelines/components/buttons-floating-action-button.html#buttons-floating-action-button-transitions>, under "Transitons" there is an option "Toolbar")? P.S.: I don't have a windows machine to create the docker image. I was thinking about deploying it to some cloud service and you and the others can point to it and test.

…

On Fri, 16 Jun 2017 at 21:59 Sean Barbeau ***@***.***> wrote: As far as the layer UI, I think the bikeshare layer control would fit better outside of the navigation drawer. For the general map layer control (which would include bikeshare for now, potentially others in the future), I had in mind another action button above the "My location" button - something like this: [image: image] <https://user-images.githubusercontent.com/928045/27244309-f8d7dc5e-52b3-11e7-9ef4-d940573e4884.png> When tapped, it would expand to show a picture and text for each layer, like this animation from the Material design - Components - Buttons: Floating Action Button -> Speel dial <https://material.io/guidelines/components/buttons-floating-action-button.html#buttons-floating-action-button-transitions> example: [image: components-buttons-fab-transition_card_02-small] <https://user-images.githubusercontent.com/928045/27244549-096664fe-52b5-11e7-9774-d806f5ecb1a2.gif> For now this would just contain the bike image and text, but in the future we could add Uber, Lyft, etc. Unfortunately I don't know if code to actually implement this exists - I would hope it's in the Android support library or another open-source Google project. You might need to do some digging around. Here's the link to the material design layers image: https://material.io/icons/#ic_layers — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#402 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADr1j1LJLHQI9DsgYstLp4LANWug3BkMks5sEuy2gaJpZM4Gu-3A> .

[barbeau]

BTW, great work on this so far! I think I forgot to say that earlier :).

Should the bus stops also have an option to switch on/off?

Good question. Let's leave them on by default for now, it will make the initial implementation simpler. Although internally, as I previously mentioned, I do want to move towards a controller/loader structure that would allow us to turn stops and routes (including more than one route) on and off programmatically independent of one another. This would be needed to make them a separate UI layer in this control. Ultimately I'd like a Nearby routes/stops toggle option, possible controlled from a different UI control (maybe tabs-ish at the top or bottom of screen - more at #352). Internal controller/loader would need to be modified for that too. So I think the internal code is something we need to eventually tackle, although I'm ok leaving the bus stops off this particular map layer control.

As for the transition, do you prefer this one that you showed or the
toolbar (I could not find a gif for it, but take a look here
https://material.io/guidelines/components/buttons-floating-action-button.html#buttons-floating-action-button-transitions,
under "Transitons" there is an option "Toolbar")?

I did see this toolbar option, and I think its the other potential candidate along with the speed dial example. I think the main limitation to the toolbar is that it doesn't allow text + images and you're limited to five items (the screen isn't wide enough for either), and I think it would look strange above the My Location button - we'd need to put it at the bottom of the screen and the My Location button above it (not a big problem, but a consideration). The advantage to the toolbar over speed dial is that it keeps all options near the bottom of the screen near your thumb - the speed dial would get harder to reach with the more items we add.

I think I was leaning ultimately towards the speed dial option due to allowing text + images, and allowing potentially more items in the list. Some layers may not be obvious from an image alone, and in my experience you always end up with more map layers than you think you will.

P.S.: I don't have a windows machine to create the docker image. I was
thinking about deploying it to some cloud service and you and the others
can point to it and test.

That would work - I also need to figure out the Windows Docker issue, so I'll take some time to try and spin it up myself too.

[barbeau]

Issue fixed in commit carvalhorr/onebusaway-android@b0a698f

@carvalhorr I'm not sure if this fixed the issue? On a clean install after the above commit it seems like bikeshare markers never appear, even if I toggle the layer on and off, and exit and re-enter the app.

[barbeau]

Ah, sorry - I forgot to add the custom OTP URL :(. My fault. Looks like carvalhorr/onebusaway-android@b0a698f did indeed fix the problem.

[carvalhorr]

• - Change Regions API URL - We are going to use https://raw.githubusercontent.com/OneBusAway/onebusaway-multiregion-support/bikeshare-staging/staging/regions-v3.json in the beta release to avoid impacting all OBA Android Tampa users with the new OTP server version

Regions API URL changed in commit carvalhorr@736fb11

[barbeau]

String bikeStationId = bikeStation.id.replaceAll("[^0-9]", "");

• Could you replace this with an if (bikeStation.id.startsWith(... solution? GBFS IDs can be alphanumeric, so I believe this could break some future IDs (e.g., UUIDs). Given this is hard-coded for SoBi, I'd prefer to specifically look for their case (prefixes of bike_ and hub_), and strip off only those character strings.

[carvalhorr]

• - Looks like the deep link URL isn't being formed correctly - here's the URL Chrome opens on my device when I tap on the floating bike marker:
  https://app.socialbicycles.com/map?bike_id="bike_3561"
  URL should be:
  https://app.socialbicycles.com/map?bike_id=3561

Fixed in commit carvalhorr@44a8e95

[carvalhorr]

• - Support both transit and bikeshare trip plans by default

Commit carvalhorr@80c9ba9 included bikeshare by default when planning a trip in a region that bike is supported

[barbeau]

• - Refactor LayerUtils.isBikeshareLayerActive() - The current naming of this method doesn't really match the functionality, which is determining if bikeshare is enabled for the currently selected region or custom OTP API. Let's refactor this to be Application.isBikeshareEnabled().

[carvalhorr]

• - Refactor LayerUtils.isBikeshareLayerActive() - The current naming of this method doesn't really match the functionality, which is determining if bikeshare is enabled for the currently selected region or custom OTP API. Let's refactor this to be Application.isBikeshareEnabled()

Resolved in commit carvalhorr@8f38538

• - Let's change bike_station_title to Rent a bike here to better indicate it's related to this station.
• - Let's swap the "Rent this bike" and the bike ID locations, so the ID is the title. This will match the vehicle marker balloon better (see below - in fact, just use those exact styles).

Both items resolved in commit carvalhorr@f79dccd

[carvalhorr]

• - Ensure custom OTP URL is saved when switching regions (but check master branch behavior - I believe switching to official region that has an OTP URL should overwrite the custom OTP URL)

The custom OTP url is saved when switching regions both on the gbfsand master branches.

[carvalhorr]

• - Sliding panel collapses if you tap on the vehicle marker or bikeshare marker

Issue resolved in commit carvalhorr@93402db

The same behavior will apply in HomeActivity. If a user clicks on a bike marker while viewing the bus stop info (on the sliding panel), the bus info will continue on the screen along with the bike station balloon. This seems to be more consistent with the behavior when showing the route on map.

[barbeau]

• Tint the ">" in the bike marker balloons to be gray to match the bus marker balloon. It's currently black.
• Center the "Rent a bike here" text in the bikeshare hub marker balloon
• Change the "Rent a bike..." to "Tap to reserve a bike" in the bikeshare hub marker balloon to match the floating bike marker balloon.
• Change floating bike marker balloon text to "Tap to reserve this bike"
• Make ">" in bike marker balloons right-align with marker title (i.e., there should be the same margin between right edge of balloon and title and right edge of balloon and ">")
• I'm noticing that if you tap on arrival and do "Show route on map", and then leave the app by pressing Home button to do other things (open a few other apps) so the activity gets destroyed (I assume), when you return to the app the Layer FAB is too high. You can repeat these steps again to make it even higher. The My Location FAB seems fine. Screenshot below.

• When switching from "Nearby" in HomeActivity to other fragments (e.g., "Starred Stops"), the Layers FAB isn't hidden (see below)

[barbeau]

For the record, here is what SoBi's current Android app looks like for hub markers:

[barbeau]

• - Looks like there is at least one unused PNGs in the project - bike_station_marker_big_old.png. @carvalhorr Could you please remove this from all the density folders (hdpi, xhdpi, etc.), and double-check to make sure there aren't any other unused/old resources in the PR? I couldn't find any others...

[barbeau]

@carvalhorr What would you think of making the small bikeshare markers at more zoomed-out levels a little smaller?

On the left below is the currently size of 22dp, and on the right is 15dp. I think I like the smaller circles - it's a little less overwhelming when there are a large number of stations/bikes together.

[barbeau]

• If you tap on the Layer FAB to expand it, and then tap the device Home button, and then re-open the app, the Layer FAB ends up in a strange state (see below - control is expanded but layer icon is shown, and it's crooked)

[carvalhorr]

• If you tap on the Layer FAB to expand it, and then tap the device Home button, and then re-open the app, the Layer FAB ends up in a strange state (see below - control is expanded but layer icon is shown, and it's crooked)

I could not find a solution in which the screen would return displaying the layers FAB in the same state (speed dial open), so I closed the speed dial when the activity's onStop method. This way when the user returns to the app, the FAB is closed.

[barbeau]

• As of 2a88d4d, if you uninstall the app, and then re-install and run, and you're located in Tampa, the Layer FAB does not appear on the first execution after installation (I'm assuming that the regions callback isn't correctly triggering the control to appear). If you close the app and restart it, then the Layer FAB appears.
• Similarly, if you have a region selected that doesn't support bikeshare (e.g., Washington D.C.), and you change to Tampa (which does support bikeshare), the Layer FAB doesn't appear (although if you have Tampa selected, and switch to Washington D.C., the Layer FAB does correctly disappear).

[carvalhorr]

• - As of 2a88d4d, if you uninstall the app, and then re-install and run, and you're located in Tampa, the Layer FAB does not appear on the first execution after installation (I'm assuming that the regions callback isn't correctly triggering the control to appear). If you close the app and restart it, then the Layer FAB appears.
• - Similarly, if you have a region selected that doesn't support bikeshare (e.g., Washington D.C.), and you change to Tampa (which does support bikeshare), the Layer FAB doesn't appear (although if you have Tampa selected, and switch to Washington D.C., the Layer FAB does correctly disappear).

The first issue is fixed by commit 92bc1be

I could not reproduce the second one.

[barbeau]

Did you try reproducing the second one via the emulator with a Tampa location? The commit you just added may fix this too. I think this reverts the commit that fixed the "Issue fixed: layers FAB not hidden when switching to "Starred stops" problem - do you if after the above it's happening again now?

…

On Aug 20, 2017 10:34 AM, "Rodrigo" ***@***.***> wrote: - - As of 2a88d4d <2a88d4d>, if you uninstall the app, and then re-install and run, and you're located in Tampa, the Layer FAB does not appear on the first execution after installation (I'm assuming that the regions callback isn't correctly triggering the control to appear). If you close the app and restart it, then the Layer FAB appears. - - Similarly, if you have a region selected that doesn't support bikeshare (e.g., Washington D.C.), and you change to Tampa (which does support bikeshare), the Layer FAB doesn't appear (although if you have Tampa selected, and switch to Washington D.C., the Layer FAB does correctly disappear). The first issue is fixed by commit 92bc1be <92bc1be> I could not reproduce the second one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#402 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA4pLZ_AAVngaElK8f5PtMVMPcl1XINcks5saEPagaJpZM4Gu-3A> .

[carvalhorr]

I tried to reproduce it using my device with the location set to Tampa. Apparently, the fix solves this problem too.
The previous commit indeed undid the fix for the wrong display of the layers FAB, but only when you navigate to a specific starred stop and show the map for that stop.

The commit carvalhorr@802680f should make it work properly now for all the interactions:

• first app install
• switching between areas with/without support to bikeshare
• switching between "Nearby"/"Starred stops"/"My reminders"
• navigation to a starred stop (and showing the map), then returning to the "Nearby" view

[barbeau]

@carvalhorr Awesome, thanks! I'll check it out.

• Would you be able to bump the version of the speed dial library and configure to keep it open when tapping the "Bikeshare" control? Seems like this should be a quick fix - see Feature request - Allow speed dial to remain expanded when item is tapped markormesher/android-fab#14 (comment) for instructions.

[barbeau]

• We're now looking for a way to disable the speed dial cover view so we can scroll the map while the speed dial is expanded (see Feature request - Allow speed dial to remain expanded when item is tapped markormesher/android-fab#14 (comment)).
• Based on https://github.com/markormesher/android-fab#installation, looks like we need to add -dontwarn java.lang.invoke.* to proguard-project.txt

[barbeau]

• If you uncheck the bikeshare layer in HomeActivity, and then plan a trip, you get bikeshare results but no bikeshare marker appears on the map (see below screenshot) - IMHO the behavior should be that if the "bus & bikeshare" or "bikeshare only" trip options are selected, we should always show the markers on the map as part of the trip plan (even if the HomeActivity bikeshare layer has been toggled off). So, the two should work independently of one another.

[barbeau]

• The Additional Preferences on Plan a Trip is not saving the selected trip mode

[carvalhorr]

• If you uncheck the bikeshare layer in HomeActivity, and then plan a trip, you get bikeshare results but no bikeshare marker appears on the map (see below screenshot) - IMHO the behavior should be that if the "bus & bikeshare" or "bikeshare only" trip options are selected, we should always show the markers on the map as part of the trip plan (even if the HomeActivity bikeshare layer has been toggled off). So, the two should work independently of one another.

Fixed in commit carvalhorr@551c71a

[carvalhorr]

• The Additional Preferences on Plan a Trip is not saving the selected trip mode

Fixed in commit carvalhorr@c0d50df