Closed remulasce closed 9 years ago
I need to learn a bit more about relational databases to see how this sort of data structure would work.
Java_core is locked, but I can write the scraper at least.
Nighelles: Lol, talking mad shit about my SQL /AFTER/ the "learning a bit more about relational databases" step.
Scraper has been modified. Database files will now include a stoproutes table, with the stuff you need.
Currently regenerating all the databases...
Scraping Complete.
Deleted the lametro-combined database, since we don't use it, and it would now be obselete.
We don't want to change OmniAutocompleteEntry, because every time we change that class all the existing historical entries get dropped. So unless we want to make an upgrade path for that or bundle this with a bunch of other OAE changes, we should avoid it.
I think we should be able to do this almost entirely within the OmniAutoCompleteAdapter.
Right now we're not even making the views ourselves. We have a custom listitem with a textview, whose id we push to the default toString converter.
So I think we can override getView, and check if there's any known route colors to fill in there.
The getView fxn would work with the existing autocomplete entries, and just do an sql check on the stops against our new databases.
So, rough tasks:
For UI, I'm going to assume we just show the color bars. That gets you all the Rail routes, distinguishes Local from Rapid, and doesn't need much space. We could actually probably reserve enough space for most stations without having to dynamically shuffle the sizes.
Also note that the RequestList then will be the only thing missing these bars. It could look out of place.
I might even care.
SQLReader is modified.
Interface in.
And omni input deal can see it now.
AUtocompleteAdapter gets colors
Colors have
A proper fix would be to move the colors to SQL with the rest of just about everything. That would take quite a while longer.
UIs are made.
Need to just "do it" now, I suppose.
Note extra step: Determine what colors to use.
Since each request can have multiple stopids with the same route, we have to do some duplicate checking.
Ok, got the colors.
Only had to fix, like, 2 things along the way.
On to actually doing the thing now.
Ok, it's in. Even uses cool recycling.
Issue I think is that we're hitting the file system in the middle of getView, which is UI thread. Need a background loader / filler, or to load it sooner somehow.
They lazy load now.
I'm still a little concerned about performance. I fire a lot of asynctasks to do this stuff.
Maybe I should make #267
We should probably have a 'loading' state that's differentiated from the "nothing" one.
Loading state is in- White background while loading, grey when done.
Actually still feels fine off debug.
Not like I'm missing a good opportunity to do this or anything.
Do agencies other than LA have route colors?
See #245
It would be great if we could see what lines were actually going to be tracked without having to add the station. Especially if you're unfamiliar with the exact name of all your stops, it would help make sure you're selecting the right stop.
There probably isn't enough space to actually list the number of every single line, especially to big bus depots, but we could probably fit in the line color slices before the stop names. That would distinguish between the rail/route lines, and also help figure out if the stop you're typing is a Rapid stop or if you need to select / walk to a further station.
See #214. This would help with that for colored lines, so you could at least know you selected the right stop when you're wondering why no arrivals are showing up.
Of course, this would require scraper / sql / java_core changes.