* Move firebase user agent logic to a separate class.
* FIRAppTest: prefix some tests with the tested method names
* FIRAppTest: user agent new fields tests
* New user agent field added.
* Headers
* API docs
* ./scripts/style.sh
* nullability fix
* Move environment info methods to GoogleUtilities
* GULAppEnvironmentUtilTest
* GULAppEnvironmentUtil swift tests
* FirebaseApp user agent swift flag test
* ./scripts/style.sh
* Cleanup CoreDiagnostics
* Nullable device model
* FIRCoreDiagnosticsTest fix
* Merge fixes
* Fix import
* rename
* Cleanup GUL imports (since all headers are public now)
* update nanopb from 0.3.9.5 to 0.3.9.6
This fixes issues building firestore SDK with Python3.
Interestingly, latest version 0.4.2 still errors during the build
but 0.3.9.6 works. The git commit for this fix in nanopb
https://github.com/nanopb/nanopb/commit/63f8e5e4946a5f8f0211b454bd37187871c3d023
* Update generated sources
* updating just nanopb dependency version
nanopb updated from 0.3.9.5 to 0.3.9.6
(pod version 1.30905.0 to 1.30906.0)
* Add missing source specifier
* Generated files for protos using nanopb 0.3.9.6
* removed unnecessary whitespaces in files generated by protoc
* using more qualified relative paths for header includes
* Changelog
Co-authored-by: Marek Gilbert <mcg@google.com>
Co-authored-by: Paul Beusterien <paulbeusterien@google.com>
* remove ios 8 related check as our sdk minimum support is iOS 9 now;
* update changelog
* remove FIRInstanceIDURLQueryItem
* move appid to constant class
* update changelog
* fix clang format and typo in changelog
* Definition is currently in an "unreleased" extension to FIRServerValues
* Tests are added to FData.m (integration tests)
* Some tests are renamed to make it clear that ServerValues != timestamps
* Functions that resolve server values now need access to any existing snapshot. This is done with lazy evaluation as described below:
Based on fix https://github.com/firebase/firebase-js-sdk/pull/2499
to bug https://github.com/firebase/firebase-js-sdk/issues/2487
Micro-benchmarking showed that N writes in succession led to N^2
performance when calculating the resolved write tree for those
writes (thankfully only at the subpath in this SDK). Lazy evaluation
of current data matches the optimization in JS that mitigated a
20% performance regression.