Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Added optional single host MvxStartActivity#4846

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
entdark wants to merge2 commits intoMvvmCross:develop
base:develop
Choose a base branch
Loading
fromentdark:single_host_start_activity

Conversation

@entdark
Copy link
Contributor

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

Prevent doubleAcitivity navigation on startup (MvxStartActivity then first VMActivity) and navigate directly to the main launcherActivity that isMvxStartActivity and the host for fragments.

⤵️ What is the current behavior?

CurrentlyMvxStartActivity starts the app and navigates to the first VM that view is expected to be anActivity.

🆕 What is the new behavior (if this is a feature change)?

MadeMvxStartActivity to be used simultaneously as the main launcher and the host for fragments.
SingleHostActivity property controls the old and new behaviour.
In the new behaviour it neverFinish() theMvxStartActivity when it already launched with first VM.

💥 Does this PR introduce a breaking change?

Should not. I made things optional and defaults to original behaviour. (Maybe should default to the new one and break?)

🐛 Recommendations for testing

Test any first VM that navigates to aFragment rather than to anActivity.

📝 Links to relevant issues/docs

🤔 Checklist before submitting

@Cheesebaron
Copy link
Member

Using MvxStartActivity is already optional, you can simply not have it in your App and makre you "single host" Activity as the MainLauncher, so I am not sure if this PR is necessary. Can you elaborate exactly what it solves?

@entdark
Copy link
ContributorAuthor

entdark commentedMar 29, 2024
edited
Loading

Can you elaborate exactly what it solves?

MvxStartActivity is the only default way that callsIMvxAppStart.StartAsync(). Calling it manually and handling thatIMvxAppStart.IsStarted is a bit overcomplication. It would be cool to have single host activity out of the box that does all the startup magic for you.
In my projects I have to call it manually for now.

Maybe my solution could be designed a bit better and/or named better - I am fine to tune it before the PR.
Additionally, I also thought creating anotherMvxStartActivity maybe named differently with all that logic or revert backMvxSplashScreenActivity and have them both. CurrentlyMvxStartActivity is more like oldMvxSplashScreenActivity.

@github-actionsgithub-actionsbot added the p/androidAndroid platform labelJul 20, 2025
Copy link
Contributor

CopilotAI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR introduces an optional single host mode forMvxStartActivity to prevent double Activity navigation on startup. Instead of navigating fromMvxStartActivity to a separate Activity for the first ViewModel, it allowsMvxStartActivity to serve as both the launcher and fragment host.

  • AddedSingleHostActivity property to control behavior (defaults to false for backward compatibility)
  • Changed base class fromMvxActivity toMvxActivity<MvxStartViewModel> with proper ViewModel typing
  • Modified layout inflation to use binding-aware inflation and conditional window features

}
}

publicclassMvxStartViewModel:MvxNullViewModel{}

Choose a reason for hiding this comment

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

The MvxStartViewModel class is placed at the end of the file outside the namespace. This should be moved inside the namespace or to a separate file for proper organization and to avoid namespace pollution.

Suggested change
publicclassMvxStartViewModel:MvxNullViewModel{}
publicclassMvxStartViewModel:MvxNullViewModel{}
}

Copilot uses AI. Check for mistakes.
Copy link
Member

Choose a reason for hiding this comment

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

Please move it to a separate file

// Set our view from the "splash" layout resource
// Be careful to use non-binding inflation
varcontent=LayoutInflater.Inflate(_resourceId,null);
varcontent=this.BindingInflate(_resourceId,null);

Choose a reason for hiding this comment

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

The change from non-binding to binding inflation may have unintended consequences when SingleHostActivity is false. Consider making this conditional based on SingleHostActivity property to maintain existing behavior:var content = SingleHostActivity ? this.BindingInflate(_resourceId, null) : LayoutInflater.Inflate(_resourceId, null);

Suggested change
varcontent=this.BindingInflate(_resourceId,null);
varcontent=SingleHostActivity
?this.BindingInflate(_resourceId,null)
:LayoutInflater.Inflate(_resourceId,null);

Copilot uses AI. Check for mistakes.
Copy link
Member

Choose a reason for hiding this comment

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

This could be a breaking change.

Copy link
Member

@CheesebaronCheesebaron left a comment

Choose a reason for hiding this comment

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

Sorry to leave this one hanging, can you pelase address the linting issues and review comments

}
}

publicclassMvxStartViewModel:MvxNullViewModel{}
Copy link
Member

Choose a reason for hiding this comment

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

Please move it to a separate file

// Set our view from the "splash" layout resource
// Be careful to use non-binding inflation
varcontent=LayoutInflater.Inflate(_resourceId,null);
varcontent=this.BindingInflate(_resourceId,null);
Copy link
Member

Choose a reason for hiding this comment

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

This could be a breaking change.

@entdark
Copy link
ContributorAuthor

entdark commentedSep 16, 2025
edited
Loading

This PR still bothers me a bit. Thinking of it I found another solution: mark the main launcherActivity in theApplication that we should start initial navigation from. The design should look like this:

MvxAndroidApplication<TMvxAndroidSetup,TApplication,TActivity>:MvxAndroidApplication<TMvxAndroidSetup,TApplication>whereTActivity:Activity{publicoverridevoidOnCreate(){base.OnCreate();RegisterActivityLifecycleCallbacks(newActivityLifecycleCallbacks(this));}classActivityLifecycleCallbacks(global::Android.App.Applicationapplication): Java.Lang.Object,IActivityLifecycleCallbacks{bool_isResumed;Bundle_bundle;Setup Setup=>MvxAndroidSetupSingleton.EnsureSingletonAvailable(application).PlatformSetup<Setup>();IsMainLauncherActivity(Activityactivity)=>activityisTActivity;publicvoidOnActivityPaused(Activityactivity){if(!IsMainLauncherActivity(activity))return;_isResumed=false;CancelMonitor();}publicvoidOnActivityResumed(Activityactivity){if(!IsMainLauncherActivity(activity))return;_isResumed=true;Monitor();}publicvoidOnActivityCreated(Activityactivity,BundlesavedInstanceState){if(!IsMainLauncherActivity(activity))return;_bundle=savedInstanceState;Monitor();}publicvoidOnActivityDestroyed(Activityactivity){if(!IsMainLauncherActivity(activity))return;CancelMonitor();}publicvoidOnActivitySaveInstanceState(Activityactivity,BundleoutState){}publicvoidOnActivityStarted(Activityactivity){}publicvoidOnActivityStopped(Activityactivity){}voidInitializationComplete(){if(!_isResumed)return;if(Mvx.IoCProvider.TryResolve(outIMvxAppStartstartup)){if(!startup.IsStarted){Task.Run(async()=>awaitstartup.StartAsync(_bundle));}}}voidMonitor(){Setup.StateChanged-=SetupStateChanged;if(Setup.State==MvxSetupState.Initialized){InitializationComplete();}else{Setup.StateChanged+=SetupStateChanged;}}voidCancelMonitor(){Setup.StateChanged-=SetupStateChanged;}voidSetupStateChanged(objectsender,MvxSetupStateEventArgsev){if(ev.SetupState==MvxSetupState.Initialized){InitializationComplete();}}}}

So basically we move responsibility to start the initial navigation toApplication and its subscription to main launcherActivity lifecycle.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

Copilot code reviewCopilotCopilot left review comments

@CheesebaronCheesebaronCheesebaron requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

p/androidAndroid platform

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@entdark@Cheesebaron

[8]ページ先頭

©2009-2025 Movatter.jp