tags:

views:

133

answers:

1

Despite similar question was asked, I have differnet situation: My app consists mostly of a background Service. I want to start external activities and get results back.

I see several options:

  1. Create dummy Activity and keep reference to it for using its startActivityForResult. This consumes quite a lot of memory, as we know.

  2. Use Broadcast Intents instead of Android's results infrastructure: ask client activities to broadcast their results before closing. This kind of breaks the idea and not so performance-efficient.

  3. Use Instrumentation directly - try to copy code from startActivityForResult into my Service.

  4. Use Service interfaces - serialize and add AIDL connection to the Intent for starting an Activity. In this case Activity should call Service directly instead of providing result.

The third approach feels closer to Android for me, but I'm not sure if it's possible to do - Service does not have its Instrumentation, and default implementation seems to always return null.

Maybe you have any other ideas?

+1  A: 

I think option 2 is the most idiomatic way on android. Using startActivityForResult from an Activity is a synchronous/blocking call, i.e., the parent activity waits and does not do anything until the child is done. When working from a Service and interacting with activities your primarily doing asynchronous/non-blocking calls, i.e., the service calls out for some work to be done and then waits for a signal to tell it that it can continue.

If you are using the android local service pattern then you can have your activities acquire a reference of the Service and then call a specific function after it has performed its work. Attempting your option 3 would be counter to what the framework provides for you.

Qberticus
Thanks for your thoughts! Now I'm choosing between 2 (easier to implement) and 4 (more secure/private and should be faster).I don't really agree that startActivityForResult is blocking (because it uses callback function, not result value), and also Instrumentation is in public API =)Thanks!
Alexander Kosenkov
I meant it's not blocking in the traditional sense (e.g., a blocking io call). It's blocking in the conceptual manner in which you use it.
Qberticus