passsy / compositeandroid Goto Github PK

The implementation seems very heavy when I look at the source code. I stopped being as worried about garbage collection with ART, but it seems like each stage of the Activity or Fragment lifecycle is creating at least 1, if not more objects:

return callFunction("getContext()", new PluginCall<FragmentPlugin, Context>() {
            @Override
            public Context call(final NamedSuperCall<Context> superCall,
                    final FragmentPlugin plugin, final Object... args) {

                return plugin.getContext(superCall);

            }
        }, new SuperCall<Context>() {
            @Override
            public Context call(final Object... args) {
                return getFragment().getContext__super();
            }
        });

I have no measured data on this, but couldn't this be easily implemented without the overhead of multiple function objects created at each method call?

Hi,

I really like this library and it has brought some great improvements into my code. Thanks :-)
However I'm facing a challenge now:

I'm using Dagger2 as a dependency injection framework in my app.
I have a (CompositeAndroid) plugin that needs to have access to some injected classes.
However since plugins are added in the constructor of an Activity (or Fragment) and fields are injected in onCreate() of the root base Activity it is not possible to access injected fields on construction so I cannot pass it as a parameter to the plugin from the Activity.

Example:

abstract class LockableSupportActivityBase : DaggerSupportActivityBase() {

    @Inject
    protected lateinit var preferenceHandler: PreferenceHandler

    init {
        // this throws NotInitializedException on "preferenceHandler"
        addActivityPlugins(LockPlugin(preferenceHandler))
    }

}

Injecting the Plugin itself is also not possible since it has to be added to the Activity in the constructor and the activity also has access to injected properties only right after super.onCreate() (so it's too late).

Example:

abstract class LockableSupportActivityBase : DaggerSupportActivityBase() {

    @Inject
    protected lateinit var lockPlugin: LockPlugin

    init {
        // this throws NotInitializedException on "lockPlugin"
        addActivityPlugins(lockPlugin)
    }

}

Is there a way to work around this or is this a problem that needs a more sophisticated fix?

After I updated my compileSdk and targetSdk to 26 I got the following error in several classes:

error: reference to findViewById is ambiguous
both method findViewById(int) in AppCompatActivity and method findViewById(int) in CompositeActivity match
where T is a type-variable:
T extends View declared in method findViewById(int)

Any idea how to fix it?

Thanks & Regards

new release

Hello, may we rely on support for androidX ? Or this project is closed and not supported anymore?

Some methods have been introduced later. Right now lint doesn't warn for such calls. It warns for AppCompatActivity but not for CompositeActivity. I.e. Activity#isDestroyedI()

The @RequiresApi annotation could be added for such methods. It could be generated by the platform-tools/api/api-versions.xml which is used for lint warnings.

Hi,

in the documentation you wrote about integrating the mosby library as a plugin. Have you done so already? I started doing it but having some trouble to get it done.
Furthermore I'd like to start a repo with common plugins - If you're interested, I would contribute them directly here.

Best
Alex

Hi, as of AndroidX supports lifecycle and Activity result listening (currently rc 'androidx.activity:activity:1.2.0-rc01') it seemed that this library could be replaced. But so far difference is that lifecycle listeners can be add only before onResume() what requires quite some changes to old code bases, when you want for example catch onActivityResult() from dialog (eg. open android file chooser). And dialog is open from menu, which is created by onCreateOptionsMenu().

Am I missing something or is there possibility do add lifecycle listener after onResume?

ComponentActivity
ActivityResultCaller#registerForActivityResult

There is a new Revision 27.0.0 of the support library

Android support 27.0.2 has been there for quite a while. It would be great if we can use the latest version.

Hello,
this is not a bug report, just would like to point it out for other people having same issue.
I'm using this library with GreenRobot's EventBus. On some devices running Android 6 you could get NoClassDefFoundError telling that android.view.DragAndDropPermissions does not exists. This is correct because DragAndDropPermissions has been added on API level 24 and happens because of what explained here under "A java.lang.NoClassDefFoundError is throw when a subscriber class is registered. What can I do?".

Only solution I've found after following every suggestion on EventBus' FAQ has been to modify CompositeAndroid removing from library's classes the override of methods that returns a DragAndDropPermissions. Obviously I know that this could break your library, but I'm not using that methods in my activities.
If anyone could suggest a better method it will be appreciated.

If anyone has the same problem: I've forked this repo and published on jitpack.io a release with the mentioned workaround: https://jitpack.io/#francescopedronomnys/CompositeAndroid/25.3.1-1000

Bye, Francesco

Hi I don't know why but it seams that the library adds a huge amount of memory usage. As soon as I changed to the CompositeActivity the memory usage increased by 80mb.
I'm not very experienced with the memory analytics tool of android studio but I try to figure out what's the problem. If you're interested I can share you more details private.

Best
Alex

Hi,

I stumble across an error when getting the layoutInfalter from a CompositeFragment. Here is the stacktrace:

Fatal Exception: java.lang.IllegalStateException: onGetLayoutInflater() cannot be executed until the Fragment is attached to the FragmentManager.
       at android.support.v4.app.Fragment.getLayoutInflater(Fragment.java:1151)
       at com.pascalwelsch.compositeandroid.fragment.CompositeFragment.super_getLayoutInflater(CompositeFragment.java:1310)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$7.call(FragmentDelegate.java:204)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$7.call(FragmentDelegate.java:197)
       at com.pascalwelsch.compositeandroid.fragment.FragmentPlugin.getLayoutInflater(FragmentPlugin.java:149)
       at com.pascalwelsch.compositeandroid.fragment.FragmentPlugin.getLayoutInflater(FragmentPlugin.java:1269)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$7.call(FragmentDelegate.java:202)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$7.call(FragmentDelegate.java:197)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate.getLayoutInflater(FragmentDelegate.java:208)
       at com.pascalwelsch.compositeandroid.fragment.CompositeFragment.getLayoutInflater(CompositeFragment.java:163)
       at android.support.v4.app.Fragment.onGetLayoutInflater(Fragment.java:1101)
       at com.pascalwelsch.compositeandroid.fragment.CompositeFragment.super_onGetLayoutInflater(CompositeFragment.java:1710)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$32.call(FragmentDelegate.java:769)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$32.call(FragmentDelegate.java:762)
       at com.pascalwelsch.compositeandroid.fragment.FragmentPlugin.onGetLayoutInflater(FragmentPlugin.java:528)
       at com.pascalwelsch.compositeandroid.fragment.FragmentPlugin.onGetLayoutInflater(FragmentPlugin.java:1456)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$32.call(FragmentDelegate.java:767)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate$32.call(FragmentDelegate.java:762)
       at com.pascalwelsch.compositeandroid.fragment.FragmentDelegate.onGetLayoutInflater(FragmentDelegate.java:773)
       at com.pascalwelsch.compositeandroid.fragment.CompositeFragment.onGetLayoutInflater(CompositeFragment.java:538)
       at android.support.v4.app.Fragment.performGetLayoutInflater(Fragment.java:1132)
       at android.support.v4.app.Fragment.getLayoutInflater(Fragment.java:1117)
       at com.my.app.features.event.EventDetailFragment.attachHeader(EventDetailFragment.java:66)
       at com.my.app.features.event.EventDetailFragment.lambda$beforeInflatingForms$0$EventDetailFragment(EventDetailFragment.java:91)
       at com.my.app.features.event.EventDetailFragment$$Lambda$0.doInUIThread(Unknown Source)
       at com.arasthel.asyncjob.AsyncJob$1.run(AsyncJob.java:46)
       at android.os.Handler.handleCallback(Handler.java:751)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:154)
       at android.app.ActivityThread.main(ActivityThread.java:6776)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1496)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1386)

I dig a bit to find out how this was happening and I found out that the CompositeFragment is using a deprecated method of the Fragment class. It is using getLayoutInflater(Bundle savedFragmentState) instead of getLayoutInflater(). Maybe this won't solve the issue but I think this it still a point to figure out.

Quoting the javadoc of this function:

* @deprecated Override {@link #onGetLayoutInflater(Bundle)} or call
* {@link #getLayoutInflater()} instead of this method.

Hope this help.

Not sure I really understood how this is working. I want to use some methods that needs a context inside my FragmentPlugin (such as getString(), etc.). I tought I would simply use getFragment().getString() or getCompositeDelegate().getString() but both getFragment() and getCompositeDelegate() returns null.

How should I refer to the hosting fragment? Should I add it through my default constructor?

Thank's !

I would like use support library version 25.0.0 with CompositeAndroid but I got error:

Error:Could not find com.pascalwelsch.compositeandroid:activity:25.0.0.

Can you update CompositeAndroid to 25.0.0 ?

A new support library is available

Hi,

Encouraged by your usecase reccomendation:

• gradually add libraries like Mosby (without extending from a MvpActivity) or Flow to your Activities when you need it

I have started extendingActivityPlugin in way that will allow me to have Mosby presenter attached to it.

I have noticed that in ActivityPlugin there is onRetainNonConfigurationInstance method, although the documentation states clearly:

Retain all appropriate fragment and loader state. You can NOT
override this yourself! Use {@link #onRetainCustomNonConfigurationInstance()}
if you want to retain your own state.

and moreover the onRetainCustomNonConfigurationInstance method is missing there.

I wanted to override the onRetainCustomNonConfigurationInstance method in way it is done in Mosby MvpActivity to support Presenter lifecycle, but as I said, there is no such method in ActivityPlugin. Have you tried using Mosby with CompositeAndroid? Shall I do it in some other way?