Building an application that should run on both lightning experience and mobile Saleforce with the following component structure
mainMenu component -> search Component(s) -> custom record view
Have been trying to do use the lightning:navigation via the document here. https://developer.salesforce.com/docs/atlas.en-us.api_console.meta/api_console/components_navigation.htm
On both iOS and Android using the lightning:navigation the back functionality doesn't work correctly:
- Navigating to a new component does NOT update the hamburger menu to a back arrow on either device.
- On Android devices using the device back button results in being redirected to home/last page before app was loaded.
- On iOS without a back button the users are stranded on the newly loaded component with no way to go back.
- This solution introduces mobile devices being unable to scroll child component content when child component is larger than parent https://success.salesforce.com/issues_view?id=a1p3A0000008fdDQAQ
Does anyone know how to get the back button to function correctly? Appears to be a bug or serious lacking feature. This limitation seems to require a custom button to return to parent component and I believe this should be handled by the hamburger/back arrow interface.
Using the previous force:navigateToComponent:
- Navigating to a new component successfully updated the hamburger to a back arrow on iOS and successfully took you back to previous component.
- On Android the back button wasn't rendered but selecting the device back button correctly sends you to the parent component.
- this solution introduces mobile devices being unable to scroll child component content when child component is larger than parent https://success.salesforce.com/issues_view?id=a1p3A0000008fdDQAQ
Attempting to swap components by dynamically creating and destroying results in the back button not being effected on the mobile application. This solution would also require a custom button to return to the parent component ( not the hamburger back button). Appears that this is the only viable solution and that mobile apps at this point cannot correctly us the navigation methods provided. This doesn't feel correct..