History log of /frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
af146d6a8c0efcf5682d14047c06866a5548f78f 22-Jan-2016 Yigit Boyar <yboyar@google.com> Update data binding to kotlin beta 4

I've also run some cleanup inspections to keep codebase
more up to date.

Bug: 26738574
Change-Id: I02aa43157cad858c0ea60dd41a22150e3cf2cfa1
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
d3f2b9229472c9dae9bf4ae8b3e2d653b5653b01 17-Sep-2015 George Mount <mount@google.com> Two-way binding

Bug 1474349
Bug 22460238

This adds two-way data binding for those attributes
on Views that also have event listeners for them.
General use is also supported, but event listeners
are required to notify when those properties change.

Change-Id: Iedc66a604257930265f9d661f69658a0a0c3208b
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
4ba16229a40e9758db86d4fb1df5119fdcb8aa2a 22-Dec-2015 Deepanshu Gupta <deepanshu@google.com> Change from commons-lang3 to guava

Change-Id: I1a18e06af7bf2d65228f1491663b6e096a9538ed
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
e61d1cc710803cdf0ab4f2aca3d18c46949758a9 04-Dec-2015 Yigit Boyar <yboyar@google.com> Fix compiler tests setup, upgrade public known version

Change-Id: I91babbab13cd00d4f0df149c997349fca0aed80b
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
9784c9aaedeb863018f5fcaa0a598e8e2f8ed2f3 13-Oct-2015 Yigit Boyar <yboyar@google.com> Data binding as studio dep + java6

This CL gets rid of the gradle plugin and instead provides
DataBindingBuilder for the gradle plugin to directly use.

Now, everything that is deployed via SDK Manager (lib and adapters)
are included as prebuilts so that we avoid accidently changing
them w/o an SDK manager release.

There is still work to do:
> re-enable proguard for externel dependencies
> release a batch to ensure everything works

Bug: 22516688
Change-Id: I83ace15bd6d3d23bf5b4ad850f36453dd23ebd43
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
876ba3272f17ed891ea455e7dd526d44e468757c 17-Oct-2015 Yigit Boyar <yboyar@google.com> Fix broken test.

The test was using a sample which is not compliant with
JavaBeans notation. It did not fail before because these
tests are not compiled as data binding apps

Change-Id: Ifad7a1d204d6e6e4b227bc68ccabdb650d73dec6
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
09aeb26073fc8a98263806f53e44819ebe5046c6 09-Oct-2015 Yigit Boyar <yboyar@google.com> Handle constant predicate in ternary

If a ternary expressions's predicate is constant, we would never evaluate it
which means we would never evaluate the ternary unless some other expression
depends on it.

This CL changes ExprModel to move such constant expressions into pending list
so that they can be evaluated + necessary flags are set.
We can actually avoid this process by replacing TernaryExpression with something
else when this case is detected but that would be a bigger change and not safe
shortly before the release.

Hopefully, codegen logic will be refactored into a more well defined process.

Bug: 24768154
Change-Id: I0918568414b64d64f070978f1f8e77cc3b6c85fd
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
eebcbdd5d35e56a2c8ef37feeb65df46130d001d 26-Aug-2015 Yigit Boyar <yboyar@google.com> Fix the bug about marking expressions as read early

@{obj4.text}
@{obj4.useHello ? obj4.text : `hello`}

This case was broken and would not re-read obj4.text if
only obj4.useHello is invalidated. It was partially fixed in
Change-Id: Id449c8819b8dc0301a7ab893002478914780d480 but
but it was bringing it down to exact equality which would
mean we could fail to mark sth as read.

The coverage logic we use in expressions when marking them
as read was giving false positives, which results in
marking expressions as read before they are fully read.
This CL fixes that bug. The safe fix introduces some false
negatives when a conditional is behind another conditional.
We can address this post v1.

There was also another bug about setting conditional flags
even though the ternary does not need to be calculated.

@{obja.boolMethod(a)}
@{a ? objb.boolMethod(b) : objc.boolMethod(c)}

When obja is invalidated, it would re calculate the second
binding expression too even though it is never used (because
that expression is not invalidated). The re-calculation would
happen because we would calculate the value of `a` and set
the conditional flags w/o checking invalidation.

This would result in unnecessary calculations. I've also fixed
it for first degree where the ternary is not under another
ternary. The proper fix would requires bigger effort, post V1.

bug: 22957203
Change-Id: Ib73f31eac358f2ad7652395a021baaa93b79adf7
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
e52882df6130221462bf07f5f2b52de5c4b0f8de 30-Jul-2015 George Mount <mount@google.com> Move toCode to Expr classes.

It turns out that toCode as part of Java is just
about as readable as in kotlin and it makes much
more sense than using instanceof (equivalent).

Change-Id: Ic2a0de5c4376dafa487d048e6a9420fab9e7f22a
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
d615f15f0f0cc4c4de7570119d181e13d44e708a 05-Aug-2015 George Mount <mount@google.com> Fixed: conditional expression not always waiting for its dependencies.

Bug 22957203

Some conditional expressions were not waiting for all of their
dependencies to be evaluated before evaluting the expression.

Change-Id: Id449c8819b8dc0301a7ab893002478914780d480
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
c1560e6b00b398867da12fbdc5a1fcd1d50b801c 25-Jun-2015 Yigit Boyar <yboyar@google.com> Carry over location information from parser to annotation processor

This CL changes LayoutParser to use Antlr which provides us the location
information. This information is now serialized inside the bundle so
that we can read it in the annotation processor, enabling better error
logs with location information.

Bug:21953001
Change-Id: If9b5cf2f87598a609ddf77235decc17098a46a6b
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
2611838bffef5a009ca71e3e9e59a93f29b098ed 24-Jun-2015 Yigit Boyar <yboyar@google.com> Remove guava from compiler

This CL removes all dependency from guava and replaces it w/ either plain
java or some utilities.

Bug: 22047836
Change-Id: I94be54ed992ab6b5f27c47a8cf400ae60aef02f8
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
ec2f3896c21a504b464bf591cdb45b62692b6760 10-Jun-2015 Yigit Boyar <yboyar@google.com> Improve static method / field handling

Previously, we would allow access to static fields via instance
variables but it would not work for methods. Moreover, the behavior
was not exactly the same with how java handles it. In java, the
instance can be null but our binding code would not evaluate it
if instance is null.

This CL fixes these bugs by adding static resolution support to
methods and replacing their variable identifiers with static
identifiers while the method is being resolved so that the rest
of the system is still consistent.

Bug: 20412284
Change-Id: Id97ce564c312b97d5a0e60d7d7a5bbd06b131071
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
24ff3c01534a5e4dc9f65796009debe7fd87c1be 20-May-2015 Yigit Boyar <yboyar@google.com> Merge "Handle inter-expr dependencies properly"
7b07818f07c28c6dec34ca2a9ab5f61e86afb493 20-May-2015 Yigit Boyar <yboyar@google.com> Handle inter-expr dependencies properly

We had a bug where we would never be able to solve a case if there
are two expressions that trigger a circular dependency.

a ? b : c
b ? a : d

We actually had some logic to partially elevate conditional
dependencies but there were two issues with it:

* LayoutInflator was caching shouldReadFlags permanently
* There was a bug in how we resolve whether all potential evaluation
paths are covered. (we were not using a cloned bitset but rather
updating the original).

I've fixed these two issues and added logic to partially elevate
conditional expressions if they cannot be marked as fully read.

Bug: 21324645
Change-Id: I779afb6dae48920196404d3cfbb5f8774686404d
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
c96847768305d83c6bc4919432af9bd9bfe4c08e 20-May-2015 George Mount <mount@google.com> Fix String.format expression.

An expression @{String.format("%s", "test")} was failing
for two reasons: the L.d was doing string concatenation
and String wasn't imported and considered a StaticIdentifier.

Change-Id: I67b4c880f1e147a5c1aac15b3b845d4112c6d00b
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
8533f27db6c31b0c295ae62d314dbf07ea640571 19-May-2015 Yigit Boyar <yboyar@google.com> Properly handle constant binding expressions

Previously, we would assign each binding expression a flag id even
if it is constant. This was necessary to be able to implement
invalidateAll.

Later, we've changed how invalidateAll works and assigned it a separate
flag. Unfortunately, we were still incrementing ids for such binding
expressions, causing index out of bounds exceptions during code generation
in certain situations.

This CL fixes that bug and does not add flags to constant binding expressions
anymore.
Bug: 21284295
Change-Id: I114bf34520d0b246426ce7d45b8c511cf6709778
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
019c36b97c7c172ac03997f6bf170e65b2ed7fe4 17-Apr-2015 Yigit Boyar <yboyar@google.com> Fix how final fields are handled

There was a bug in Expression analyzer where if a field is final,
it would return dynamic=false although its parent is dynamic.

This CL changes that behavior such that if the parent of a field
access is dynamic, then field access is dynamic unless it is
static & final.
If parent is not dynamic, (e.g. android.view.View) field is
dynamic if an only if itself is dynamic.

This CL also fixes another bug where if you have a bunch of
expressions none of which can be invalidated, there would not
be any flags to set thus we would not generate proper if statements.
We were resolving tree properly but code-generation never worked
in that situation. To overcome this issue, since there should always
be a way to invalidate all bindings, I've added a flag to invalidate
all, which is automatically included in each invalidate flag set.
This does not bring any serious cost because we have flag inheritance
in the generated code.

I've also removed some code from LayoutBinderWriter that may create
duplicate names. This was failing a test where a variable and View
were given the same names. I changed these name uniqueness to be
scope based so that we can create most readable w/o sacrificing
correctness.

Bug: 20341011
Change-Id: I0e98a5e28f250c36ae5de306f5ed99adffd20b59
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
ee7586713d68806b556a425cbebf007a56261ff3 17-Apr-2015 Yigit Boyar <yboyar@google.com> Add 3rd party licenses to fatJar

This CL adds 3rd party licenses to compiler-fatJar so that
we can use it in our build process w/o maven dependency.

It also removes dependency on SDK folder for api level lookup
by shipping versions.xml file with the bundle.

It adds a new gradle task, preparePrebuilds, which bundsles
all necessary builds to a prebuild folder which should be
committed. These pre-builds will be used by the makefile to
support make builds.

Bug: 19945740
Change-Id: I0bba72bbb13770aba94317301217ddd842211e2d
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
74f72d77b1db2b78ee6422da2ec94de12edcb6dc 27-Mar-2015 Yigit Boyar <yboyar@google.com> Fix bugs related to how we handle Ternary ops

This CL fixes two bugs.
1) When a Ternary operation was inside another operation, we were
not handling dependecies properly and model would think that
the container expression can be evaluated before Ternary is evaluated,
eventually causing an exception in code-gen because Ternay is not
calculated yet.

2) This also fixes another bug where when ?? is used, we would put
ifTrue and ifFalse statements in wrong order and eventually evaluate
!??.

Bug: 19939148

Change-Id: I3e1d2bee172e47412bb8ef9e7c785aef47337155
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java
fead9ca09b117136b35bc5bf137340a754f9eddd 23-Mar-2015 George Mount <mount@google.com> Move to package android.databinding.
/frameworks/data-binding/compiler/src/test/java/android/databinding/tool/expr/ExprModelTest.java