-
Notifications
You must be signed in to change notification settings - Fork 728
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
No support for programmatically generated views #86
Comments
I like the idea of supporting this. I'm thinking that a model that subclasses
I don't like the idea of having to manually give an item type. That could hopefully be generated. I'm also thinking that we could automatically make a One other tricky part is that the adapter only has the item type Alternatively, maybe we should separate the view building from the epoxy model, and have a factory interface that builds a view for a given item type. Do you have an example use case or ideas for what this would look like? |
For an example usecase, I've been using Anko to create my views that's why I needed to have a way to use views instead of inflating layouts. What I came up with but not really tested it yet is to have a constructor for EpoxyViewHolder that takes a view.
For the adapter maybe something like this
I can see that creating the ID manually might cause a lot of careless bugs. Maybe we could make use of hashCode()? |
using One other question about item types - do you foresee a model needing to programatically change its model type? Maybe the programmatic view it builds can differ and it needs to have its item type change? In that case we can't tie the item type to the model class. |
I think models shouldn't change its item type. Basically what is being done is, instead of inflating, the view is being created programmatically. So whatever changes with the view it's like changing its properties like how we do it in xml. I think it would be better for the model to not really care about how the view is built. For the ids, how about annotation processing? A model is annotated with a string |
Generating the ids with the annotation processor would be ideal. That was my first thought. The only complication I can think of is handling multi modules. Since modules are processed independently the annotation processing in one module doesn't know about anything in another module. This makes it hard to avoid collisions.(http://stackoverflow.com/questions/38492208/multi-module-annotation-processing-in-android-studio) I can't think of a good way to manage the multi module case right now but will keep thinking. For a first iteration we could either not support multi module, or require an item type to be set manually. |
Also, going back to you proposal of
This isn't ideal since models can also be added directly to the models ArrayList. Since a common pattern is to remove all models and rebuild/add them when data changes it would also mean doing this operation for every model when data changes. I would like to think of a more optimized way of doing it. |
Well we could do something like this to handle adding and removing models
|
I have the ideas on how to do this pretty fleshed out and have started working on it. I'm on vacation and traveling for the next two weeks though so I probably won't have anything to show until after that |
@elihart I have been meaning to solve the issue with the multi-project build for a while now, but have been on vacation/extremely busy at work. If I get time this weekend, I have a very basic outline of a Gradle plugin that will solve this issue. I'll clean it up and link it here for you to reference/build upon/ignore 😜 . Feel free to reach out to me for any help/work to fix this bug along the way as well! EDIT - I was mistaken and thought we could solve this issue similar to the way that griddle does, but after spending some time on this I think I have found a solution that will fix both the multi-module linking, as well granting us the ability to guarantee a unique id. Seems as though the butter master @JakeWharton has already solved this issue https://github.com/JakeWharton/butterknife/tree/master/butterknife-gradle-plugin |
@niccorder Interesting idea to use a gradle plugin! I hadn't considered that. We use the butterknife gradle plugin but I've never looked at the source until now. Thanks for looking into this and contributing; I'm curious to see your approach. I don't quite see how it would work yet. For Butterknife there is just the one R file that needs to be copied, but for the Epoxy use case we would have an unknown number of EpoxyModel classes. I've also thought about generating an xml file for each module with The approach I've started working on is simple, but not very elegant. https://github.com/airbnb/epoxy/compare/eli/views The base class looks like this
I haven't finished the annotation processor work yet. The generated class will implement The change in the adapter is also fairly simple, if a little bit ugly. The current RecyclerView implementation always calls What do you think of these ideas? |
No problem, I really enjoy this project as I think it is a very clean way to solve one of the most frustrating aspects of Android's recycler views. Last night I took some more time to research issues/problems others have had with annotation processing/code generation and their smooth integration into an IDE such as IntelliJ, AndroidStudio and Eclipse. Here is my thought process on a Gradle plugin — Yes, we currently run into the issue of the multi-module problem which can be solved (or so I believe) like so — What are your thoughts? I see it as this — we now have the ability to remove the There were a few other ways I was thinking could work that revolved around generating the sources through a plugin, but by compiling ourselves. (i.e. the processor & plugin live together). This means we can traverse the submodules and find all classes that contain annotations & have our Gradle plugin keep a counter which would provide a Unique id. As far as your solution goes — I definitely like it as well! It may not be |
Thanks for outlining your ideas, that does seem like it could work. I'm not very familiar with gradle scripts, so I'm not clear on what exactly steps 2 and 3 would look like but I would love to see your attempt at it! Especially for step 3, is it possible to manually invoke an annotation processor class via the script? That would be great if so since we could reuse the existing processor. Looking at how Butterknife's plugin works though it uses the Your idea to combine the plugin and processor is also interesting. That could be something good to try if just using the plugin doesn't work. How much work do you think the plugin approach would be? If you're willing to do it that's great! Otherwise I probably wouldn't have much time to spend on it so I would settle for my solution for now. |
@niccorder Have you been able to spend any more time on the gradle plugin? |
I'm also curious about this :) |
Jeez Eli, I'm sorry I forgot to respond. Thanks for the reminder Henrik!
I've been absolutely slammed at work, but this weekend I'll work on it. I
don't anticipate it being too hard to get up and running as I would just
hook into the build process -> apply dependencies & logic -> ??? -> profit.
Sorry again, I'll submit a PR as soon as I have something working but I'd
love everyone's feedback to help me iterate on the initial solution.
…-Nick
On Mon, Feb 13, 2017 at 7:37 AM Henrik Persson <notifications@github.com> wrote:
I'm also curious about this :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#86 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGBw_Q2akqAFRQykP63chHfZEOmIxKJQks5rcHidgaJpZM4LP3mX>
.
|
@niccorder That would be great! Keep us posted on progress, I'm happy to look over a branch whenever you like. |
@niccorder No luck? I am planning to go ahead with my basic solution for now to get this supported in the 2.0 release. I don't think multi module projects are too common, so it is fine to not support it completely for now. |
This will be released in 2.0 #151. I still need to add the annotation processor portion to generate view type, but that should be easy. |
No option to use programmatically generated views to be used with the EpoxyAdapter
The text was updated successfully, but these errors were encountered: