So just the virtual DOM part of react
Finally finished with exams :)
Great! Feel free to share or ask any questions. Meanwhile myself and Anna try to build a "real" android app using Anvil, which is an MQTT client that uses all support libraries, recycler view, toolbars, nav drawer and other over-complicated heavyweight gifts from google. However it goes better than I initially thought.
wow.... recyclerview now supports drag and swipe via the new ItemTouchHelper. explained really short here: https://youtu.be/LqBlYJTfLP4?t=40m23s (little bit offtopic ;) )
docs can be found here: https://developer.android.com/reference/android/support/v7/widget/helper/ItemTouchHelper.html
Basically bansa
my mvvm architecture with anvil is online: https://github.com/BenedictP/NotesMVVM
over the weekend I'm going to translate the readme (and fix the "uml" picture ;) )
over the weekend I'm going to translate the readme (and fix the "uml" picture ;) )
I want to make a TodoMVC with Anvil, because I love the mindset of functional + composable components for Views (over Fragments 😒), but I need some examples
Or docs
Just found this: https://github.com/zserge/anvil-kotlin-demos#demo-04-adapters-source
Never mind 😅
i.e. Mount, Attr, Node etc?
My idea is to separate the creation of the DOM from the rendering part
Make it a two part system
I've been exploring JS approaches to DOM rendering and most of them seem to have this feature
Hey there. I'm trying to render a textInputLayout, but my app keeps crashing during the second render-cycle with the following exception: java.lang.IllegalArgumentException: We already have an EditText, can only have one
The view looks like this:
DesignDSL.textInputLayout(() -> {
DSL.layoutGravity(DSL.TOP);
DesignDSL.hint(getContext().getString(R.string.connect_hint_port));
DesignDSL.textInputEditText(() -> {
DSL.inputType(InputType.TYPE_CLASS_NUMBER);
DSL.enabled(state.connect().state() != State.CONNECT_STATE.CONNECTING);
DSL.text(String.valueOf(state.connect().port()));
DSL.onTextChanged((s) -> {
App.getInstance().getStore().dispatch(new Action("CONNECT_SET_PORT",s.toString()));
});
});
});I also tried using a standard DSL.editText() but still not working.. Thanks!
@estsauver Different SDK variants contain just different DSL.java classes generated from different
Have a look here to see which DSL methods are available in SDK19 only (or in SDK21 only) - https://github.com/zserge/anvil/blob/master/DSL.md
android.jar. I normally use sdk-19 these days, but you may choose either of them.Have a look here to see which DSL methods are available in SDK19 only (or in SDK21 only) - https://github.com/zserge/anvil/blob/master/DSL.md
Also any update on this @zserge zserge/anvil#83
@/all Hello, smiths! I'm working on Anvil 0.5.0. The major change so far is getting rid of the virtual nodes and using real views instead (yes, there was no performance gain from using virtual nodes!). This helps to fix issues with XML layouts and nasty widgets from the support libraries.
Also I'm making a change where attributes are identified by string literals (not lambda singletons) and dispatched with a switch/case statement and not hundreds of lambas. This reduces method count at least in half and allows to use the same attribute name in multiple handlers (e.g. gravity() in core DSL and gravity() in the support DSL, also users can do their own "middleware" to handle their own custom view attributes). This opens a way to proper components.
There is a lot to be done (getting rid of reflection in view factories to speed up view construction, adding keys to views to identify similar views somehow), but it seems to be usable enough to test it. I've ensured that anvil-examples work fine and some of my project also run correctly with Anvil 0.5.0. I think it should be pretty much backwards compatible with Anvil 0.4.0.
So feel free to clone the "anvil-forge" branch, run
Also I'm making a change where attributes are identified by string literals (not lambda singletons) and dispatched with a switch/case statement and not hundreds of lambas. This reduces method count at least in half and allows to use the same attribute name in multiple handlers (e.g. gravity() in core DSL and gravity() in the support DSL, also users can do their own "middleware" to handle their own custom view attributes). This opens a way to proper components.
There is a lot to be done (getting rid of reflection in view factories to speed up view construction, adding keys to views to identify similar views somehow), but it seems to be usable enough to test it. I've ensured that anvil-examples work fine and some of my project also run correctly with Anvil 0.5.0. I think it should be pretty much backwards compatible with Anvil 0.4.0.
So feel free to clone the "anvil-forge" branch, run
./gradlew publishToMavenLocal and give it a try!
Hi everyone, I'm new to Android development, but familiar with web frontend development using Mithril. When I read up on fragments since it is the blessed way of doing Android dev, I was scared into searching for alternatives. I searched for 'android virtual dom' and I was pleased to find someone @zserge being inspired by mithril, resulting with Anvil.
One of the killer features of mithril over react, is that I can easily fallback to my dirty ways of jquery dom manipulation post render.
Mithril really doesn't get in the way, and works well with others. So I wonder if Anvil has this level of flexibility? Can I get fragments (if I understood how to work it) to work together with Anvil?
Oh by the way is this where the Anvil community largely hang?
Hi Robin! Thanks for your interest in Anvil (and Mithril, too - I think it's a very underrated framework)
You're right, Anvil often plays well with normal Android development approach - you can use it with fragments, you can use View instances and call their methods directly if you want. Also, you can use XMLs if you prefer that to Anvil's DSL (or if you're refactoring existing code).
You're right, Anvil often plays well with normal Android development approach - you can use it with fragments, you can use View instances and call their methods directly if you want. Also, you can use XMLs if you prefer that to Anvil's DSL (or if you're refactoring existing code).
As for the Anvil's community - there's not much of a community that I'm aware of. There are some very nice and helpful people who hanged out here and helped me to do a big refactoring last year, but as long as everything is working - people just use it, eventually filing issues on github. So if you have a question - feel free to ask it here, if you found a bug - submit it on github.
Excuse my excessive edits
Exactly. To avoid confusion I have to mention that Anvil has evolved from "virtual DOM" concept to the "incremental DOM", because virtual DOM turned out to be too heavy for Android's GC.
However the general logic is still the same - during the rendering cycle current "declarative" layout is compared to the real layout and the real layout is lazily patched according to the changes.
You should be able to get an instance of a View like this:
However the general logic is still the same - during the rendering cycle current "declarative" layout is compared to the real layout and the real layout is lazily patched according to the changes.
You should be able to get an instance of a View like this:
public void view() {
linearLayout(() -> {
button(() -> { // Inside any view block...
init(() -> { // you may declare "init" function and pass lambda into it
Button b = Anvil.currentView(); // Type of a view is deduced automatically in most cases
mButton = (Button) Anvil.currentView(); // Or you may cast it explicitly
// You are not forced to do this within "init" block, but otherwise your code will be called on every rendering cycle
})
});
});
}
// later on you may use mButton as a normal view:
mButton.performClick();
As an alternative, you may use View IDs:
button(() -> {
id(MY_BUTTON);
});
// later just find view by ID, IIRC Android caches views and their IDs:
findViewByID(MY_BUTTON).performClick();