Skip to content

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

Merged
merged 23 commits into from
Nov 29, 2016
Merged

Update database access modifiers #297

merged 23 commits into from
Nov 29, 2016

Conversation

SUPERCILEX
Copy link
Collaborator

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?

@@ -25,7 +25,7 @@
* This class implements an array-like collection on top of a Firebase location.
*/
class FirebaseArray implements ChildEventListener {
public interface OnChangedListener {
Copy link
Collaborator Author

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.

@samtstern
Copy link
Contributor

@puf what do you think?

@@ -51,10 +51,10 @@
*/
public abstract class FirebaseListAdapter<T> extends BaseAdapter {

private Activity mActivity;
Copy link
Contributor

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;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this final?

Copy link
Collaborator Author

@SUPERCILEX SUPERCILEX left a 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 {
Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@SUPERCILEX SUPERCILEX mentioned this pull request Oct 4, 2016
1 task
@SUPERCILEX
Copy link
Collaborator Author

@TheCraftKid Thanks for catching that! I thought these methods were no modifier originally. Anyway, they're back to normal again.

@MaciejCiemiega
Copy link
Contributor

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...

Copy link
Contributor

@puf puf left a 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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I so far consider FirebaseArray to not be a part of the FirebaseUI public API. It's fine to discuss whether my consideration is valid, but that discussion is best had in an issue and not in a PR. See for example #206 and #337 (which I haven't responded to yet).

Copy link
Collaborator Author

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;
Copy link
Contributor

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().

Copy link
Collaborator Author

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;
Copy link
Contributor

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.

Copy link
Collaborator Author

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;
Copy link
Contributor

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And done.

Copy link
Contributor

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.

@puf
Copy link
Contributor

puf commented Oct 9, 2016

I would probably start with a new adapter class for that. The benefit of
reusing code that you get by inheriting from the existing
FirebaseRecyclerAdapter may not outweigh having to work around the
difference in implementation.

On Sat, Oct 8, 2016 at 11:11 PM Willie Chalmers III <
[email protected]> wrote:

@TheCraftKid commented on this pull request.

In
database/src/main/java/com/firebase/ui/database/FirebaseRecyclerAdapter.java
#297:

 protected int mModelLayout;
  • Class mViewHolderClass;
  • FirebaseArray mSnapshots;
  • protected Class mViewHolderClass;
  • protected FirebaseArray mSnapshots;

This does leave me wondering how multiple ViewHolders and models could be
used. Maybe I'll mess around with that today.


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#297, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA3w36aplKJapcqPAfKWq63IXyCxozmuks5qyAccgaJpZM4J51Xr
.

…-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
@SUPERCILEX SUPERCILEX changed the base branch from master to version-1.0.0-dev November 2, 2016 00:07
@SUPERCILEX
Copy link
Collaborator Author

SUPERCILEX commented Nov 2, 2016

@puf I've updated this PR since #276 was merged. What do you think?

@SUPERCILEX SUPERCILEX changed the base branch from version-1.0.0-dev to master November 5, 2016 05:42
@samtstern
Copy link
Contributor

@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?

@puf
Copy link
Contributor

puf commented Nov 29, 2016

lgtm, but apparently github has a special button for that now. :-)

@samtstern samtstern merged commit 8667f35 into firebase:master Nov 29, 2016
@SUPERCILEX SUPERCILEX deleted the update-database-access-modifiers branch November 29, 2016 16:48
@SUPERCILEX
Copy link
Collaborator Author

Awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants