This CL fixes an issue about ternary expressions where
a ternary expression would be evaluated with its last
evaluated dependency. This would create a problem where
ternary expressions would not be evaluated if other branch
of the conditional is chosen, This bug is fixed by checking
outher flags such that we'll still calculate it together
if all dependencies are behind the same flag vs we'll
calculate it independently if its dependency flags are different.
This CL also improves the generated code in two ways:
- When there is an if inside if, we don't add flag check (the if)
if all of its conditions are covered in the parent if.
- I replaced flag names with binary values. This looks more
readable then generated names.
Bug: 20073197
Change-Id: I9d07868206a5393d6509ab0a205b30a796e11107
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
setTag(id, val) leaks on versions before ICS. When the
minimum SDK is before ICS, setTag(val) must be used
for bindings. However, this prevents the developer from
using the tag for his or her own purposes. Therefore,
if the minimum SDK is ICS and greater, setTag(id, val)
is used.
Change-Id: I46327084bde4bafc05a64f82ad5ebcf710820ecc
By having a concrete implementation of DataBinderMapper in the
library and then stripping it out, the generated DataBinderMapper
may be instantiated without reflection.
We want to get all Views with IDs in the Binding to save the
developer effort in calling findViewById.
Change-Id: Ib7dd85ae9ecc0fd31b235364c0eadc2303dd1780
Bug 19985005
Because the generation of Binding files created @Bindable
annotations, the BR file generation had to wait until a
second annotation pass. This caused errors to be generated
that were later cleared, causing confusion. I moved the
BR file generation to the same annotation processing stage
that generates the Binding files to clear up the error
generation.
TODO: merge the annotation processing stages so that there
is less cross-talk between annotation processors.
make needs some means for copying resource files, stripping them,
and generating the intermediate java/xml files. This calls into
the same code used by the gradle plugin to do it. When aapt
work has completed, this can be removed entirely and replaced
by a simple shell script.
Change-Id: Ie6e1fda8fa27892cc74a13f1404ab064f6210270
Bug 19643846
Bug 19627630
Also made it so that setter methods will auto-cast from Object
when necessary. This is useful for heterogenous map objects
where .get(id) may return an Integer or a String or a Drawable.
Change-Id: Iacfd739ea4938f38b584a8eab9193f1fd4071df1
This CL adds support for building multi module apps
with proper context.
For library modules, we only generate base classes in the initial
compilation. We also generate a temporary BR file which does
not have final methods.
When final app is being generated, all layout binders, adapters
and Bindable information gets merged and all final classes
are generated in their appropriate packages.
This CL also adds support for Test runs and any
number of build variants.
Bug: 19714904
Change-Id: I9b50b54db05f3fa206eec33709d43c2ac94a9e5e
Bug 19627511
Bug 19709604
Changed generated classes to end with "Binding" instead of "Binder"
to avoid confusion with Android Binders.
Removed DataBinder class and moved the important aspects of its
contents to ViewDataBinding.
Improved mapping of Views in included layouts. Avoid traversing
included layouts while looking for bound expressions.
Change-Id: I1f28093b0792d5428d07192f1fc458a5b4b788b2
This CL updates project to use a local maven repo.
(local as in near source code w/ relative path).
This is necessary to have multiple versions of the
project on the same computer also provides better
separation.
I also moved integration tests to depend on these
because we cannot build the compiler and test app at
the same project.
I've changed library plugin's jar to be a separate
upload task to avoid some build issues in TestApp
when we release a @jar and @aar with same group and
artifact ids.
This CL also adds some convenience methods to
gradle build script to run all tests, prepare maven
repo, run integration tests etc. These were needed
to do CI.
Bug: 19718690
Change-Id: I3c80e09fe7c8c2780ca00c3e9b9ba99a162531cf
This CL removes java 1.7 code so that we can easily integrate
w/ Idea.
It also partially removes dependency on ModelAnalyzer for
interface generation so that we can call it from the Idea
plugin.
Change-Id: Id7616987f5660911e951ddf20dacd4f407dacbd9
In data binding, setting an attribute actually means calling a method, which might be
an issue if the method is added after a certain API.
This CL introduces a change which will check called methods per api and add necessary
API check code to avoid calling those methods in older platforms.
This CL also resurrects the Java Model Analyzer (in testing) and also fixes compiler tests.
Bug: 19593398
Change-Id: I0da4194625231cf43125e1b43338069e7d191eb9
findType did not support user-defined imports, so casting,
for example, of Foo<String> didn't recognize Foo or String.
This also will import java.lang.* by default.
Renamed Model* classes to Annotation*
Renamed Reflection* classes to Model*
Removed Class* classes -- they are no longer needed.
The names were confusing. I think this is better.
ClassAnalyzer uses normal reflection. We intend to move
to an Annotation Processor and possibly an Android Studio
plugin version of type interaction as well. This abstracts
the type interaction to prepare.
Change-Id: I2b95ea9074bca7e3053aeadcd3692dffe93b41d6
If a field is final, we know it cannot change thus cannot include it in dependency
logic. Unfortunately, observable final fields can invalidate themselves so
we should consider them dynamic.
Bug: 19299279
Change-Id: I643377f7faea6a7b0e858ee55d22318b3fc5898e
