Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property "priority" not respected #656

Open
funnel20 opened this issue Nov 6, 2020 · 3 comments
Open

Property "priority" not respected #656

funnel20 opened this issue Nov 6, 2020 · 3 comments
Labels
more info required Needs more info to become actionable.

Comments

@funnel20
Copy link

funnel20 commented Nov 6, 2020

We're struggling for days now to receive the events in the correct order.
However, no matter what we do, events are always handled in the wrong order.

We use 2 different event classes:

public class ReadingsDataDidChangeNotification {
}
public class MeterReadingSavedNotification {
    public String token;
    public  MeterReadingSavedNotification(final String token) {
        this.token = token;
    }
}

These are posted from 2 different Classes in following order:

// Send Notification to refresh the RecyclerView:
Timber.d("Send ReadingsDataDidChangeNotification");
EventBus.getDefault().postSticky(new ReadingsDataDidChangeNotification());
// Send Notification to highlight the updated row in the RecyclerView for this meter reading:
Timber.d("Send MeterReadingSavedNotification");
EventBus.getDefault().postSticky(new MeterReadingSavedNotification(meter.token));

For the the receiving class MeterReadingsFragment it's important to always execute the action for ReadingsDataDidChangeNotification first, therefor it's set to a higher priority (2) than MeterReadingSavedNotification (1):

@Override
public void onStart() {
    super.onStart();
    Timber.d("Register EventBus");

    EventBus.getDefault().register(this);
}

@Override
public void onStop() {
    super.onStop();
    Timber.d("Unregister EventBus");

    EventBus.getDefault().unregister(this);
}

@Subscribe(priority = 2, sticky = true, threadMode = ThreadMode.MAIN)   // Highest priority to always be executed first
public void onMessageEvent(ReadingsDataDidChangeNotification event) {
    Timber.d("ReadingsDataDidChangeNotification");

    // Reload RecyclerView:
}

@Subscribe(priority = 1, sticky = true, threadMode = ThreadMode.MAIN)
public void onMessageEvent(MeterReadingSavedNotification event) {
    Timber.d("MeterReadingSavedNotification");

    // Highlight row in RecyclerView and after a delay unhighlight:
}

However, when checking Logcat, the order is always the wrong one; MeterReadingSavedNotification is always called first, no matter what we do:

2020-11-06 11:38:16.059 15332-15332: Send ReadingsDataDidChangeNotification
2020-11-06 11:38:16.062 15332-15332: Send MeterReadingSavedNotification
2020-11-06 11:38:16.117 15332-15332: (MeterReadingsFragment.java:178)#onStart: Register EventBus
2020-11-06 11:38:16.125 15332-15332: (MeterReadingsFragment.java:156)#onResume: Resume
2020-11-06 11:38:16.178 15332-15332: (MeterReadingsFragment.java:324)#onMessageEvent: MeterReadingSavedNotification
2020-11-06 11:38:16.184 15332-15332: (MeterReadingsFragment.java:310)#onMessageEvent: ReadingsDataDidChangeNotification

We have:

  • used different ThreadMode options.
  • switched priority numbers.
  • changed the order of the @Subscribe() events in MeterReadingsFragment.

It seems that priority has no effect at all.
Is this a bug, or do we implement it wrong?

@greenrobot-team
Copy link
Collaborator

@greenrobot-team greenrobot-team added the more info required Needs more info to become actionable. label Nov 24, 2020
@funnel20
Copy link
Author

@greenrobot-team Yes of course.

@xxxifan
Copy link

xxxifan commented Feb 9, 2021

same here.
it seems like sticky events is not run with a priority but a LIFO strategy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
more info required Needs more info to become actionable.
Projects
None yet
Development

No branches or pull requests

3 participants