There is one other difference:
Services provide a mechanism to keep their background code running at a
foreground priority (w.r.t process lifetime).
This makes a difference if no activities belonging to the application
are visible, and your application needs to continue working in the
background.
On the other hand, AlarmManager can be used for this instead, at the
cost of slight code restructuring.
-- Kostya
06.10.2010 12:45, poohtbear пишет:
I assume that the time to get the Service object for local binding is
close to 0 for local service , if not then i have an issue since i'm
kind of splitting my program's entry point.
On Oct 6, 10:23 am, Dianne Hackborn<[email protected]> wrote:
You are making services too complicated. If you keep all of your components
in the same process (the default for an .apk), you can just do direct method
calls. See the local service sample code in the docs:
http://developer.android.com/reference/android/app/Service.html#Local...
<http://developer.android.com/reference/android/app/Service.html#Local...>At
the point where you do the cast in onServiceConnected(), you have the real
service object and can do all normal Java stuff with it.
On Wed, Oct 6, 2010 at 1:16 AM, poohtbear<[email protected]> wrote:
I have an application which requires networking service.
I took on LWUIT4IO and adjusted it to my needs so now i have a network
queue that can run one or more network threads.
Now, my application is based on single root activity that spawns other
child activities as needed (it's a reservation center for vacations,
car rental etc.. each in it's own activity).
The network is common to all and should be used by all activities. the
network thread requires, basically, a callback to notify it's finished
and return the result (input stream or byte array) .
At first i thought that i should use a service instead of a singleton
that will be started in the root activity(the service will also be
started in the root activity), however working with a local service is
problematic for me:
1. no callbacks which makes me use intents to encapsulate the request
\response in intents - time consuming, also since there is not single
point of listening (i have to use BroadcastReceivers) i have to add a
calling class name or some other identifier so the sender of the
request will know it's for him, i think this is also a waste of time
and resources since i need only one listener.
2. i think i CAN use callbacks if i use Binder object to return local
instance of my Service and then use the queuing method directly, this
is problematic for me as acquiring Binder object is asynchronous and i
need it 'on the spot'
3. I thought of using a static instance of the service and null it in
onDestroy of the service, but if i use that way, i'm not so sure i
need a service...
4. i saw a small answer in stackoverflow about inheriting application
and putting whatever member you need there so when you use
getApplication you get this instance and then you can retrieve
whatever you want, is this even advisable ?
In short i'm not so sure Service is what i should use, any advise here
would be great...
Eyal.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]<android-developers%2Bunsubs
[email protected]>
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
[email protected]
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
