I have IP client application which has the following objects:
Socket instance connected to IP server.
Thread instance, executing ThreadFunction. This function continuously reads the socket, when it is connected.
Now I am trying to understand, what should I do, when activity is recreated (for example, after changing screen orientation). Is Socket instance lost? What happens with ThreadFunction? Looking at the other side behavior (IP server), I see that the client, Android application, is not disconnected. So, what should be my strategy in this case: should I create these resources again, or try to restore them by some way?
The answer to your question related to what happens to the resources when the application is destroyed, is that everything goes away, including sockets and runnables.
Even from the server side, the socket will be gone as soon as the server try to communicate over it.
Your best solution, as said already is to manage it using a service. It's quite similar to use an activity, and I encorage you to see a couple of examples.
If you realy want to make what you have now consistent without using a service, you may disable the screen rotation adding android:configChanges="orientation" to AndroidManifest.xml
I recommend using a Service. It is designed to do what you are asking.
Related
If two (or more) devices are connected to the same network, and each has my apk installed, how might one device efficiently 'talk' to the other? Google Play services, Wifi Direct, and bluetooth is unfortunately not available on these devices.
I thought of using a 3rd party push notification service, but ideally I need the response between either device to be as fast as possible, and long-lived.
I have managed to get two devices sending messages to one another using the old client-server Network Discovery Sample app in the docs. However, if either of the apps is closed or leaves memory, the connection is obviously broken. Therefore I'm trying to figure out if this is possible through a Service, which I understand exists outside of the Activity lifecycle.
I understand how an Activity might connect to a Service to send a message (good sample on that located here), but from what I gather this all happens locally on the device. Is it possible to have this exchange happen over a local network, from one app to another? I guess what I'm saying is how can I set up a basic client server socket relationship between two apps that won't die?
It has been a long time but it should still work.
The problem here, as I understand it, is to have something that keeps running when the app is gone.
I remember using IntentService for this purpose. In the onHandleIntent() we made it loop while(!stopCondition) {...}
It was a stable solution then but it was around kitkat's time.
I'd try with the solution in your first paragraph being executed and managed by the IntentService which should keep it available.
I recently set up a web service using LABVIEW which exhibits a bunch of shared variables which can be changed via buttons in the LABVIEW program itself.
Apart from this I would also like to control the shared variables via my Android phone.
Actually, this works pretty well and I can also see the LABVIEW button's state change when I click the Android buttons within my app.
My question is now: Up to now the LABVIEW buttons' state is only updated but the other way round doesn't hold true. How can I make the Android buttons' state change when using the LABVIEW buttons?
Do I have to employ IntentServices or do I have to use GCM (Google Cloud Messaging) etc.?
I dont know exactly how LABVIEW works but basically you are providing some server-client communication functionality. So there is no magic way of updating your android's application state based on changes happening on the server side. basically you will have to follow polling or pushing approach.
Either your application can ask the server periodically (poll), or your server has to notify the client when the changes occur (push). The first approach is simple but will eventually drain your battery quicker, meanwhile pushing messages from server to client is more elegant but requires greater efforts.
How can I make the Android buttons' state change when using the LABVIEW buttons?
Using poll or push approach.
Do I have to employ IntentServices?
You dont have to. But eventually your notification mechanism will reside on a service. it might happen that IntenService is a good solution but depends on your requirements.
Do I have to use GCM (Google Cloud Messaging)?
You dont have to. There are other solutions as well such as establishing yourself a socket level communication.But GCM might be quicker for your case.
I'm a beginner in android development and I'm trying to implement an android udp client, which connects to a java server and sends/receives some packets from it.In this process it collects some data (like round-trip delay etc), which is used to measure the QoS of that particular network. I have tried implementing the connection and sending/receiving data using Java Threads, but the application crashes, and hangs if i try to use more than 2 threads. So I'm looking for alternatives. While going through this site as well as some other links I found that in android multiple threads can be implemented using AsyncTask, Handler etc. Also I found that the Service class also helps to run a background service in an app. Please suggest which approach among these would be the best to achieve my purpose.
Thanks in advance.
You can use AasyncTask to do this and as you mentioned service may be useful too, where u can let your application do whatever it wants in background , if user needs to use application by its interface then AsyncTask must be used to avoid Crashing
There is not one right answer that can be applied as a broad stroke to how to do Android multi-threading. There are a few different ways to approach it based on what your specific needs are.
Any long running, blocking call, in Android will result in the application crashing.
The most common solution is to use an AsyncTask though. For example, when I want to make a call out to a web API endpoint for some XML data within an Activity I would in this case use an AsyncTask and kick off the calls from within doInBackground.
This is not an appropriate solution though if the wait time is longer, or possibly an unknown wait time. Or in a situation where there will always be waiting such as a message queuing service. In this type of situation it may be best to write a separate app based on extending the Service class. Then you can send/receive notifications to/from the service from your primary application in a similar manner to how you would communicate with a web service.
I'm working on an Android application interacting with Arduino. I'm trying to manage multiple activities, each one being responsible for controlling a specific part of the Arduino board.
Unfortunately, tutorials on the web use only one activity. So I don't know how to proceed for keeping the connection with Arduino alive while navigating to a new Activity or for closing it properly and then re-open it on the new Activity.
Any idea?
You could use a Service to connect to Arduino and to keep that connection open. Your Activities can then talk to the Service, being started, stopped, switched, etc.
EDIT: How this can be done is already handled by another question/answer:
Long running ADK Accessory (Service?)
I haven't used Arduino with Java before, but you might want to follow a Singleton pattern. Using a Singleton pattern, whatever objects you are using to connect to it can be accessed from multiple activities and multiple threads.
Using a Singleton will only alleviate your problem though. You still need to figure out how to close/reopen it.
Also, it is important you know how the Activity Lifecycle works. If a user receives a phone call, the screen turns off, or the orientation of the screen changes it will destroy your activity and recreate it. You'll have to handle how you're going to save and restore where you were. This will most likely mean you have to close/reopen the connection.
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