HustleTime Development: New Feature and bug fixes

Now that I’m back working on my mac, and an xCode that seems to be far more responsive to the machinations of ReactNative than it’s counterpart, Android Studio, I can get back to work.

One of the things I’ve done is now completely implements the 2 versions of the <ArrivalNotification />

This is going to be very useful to all the folks who need to see the last stop on a train. It’s a work in progress, however, as I need to continue to look for oddball train terminals that aren’t part of the default set of stations. What I mean, is that if a train ending service at some random station, HustleTime might not know what to do with it, until I add that station to the list of possible terminal stations.

It’s an imperfect system, but essentially it derives from the fact the MTA GTFS doesn’t include the last stop field, and instead, I’m reduced to some heavy lifting as hustletime-api sorts through all the stops in a current route and then gets the last entry in that array, stores it to a variable, and then includes that in the JSON for each arrival.

I’ve added a little searching indicator so you see when HustleTime is looking for data from the server . This is helpful when you’re underground, and/or don’t have a great signal, so you’ll see that HustleTime is working to get you up-to-the-minute info for arrivals.

I’ve also gone into the code and tried to eliminate some unnecessary API calls to the server. This is mainly accomplished by setting redux store to have an additional key called appReady.

  appReady: {
    featuresLoaded: false,
    mapLoaded: false,
    located: false,
  }

as parts of the app load, it will hit the reducer and change the values in the store, only when all 3 are true, will the app load data from the MTA. One disadvantage of this is that Location Services do indeed need to be enabled for the app to function, where in the past, I had set a default location. My next step is to set a default location if indeed location services are denied.

That involves adding a callback function to the second field in the navigator.geolocation.getCurrentPosition function.

getLocation = () => {
  navigator.geolocation.getCurrentPosition(currentPosition => {
    this.props.dispatchedNewCenter({
      latitude: currentPosition.coords.latitude,
      longitude:currentPosition.coords.longitude}),
    this.props.dispatchedCircleCenter({
      latitude: currentPosition.coords.latitude,
      longitude:currentPosition.coords.longitude})
    }, error => {
      this.setDefaultLocation()
    }
  )
  .then( x => this.props.dispatchedAppReady({located: true}))
}

setDefaultLocation = () => {
  this.props.dispatchedNewCenter({
    latitude: 40.6931111,
    longitude: -73.9913111}),
  this.props.dispatchedCircleCenter({
    latitude: 40.6931111,
    longitude: -73.9913111})
}

When Ios rejects the location request due to a permission not being enabled, it’ll call the setDefaultLocation function, and set lat and lng for somewhere in Boerum Hill.

I’m excited for this latest version of HustleTime, and I’m fairly confident that this will be the last real round of functional updates before I get into the two next big pieces:

  1. refactoring code for readability and efficiency
  2. cosmetic upgrades

Look for this new version (2.1) on the AppStore in the next few days!

as always,
You can get HustleTime on both Android and iPhone free!