It’s not totally clear to me exactly what is wrong here, but I think you’re on the right path, I just don’t really understand checking the component name. The ionViewWillLeave only fires when you leave the view it’s defined on, so I can’t really understand why you’d need to know the name, just put it on the view you want to detect leaving.
Hmm doesn’t the ionViewWillLeave() fire every time you leave your page? So when I pop the page to devicesPage and when I push to editeDevicePage, both events trigger ionViewWillLeave(). In that sense it is working but doesn’t help me with my case.
I need some way to know Im leaving for the devicesPage so I can run the bluetooth disconnect method.
Actually, sorry, I understand now I think. So then, if you only want to disconnect when you get back to the devices page, then put ionViewWillEnter on the devices page.
is a bit contradictive since I am checking for it while leaving the singleDevicePage, but during my testing I noticed that when pushing to EditDevicePage from singleDevicePage the ionViewWillLeave will return that the nav.getActive().component is actually EditDevicePage(the page you are pushing to) and not SingleDevicePage( the page you are about to leave).
So then, if you only want to disconnect when you get back to the devices page, then put ionViewWillEnter on the devices page.
Concerning this, I have thought about it, but I would have to send the deviceId as a parameter to the parent devicesPage via pop (not sure if they implemented that functionality). Hoped that there was a cleaner solution to handle the disconnection from the singleDevicePage.
Got it, ya, makes sense, you can send that data back with the pop though. Alternatively, if you can only connect to one device at a time, you could abstract the device handling to your bluetooth service like: