I have an android app with multiple activities. One needed class contains a socket connection server.
I am deciding to make this server class either as a nested sub class in the main activity or extend Service to run in the background as a service class.
Some people have commented that the service can really burn down the users battery and I have found that it is hard to kill a service class. I sometimes use a notification in the top menu so a user can stop the service and the app with a button click. but when the user does this it gives an error message that looks like the app crashed and that does not look kosher.
by putting the socket server class in a blank activity that contains no xml layout file it will probably bring up a blank page that will lose focus from the main activity, and that will not look good, unless there is some way to get around this problem.
one alternative idea is to put the socket server inside of a utility class that does not extend any other class and use a nested broadcast receiver or intents to send messages back to the main activity.
another alternative idea is the put the socket server inside of a class that extends application.
what is the correct way to implement this socket server class?
we have a (bluetooth) server socket that runs in a thread in a dedicated service with no issues reported by users.
Some people have commented that the service can really burn down the users battery
In my opinion you should "Suck it and see" ie unless you try it and test it you'll never know. Yes, there are alternatives and yes it will take more than zero additional battery, but test it and take measurements.
Related
i am creating an app in which from many activity we send and receive data through Bluetooth ,
so if i release socket in 1 activity ,so in other activity i have to connect that socket again
,so some time it is connect and sometime it disconnect , so how can i create only 1 socket and share to all over app?i have already tried to make 1 conman class to share but that also did't worked out.
the right way to maintain Bluetooth connection between different activities, and in general - to share any Object across the entire application, is by using a Service class.
android Service derived class is the facility for your app to perform operations, and hold references to objects that needs to maintain it state regardless if any Activity changed, or even when there is no any Activity at all (when your app is in background)
you can bind the current foreground activity to a Service, and by that - to communicate with it from the current activity.
for more info - read: http://developer.android.com/guide/components/services.html
you'll find tones of tutorials and samples by searching on android Service, and binding to a Service...
I guess that for someone who not familiar with android Service - it would look a little complex and hard to understand ant implement, but eventually it's one of the most important component of the API's, so it worth the effort.
I'm messing around with one of the Android Samples Bluetooth chat, im relatively new to Android so I'm here to get users opinions, In the main activity class and instance of the class "BluetoothChatService mChatService" is created this does all the controlling of the bluetooth connectivity,
Now I have created a new Activity that launches a page of buttons, these buttons will send certain hardcoded messages depending on which one is pressed, aseen as "mChatService" has been initiated and is handling the connection I would like to make this class instance available in my newly created Activity so I can send messages straight away,
What is the best practices to make this available?, I have read about Serializing the class (which wont work in this instance) so I can pass it in with the Intent, and also singletons?
Can anyone advice what way this SHOULD be done?
Thanks!
If you can't make your class Serializable you could use Parcelable and do intent.putExtra() when sending and intent.getExtras().getParelable() on the receiving end.
Passing a reference to a Bluetooth class might get tricky. You would probably be better handling the message sending back in the original activity.
I am creating a project which connects to an embedded Bluetooth chip. Currently I have it set up with a separate application class which controls all the bluetooth functionality.
My program initialized with a main menu that has 9 buttons. In the main screen I create the connection to the Bluetooth device. Each button brings me to a separate Activity. Each activity needs to receive different pieces of data from the Bluetooth chip.
My question to you all is, would it make sense for me to use a service instead of an application? From what I understand of a service, it is used because there is always something running in the background. However in this case nothing needs to be running in the background ( unless keeping the connection with the Bluetooth device counts), data is only sent/received when an Activity asks for it.
Or, am I completely off track and shouldn't use either? Just a simple class to act as my data container which can be passed through intents? I know this will work, but am very new to Android and intents seem to be a bit messy. I would rather not use intents if I didn't have to.
I'm also building up a bluetooth connection, and i put the whole communication stuff in a service and bind to this service with every activity that needs to use the connection. This works pretty well for me. You might want to choose this way too.
Actually i earlier realised a way holding the connection in the application, but now i prefer the service way, because i'm using the application for global states.
Using service also reduces the need of intents to a very small amount :)
In your case a static property for the bluetooth connection would be the most pragmatic solution
I am developing an application which has around 8 Activities, and a class which is used to connect/receive data to/from an embedded Bluetooth chip. When I started, a Bluetooth object was initialized in my initial Activity, where there was a Handler which received messages from the Bluetooth object.
After poking around on the internet for a while, it seems like the best idea for me is to turn my class into an Application subclass. However, doing this removes the need for me to initialize an object in the MainMenu, which removes my ability to pass it the Handler used.
Does anyone know of a way to eliminate the need for a Handler, so that every time the Bluetooth Application changes it state or receives data, the current Activity can access it?
My main problem with this approach is that the Activity doesn't know when the Bluetooth Application will be sending it messages, the Application waits and listens, and then notifies the Activity when it happens.
OR
Is it bad practice for me to write the Handler into the MainMenu, have it handle messages for ALL the different activities, and then pass the Handler from Activity to Activity?
I'm going to assume that you're trying to achieve the following as it's a little unclear from your question your ultimate aim (sorry!):
Your application has several activities but only one Activity receives the data from the bluetooth device.
The other activities in in your application require the data from the bluetooth device but are not receiving it directly from the bluetooth device. Currently you're providing the data via the one activity mentioned above.
You want to NOT use a Handler to achieve this.
If my above assumptions are correct then you are going along the correct lines but you probably do not want to use a Handler.
You are quite correct in having one Activity handle all the interactions with the Bluetooth device. It simplifies things and provides a much better, cleaner way of handling the Bluetooth device. However you need to get the data from this one Activity to all the others and to achieve this you would probably want to use Broadcasts, BroadcastReceivers and Intents. See here for an overview.
However if you can you might want to take a look at using LocalBroadcastManager as this keeps any broadcasts within your own app's space. Broadcasts are global and should be avoided if you do not need to pass the data outside of your own app due to security implications.
Finally, have you considered using Fragments for your other Activities? Another disadvantage with Broadcasts is there is extra overhead associated with them. If you're keeping data within your app then you can create an interface to be implemented by each of your Fragments and your main activity just calls that interface on the Fragment that is currently selected.
You can use BroadcastReceiver class to send broadcast messages to your activities. see here http://developer.android.com/reference/android/content/BroadcastReceiver.html
When you get the data you need into the application class, you can send it to the activity you want.. just make sure that the activity has registered to receive that broadcast message..
I've got a little gap in my knowledge here and I want to make sure I do it right before writing all the wrong code.
I have an Android app that extends Application to set up some core functions for a TCP client. There are a few different Activity screens that should interact with Application. What I'm stuck on, is what to do when a data packet is received by Application. I want to relay it to the currently-visible Activity, whatever it is.
Coming from a C# background, I'd just create an Event in the Application, and simply subscribe to that event when an Activity is created. But I'm getting confused with Java Listeners, Handlers, ...
What's the best way to go about that? Should I be doing a Service instead? (But I don't really care if the TCP connection is killed when the app is not shown.)
I would go with a LocalBroadcastManager (documentation) approach.
Create one of those puppies in your Application class, and register/unregister your Activity objects in onStart and onStop. See Context.registerReceiver. Note that this requires using Intents, which might be too restrictive/heavy-weight for your application; packing/unpacking data can be a chore.
Alternatively, you don't have to use any specific android class to do it--just keep track of what Activity your program is in by calls to your Application in onStart and onStop. Might help clean your code if you make all of your activities-of-interest extend a subclass of Activity that contains this logic.