Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

[Android] Fix bug. Children pages in NavigationPage were got appearing events even if they were not latest in navigation stack #758

Closed

Conversation

rotorgames
Copy link
Contributor

@rotorgames rotorgames commented Feb 12, 2017

Description of Change

If add the NavigationPage in an UI stack and push two pages, later delete the NavigationPage from the UI stack and add it again, all pages in the NavigationStack will have OnAppearing event, even if they will not be latest in NavigationStack. Also if do to PopAsync, hidden pages will not get OnAppearing event.

Bugs Fixed

API Changes

None

Behavioral Changes

None

PR Checklist

  • Has tests (if omitted, state reason in description)
  • Rebased on top of master at time of PR
  • Changes adhere to coding standard
  • Consolidate commits as makes sense

@dnfclas
Copy link

dnfclas commented Feb 12, 2017

Hi @rotorgames, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

@dnfclas
Copy link

dnfclas commented Feb 12, 2017

@rotorgames, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, DNFBOT;

@rotorgames
Copy link
Contributor Author

@hartez @jassmith @StephaneDelcroix Any news about it? I can not use the single instance of NavigationPage many times because all pages in it will be get OnAppearing and OnDesappearing even if they will not be the last in NavigationStack.

I want to see it in v2.3.4 so much. Please review it.

@rmarinho rmarinho self-assigned this Mar 23, 2017
@rotorgames
Copy link
Contributor Author

@rmarinho Hello. Will we be able to see it in new release soon?

@@ -589,6 +585,46 @@ void SetupToolbar()
_toolbar = bar;
}

void InsertPages(IEnumerable<Page> pages)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan to add another way to insert pages to the fragment stack. Can't we fix the problem just on SwitchContentAsync ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I will try to do it soon

@rmarinho
Copy link
Member

@hartez can you take a look at this please. Thanks

Copy link
Member

@rmarinho rmarinho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan to add another way to insert pages to the fragment stack

@StephaneDelcroix
Copy link
Member

no activity. closing.

reopen (or open a new one) when the comments are addressed

mattleibow pushed a commit that referenced this pull request Jan 28, 2021
Context: https://github.com/dotnet/core/blob/79c19c12ab2bc11912551bb0c3025f602cd541d9/Documentation/diagnostics/portable_pdb.md

In doing some performance testing with builds in VS 2019, I noticed:

    115 ms  _ConvertPdbFiles                           1 calls

And looking at files were converted:

    ConvertDebuggingFiles
        Parameters
            Files
                C:\ProgramData\Xamarin\NuGet\xamarin.essentials\1.0.1\lib\monoandroid81\Xamarin.Essentials.pdb
        [Output] ConvertedFiles:
            C:\ProgramData\Xamarin\NuGet\xamarin.essentials\1.0.1\lib\monoandroid81\Xamarin.Essentials.dll

The Xamarin.Essentials NuGet package is shipping a non-portable PDB
file. This is a Windows-specific format that Mono doesn't support.

Xamarin.Android runs a tool called `pdb2mdb` when it encounters a
non-portable PDB file so symbols be converted to something that Mono
can use. If you have `DebugType=full` or `DebugType=pdbonly`,
Xamarin.Android has to do this extra work to convert it.

I see no drawbacks to just use `DebugType=portable` in this project
all the time?

Since Xamarin.Essentials uses sourcelink, I double-checked and they
support portable PDBs:

https://github.com/dotnet/sourcelink#prerequisites-for-net-projects

I sent a similar PR to Xamarin.Forms, shipping since 3.4. I wrote a
bit more detail on symbol files there if you need more info:

#4201
mattleibow pushed a commit that referenced this pull request Jan 28, 2021
Context: https://github.com/dotnet/core/blob/79c19c12ab2bc11912551bb0c3025f602cd541d9/Documentation/diagnostics/portable_pdb.md

In doing some performance testing with builds in VS 2019, I noticed:

    115 ms  _ConvertPdbFiles                           1 calls

And looking at files were converted:

    ConvertDebuggingFiles
        Parameters
            Files
                C:\ProgramData\Xamarin\NuGet\xamarin.essentials\1.0.1\lib\monoandroid81\Xamarin.Essentials.pdb
        [Output] ConvertedFiles:
            C:\ProgramData\Xamarin\NuGet\xamarin.essentials\1.0.1\lib\monoandroid81\Xamarin.Essentials.dll

The Xamarin.Essentials NuGet package is shipping a non-portable PDB
file. This is a Windows-specific format that Mono doesn't support.

Xamarin.Android runs a tool called `pdb2mdb` when it encounters a
non-portable PDB file so symbols be converted to something that Mono
can use. If you have `DebugType=full` or `DebugType=pdbonly`,
Xamarin.Android has to do this extra work to convert it.

I see no drawbacks to just use `DebugType=portable` in this project
all the time?

Since Xamarin.Essentials uses sourcelink, I double-checked and they
support portable PDBs:

https://github.com/dotnet/sourcelink#prerequisites-for-net-projects

I sent a similar PR to Xamarin.Forms, shipping since 3.4. I wrote a
bit more detail on symbol files there if you need more info:

#4201
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants