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.
Related
In terms of Android mobile development's extends Application, would it be possible to create a Websocket listener (Socket.IO, etc) in the application for notification, while also creating a flag in the extends Application class, while ALSO having the class or fragment of some sorts that displays the actual data to have a while loop of the flag from the extends Application class to lets say refresh the data display? Or is extends Application static in a way and the live time updates cannot work?
From what I know, yes. Yes it is possible to utilise the Application class to listen for external events. Application instance lives alongside your app. So in theory it is feasible to use it as a somewhat listener and then dispatch the events to the currently resumed Activity/Fragment.
That said, I don't think deriving Application just to act as a listener would deemed as a good practice. Android has provided the Service class which was built for these use-cases in mind. Put simply, they act just like Activity but without any UI whatsoever.
It is where I think would be the best place to listen for events. You could then command the aforementioned Service to fire off a Broadcast whenever an event of interest is being detected. After all of that, what is left is to assign a BroadcastReceiver in your Activity/Fragment and update its state according to the event you've just received.
I have a class called FlashlightFragment that allows the user to control the flashlight.
The problem is that the user can turn the flashlight on or off from a number of places. Since all changes to the flashlight pass through a class called FlashlightHelper I want to broadcast a message from it that can be received anywhere on my app. I remember there was a way to do this but I cannot remember the name of the feature.
Basically I want to send a message like: "FLASH_ON" from FlashlightHelper and then set listeners on different fragments and activities on my app that can receive this message.
How is this done?
I won't specialize to the specific situation that you face but instead answer the question in general: How to send a message from one class to another (or to many others).
BroadcastReceiver
Intents and Intent filters
... These are the main methods that will probably be enough for you. Then there are software engineering patterns such as The singleton pattern that will do the trick, but I ll stick to the first to If I were you.
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.
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.