Arch change - use event mechanism to synchronise fragments

[deftelf]

So far to avoid bringing in too many dependencies we havne't had a separate event bus to trigger syncs between note edit/compose and note list, relying on onActivityResult to do it. This is now causing problems:

1. Using onActivityResult doesn't work between fragments on the same screen (as a tablet layout would have) and would require extra tablet-specific code to do the syncs
2. Going straight to a NoteAcitivty without creating it from NoteListFragment.startActivityForResult means NoteListFragment never gets the result code.

Simplest way to clear this problem is to integrate EventBus https://github.com/greenrobot/EventBus, and have syncs handled like that. The SyncManager and NoteFragment would both trigger a NoteFragmentChanged event at the point that they have updated the disk state. This could be a sticky event, that contains the timestamp. Any fragment that subscribes to it would get the most recent changed timestamp, and could compare it with the last time it ran notifyDataSetChanged, to determine if it needs to again. startActivityForResult can then be removed.

There may be other mechanisms that might be better, discussion here for any that have an opinion.

[noelbautista91]

This would be nice to have before implementing #64, #54, and #59.

[noelbautista91]

As of today, #71 DOES sync between Fragments (using the sync manager, correct me if I'm wrong).

On a side note, you could also use BroadcastReceivers

I like the explanation from this SO discussion.

From the same link:

For message broadcasting between UI- and core-layer I would use the BroadcastReceiver-approach that lets you decouple your UI layer from the logic layer.

As a second side note: given that we've shown that fragments could communicate already via SyncManager, is this feature still required? Do we have other views that need to communicate?

[deftelf]

Shudder internal BroadcastReceivers. I've seen a project that does events like that (the android way), and it's horribly over engineered and boilerplatey...

I think we can close this if we're sharing both fragments across the same activity for #71