Remove support of FragmentActivity and related widgets

[dulmandakh]

This PR removes support for FragmentActivity, which is used to support Fragments on Android version below API 11, because RN supports Android API 16 and above.

Please review: @hramos@mdvacca

Test Plan:

Everything works just normal

Release Notes:

[ANDROID] [ENHANCEMENT] [Views] - Message

[hramos]

cc @mdvacca

[dulmandakh]

Please review and merge @mdvacca. It removes FragmentActivity support which was required to support Fragments on Android below 3.0.

[dulmandakh]

Please review and merge @hramos@mdvacca. Once merged I would like to work in DialogModule to fix app crashes. Thank you

[janicduplessis]

Nice this actually cleans up a lot of code!

Could you also check if it is possible to get rid of some react_native_dep("third-party/android/support/v4:lib-support-v4") in the BUCK files of the modules that don't need it anymore?

[janicduplessis]

I think this should be return Assertions.assertNotNull(mActivity) so we still crash if it is null.

[dulmandakh]

@janicduplessis removed lib-support-v4 dependencies, and added assertion as you suggested. Thank you

[facebook-github-bot]

@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[dulmandakh]

@hramos is there any issue regarding this PR?

[dulmandakh]

@hramos this is still not imported (merged). Could you please check if there is any issue, so I can help to resolve if any.

[LinusU]

Haven't researched this too much, but it seems like the built-in FragmentManager is being deprecated in favor of the one from the support library.

Seems like the direction Android is going towards is to keep many things just in the support library (ref: https://stackoverflow.com/a/39747063/148072), so maybe we should go back to using that?

[hramos]

Nothing wrong with the PR, it just needs to be approved internally before it can land.

[dulmandakh]

incorporated suggestions from @kmagiera in #19741 to make transition from ReactFragmentActivity to ReactActivity easy.

[facebook-github-bot]

hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[janicduplessis]

Yea it looks like we might have gotten this wrong, @LinusU is right and FragmentManager is being deprecated https://developer.android.com/reference/android/app/FragmentManager. Not sure if we could remove the android.app.Activity code paths instead. This would probably be a breaking change though for brownfield apps, in case they don't use AppCompatActivity.

[dulmandakh]

@janicduplessis@LinusU IMHO, even if FragmentManager is deprecated it's not removed so we can still use it. Therefore, removing unnecessary code, used to support older versions RN don't support, will make changes or refactoring easy. Please correct me if wrong.

[LinusU]

Therefore, removing unnecessary code, used to support older versions RN don't support, will make changes or refactoring easy.

The thing is that the concepts of using a FragmentManager and using Fragments is not going away and is still a recommended way to build your applications. It's just that the code path that's being actively developed is being moved from core to the support library.

Therefore I think it would better to remove the code that uses the built-in FragmentManager and switch all the usage over to the support library version. That is the path that Google wants developers to go forward, which is why they are deprecating the FragmentManager.

As @janicduplessis said though, that might be a breaking change, I'm not too familiar at this point to tell...

Anyhow, if we remove all this code, I think we'll just have to reintroduce it soon as the built-in classes are deprecated in the latest version of Android, and will probably be going away soon...

[LinusU]

Looking over the diff again, I think that most changes are really good, just that we should use the support library versions instead of the core ones.

e.g.

Making ReactActivity extends AppCompatActivity is great, and AppCompatActivity is a direct extension of android.support.v4.app.FragmentActivity.

Removing the body of ReactFragmentActivity is great since it, by extension of the last point, will be a subclass of FragmentActivty.

I do not think that we should make these changes though:

• getSupportFragmentManager() -> getFragmentManager()
• android.support.v4.app.DialogFragment -> android.app.DialogFragment
• android.support.v4.app.FragmentManager -> android.app.FragmentManager
• ...

Since this will be going towards deprecated functions.

[LinusU]

Also, one last thing, sorry for the wall of text 🙈

used to support older versions RN don't support

The majority of the development has happened inside of the support libraries version of the fragments. So it will contain bugfixes and features not present on earlier versions of Android. So it's not really binary, is it supported or not, but rather it enhances it on all versions of Android.

e.g. here you can see the Android team not accepting a pull request to fix a bug, since they want people to use the support library instead: android/android-ktx#161 (comment)

I hope that this has shed some light on this ☺️

[dulmandakh]

@LinusU thanks for suggestions, I got the idea.

[dulmandakh]

@hramos maybe, should I split this into smaller, less disruptive PRs?

[dulmandakh]

@janicduplessis@LinusU I have no experience working with brownfield apps, so I have this question. Is it true that brownfield apps must extend either ReactActivity or ReactFragmentActivity to use React Native?

[dulmandakh]

@hramos could you please try to import #20602. I'll try to split this PR into smaller, less disruptive PRs in the future.

[dulmandakh]

After some research and though, it seems that #20602 would be more appropriate to be merged first. Then clean do some cleanups.