gistfile1.txt

Single Purpose
- to return/forward the selected fleet object to the book ride activity


Api Calls
- Fleets
- FavoriteFleets
- DeleteFavoriteFleet

Fragment
- Two modes
-- favorites 
-- select a fleet


AppState connections
- sets provider user select = true
-- should to be responsible for this, this shoudl be handled by the calling activity
- sets current fleet
-- should to be responsible for this, this shoudl be handled by the calling activity
- gets bookable providers
- gets un-bookable providers
- gets current ride dropoff location
-- checking for and selecting a dropoff location should be handled by the bookride activity


UX Paths
- favorite ==> bookride activity
- select a fleet <==> book ride activity
-- if dropoff required then start SelectAddressActivity for result (but don't do anything w/ the result)
- if select a fleet && no bookable fleets ==> show un-bookable fleets (not sure how to get this data), i guess we're trying to let them call and book, but it seems wrong since the purpose of the app is to book w/in the app
-- this may indicate that we need to filter the FleetsService call to only show bookable,
--- could be done in the adapter?
-- need to show warning dialog if this is the case ? seriously, why not just only show bookable providers, in fact, how do we even get back non-bookable providers


Conditions for fleet selection
- must be bookable in all cases
-- FavoriteFleets does not contain bookable flag
--- must compare w/ results from Fleets call


Code Issues
- "ignore taps" seems unnecessary
- view holder pattern needs work
-- should accept a view at the least and assign the held view objects automatically
- new instance method uses hard coded string for arg_params "favorite", needs to use a constant
- bad use of local constants "typeBookableProviders", could be a simple boolean if not removed entirely
- we display the "no bookable fleets" dialog twice, not DRY
- it's not clear why we would start the BookRide activity for result from this fragment (:226)
- inconsistent messaging
-- why are we warning the user that they need to upgrade to use this fleet, why not just only show fleets they can book. Provide the user w/ a clear path to book, don't fake them out to try and guilt them into upgrading
- no need for the settings drawer to be present in the "ChooseFleetActivity" since this is only called during the booking flow and is not a top level nav drawer item
- get rid of the use of  yes/no dialog in the base fragment activity
- get ride of "check for empty ride" in onresume and elsewhere, also remove the interface from the actiivty 


Blockers
- need approval to only show bookable fleets
- need to figure out how to sync up the two fleets calls in the event that we're dealling w/ the favorite fleets mode
-- possibly soultion: wait until the user clicks a fleet, then make the call and check when it returns
--- we can do something like this

if(has bookable fleets){
	checkBookable(int x)
} else {
	getBookableFleetsJob.start().callbackMethod(checkBookable(final int x))
}
// ideally this entire fragment would just return the fleet id to the bookride activity and that would be responsible for checkign bookability