in the App i am developing, i have a a layout with 6 TextViews, these textviews wil display data received at very high rate from a server. so far, i set the
values i receive to the textviews, but when i run the App. the data that textview displays are changing very slow because of the values sent at very high rate.
for an example, the server send almost 100 line in one second, and the datat in this 100 lines should be displayed by the TextViews..but because, as you noticed,
the high rate at which the dtat is being sent, the TextViews cannot show all the data by the time they sent.
What i want to do is, to be able to display these frequent data using the textViews but without lagging or delay in display the data, something like how do you see
the sensor data displayedin a textView.
given the above issue, does using the handler might help?
given the above issue, does using the handler might help?
To answer your question, this is what the docs say in regards to Handler:
There are two main uses for a Handler:
(1) to schedule messages and runnables to be executed as some point in the future; and
(2) to enqueue an action to be performed on a different thread than your own.
Honnestly, I don't see how the Handler could help you achieve what you are looking for.
Do you make your http request in a separate thread? (if not, then you should)
Also, I am not sure I understood the connection between the TextViews and the very high rate from server.
The handler is only a means of enqueuing a Runnable to be run in the Main Thread. You shouldn't plug the output of the server directly to the GUI, because you might be clogging up the main thread.
If you are downloading at high frequency, I'd suggest storing the downloaded data somewhere in memory (or persistence if needed), and have the GUI read this intermediate data at a slower pace.
Related
What is the best way of recording rapidly updating data in Android?
In my specific example I am trying to record various data tidbits whenever (acceleration) onSensorChanged fires, which is often. It's fine for some quick processing and displaying, but anything more (plotting or recording data) makes it rather slow. It's worth noting that I'm storing it in a variable and not to file.
You are advised to do as little as possible in an onSensorChanged, so I tried the following:
In an IntentService: Fetch the rest of the data you want to record and store all of it in a variable. Result: Even though an intent service executes in its own thread, only one can run at a time. Data thus seemed to come in quicker than it could be processed and would end up with a long queue of data to be processed, giving a long and constant stream of GC_FOR_ALLOC. Ultimately making it a bad choice
In an AsyncTask fetch the extra data you want to record and then start an IntentService for recording it to a variable.
Result: Pretty much the same as above.
Overall both of these methods were actually performing significantly worse than just doing the extra data fetching and recording in the onChanged, as well as consuming significantly more power. I haven't been able to find any concrete advice on rapid data storage. Would a buffer or cache perhaps be more efficient?
After some debugging and attempts at using different data structures for storing the rapidly updating data, it turns out that using the IntentService works reasonably well. Changing from an ArrayList with O(n) for adding new elements, to a custom LinkedList that just appended new values to the end with O(1) made a massive difference. As the LL is able to process the data so much quicker, the problem of a huge queue of pending values to record basically disappears.
I have quite much data to send to a server. The format is JSON and my platform is Android. I was wondering would it be wise to somehow divide the data in smaller packets, or send all the data at once? Also would it be good idea to run the sending code in a different thread? I use HTTPPost to send the data with Android
Creating smaller packets will cause a lot more overhead, thus a lot more data to send. Also, all networking should be executed on a separate thread (not UI thread).
Whether to use "many" HTTP requests or just one depends on your program flow. On one hand, you don't want to send data over the network that you are not sure you will need, so one catch-EVERYTHING post may be a bad idea. On the other, reducing the number of requests is going to reduce the overhead associated with each one, and thus result in less total time spent sending.
And yes, always perform network operations outside the UI thread. As far as the rest of the system is concerned, these are intolerably slow.
I am creating a simple android game that deals with multiplayer and connecting to server. This is what I want to achieve for my game.
Client sends keystroke movement to server.
Server accepts input, update the state and calculates and returns new position to client
Client gets new position and update the screen.
I already have some code written and so my one of my threads sends keystroke to server, waits for the new position, then update the screen. The thing is there is lag between the player's movement. I think it has to do with latency. I also tried two thread, one for sending/receiving data from server and another is updating the screen. But it didnt' solve my latency problem.
Can anyone suggest a good design for networking game?
Do I need to do early prediction?
Do I need separate thread for fetching data and rendering screen?
P.S.This is my first time creating a network game so i have no idea what im doing.
The structure I prefer to use is to have one thread updating graphics and logic on the client side, and then one thread receiving and sending data to the server. If you have problems with latency, there is a magic option which might solve it if you want data to be sent continously. (at least this is the syntax if you are using java)
mySocket.setTcpNoDelay(true);
This option solved my latency issues when I sent real-time coordinates over a network.
Edit: I think TCP by default waits and bunches together data before sending it, which could be a problem if you want to send small updates fast.
I am in the middle of developing an android application and I have stumbled across something that I don't really know the best way to solve.
What I wwant to achieve is, when a user logs into the application, I want to start a thread if the device is connected to a network(what kind of network doesn't matter)
The thread should perform an action every 10 minutes.
What this thread needs to do is, loop trough a list, a queue to be more exact.
This queue will have objects, and based on the objects in the queue when there is a connection available, execute.
The queue will be filled trough the flow of the application.
For example filling in a questionary.
The answers need to be synched to the server. Every question can include pictures takebn from the camera etc, so I want to save certain data as an object, put them in a queue, and have a thread handle the http requests. This way the UI won't be blocked. It's of great importance to sync whenever possible.
What I want to avoid is having another process run aside from my own APP. That's why I haven't used a service. Or do I missunderstand the concept of services as a whole?
Are there specific queue objects or lists?
I want to loop trough the queue list that can be filled at anytime while the program is alive, with a thread.sleep like method when the list is completely empty.
Please leave me hints and tips on what way to go with this.
A service isn't it's own process... from the Documentation: "A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of."
A service really is the best choice for what you're talking about. You spawn your own thread in the service that then does the following: check your queue for objects and send any to the server (since you're already not on the UI thread, you can do this without spawning yet another thread if you want). If the queue is empty, use a Timer to schedule another invocation of your upload method.
New to stackoverflow, been very helpful searching, but alas the time has come to ask a question.
I am trying to use an android 2.2 single core phone to do some research. I have implemented an algorithm that does quite a few calculations and produces a lot of data. These data must be processed, and the solution presented back to a client app within a 40ms time frame, then process again with new state data coming from the client. Also, the result of the calculations must be stored to the SD card as a data log. So being new to multithreading and android both, what should I use to do the following in my app: (As a side note, this phone, when in research mode is not intended to be used as a phone, phone will be in airplane mode with wireless off, and all apps that can be turned off will be turned off, and there is no need for UI display or interaction once it is up and running...)
need to process packets coming in over adb on serial port, these packets are state data that the program needs to perform its calcs on. These packets will be coming every 40ms, so I planned on using their arrival to trigger the start of the processing.
need to know if the algorithm is taking longer than 40ms and cancel it if so and send a message back on the serial port that it overran.
the calculation results need to be sent back over the serial connection via tcp and adb
The calculation intermediate data need to be recorded to SD. This can be quite a lot of data, on order of 140k, every 40ms.
So I have had trouble getting all the pieces together. I can't get my head around how a single core is going to keep up with all this going on at once?
So here is my thought, please tell me if I am headed in the right path. I am not asking for you to solve my problem, only any advice on how to break this beast down:
So i start a service to process the tcp packets coming in from the client
Use a service bound to the main worker thread to handle writes to the SD card
So assuming this setup, can i make the algorithm part of this somewhat deterministic so that it always runs if it gets a new tcp packet, and preempts the SD write going on in the background?
Argh...should have picked something simpler for my first program
Thanks.
Yes I think you are right, that it would be better to pick something easier for your first App ;)
But as far as I understand what you are trying to do, I don't think, that you need asynchronous multiprocessing. You get some data want to process it and pass a result. I think a HandlerThread is exactly what you are looking for. It is able to recieve Messages
with data inside. You send them to the Handler and process them in an overridden handleMessage(Message m) method. So everytime you recive a Message you could just log the Time
and see if the last one is older than your limit. If it is, you could just throw the Message or the whole queue, or send a Message to your serial-port inicating the overflow.
This could be implemented as you suggest in a Service. Another HandlerThread can be started with Thread.PRIORITY_BACKGROUND to write everything to SD.
You can send Messages even very compfortable if you apply a Messenger to the Handlers