Android Crashes on App Resume
bradmartin opened this issue · 36 comments
- Install plugin into demo app using demo code.
- Run the app
- Pause (minimize the app)
- Resume and 💥
Won't see the NS exception activity since its a crash.
Android Studio logs provide this:
--------- beginning of crash
2018-10-16 10:57:05.165 7650-7891/com.permobil.smarteval A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x58 in tid 7891 (GLThread 8661), pid 7650 (mobil.smarteval)
2018-10-16 10:57:05.187 610-610/? E/HWComposer: getLayerReleaseFence failed for display -1: Invalid display
2018-10-16 10:57:05.204 610-610/? E/HWComposer: getLayerReleaseFence failed for display -1: Invalid display
2018-10-16 10:57:05.237 610-610/? E/HWComposer: getLayerReleaseFence failed for display -1: Invalid display
2018-10-16 10:57:05.255 610-610/? E/HWComposer: getLayerReleaseFence failed for display -1: Invalid display
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: Build fingerprint: 'google/walleye/walleye:9/PPR2.181005.003/4984323:user/release-keys'
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: Revision: 'MP1'
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: ABI: 'arm'
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: pid: 7650, tid: 7891, name: GLThread 8661 >>> com.permobil.smarteval <<<
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x58
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: Cause: null pointer dereference
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: r0 cb877000 r1 000049a6 r2 00000000 r3 40000000
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: r4 e363e518 r5 c64dba68 r6 00000000 r7 c057e800
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: r8 00000000 r9 e178b600 r10 c057e900 r11 c78e2e00
2018-10-16 10:57:05.268 7894-7894/? A/DEBUG: ip e9a72d00 sp c057e7f8 lr c56fd221 pc c56fd1f0
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: backtrace:
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #00 pc 000261f0 /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #01 pc 0002621d /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #02 pc 000dd3d3 /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #03 pc 00076c01 /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #04 pc 00076c2d /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #05 pc 00074571 /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #06 pc 0005e7d7 /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/lib/arm/libmapbox-gl.so
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #07 pc 00411a79 /system/lib/libart.so (art_quick_generic_jni_trampoline+40)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #08 pc 0040d575 /system/lib/libart.so (art_quick_invoke_stub_internal+68)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #09 pc 003e6b79 /system/lib/libart.so (art_quick_invoke_stub+224)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #10 pc 000a1015 /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+136)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #11 pc 001e5ae9 /system/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+236)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #12 pc 001e05d7 /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+814)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #13 pc 003e2661 /system/lib/libart.so (MterpInvokeDirect+196)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #14 pc 00400414 /system/lib/libart.so (ExecuteMterpImpl+14484)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #15 pc 003b7868 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/base.apk!classes2.dex (deleted) (com.mapbox.mapboxsdk.maps.renderer.MapRenderer.onSurfaceCreated)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #16 pc 001c4d53 /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.2471763592+378)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #17 pc 001c9439 /system/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+152)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #18 pc 001e05bf /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+790)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #19 pc 003e1cef /system/lib/libart.so (MterpInvokeSuper+1098)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #20 pc 00400394 /system/lib/libart.so (ExecuteMterpImpl+14356)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #21 pc 003b83d4 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/base.apk!classes2.dex (deleted) (com.mapbox.mapboxsdk.maps.renderer.glsurfaceview.GLSurfaceViewMapRenderer.onSurfaceCreated)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #22 pc 001c4d53 /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.2471763592+378)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #23 pc 001c9439 /system/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+152)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #24 pc 001e05bf /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+790)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #25 pc 003e1cef /system/lib/libart.so (MterpInvokeSuper+1098)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #26 pc 00400394 /system/lib/libart.so (ExecuteMterpImpl+14356)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #27 pc 003ae4ce /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/com.permobil.smarteval-InwI9vpywFWtqxXZ33ewaw==/base.apk!classes2.dex (deleted) (com.mapbox.mapboxsdk.maps.MapView$5.onSurfaceCreated+10)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #28 pc 001c4d53 /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.2471763592+378)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #29 pc 001c9439 /system/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+152)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #30 pc 001e05bf /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+790)
2018-10-16 10:57:05.297 7894-7894/? A/DEBUG: #31 pc 003e23a3 /system/lib/libart.so (MterpInvokeInterface+1010)
From quick searching on mapbox repo here it looks like handling the app events might be a fix for this.
Testing out a few things in an app, if so, will provide PR to README with ways to handle.
I've had the same issue with the new version.
Found a workaround:
I have added the const applicationModule = require("tns-core-modules/application"); and registered the events :
applicationModule.on(applicationModule.suspendEvent, function () {});
applicationModule.on(applicationModule.exitEvent, function () {});
both of them removing the mapview from the parent view and with the resume event I'm readding the mapview to the parent:
applicationModule.on(applicationModule.resumeEvent, function () {}
@stoanarrr Thanks for sharing! Brad and I were trying a similar approach with less luck. Can you share the actual implementation?
For others: roll back to 4.3.1 and you should be crash-free as well.
Yeah,
I'm going to write a small snippet tomorrow..
Hi @EddyVerbruggen and @bradmartin
Created a simple base project nativescript-mapbox-showcase.
Have a look into the home folder.
I think it's not the best solution, but it works fine for me.
Weird thing, on my Huawei P10 with android 8.0.0, without the workaround the map was redrawn automatically but the map listeners weren't working. With the workaround all works fine for me.
Hopefully I could help you ;)
@stoanarrr Thanks for sharing! Brad and I were trying a similar approach with less luck. Can you share the actual implementation?
For others: roll back to 4.3.1 and you should be crash-free as well.
Confirm roll back to 4.3.1 fixed crash issue. Thanks!
While switching between pages, app crashes to (as mentioned in issue #275), solution for me was, to listen for the "onNavigatingFrom" event (Page docs) and when it's triggered detach and destroy the map like I mentioned before.
Hey @EddyVerbruggen , I am also experiencing this same problem.
The reason I updated to 4.4.0 was because it seems that this version of the plug in fixes the bug where the app would crash while moving as discussed in this issue #265.
If I downgrade to 4.3.1 to accommodate for the Android crashes, won't that mean I will experience the problems that were solved in 4.4.0 again?
@BMwanza - you are correct, downgrading would lose the fix for an issue that 4.4.0 corrects.
The solution, caused by Mapbox changing their native SDK, is to do what @stoanarrr suggested by destroying the map during a navigation event.
@bradmartin Oh man, wish they didn't change their Native SDK
I'm also experiencing my Android App crashing not only on the onNavigationFrom event, but also on the onPageLoaded event.
I am using a Tabview on my app, so I feel that I would also have to set an onPageUnloaded event to destroy the Mapbox there as well. But this if it's destroyed during the onPageUnloaded event, if the user selects the tab icon that had the page with the map loaded, it wouldn't appear on the screen anymore. I feel like it would be more beneficial for me to wait for stable release to fix rather than implement the work around for that reason.
Do you guys think MapBox will change their SDK to resolve this in the near future? Might just have to delay my Android Release
One of the mapbox members described how to work with the new behavior here which is what we are essentially doing when we destroy it during a navigation event. Which this to me indicates it is not an issue with their SDK and how they are designing it to be consumed. It seems like it is up to you the consumer of their SDK to follow this approach in your implementation.
I think this should be done at the app level and not in this plugin itself, because adding listeners could cause unwanted behavior and result in more issues being raised with odd behavior. Really tough to say what's best without researching more on a solid approach in the plugin.
Yes mapping definitely is not easy! Yes I have a lot of respect for their Engineers and as well as you and Eddy. I'm sure some solution will come shortly!
how are you guys detaching and destroying the map. I called mapbox.destroy where mapbox is the ref element and it still crashes when i navigate from the page on 4.4.0
@stoanarrr is there any chance you could kindly share some code for what you describe?
@paul-muckypuddle sure!
Look here: mabox showcase
Hi @stoanarrr, I've downloaded and tested your demo and it destroys the map passing from home to the second page; but part of the memory still persist (around 30MB each time). I went from and to a couple of time and it does so (I've tried it on android real device measuring the memory form Android Studio) until the app had around 300 MB from the initiale 170 MB. Do you have any solution to suggest? thanks in advance
Hi @simonettoa tried it with my other app -> same problem appeared. I think it's the same as #181 .
Maybe somewhere the javascript object doesn't release the java binding so the GC couldn't remove the instances...
Has anyone come up with a permanent fix for this? More specifically on Vue implementation.
How we could destroy mapBox with NS+Angular?
mapboxdestroy() is not a function ERROR. So this method dos not exist.
Would appreciate any help.
I think I have made some progress on this. Using a strictly native app I have verified that it does not crash even if a custom style is used.
There are a number of closed issues in the mapbox native issues list referencing the need to follow the recommended lifecycle hooks. I notice that the nativescript plugin does not.
So I've attempted to translate the working Java example into Nativescript as a test. Unfortunately, I am relatively new to both android and nativescript development and am running into an android exception I do not understand. So if you could take a quick look, it would be greatly appreciated.
I've put together a StackOverflow question and repositories for the source java example and an attempt at a nativescript translation:
FWIW, I've managed to get a rough version of standalone Android NativeScript test app working.
https://github.com/Yermo/NsMapboxTest
So far I have not been able to get it to crash even after dozens of pause/resume cycles. At present, I do not know if this is coincidence or whether this demonstrates that the crash problem resides in the nativescript mapbox plugin code.
My strong suspicion is that the crash is not a mapbox bug but some kind of race condition on the nativescript mapbox plugin side.
For reference the corresponding Native Java test app is here:
Is this line here doing what is suggested so far? Pausing the map in the native android app, if you remove that and then resume the app does it crash or not?
Another question, how are you using the nativescript-mapbox plugin on your test app? https://github.com/Yermo/NsMapboxTest/blob/master/package.json#L14 you seem to be missing the dependency? Even though you have the mapbox lib in the gradle file but I didn't see how you're initializing an instance of the native mapbox inside the map component. Maybe I'm missing it, low on time to debug it all but I don't see the mapbox API being used inside the NS app.
@bradmartin, I'm not using the plugin in my test app. The whole point was to determine if there was something intrinsic to the Mapbox library that was causing the crash, or failing that, that there was something intrinsic to the NativeScript <=> Mapbox bridge.
The first test was to create a native Java app and to see if it crashes onPause/onResume. It does not.
The second step was to translate the Java app into NativeScript, as close as possible, to see if it crashes onPause/onResume. After dozens of iterations, it does not.
However, using the NativeScript Mapbox plugin I can reliably get it to crash within two or three iterations.
Hence, unless I am overlooking something obvious, there is something in the Nativescript Mapbox plugin that is causing the crash.
That was the whole point. Now the question is what is the difference?
From what I see, your NativeScript app isn't using the Mapbox library in any way. Just adding the dependency to gradle doesn't cause any of the APIs to be called or create an instance of a map. You have a ContentView in your app but there's nothing about mapbox related to the ContentView that I see on the repo.
Also, in the native/java android app, you are calling pause on the mapbox instance. Which is similar to what has been suggested with the mapbox plugin for nativescript. I found one of the mapbox developers explaining the issue here when someone ran into this issue with their native/java android app.
Which in the java app you posted, in the activitie's onDestory there is the code to destroy the mapbox instance, which is what has been suggested to do with the NS plugin since mapbox changed their SDK. Hopefully this helps us get on the same page so we can be sure about the approach and provide a "better" approach for NS devs using the mapbox sdk.
I am very new to both NativeScript and Android development and am somewhat out of my depth but coming up to speed quickly. I had hoped to avoid having to dive into the weeds.
The java code is verbatim from the Mapbox getting started guide. It does not crash. As a result, I conclude the crash is not being caused by the Mapbox API.
The next step was to see if maybe the crash is being caused by NativeScript itself.
My approach was to try to create as close a direct translation of the Java sample code as I could make work in NativeScript. It has some hacks that I would like to address but follows the same custom Activity approach. I am calling the Mapbox Android SDK methods directly to isolate out the plugin.
The ContentView is not being used in the test app only because I spent hours trying to figure out how to get a reference to it in activity.android.ts so I could make the map a child of that view. I punted on it. If you could provide me some pointers how to do that, I'd greatly appreciate it. See onCreate in activity.android.ts.
Interestingly, I have not been able to get the test NativeScript app to crash. From this, I tentatively conclude that the crash is not due to NativeScript itself. So the cause of the crash is likely due to something being done in the plugin.
Of course, since the map view is not a child of ContentView it's possible I'm side stepping the cause of the crash. Again, if you can provide me some pointers how to programmatically make the MapView a child of ContentView I'd appreciate it. (Not creating an XML component, but programmatically so we have access to the savedInstanceState for onCreate(). Or can that object be gotten some other way?.)
Also, the view hierarchy doesn't seem to be constructed by the time onCreate() is called in the activity so I've added a timeout callback as a hack. It's possible that's avoiding the crash.
If you run it, you'll notice that when it's put into the background it calls onSaveInstance() and onStop(). When brought to the foreground it calls onStart().
The map instance itself is not destroyed in this sample as onDestroy() never gets called. The same is true of the java app.
I also notice that the map loads much quicker onPause/onResume. The SDK itself seems to be redrawing the map itself.
Using the Nativescript Mapbox plugin, there's a SEGV in some glthread onResume. Destroying the map and recreating it onPause/onResume seems to prevent the crash most of the time but takes too much time on resume, hence the desire to figure out why it's crashing and fixing it correctly.
At first I thought the crash was being caused by Telemetry because disabling that makes plugin based apps more reliable. Instead of crashing on the first pause/resume, it would sometimes go through 12 iterations before crashing, but it still crashes.
Just calling onStop in the plugin doesn't solve the crash in my tests here. I was thinking that maybe the crash is due to the fact that the plugin passes null to onCreate() instead of the savedInstanceState.
The plugin also doesn't call onSaveInstanceState().
There are a bunch of threads in the android native issues list mentioning that the lifecycle hooks must be called otherwise the app will crash. That's what prompted this whole line of inquiry to start with.
So that's where I'm focusing my attention.
In the plugin MapboxView class, is there a way to hook into the activity callbacks somehow and also get the savedInstanceState there?
Or does that have to be done in a custom activity?
Now I see :)
So the mapbox android app code that you used verbatim doesn't crash because they are handling the lifecycle events and pausing/destroying the map which is what we need to do in NS when you use the plugin that uses the native SDK.
So this plugin does not handle the lifecycles for you. Mapbox SDK doesn't either, which is why in their sample app they are leaving it up to the developer to call the pause and destory methods on the map instance. That is what has been suggested here. With NativeScript you can hook into the pause and destroy events of an android activity. You would use the application core module and then use the suspend and exit event. Suspend is the pause of an activityand Exit is thedestroyof an activity. So in those events you could provide your instance of the map and call thepauseanddestroy` methods. As for navigation, it's a similar approach, you'd use the NS page/frame navigation events when leaving or returning to a page and calling the methods correctly.
Thank you for the pointers. I really appreciate it. Figuring out how all this stuff hooks together, starting essentially from scratch, has been quite a challenge.
I had looked at the application object.
The sample app calls onCreate with the savedInstanceState:
public onCreate(savedInstanceState: android.os.Bundle): void {
...
this.mapView.onCreate( savedInstanceState );
So at the point in the plugin where the map is being created, how do we get the savedInstanceState so we can pass it to mapView.onCreate()?
Also, I'm guessing:
AndroidApplication.saveActivityStateEvent,
is the analog of the activity onSaveInstanceState() method?
Sadly, calling the lifecycle methods does not fix the problem /if/ the map is added as a child to any component in the view. It will still freeze/crash on resume.
However, if the map view is added to the top of the hierarchy, as I am doing in my test app then it works exactly as the native app and it does not crash even through dozens of interations.
If I try to add the map below any tag in the view, whether using a mapView in a Fragment, a mapView directly in a placeholder, or even a SupportMapFragment, the app will freeze and crash on resume.
Destroying the map completely onPause by removing the tag completely (i.e. *ngIf="shown" or some such) and then rebuilding it all on resume does work but not 100% of the time and there seems to be a memory leak.
The mapbox documentation explicitly states that the map lifecycle events have to be called directly from the containing activity. I don't understand why that would have to be the case but even then it does not address this crash if added below any other tag.
I'm presently at a loss how to proceed tracking this down. I'd be grateful for any pointers.
Downgrading to 4.3.1 has stopped the crashing but the plugin no longer displays the userLocation.
Any suggestions? I've been stuck with this since Monday :(
What I have done in my angular app is to catch pause, exit, navigatingTo, navigatingFrom, and resume.
On pause, exit, and navigatingFrom, I destroy the map object.
On resume and navigatingTo I recreate the map from scratch.
It's a terrible kludge but it does seem to work. I have some test cases on github where I've tried to narrow down the cause of the crash but have not been successful yet.
I've noticed, that issue couldn't be reproduced if u use this.mapbox.show({...}) in your component.ts, instead of <mapbox> in your .html file. And it could the case, but I have no idea, how to create elements above the map when I create it with this.mapbox.show command.
Does anybody know, how to do that?
Any updates for this issue?
@ShyshkovOleg A possibile temporary workaround suggested by a friend of mine may be showing the MapBox tag using an *ngIf directive bound to a boolean variable which is set to false on suspendEvent and true to resumeEvent.
@ShyshkovOleg A possibile temporary workaround suggested by a friend of mine may be showing the MapBox tag using an *ngIf directive bound to a boolean variable which is set to false on suspendEvent and true to resumeEvent.
@ShyshkovOleg I did what you suggested and its working fine.
component:
...
showMap$ = new BehaviorSubject<boolean>(false);
constructor(private page: Page) {
// required for hiding map
applicationOn(suspendEvent, (args: ApplicationEventData) => {
this.showMap$.next(false);
console.log('showMap: false');
});
// required for showing map
applicationOn(resumeEvent, (args: ApplicationEventData) => {
this.showMap$.next(true);
console.log('showMap: true');
});
}
...
and html:
<Mapbox *ngIf="showMap$ | async"
accessToken="your token here"
mapStyle="traffic_day"
latitude="51.9280572"
longitude="4.4201952"
zoomLevel="7"
delay="450"
showUserLocation="true"
hideCompass="false"
disableZoom="false"
disableRotation="false"
disableScroll="false"
disableTilt="false"
(mapReady)="onMapReady($event)">
</Mapbox>
Tried *ngIf to conditionally show the map like above and mine is crashing whenever I route to another page or minimize / re-open the app. I suppose ill have to downgrade like everyone else as well although I need the tracking features as well...
constructor(private page: Page) {
applicationOn(suspendEvent, (args: ApplicationEventData) => {
this.showMap$.next(false);
});
applicationOn(resumeEvent, (args: ApplicationEventData) => {
this.showMap$.next(true);
});
this.page.on('navigatingFrom', (data: NavigatedData) => {
this.showMap$.next(false);
});
}
I have this working like a champ in my fork using the current version of the Mapbox API however I am not using an async pipe. Just a boolean property and change detection. (NS Angular).