I formed preference using XML, but I don't know how can I open other view using XML tag intent...

by Scent » Thu, 30 Apr 2009 02:05:50 GMT

Sponsored Links
 Hi, all.

I formed preference view using XML codes..
in here, I wonder that how can I show other View at click this item
using <intent> tag.

if not available, could you give me some advice about this...
I want to implement using XML tag


            android:data="android.app.MoneyAgent" />


Other Threads

1. Alpha Buffer support on G1

Is it possible to generate an EGL Config with an alpha buffer on
the G1?  When I request a non-zero number of bits for the alpha buffer
I can get a R5G5B5A1 or R8G8B8A8 visual, but neither of them renders
correctly to the screen.  I assume that's because the G1 only supports
R5G6B5 visuals.  It does surprise me that I can even get those visuals
though.  It's fairly obvious looking at the 32bpp visual artifacts
that the frame buffer is indeed laid out with 32bpp, but display
hardware is treating it as 16bpp, resulting in the left and right
halves of my scene rendering in alternate scan lines, with distorted

    So does anyone know if there is any way to get an alpha buffer on
the G1?

    I've tried using FBO's but they don't seem to be implemented
either.  Or I'm using them incorrectly.  If I call
glGenFrameBuffersOES on a GL11ExtensionPack reference I get an
UnsupportedOperationException.  I am getting my GL11ExtensionPack
reference by casting the return value from my EGLContext.getGL() call.



2. eglSwapBuffers slow?

I have been trying to optimize on OpenGL render, and I've come
upon an irreducible problem.  It seems that on the G1 a call to
eglSwapBuffers will always take at least 9ms.  I understand that the
buffer swapping is restricted to a maximum of 60Hz (well, the refresh
rate of the screen, which in this case happens to be 60Hz).  But I'm
never seeing it take less than 9ms, even when I'm doing more than 8ms
of work.

    Has anyone seen this?  I've been reading through the code and
can't find anywhere that there is explicit mention of a fixed delay.
Not that I was really expecting to find something like that.  What I
do find is that the swap code eventually calls unlockAndPost and then
lock on the underlying surface.  The unlockAndPost causes the
underlying driver to start the swap and the lock waits for that to
finish.  The driver is told to do the swap via an IOCTL call on /dev/
graphics/fb0 that actually does a BLT.

    I wonder if the IOCTL round trip to the kernel and the thread
switching time is adding up to make eglSwapBuffers so slow?  Or if the
requested BLT takes this long?  If the BLT were actually taking
something close to this long that would explain things because the
lock call waits until the BLT is done (at least that's what it looks
like to me).

    As partial confirmation of this, when I up the surface size by
going to an RGBA_8888 surface the eglSwapBuffers call goes from taking
9ms to taking 15ms.  Which pretty much means you can never get 60
frames per second using an RGBA_8888 surface.


3. Android Family

4. Widget process lifetime: Why not stop the service?

5. Airtell calling card - receipt

6. More FaceBook, My Space, Youtube, Google News Online at this

7. gridview column size