Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
fix: crash on Android Tab-View #6466 #6467
This fix has been tested in production with no new issues occurring.
Long-term solution would be one of the following, though:
Both 2 and 3 manage the save/restore cycles. The main difference between 2 and 3 is that 2 uses more memory, but allows for quicker switching between Fragments than 3. Since tabs should usually be limited to 5 or less, this may be the best choice to maintain performance, which is important for top level navigation tabs.
When I have more time I may experiment with these options myself to see what the difference to performance and memory consumption is for each.
What is the current behavior?
~2% Crash Rate on Crashlytics:
What is the new behavior?
Hi and thanks for the PR!
The team have been quite busy baking the upcoming NativeScript 5.0 release. We hope you love it as much as we do! The major release is the reason we taking longer with PR reviews. We will resume active reviewing in the following weeks.
Thanks for your patience and for being awesome contributor!
@DickSmith I went through a lot of threads that discuss potenial causes/solutions for the "No view found for id [...] (unknown) for fragment" exception like this and this (the latter looks promising but we still need a repro to work on) and I am not convinced that the proposed solution here addresses the root cause of the problem.
After the rework with commit ac04ede we started using a modified version of the stock Android FragmentPagerAdapter (main logic is the same) and the stock one does not have any similar safeguarding mechanisms. At the moment we are not planning to reintroduce the saveState / restoreState logic i.e. mimic the FragmentStatePagerAdapter.
I personally have seen the aforementioned error while sorting out various issues with frame/tab fragments over the past month (there are multiple fixes on fragments after rc was released). I am not sure how you are certain that no issues are occurring with the proposed fix having no reliable way to reproduce this but my first suggestion would be for you to roll out a version of your application that uses tns-core-modules@next (or wait a couple more days till firstname.lastname@example.org is published but "next" essentially has all the fragment fixes now) and give it a go. If you still believe that the problem occurs in your app I would try the solution suggested in https://stackoverflow.com/a/19900206 and extend the org.nativescript.widgets.TabViewPager in tns-core-modules-widgets and test again.
Hey @manoldonev ,
So I had discussed this issue with several members of the core-team when we met at jsMobileConf in Boston a few weeks back.
Not having a proper save/restore state is the problem here, since on resuming the activity, the
I have Crashlytics, which tells me the frequency and occurrence rate of a crash, and after making this hotfix, my crash rate improved. Crashlytics never provides repro.
This just prevents the crash, and does so 100%, I was getting hundreds of this crash, and now get none, with no other crash replacing it down the line. There is the possibility that the app may then be in an unresponsive state, and the user will need to manually quit and restart the app, but this is still infinitely better in a released production app with end users.
One thing that we wanted to figure out is wether it fixes an actual issue in the current codebase, as AFAIK - we have done some fixes since the version you are using. Do you think there is a way to do that? It will probably involve rolling out a version without the fix, but with updated version of NativeScript and monitoring if the errors will show up again in the analytics. I would understand if you are reluctant to do that though.
If you are out of ideas (we are) of how to further understand the actual problem and how to reproduce it - I would suggest just to merge the PR. Maybe, add an appropriate comment in the code (as it might be confusing to commit transaction on
At this point our tns-core-modules is 95% 5.0+ for Android (I last diff'd the packages on Monday or Tuesday after the official release). The only place it isn't is for text-base and its descendants, since so much of that is handled in common between iOS/Android and in iOS views still seems to have some quirks around the new lifecycle stuff.
Our, core-modules widgets is at 5.0+ (with some additional fixes from us). We also build with CLI 5.0. The only things at this point that aren't really flush with latest (other than additional bug fixes) are the tns-core-modules for iOS stuff I mentioned (due to the scrollview and other issues we've discussed) and the runtimes, mostly due to a compatibility issue with the latest runtime and Crashlytics.
I'll definitely add a comment with some of the stuff I mentioned at the top of this ticket, as I think we either need to reimplement save/restore, or one of the other Adapters that handle it, or find a way to guarantee that this component won't try and execute on potentially garbage-collected objects after restore (which I don't think is possible). Like I mentioned, this 100% prevents the crash, and in many cases won't lead to any adverse behaviour, but in some case may result in the tab being in a bad state due to the lack of restore logic (but still better than a much more frequent crash).
As an additional aside, the real solution here may also be to differentiate between Tabs and Bottom navigation buttons, which Google does, both in their API and their Material Design docs.