Please explain View.addFocusables

by Nigel » Thu, 03 Sep 2009 18:36:18 GMT


Sponsored Links
 I'm creating a custom component.  The child components are not acting
as expected in regard to my custom components re-acting with its
siblings.

On investigations to solve this I came across View.addFocusables and
View.addTouchables.  These may help me, but I'm not really sure how
they're intended to be used.  Can anyone provide a better description,
or example, of how these are intended to be used?  A dig around on
Google revealed nothing :-(...

Any explanation - or links to pages I couldn't find - much
appreciated.

Cheers - Nigel
--~--~---------~--~----~------------~-------~--~----~



Please explain View.addFocusables

by Nigel » Fri, 04 Sep 2009 16:48:29 GMT


 addFocusables was on the wrong track.  The solution was much more
mundane.

My custom component was derived from View.  It needed to be derived
from one of the ViewGroup classes - in my case FrameLayout.

Nigel




--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Other Threads

1. Android - Large Application size (Memory) issue

Hello all,
I am facing the "Memory" related issues and i am searching the
possible solution to this issues since last 2 weeks.

Right now i have developed an android application for the personal
perpose, whose size is 54 MB, from which 52 MB of only Images/Photos.

So i want to install it on Android SDK 2.2 for that i have already set
android:installLocation="preferExternal" in the AndroidManifest.xml
file. I have created 256MB sd-card while creating an avd , heap size -
192 , ram size - 192, cache-partition-size - 256MB

but it still showing me an error:
[2010-08-27 17:58:28 - demo_test] Failed to upload demo_test.apk on
device 'emulator-5554'
[2010-08-27 17:58:28 - demo_test] java.io.IOException: Unable to
upload file: No space left on device
[2010-08-27 17:58:28 - demo_test] Launch canceled!

what issues i am facing ? pls give me suggestion or solution to these
issues

-- 

2. Is there a way to request permissions from auser as you need them?

UKth
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Indicator Veritatis <mej1...@yahoo.com>
Sender: android-developers@googlegroups.com
Date: Sun, 29 Aug 2010 17:11:56 
To: Android Developers<android-developers@googlegroups.com>
Reply-To: android-developers@googlegroups.com
Subject: [android-developers] Re: Is there a way to request permissions from a
 user as you need them?

In other words, it is your anecdotes against his. I thought I would
not need to remind you, but I guess I do: THE PLURAL OF 'ANECDOTES' IS
NOT DATA!

BTW: adducing the MIDP and Win7 experience is most unconvincing even
for its already unconvincing anecdotal class. This is because in both
those schemes, there was no alternative: you HAD to request
permissions every time, even if it had been granted before. But
Android already supports asking on a per application basis.

Now it is time for my anecdote against yours AND his;) I got very fed
up with both Win7 and MIDP under Symbian because it kept asking over
and over, but I recognized that a major complicating frustration
factor was that the Symbian implementation of the Socket and HTTP APIs
was so busted in the first place. That is, it would have been far less
annoying, IMHO, if the network connection had actually WORKED when I
gave it permission to go ahead. But instead, it was asking even more
frequently than their questionable design called for, because they had
to keep setting up the connection again every time it broke -- which
was SO often.

So after suffering though that, what I decided was needed, what I
THOUGHT this thread was going to drift to, was a "two-tiered"
permissions scheme: allow granting some permissions on a per-
application basis, but some on a per-run basis. That is not to say I
am sure which should go to which. Perhaps the Manifest needs to grant
the application permission to ask permission;)

But thinking about this reminds me of another relevant data point:
until the user sees an application ask over and over for net
permission (for example), the user has only a fuzzy notion in his mind
of when which application DO use the net (and when). This is one
Achilles' Heel (that millipede may have many more) of the current
permissions scheme in Android. Why, for example, does Bump need
Network at all, if it is using Bluetooth to communicate between Bumper
and Bumped?

This is an example of why I have to agree with what was said earlier:
the current permission scheme really does look like it was designed by
software developers, NOT by a UX expert. But such features really do
need to be designed as a joint effort between UX and security experts.
Otherwise the difficult trade-off between usability and security will
come out badly -- as it already has so often.

While I am making proposals, I suppose I should also propose an
enhancement of the current Internet permissions: separate permissions
for low and high bandwidth. I propose this because when Android was
designed, carriers were offering unlimited bandwidth plans for
smartphones. But now they are backing away, offering unlimited data
plans only for feature phones -- if at all. So now we can no longer
splurge on bandwidth.

Yet I have noticed that many websites and many web clients still
assume we can splurge, forcing the poor user to load and reload what
should have been cached as well as download lots of junk before he
gets to the data he -really- wants etc. But on AT&T, this can easily
cause him to go over the 2G download limit on the high-end smartphone
data plan. I know, because it has happened to me already;)

Splitting Internet permissions into low and high does not solve the
problem, but it might help mitigate it.






-- 

3. stretch_copybit::run_render fail causing noticeable pauses in my display

4. Bes resource to get started with Android development.

5. Lanunch an application at the time of Start up

6. signing apk using netbeans compile

7. Android with XML-RPC