search

remulasce / metroapp

Realtime arrival notification utility for LA Metro
2 stars 0 forks source link

Figure out how we're going to do regionalization #278

Closed remulasce closed 7 years ago

remulasce commented 9 years ago

Options are basically either release a different app per region, or to release one master app that figures out where you are and sets itself appropriately.

Also, figure out what agencies to support for the NorCal region- just AC Transit, or we can add whatever is supported by NextBus. That might mean we need UI to show what agency is providing which trips.

The Play Store does direct keyword matching of app titles, which means people searching for a specific agency predictions will see a city-branded version as higher. But it's kind of a pain to support a whole bunch of different app releases.

remulasce commented 9 years ago

We should probably also release an Android version of however we do norcal regions.

nighelles commented 9 years ago

Ok, so the issue is that I wrote everything for regionalization except how to actually decide which region we're in.

remulasce commented 9 years ago

Right. So we can either write that bit, or just hardcode it in different app configurations.

nighelles commented 9 years ago

I don't think its that hard to write that bit, and it can be done in Java probably?

On Saturday, July 4, 2015, remulasce notifications@github.com wrote:

Right. So we can either write that bit, or just hardcode it in different app configurations.

— Reply to this email directly or view it on GitHub https://github.com/remulasce/metroapp/issues/278#issuecomment-118543971.

remulasce commented 9 years ago

No, not hard. The Android side would need some of my recent history code redone though. I'd say keep it out of java_core, and keep j_c as deterministic as possible. That'll let you use some better platform-specific features as well, like Google Play's built-in geofencing notifications.

The real question is if we actually want one single app for all regions. Since we only have 2 regions anyway, it might make sense to just make 2 different apps. And if we convert the Android app to multi-region, I need to change the name and let users know what's going on.

I guess we could include full region support, then also make multiple app entries using identical code and just not tell users the app actually works everywhere.

Can you check how the App Store search results work? Will including the city in the title of the app improve search hits from that city?

nighelles commented 9 years ago

I don't think the App Store does searches that way. Also; they frown upon arbitrarily region restrictedapps

On Saturday, July 4, 2015, remulasce notifications@github.com wrote:

No, not hard. The Android side would need some of my recent history code redone though. I'd say keep it out of java_core, and keep j_c as deterministic as possible. That'll let you use some better platform-specific features as well, like Google Play's built-in geofencing notifications.

The real question is if we actually want one single app for all regions. Since we only have 2 regions anyway, it might make sense to just make 2 different apps. And if we convert the Android app to multi-region, I need to change the name and let users know what's going on.

I guess we could include full region support, then also make multiple app entries using identical code and just not tell users the app actually works everywhere.

Can you check how the App Store search results work? Will including the city in the title of the app improve search hits from that city?

— Reply to this email directly or view it on GitHub https://github.com/remulasce/metroapp/issues/278#issuecomment-118560622.

remulasce commented 9 years ago

Region-restricted like, they don't open outside a certain area? Or just any app that's only useful in one place?

nighelles commented 9 years ago

I think it's ok as long as there's a reason for it to only be in one region

On Saturday, July 4, 2015, remulasce notifications@github.com wrote:

Region-restricted like, they don't open outside a certain area? Or just any app that's only useful in one place?

— Reply to this email directly or view it on GitHub https://github.com/remulasce/metroapp/issues/278#issuecomment-118560963.

remulasce commented 9 years ago

I'm feeling, do it on the platform-specific side, and then each of us should just do it how they want, as long as they have a solution for both regions.

remulasce commented 8 years ago

Ok, trip to Norcal. Putting together a branch for ridiculous live testing.

Looks like only SF-Muni and AC Transit are on NextBus.

Missing is:

Ugh. Bart should be #1 I think, because they are using GTFS, which is a reasonable spec. The others are just so awful. Ugh.

nighelles commented 8 years ago

You on skype? Let's get stuff ready for live testing.

nighelles commented 8 years ago

Example request:

http://api.bart.gov/api/etd.aspx?cmd=etd&orig=RICH&key=MW9S-E7SL-26DU-VV8V

remulasce commented 8 years ago

Ok, I propose plan:

Plan:

1. Settings dialog to manually set agencies 2. Default option for "automatically detect" 3. Autodetect with a service zone for each agency

  1. I think per-agency service areas work better than having a general region
  2. I can't think of any real user-facing reasons why, Maybe I want to discount agencies in the LA boonies when you're on the westside without having to define like 3 LA subregions?
  3. I think it'll make future expansion more automateable. Just throw in a new database file, with a scraped coverage area, and you're done. So we could have nationwide NextBus expansion in constant time.
    1. We deploy literally the exact same app to different markets, with different names to match keywords. Or we can call it a nationwide app, and just not have to do anything more.

Manual toggling makes sense for the "travel" use case, and in the end we need a way to test-change the region anyway so we may as well make it a feature.

Then we can have the "auto-detect" agency setting automatically fill in the manual checkboxes, so when you disable autodetect it keeps the same current agencies, but lets you change them. So if you just want to add one agency, all the others you use are already checked.

Remaining decisions:

remulasce commented 8 years ago

So step 0 of plan is to remove the old "single agency" string from regionalization helper.

Looks like it's currently only used to set the notifyservice, and as the fallback if a stop's agency isn't set.

So, reminder: NotifyService probably needs some work.

remulasce commented 8 years ago

Manual settings dialog now works.

remulasce commented 8 years ago

Improvements Remaining:

remulasce commented 8 years ago

Looking at autocompletehistory filtering. Interesting edge case: Each entry can have stops consolidated from different agencies, so what if only one of those agencies is in the current region?

I'm thinking for now, if any stop is in-region, allow the whole entry.

remulasce commented 8 years ago

Ooh boy. If you've got identically named stops from different agencies, you can create multiple history entries for the same-named stop, from different agencies.

Interestingly, I think this is easy to fix. We just need to move the stop consolidation to the final stage of autocomplete matching.

remulasce commented 8 years ago

Also, with name-consolidation, we can run into issues with multiple agencies using identical stop names. Like, imagine 2 Union Stations, or 2 Main / 2nd streets.

remulasce commented 8 years ago

We could probably do some proximity-based thing to not-merge those.

remulasce commented 8 years ago

The no-duplicate-servicerequests function doesn't check for differing agencies in the requestlist.

So that's another possible collision: Add Vermont / Athens Station with only metro-rail enabled. You get a request for only the Green Line. Then disable lametro-rail, andenable lametro. Then add Vermont / Athens Station.

Currently you won't be allowed to add the second Vermont / Athens Station, even though its agency differs from the one already added.

But if both agencies were enabled, then you wouldn't be able to convert the existing Vermont / Athens into a combo metro / rail station.

So maybe a replacement policy would work better? If the existing one is no longer in region-scope?

Man are there a lot of edge cases.

Probably need to just clear existing entries when changing regions.

nighelles commented 8 years ago

Region decision code probably lives in java core, but that needs to have some sort of external thing to get location, which is platform specific.

What would be nice is if all the people are pulling geo-data from some big external source that is official in some capacity. That way stations that are the same across agencies would have the EXACT same lat and long, which would make it easy to present them as the same station.

remulasce commented 8 years ago

OK, Android autocomplete history solution: If an autocomplete entry contains any stop that is out of region, it doesn't get suggested.

This loses the use case where you're at some common transfer point, and want to enable another agency and expect it to have the same autocomplete priority.

But it makes the rest of the interaction a lot simpler.

Remaining: Don't show duplicate entries that just have a subset of the stops for a particular name.

remulasce commented 8 years ago

Actually, no. You should be able to history-select stations for individual regions, so long as we make that clear.

If a user makes a mistake when doing this, it'll get pushed out by recency calculations eventually anyway.

remulasce commented 8 years ago

See Milestone Auto-Regionalization for full tasks.

remulasce commented 8 years ago

Ok, Android version now checks what agency .db files are loaded onto the devices at startup, and loads the names / bounds from all those.

remulasce commented 8 years ago

Android autodetect checkbox works now.

So all remaining is to display what's going on to the user.