Closed cormacmchale closed 5 years ago
First and foremost when we developed the idea for the app we decided that there was no information that shouldn't be repeatable on the database... by this I mean that essentially two users could have the exact same journey because that would be applicable in the real world. I would Imagine that two users having identical Journies might cause an issue with the markers, perhaps something to look into eventually.
Journey-Planner Page. This page is where a user would send a Journey to the database. First the user searches by string to find a location. The Google API provides much of the functionality
Basically whats happening here is Google's GeoCoder takes a string in and return an associated ILatLng inside of an asynchronous function. Inside this function we set the camera target to this location and add two dragable markers which represent the start and end point of the journey
After selecting the addJourney button the function is run to add that info to the database. It's quite a chunky function but i'll do my best to outline whats happening. First the Page checks if a user is logged on (see login functionality issue). The positions of the markers are got by calling the .getPosition() function on the objects. The LatLng's and the user name are now passed to the getJourneyInformation() function.
This function essentially just takes the LatLng positions of the markers and geocodes a location to display for the user later on. The reason it it set up in this embedded style is because in order access the information correctly inside asynchronous function I had to perform all of the logic inside the callback function. There's a batch Geocode function but I had implemented this working correctly so I didnt feel the need to change it. All of this information is then passed onto the service. (See service issue for further information)
The Map page. This page displays all the Journies that have been added to the database
It just calls the getJourney() function from the service and passes the observable collection of documents as it exists at that moment into an array for the app to deal with. It then loops through the array and passes the required information from each document into the addMarkerFromDatabase() function.
This function just adds a marker at the start and end location with the title being the name of the user who added the Journey so the user can see who is going on that Journey. Finally a Polyline is added so the user can distinguish between Journies in terms of UI.
The convert RGB function is discussed in more detail in the Android bugs issue
Now finally in order to get as much CRUD functionality as possible we added in the option for delete Journey, we also decided to change up the UI here for the user so as not to overdo the map usage. So in order to display the Journies for whichever user is logged in we needed first the address of the marker locations (this is why we Geocode on the way up! was much easier than doing it here). This html should give you an idea of how I'm displaying for a particular user.
So with an ion-card for each document, display the journey start address and end address for Journies that have the associated UserName of the user logged in.
The Delete button on the html passes the document ID to the logic of the page to be sent to the service for deleteById(). again all this function provided by the good folks at google.
This section will document how the information was handled between the apps pages and the service and also how we viewed our information as developers.