You don't need a service.  And please please don't use startService()
unless you really want to use up the user's resources with your app trying
to run when they are not in it.  Way too many apps I see abuse resources
and keep themselves running in the background and thus just sucks.

Just make a singleton that manages the stream, which any part of your code
that wants it can access.

On Mon, Apr 16, 2012 at 12:10 PM, Federico Paolinelli <[email protected]>wrote:

> Another approach that you could follow is to host the tcp connection
> inside a service (
> http://developer.android.com/reference/android/app/Service.html)
>
> You can then access the service from any activity you want using the
> binding pattern or through intents.
> Just remember that your app may continue to live in background, and your
> service will still be running unless the os kills it. It's up to you to
> disconnect if the activities go in background or if you want to notify the
> user that the connection is still up and running.
>
> Remember also that service runs in the ui thread, so you will likely need
> to run a different thread inside the service.
>
> Hope this helps,
>
>      Federico
>
>
>
>
> Il giorno lunedì 16 aprile 2012 18:31:09 UTC+2, Tonez ha scritto:
>
>> Hi Everyone,
>>
>> I'm building an Android app which uses TCP sockets to communicate with
>> a .net server application.  The android app as a whole relies quite
>> heavily on TCP and as such nearly all the features in the app require
>> writing to and listening from a socket stream.  I'm trying to
>> determine what the best design approach is for having more than one
>> activity utilize a live active socket.
>>
>> I've recently just finished building an iPhone version of this app,
>> the way in which I got each feature (different view controllers) to
>> use one live active socket connection was by passing the live socket
>> instance to each view controller, each view controller would then
>> retain ownership of that socket and as such the delegate methods which
>> fire when a transmission is received work as expected.  Trying to
>> simulate this design in Android is proving to be a pain because I
>> can't pass a live socket instance to another activity as part of an
>> intent parameter.
>>
>> If I wanted to have activity A listen for incoming TCP data, and then
>> navigate to Activity B but then have activity B send TCP data to
>> the .net server and of-course spawn a new thread to listen for
>> incoming TCP data - what would be the best approach to achieve this?
>>
>> At the moment what I have is as follows:  activity A spawns a new
>> thread listening for incoming TCP data, activity A can communicate
>> with the .net server perfectly fine.  When I navigate to activity B
>> and then want to communicate with the .net server - creating a new
>> socket instance and then listening for incoming data results in
>> activity A's readLine() method receiving the data.  Which makes sense,
>> it's still running - but obviously the goal is to have activity B
>> receive this data.
>>
>> An alternative approach I tried was to close down the TCP socket I
>> have in activity A when opening up another TCP socket connection when
>> I need to use TCP in activity B - although this somewhat works it
>> really feels like the wrong way to go about it.
>>
>> And lastly, one other approach I've thought of is to have one activity
>> handling all TCP comms with the .net server and contain all the
>> functionality in this one activity by swapping out .xml layout files
>> when necessary.  Obviously this will result in one massive .java file
>> and again is a route which feels wrong.
>>
>> Any advice on how I can go about designing my app given that I want to
>> use TCP functionality in every activity would be greatly appreciated.
>>
>> Many thanks,
>>
>> Tonez
>
>  --
> 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
>



-- 
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.

-- 
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

Reply via email to