You could use a static value in your widget class. Increment the
static value in the constructor and use that to initialize an ID that
is local to the instance. Basically the classic singleton pattern. You
can add serialization for the static if you plan to support multi-
threading but that's not
Yes, but that still doesn't assure that you won't collide with somebody
elses custom view ID numbers.
On Mon, Dec 27, 2010 at 9:22 AM, Bret Foreman bret.fore...@gmail.comwrote:
You could use a static value in your widget class. Increment the
static value in the constructor and use that to
For the case you're describing, it doesn't matter.
RelativeLayout only looks at its own children when resolving id references.
-- Kostya
27.12.2010 20:40, John Lussmyer ?:
Yes, but that still doesn't assure that you won't collide with
somebody elses custom view ID numbers.
On Mon, Dec
The view ID is intended to be used inside the scope of an onClick() or
some other onEvent() method. In that case, the onEvent method was set
in the initialization for the widget, which will be unique to your
widget. In other words, it's always one of your custom widgets. I
wouldn't use a view ID
Well, things just aren't quite working that way.
I had 2 instances of my custom view (subclass of RelativeLayout) on screen.
Each of these did have a unique ID number.
When the children of my view all used the same set of ID numbers
(900,901,902 for the 3 children of the custom view), then when
It will return the first it finds during a depth-first traversal of the
hierarchy. The framework uses framework ids -- 0x01nn. It is up to you
to generate unique id integers (if you aren't using @id/blah) however you
would like, if needed. There is no requirement for ids to be unique in a
6 matches
Mail list logo
