If you have any doubts then post in community they are there to help 
1 Like
If an extension builder were App Inventor:
-
the classes (
import) are components, but unlike App Inventor, if you want to use a class, you have to define it. -
the libraries (
@UsesLibraries) are extensions - they are outside of the built-in classes. -
the permissions (
@UsesPermissions) are the Screen.AskForPermission block - they need to use that particular permission. -
everything else (
@SimpleSomething,@Override) are blocks - they tell the extension how to behave. -
the Compile Extension button is the Build > APK option - it compiles the extension.
-
us, users who finds that extension are the app users - we use that extension.
Just to let people understand a basic structure of extensions...
Since when did @Override became a block? its used when implementing a interface
again no those are java codes meant to shorten our work.
Well, they have one similar point - anyone can develop libraries (extensions), and you mentioned the exact point -
They can be made by external people, not just Google. Same thing for extensions - they don't have to be developed by the MIT, they can just be developed by normal people.
They can be blocks, only for the fact that they don't exist as blocks. Maybe some day there will be a Override block in a block language. Just a metaphor 
A quick nutshell of this topic - choose a good extension builder, learn Java, understand the structures of extensions, code the extensions, and you're done.
2 Likes
just because they have similar point does not mean they are same
1 Like
I think the theory of including @Override in this list is that the App Inventor annotation processors use this to exclude the other @Simple* annotations in the parent class, effectively allowing one to hide blocks that were defined in the superclass. Technically, this allows one to "undefine" blocks.
4 Likes