The app now not only shows the routes that visit a stop, it shows coming departures! Admittedly it’s slow and the results aren’t accurate – the times are all wrong – but it’s definitely a step in the right direction.

Last week I made some progress with showing which busses/trains will be the next to leave from the stop you’re currently at. I’ll post a video of how far I got with that – I can now show the names of the routes that stop there but not when they do.

I’ve spent more time reworking and cleaning up existing code. I’ve changed how transit info is scheduled such that you need to extract even less data to show information at a given location so that saves time and memory.

I’ve also started working on a component that talks to rejseplanen.dk. The app won’t need it but as I start working on displaying some of the same information that they do it’s really useful to be able to compare what I generate with what they produce when given the same input. If there’s a difference, probably I’ve made a mistake.

I’ve also spent some more time working on how to display maps. I have a new approach when everything is split into triangles and my initial experiments look pretty terrible but I think I can make it look better. I’m not planning on spending more time on that this week though. This week I want to get further with showing arrival times, rather than just routes. In fact, I really really want that to work tomorrow because I want to use it when I take the bus Wednesday morning, in two days.

As the video below says, this week was almost exclusively working on android. It’s tricky, I’ve never done anything on android before so I’m learning as I go and I make mistakes and have to change stuff I’ve already done all the time, but I’m making progress.

One thing I worked on was making data access faster. It used to be that from the time you clicked the location button to the nearest stops showed up there was a delay of like 3 seconds. This was because the app loaded everything before it was able to access anything. Now instead of having the data together in a single file that has to be read in one go I’ve split it into a number of separate files in a zip archive that I can read out individually. So now, to show the stop list I only have to read the geographic index and the stops information and not the schedules themselves. And longer term I can split things even further so I only have to read some of the geographic info and stops.

I also added an action if you click a stop, you now go to a stop info view. It doesn’t show anything but it will. Just this took a lot of time because now having two views instead of one revealed some bad decisions I’d made last week that I had to fix.

Another thing I worked on was reading calendars – that’s the “monday to friday except public holidays” aspect – so now those are available to the app as well, though I don’t use them yet.

I’ve realized that I probably have to include maps in the app as well, and they have to work offline as well so I can’t just rely on google maps they probably have to be my own set of maps. That could potentially end up taking a lot of space if I don’t simplify them and I want them to be simple and stylized like transit maps usually are. I played around with some ideas for how to those automatically but so far it’s not been a success. My attempt to make a compressed version of Fyn that looks less pixelated than just a bitmap when you zoom in wasn’t a total disaster but yeah… it’s not production ready.

This week I want to show a departure board on the stops info page. It may not be correct – I may not take calendars into account yet for instance – but I’d like to show something.