-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Update database access modifiers #297
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
Update database access modifiers #297
Conversation
@@ -25,7 +25,7 @@ | |||
* This class implements an array-like collection on top of a Firebase location. | |||
*/ | |||
class FirebaseArray implements ChildEventListener { | |||
public interface OnChangedListener { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one should definitely be changed, I don't know why it's not at least protected.
@puf what do you think? |
@@ -51,10 +51,10 @@ | |||
*/ | |||
public abstract class FirebaseListAdapter<T> extends BaseAdapter { | |||
|
|||
private Activity mActivity; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had some cases in the past where I wanted to use the activity and layout in my concrete implementation. I'm not sure if these still apply, but would prefer to keep these protected for now.
protected int mLayout; | ||
protected Activity mActivity; | ||
Activity mActivity; | ||
final Class<T> mModelClass; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this final?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think everything is good now: easy subclassing, developer happiness, the usual. 😄
@@ -24,8 +24,8 @@ | |||
/** | |||
* This class implements an array-like collection on top of a Firebase location. | |||
*/ | |||
class FirebaseArray implements ChildEventListener { | |||
public interface OnChangedListener { | |||
public class FirebaseArray implements ChildEventListener { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class is now public so that people can extend it and everything is protected
for the same reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh and I forgot to mention: abstraction from ArrayList<DataSnapshot> mSnapshots
is still maintained with this new model.
@TheCraftKid Thanks for catching that! I thought these methods were no modifier originally. Anyway, they're back to normal again. |
I would also vote for it. It would allow developers to implement many usable sub classes that are otherwise not possible without copying the code, which is not an elegant solution... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not getting back sooner. Let's take the "make FirebaseArray public" topic to an issue and continue discussion of the other changes here (if needed).
@@ -24,7 +24,7 @@ | |||
/** | |||
* This class implements an array-like collection on top of a Firebase location. | |||
*/ | |||
class FirebaseArray implements ChildEventListener { | |||
public class FirebaseArray implements ChildEventListener { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted to making it no modifier. If this is the case, I think all of FirebaseArray
's methods should also be no modifier since FirebaseArray
will never be used outside of the package.
FirebaseArray mSnapshots; | ||
protected final Class<T> mModelClass; | ||
protected int mLayout; | ||
protected FirebaseArray mSnapshots; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mSnapshots
field should not be modified by subclasses, hence it should not be accessible. All the pertinent info of snapshots is already available via getItem()
, getRef()
and getRef()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
protected Activity mActivity; | ||
FirebaseArray mSnapshots; | ||
protected final Class<T> mModelClass; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more inclined to make mLayout
private than to make mModelClass
protected. The logic is the same: subclasses should not be modifying these fields as it may lead to unexpected behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Class<VH> mViewHolderClass; | ||
FirebaseArray mSnapshots; | ||
protected Class<VH> mViewHolderClass; | ||
protected FirebaseArray mSnapshots; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as for the other adapter: the fields should not be accessible to subclasses, as those might otherwise modify them. The pertinent information from the fields should already be available through getters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does leave me wondering how multiple ViewHolders and models could be used. Maybe I'll mess around with that today.
I would probably start with a new adapter class for that. The benefit of On Sat, Oct 8, 2016 at 11:11 PM Willie Chalmers III <
|
…-database-access-modifiers # Conflicts: # database/src/main/java/com/firebase/ui/database/FirebaseArray.java # database/src/main/java/com/firebase/ui/database/FirebaseListAdapter.java # database/src/main/java/com/firebase/ui/database/FirebaseRecyclerAdapter.java
@puf this is a very old PR with a small footprint, looks like @SUPERCILEX even updated it recently after #276 was merged. Could you two make a yes/no decision on this and either merge or close it? |
lgtm, but apparently github has a special button for that now. :-) |
Awesome! |
As I was going through the adapters for PR #276, I noticed that the access modifiers were all weird. Is there something I'm not getting or is this change ok?