Skip to content

Method to update Query in Firebase and Firestore Adapters. #1660

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 17 commits into from
Aug 1, 2019

Conversation

PatilShreyas
Copy link
Contributor

This PR Implements a method to change/update Query in both Firebase as well as Firestore Adapters. (Issue #1614)

@PatilShreyas PatilShreyas requested a review from samtstern as a code owner July 20, 2019 14:27
@PatilShreyas
Copy link
Contributor Author

@samtstern There are some Auth lint errors exists that's why Trivis CI failed.

@PatilShreyas
Copy link
Contributor Author

@samtstern These are errors.

  The first 3 errors (out of 84) were:
  /home/travis/build/firebase/FirebaseUI-Android/auth/src/main/res/layout/fui_auth_method_picker_layout.xml:11: Error: This view is not constrained horizontally: at runtime it will jump to the left unless you add a horizontal constraint [MissingConstraints]
      <me.zhanghai.android.materialprogressbar.MaterialProgressBar
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /home/travis/build/firebase/FirebaseUI-Android/auth/src/main/res/layout-land/fui_auth_method_picker_layout.xml:12: Error: This view is not constrained horizontally: at runtime it will jump to the left unless you add a horizontal constraint [MissingConstraints]
      <me.zhanghai.android.materialprogressbar.MaterialProgressBar
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /home/travis/build/firebase/FirebaseUI-Android/auth/src/main/res/layout/fui_confirmation_code_layout.xml:9: Error: This view is not constrained. It only has designtime positions, so it will jump to (0,0) at runtime unless you add the constraints [MissingConstraints]
      <me.zhanghai.android.materialprogressbar.MaterialProgressBar
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  The first 3 errors (out of 4) were:
  /home/travis/build/firebase/FirebaseUI-Android/app/src/main/res/layout/auth_method_picker_custom_layout.xml:81: Error: This namespace declaration is redundant [RedundantNamespace]
      <com.firebase.ui.auth.util.ui.SupportVectorDrawablesButton xmlns:android="http://schemas.android.com/apk/res/android"
                                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /home/travis/build/firebase/FirebaseUI-Android/app/src/main/res/layout-land/auth_method_picker_custom_layout.xml:98: Error: This namespace declaration is redundant [RedundantNamespace]
      <com.firebase.ui.auth.util.ui.SupportVectorDrawablesButton xmlns:android="http://schemas.android.com/apk/res/android"
                                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /home/travis/build/firebase/FirebaseUI-Android/app/src/main/res/values/strings.xml:26: Error: Duplicate string value Google, used in logo_google, providers_google and tos_pp_google [DuplicateStrings]
      <string name="providers_google">Google</string>
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /home/travis/build/firebase/FirebaseUI-Android/app/src/main/res/values/strings.xml:46: Duplicates value in providers_google
      /home/travis/build/firebase/FirebaseUI-Android/app/src/main/res/values/strings.xml:50: Duplicates value in providers_google

@samtstern samtstern added this to the 5.0.1 milestone Jul 23, 2019
Copy link
Contributor

@samtstern samtstern left a comment

Choose a reason for hiding this comment

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

@PatilShreyas thanks for this! Just a few comments.

*
* @param newQuery is a new updated query.
*/
public abstract void updateQuery(@NonNull Query newQuery);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be added in BaseObservableSnapshotArray instead? It seems a bit strange that this would be the only method defined on ObservableSnapshotArray

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because BaseObservableSnapshotArray is inherited in both ObservableSnapshotArray of Firestore as well as Firebase realtime database too. And most importantly, the Query class of both databases are not the same.

  • Firestore Query Class: com.google.firebase.firestore.Query
  • Firebase Query Class: com.google.firebase.database.Query

Copy link
Contributor Author

@PatilShreyas PatilShreyas Jul 23, 2019

Choose a reason for hiding this comment

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

If we add this method in BaseObservableSnapshotArray then Query parameter will be different for them. What else can we do here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would say let's just not make this part of the base class at all, it can just be something implemented in each of the Array classes.

That will also allow us to give the indexed version a better name: updateKeyQuery()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have instantiated FirestoreArray by its superclass references in Adapter classes. So, Will it be fine them to be instantiated as Array classes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fine 😃. Okay then 👍 .

Copy link
Contributor Author

@PatilShreyas PatilShreyas Jul 25, 2019

Choose a reason for hiding this comment

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

I have some questions.

  • If I instantiate mSnapshots as FirebaseArray' as then how to take care of FirebaseIndexArray`?
  • How could we know that when to call updateQuery() or updateKeyQuery()?
    In FirebaseRecyclerAdapter if I create an instance of FirebaseArray then we can't instantiate FirebaseIndexArray. How to do it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh no that is a problem ... any ideas? I don't know why I am so opposed to adding updateQuery to the ObservabeSnapshotArray classes ... it just feels wrong. But maybe that is the best way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I also thought a lot about it before implementation in ObservableSnapshotArray class. But I can't find anything helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had one idea. But that idea was not much good to implement. Means, it's not good practice to implement. I had idea to use instanceof to check whether it's instance of Firebase array or index array. We will check it in our method and by casting we will call array class method. That was the idea.

@@ -25,6 +26,7 @@ public boolean areItemsTheSame(@NonNull DataSnapshot oldItem,
return oldItem.getKey().equals(newItem.getKey());
}

@SuppressLint("DiffUtilEquals")
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this lint suppression added in this PR when nothing else about this file changed?

Copy link
Contributor Author

@PatilShreyas PatilShreyas Jul 23, 2019

Choose a reason for hiding this comment

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

Because it caused an error when I run the command gradlew assembleDebug proguard-tests:build check

When I checked that class, it's showing me the red line under return statement showing a suggestion to add this line.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok I am fine with this, although I bet if we revert the unrelated changes in this PR, this will go away.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh! Okay.

repositories {
jcenter()
}

plugins {
`kotlin-dsl`
kotlin("jvm") version "1.3.41"
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain why we need all of these kotlin changes in this PR? Are they related?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No. I just updated it as it's on my system.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok let's revert these changes since they are not related to the feature.

@@ -1,5 +1,5 @@
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.1-all.zip
distributionUrl=https\://services.gradle.org/distributions/gradle-5.1.1-all.zip
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's also revert this, this could be a big change and I want to do it separately (when I have time to verify the release process with gradle 5)

PatilShreyas and others added 4 commits July 25, 2019 05:56
Change-Id: I3d6465a15171b2cd5629d93e5745585552129d2d
Change-Id: Iacc39b3b49d1b6e5ce753ee0ab3a11ac975b9de0
@samtstern
Copy link
Contributor

@PatilShreyas ok I did some thinking and experimenting. First I found better words to explain myself :-) the reason I am not comfortable with updateQuery on ObservableSnapshotArray is because that class previous did not know that Query existed at all.

Second I think it may be better to structure this as setOptions where instead of just replacing the query you replace the whole options object you used to start the Adapter. Here's an example of how that might look (for RTDB only):
PatilShreyas#2

What do you think?

@PatilShreyas
Copy link
Contributor Author

Right @samtstern!

@PatilShreyas
Copy link
Contributor Author

PatilShreyas commented Jul 30, 2019

@samtstern I have merged your PR and make changes as you suggested. Also implemented in Firestore adapter. Also, tested updateOptions on adapter.

@samtstern
Copy link
Contributor

@PatilShreyas sorry I missed your last comment! Thanks for working with me on this, LGTM.

@samtstern samtstern merged commit d7aec38 into firebase:version-5.0.1-dev Aug 1, 2019
@PatilShreyas
Copy link
Contributor Author

Anytime! Thank you!

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.

2 participants