[ADT] Question about custom widgets

Common bugs/problems with the Android SDK the Emulator and the ADT-Plugin.

[ADT] Question about custom widgets

Postby impinc » Sun Aug 14, 2011 9:19 pm

I started my programming with App Inventor, then eventually now I'm using eclipse and the SDK. However, the app Inventor team released the "Java Bridge" to help those who know app inventor learn java.

I've since added to this library. My idea is this. App Inventor is being discontinued at the end of the year. What I'd like to do is to add the bridge components (or widgets if you will) to the graphical layout editor. I think this will help the many people who use App inventor, who will be looking for another way to code.

I've searched all over, but can't seem to find what I'm looking for. I imagine this probably involves creating another plugin for eclipse? Or is there some way I can add these other widgets to show in the graphic view?

Any help would be appreciated.

Ryan Bis

Posts: 4
Joined: Tue Jul 26, 2011 5:43 pm


Re: [ADT] Question about custom widgets

Postby impinc » Mon Aug 15, 2011 5:16 am

This is the answer I got in the adt-dev forum:

This isn't supported well yet, but it's definitely something we want to do.

There are two main limitations.

The first one is the platform: When you have a custom view, you have
to manually modify your project to declare the styles that your View
will use via XML. It would be nice if we can figure out a way here to
make this process easier -- possibly using annotations on the view
class that the tool can use to infer which attributes are available,
or perhaps allowing (via our API, discussed below) your widget to
contribute metadata to the styles.xml etc file which we add to the
project on demand when the widget is first dropped (and that would
also use to infer information about your custom view's properties; we
currently just use some basic reflection.)

The second is the tool: We have a lot of support for adding
"designtime" support for the various views. Pretty much all custom
behavior you see for the various views (the guideline feedback shown
in relative layout, the context menu items for setting properties or
specific properties like id, width and height, the automatic drop
handling (setting the layout weight of a text field in a linear
layout, or setting a drawable image when you drop an image view, and
so on) -- all of that is done via a "designtime API"; it's hardcoded
in the layout editor tself. And furthermore, the designtime helpers
live separately from the views, so you can create new designtime
helpers for new widgets and supply them to the tool. By default, the
tool will look in the same package as the custom view (as well as a
few other places) to see if it can add designtime behavior to a custom
view in the layout.

That's the good news. The bad news is that this API is still in a lot
of flux, and while the API lives in a separate package (and is
completely agnostic from which window system etc you are using, so in
theory the designtime helpers used for our Eclipse layout editor could
also be used by any potential other layout editors written in Swing
and so on) we haven't properly pulled it out from the remainder of the
IDE, so there isn't a simple .jar file you can just use as your
library jar to build your designtime helper against. What you have to
do is build the IDE plugins (documented on tools.android.com/build),
place your designtime helpers in there somewhere, build them, and then
pull these jars out and ship with your custom view (but probably in a
separate jar, even if in the same package, such that a running
phone/tablet app doesn't get bloated with designtime classes).

We definitely want to improve the workflow for this, as well as work
on finalizing the API (I'm about to file a CL for a big change to how
actions work for example) -- but it's still going to take some time.
Our focus has been on getting the base level functionality for the
built-in widgets up and running. However, having you and others
actually wanting to use this functionality makes it not just more
important for us to work on, but can also help us drive the API
forwards when we see your use cases and API requirements.

This was from Tor Norbye on the adt-dev google group.
Posts: 4
Joined: Tue Jul 26, 2011 5:43 pm


Return to SDK/ADT/Emulator Problems

Who is online

Users browsing this forum: No registered users and 3 guests