-
-
Notifications
You must be signed in to change notification settings - Fork 86
Migration to Navigatum #1462
Migration to Navigatum #1462
Conversation
- new navigation details screen - integrate NavigaTumApi to centralized search
- move to new navigation details view
Migration more or less should be ready. I have migrated three roomfinder endpoints:
What is still to be done?
Problems/questions
|
If we comment on TUM-Dev/NavigaTUM#130 about the change timeline, it is stable ;)
@joschahenningsen historically What is the status on this? Was this ever used in the app?
@joschahenningsen Can we migrate the backend (add a new field?) |
I think this might be used in the calendar somewhere. I'll need to do some more digging though.
Sure, as long as it does not break old clients :) Do you have a way of mapping those ids? On another note: Do y'all need some help with the merge conflicts? :D |
I have implemented a new UI, so it has more information. Users can choose between all available site plans and zoom in and out. Besides that, users can open location in other apps that can handle geo-locations as input (#1456). Also, there is a button for a future interactive map, for now it just redirects to the NavigaTum website (idk if some1 is working on an interactive map right now #1437) |
RoomFinderScheduleI did some digging into this secret RoomFinderSchedule logic ;p
I find out that this logic was not available to execute after these two commits: In both these commits, it looks like this might be removed accidentally, but cannot be sure. However, it looks like, since April 2018 this RoomFinderSchedule feature does not work, so I think it would be best to deal with this problem in a separate issue. Also since it was not available for so long, there is a question if anybody needs it. Barrier-free APIAnother case is what shall we do with this Barrier-free API
Should we wait for TUM-Dev/Campus-Backend#80 to be merged and ready to use, so it can be implemented here as well? Or we just merge this PR now with my temporary solutions and take care of Barrier-free in another one? @CommanderStorm |
Actually, we don't need to wait for that PR, as the current backend does already provide us with the exact information we need: Doing so should cover all cases, since the fixes we added for invalid However, if you like, we can use your solution and migrate all occurrences of the |
…avigatum � Conflicts: � app/src/main/AndroidManifest.xml � app/src/main/java/de/tum/in/tumcampusapp/api/app/TUMCabeClient.java � app/src/main/java/de/tum/in/tumcampusapp/component/other/general/RecentsDao.java � app/src/main/java/de/tum/in/tumcampusapp/component/other/locations/LocationManager.kt � app/src/main/java/de/tum/in/tumcampusapp/component/tumui/calendar/CalendarDetailsFragment.kt � app/src/main/java/de/tum/in/tumcampusapp/component/tumui/roomfinder/model/RoomFinderRoom.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/barrierfree/BarrierFreeFacilitiesActivity.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/SearchFragment.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/SearchResult.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/SearchResultState.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/SearchResultType.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/SearchViewModel.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/adapter/RecentSearchesAdapter.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/adapter/ResultTypesAdapter.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/adapter/SearchResultsAdapter.kt � app/src/main/java/de/tum/in/tumcampusapp/component/ui/search/di/SearchComponent.kt � app/src/main/java/de/tum/in/tumcampusapp/di/AppComponent.kt � app/src/main/res/layout/activity_search.xml � app/src/main/res/layout/fragment_search.xml � app/src/main/res/layout/toolbar_search.xml � app/src/main/res/values-de/strings.xml � app/src/main/res/values/strings.xml
What works for you…
For rooms/buildings, this definitively does not make sense, as we have a priority between our items. We should therefore just drop this sorting. Finding a total order between these items is not trivial and should be its PR From an ordering, I would therefore prefer:
Assumptions being,
|
Ok, I will reimplement the ordering as u suggest and other fixes , but probably I will do it next week after my exams |
I will take another look once @PiotrKedra has implemented the changes, just tag me again then please :) |
app/src/main/java/de/tum/in/tumcampusapp/api/navigatum/domain/NavigationEntity.kt
Outdated
Show resolved
Hide resolved
….java Co-authored-by: Frank Elsinga <[email protected]>
…NavigationMap.kt Co-authored-by: Frank Elsinga <[email protected]>
…al/RecentsDao.java Co-authored-by: Frank Elsinga <[email protected]>
…earchFragment.kt Co-authored-by: Frank Elsinga <[email protected]>
…inder/NavigationDetailsFragment.kt Co-authored-by: Frank Elsinga <[email protected]>
Co-authored-by: Frank Elsinga <[email protected]>
…inder/NavigationDetailsFragment.kt Co-authored-by: Frank Elsinga <[email protected]>
…atum � Conflicts: � app/src/main/res/values-de/strings.xml � app/src/main/res/values/strings.xml
I have implemented changes, and also left comments on some conversations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo this can be merged. All my major comments have been adressed.
@Bentipa do you want to review it, or should I merge it?
@PiotrKedra Thanks for the wonderful work you did ✨ |
@CommanderStorm Just gave it a quick look cause of time reasons, but looks good overall to me. So we can merge it. |
Issue
This fixes the following issue(s):
Depending on merging centralized search #1457, I decided to work on this PR rather than the master branch because I used some room finder logic there.
Description
Migrate to: