intent.action_send and intent chooser

by tnull » Tue, 20 Jul 2010 22:20:44 GMT

Sponsored Links
 When creating an intent with action send to send some data, is there a
way to filter the results that are included in the activity chooser
that is created using Intent.createChooser? I have not seen a way to
do this other than setting the mime type, but it is not flexible

For example, there is a situation when I want e-mail apps to be the
only results in the activity chooser dialog. Setting the type to "text/
html" successfully filters this down to email apps, except when
bluetooth is enabled. Bluetooth appears in the list as well, but this
is not desirable. Surely there is a way to have a little more control
over the results?


intent.action_send and intent chooser

by Mark Murphy » Tue, 20 Jul 2010 22:31:06 GMT


What are "e-mail apps"?

Only on your test environment(s). Anyone can create an application
that supports ACTION_SEND of text/html -- this it not something
exclusive to "e-mail apps". I would not be the least bit surprised if
there are others on certain devices or out on the Market.

Write your own chooser dialog, using PackageManager.

Mark Murphy (a Commons Guy)  |  | 

_The Busy Coder's Guide to Android Development_ Version 3.1 Available!


Sponsored Links

intent.action_send and intent chooser

by tnull » Tue, 20 Jul 2010 23:39:13 GMT

 With e-mail apps, I just meant I was looking to filter the results to
e-mail clients, not necessarily anything that can handle "text/html",
which I realized wouldn't work when bluetooth popped up.

Thank you for the tip on creating my own dialog using PackageManager,
I will look into that.


Other Threads

1. Application not responding - boot receiver - Why does it happen?


I am talking about an application which works with a background
service. To start that background service I have registered a
Broadcast Receiver which waits for the boot completed action. When the
receiver is called I am directly starting up the background service.

To sum up:

MyBroadcastReceiver waiting for boot completed -> starting
backgroundservice -> backgroundservice sitting in the background doing
its job.

Why do I get "/my application name/ not responding" directly after the
reboot. (even before the broadcast receiver got called) Does the
system automatically restart services that had been running in the
background before the restart of the system? Or why do I get this

I'm looking forward reading your answer.

2. Problematic Android heap management remaining cause of crashes

One of the main reasons that my app still occasionally crashes is that
I have limited control over Android's heap management. In particular,
when I launch a new activity from within my app, I see in the DDMS
debug view for my dev phone 1 a huge - albeit temporary - free memory
dip that sometimes measures over 2MB, and the free memory as a result
going down to a mere several hundred KB is then occasionally the
reason that the camera preview internally (not in my Android code!)
cannot allocate the 230400 bytes needed for a preview image. I cannot
catch this internal OutOfMemory exception to prevent an application
crash because it occurs in the lower level camera code, not in my own
application-level memory allocations and preview processing.

The newly launched activity that causes the free memory dip itself
does not use much memory (maybe 0.5 MB), and after a second or so I
therefore again have at least 3 MB free memory, so I conclude that it
is in the transition between two activities (the main one and the
startActivityForResult()-launched one) that the memory dip occurs. My
app does not leak memory, as is evident from the fact that free memory
remains approximately constant even when I run my app for a long time.
Normally I have between 3 MB and 3.5 MB free memory while running my
app, at a DDMS-reported heap size of 5.6 MB (apparently Android
process management already takes a huge bite out of the 16 MB total
heap that any app is supposed to have?). I also apply System.gc() and
Bitmap.recycle() in my code where big memory blocks such as for
bitmaps are allocated/freed, and I apply try-catch blocks to catch
OutOfMemoryError exceptions arising from my own code to transparently
recover from temporary memory dips without a crash, because those
OutOfMemoryError exceptions arise from Android not cleaning up in time
- but again, I just cannot catch Android's lower level memory
allocation problems that still cause my app to crash. :-(

Is there a way to prevent the large - though temporary - free memory
dips that occur when a new activity is launched? It looks as if
Android cleans up for the launching app only *after* the new activity
has been fully launched, and acts much like there are temporarily two
complete activities plus transition management overhead in memory as
far as heap usage is concerned? It is pretty bad if one cannot trust
memory management when this causes unpredictable application crashes
due to things that lie beyond the reach of the application programmer.



3. Trouble with TabActivity

4. Does Android need a more compelling/smoother user interface? (consumer view)

5. Creating gradients on a view/layout in xml.

6. How can i make my wireless work?

7. adb Error: ADB server didn't ACK