There is a project with title Add components programmatically in the components category of GSoC projects.
Project definition :
Currently components as Sprites have to be manually added to a Canvas to be able to use them. In situations like games, it would be a lot more useful if Sprites could be instantiated and created when needed. In Scratch this functionality is called cloning and it would be a great starting point to see how cloning works to design a similar feature in App Inventor.
I have attached a photo here showing how implementation can be done.
In the blocks editor we can give an option for creating a new component .By choosing the component we can create a component. As we select the component the properties menu will pop up on the right side of the blocks editor. we can set all the properties. & As we add the component it’ll also be added in the components shown in the designer.
After that we can create more built -in blocks.
example : if we create a button then in which layout it should be added.
Can we implement like this??
Is it appropriate way to do this?
can we do the same thing any other way ??
unfortunately I do not have answers to your questions... @ewpatton is currently in vacation for 1 week and most probably will answer them after he is back
this feature is available as extension but as far as I can see, it still can be considered as a project...
This seems like a very good approach to the feature we have in mind for App Inventor. It is not as generic as the Kodular extension, but it is something the user can find while exploring in the interface and figure out themselves, which is one of our user interface goals.
I think the more appropriate thing would be to do something like what Scratch does and have a block that clones an existing component (or Sprite in Scratch parlance). The block would need to take a reference to the original component to be cloned and a reference to the container to place the cloned component into. We'd probably also need methods on the various containers to reorder components, which might get complicated.
Another option, and what I thought this was when I first looked at it, was an additional option under Any Component. This would require there be at least one instance of the component on the project because that’s how the Any Component menu works – having a menu option for every possible component in the designer is pretty daunting.
So, in the Blocks Editor where there’s already at least one button on the project, you’d see:
Any Component
Any Button
Create New Button
This method would then take the required inputs for the constructor and produce a new component.
This approach sounds good. But this approach will not work for other type of components which don’t exist on the project or screen.
suppose i haven’t added anything on the screen (designer) and in blocks editor i directly want to add a button. how would this work ?
The typical strategy for using the ‘Any Component’ is to create a component and make it invisible. Given that some components need quite a bit of configuration, I’m not sure that doing all the work in the blocks is the correct approach. I think the cloning/copying capability is probably best when paired with some prototypical components that the developer customizes in the designer before replicating them with blocks–at least it seems like it would be a much faster way to build a UI than building the entire thing via the blocks.
Edit: It’s also important to note that components declare permissions and other assets and so we need to know at compile time if at least one component will be used to ensure its dependencies are included. This recently bit us when we made it so that ‘Any Marker’ appears even if a Marker isn’t present in the app. The default assets for the Marker weren’t included in the compiled apps and so they would fail.
I wasn’t aware of the permissions issue. It doesn’t seem like a big requirement that there be at least one component on the project which can be set to invisible.
Which components are you thinking of that require lots of config out of the box? It seems like most visual components have logical defaults such that they can be dragged to the Designer and do something reasonable with little or no additional user input.
The location of the new visual component seems like an issue. Can we currently add components to an arrangement using blocks?
BTW: The clone method seems totally reasonable to me. I’m just trying to think out the space of the problem.
The $add method declared in ComponentContainer.java can be exposed as a @SimpleFunction. Subclasses can then override the method and add component-specific implementations for adding children at runtime.
However, additional methods will have to be written to let the user add a child at a specific index.
A constraint with instantiating components using their existing constructors is that the user will be forced to append them to a parent right within that block. They will be unable to create a component and at a later time set a parent.
Also, we will probably need some sort of checking for valid parents. This is currently done for MockComponents (you can't drop a Ball inside any component other than a Canvas), but to my knowledge, no such system exists in the components side (rightly so, because components defined at compile-time are already validated by their Mock counterparts)
If the component is cloned, then it will come with a parent, so that approach would deal with a lot of confusion upon creation. But the nature of how parents will be changed looks like it's a significant problem of the project.
I think you can refer to an appinventor platform in China that implements all dynamic components completely natively and has a lot of very powerful utility capabilities.
The platform is Wxbit.
