I am developing a testing application on an Architecture which is based on Producer-Consumer structure. I have an producer-consumer* problem, especially if an producer callback mechanism is utilized in android service i.e. consumer. Consumers are not supposed to hold the call for more than the minimum necessary time to have the info handed over. Since the producer’s callbacks are supposed to run in a different thread than the consumer’s one.
In my specific case within the callback of Producer only a reference moving of the passed object should be done and release the control right away. The object has to be consumed in the consumer thread. Currently I have been calling a method which only gets data coming within callback and processes that data and return it via Intent baack to the Android Activity.
Now, Android intents are well known to be resource consuming entities which are not meant (and not supposed) to be used to transfer data streams.
Within the Test app, one intent per callback is generated. Those overflow the whole system. For example, at 25% of load a traffic of about a thousand Android intents per seconds are triggered.
I want a way which doesn't include Android Intents(without any Thrid party jar) using which I can send data back to my android activity or route on host machine at super high rate so that my producer call back doesn't get crashed.
Use a socket connection between the Service and the Activity for streaming data. Intent is the wrong technique.
Related
Currently im learning how to use RxJava. I fully understand the concept of the reactive Programming paradigma where the programm needs to react to certain types of changes (Userinputs, Sensordata, etc.)
A lot of Tutorials and even the RxJava Github page explains RxJava in a very Simple way of creating a Observable and Observer. Subscribe the Observer to the Observable and you get the Stream of Data you just created manually by yourself. So like i see this, everytime i restart the Programm / App my Observer Subscribe --> gets the Data --> and then receive the onComplete. Does that mean, that the Observer is still subscribed to the Observer at this point? Or does a OnComplete Message unsubscribe the Observer?
I just cant get my Head arround this. I think of a Program (App or Backend Service) that get random Sensor Data from a Local Arduino. The Sensor Data comes in at random Time in total random variety. Can i do a one time subscription and as long the Programm runs (on my Server or on my Smartphone) the Observer is subscribed to the specific "sensor Data" Observable and even on Complete (After receiving the arriving data) its still listening for the next data that eventually comes from the sensor?
Is that right? Or do i have some kind of missunderstanding?
Once you get onComplete, stream is considered as terminated. Check:
http://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/Subscriber.html#onComplete()
Let's say a service 'MyService' is already running, doing some work like copying a file in background, before an activity, 'MyActivity' is launched. Then user launches the activity. How can I retrieve what file is being copied in MyService when MyActivity starts so that I can show it in UI?
I haven't attached a code because I want a generic answer to this. The task could be anything, like downloading a file. I'm learning coding and experimenting with services. So, I'm just copying a bunch of big files in a service.
If needed, I'll post the code.
A possible solution to this is to have the service expose a RxJava bus (or similar) where it pushes updates on what it is doing. Then the Activity will subscribe to this bus in onResume and unsubscribe in onPause and will display info based on what is being pushed on the bus.
You could have a single bus, where the event itself carries data (like the percentage of copy), or you could have multiple buses, for instance one for state (idle, copying, ...) and another one for details on the state (like a bus for percentage of copy done).
A possible implementation for the states would be
sealed class State {
object Idle : State()
class Copying(val percent: Float): State()
}
then in your Service you would have
val stateBus = BehaviorSubject.create<State>()
then
stateBus.onNext(Copying(.5f))
I am learning Android app development from Udacity.com by Google engineers and they said,
"It is not a good idea to use 'AsyncTask' as it is not attached to an activity life cycle. The virtual machine will hold on to the activity object as long as the Asynctask is running, even after Android has called onDestroy( ) method for the activity and expect it to be discarded.
If you rotate your phone, the behavior is to destroy the current activity and instantiate a new one. The naive AsyncTask implementation now has two threads trying to do the same update. So it is not the best pattern for a potentially very long running background operation , such as fetching from web services. If you leave the app, the asyncTask will run as long as as the process is kept alive , but will run at a lower priority, and your process will be the first thing to be killed if the device needs more resources. "
1) If using AsyncTask is disadvantageous why was it created? What would have been the design philosophy or the cause to create it in spite of having services(or something similar to achieve same kind of functionality)?
2) What are the situations where Asynctask should be used for betterment compared to Services/similar options available in Android?
3) What are the situations/places Asynctask should never be used?
Please do not downvote this question. I searched Stackoverflow and I couldn't find a similar question.
Advantages of AsyncTask
Provides generic solution for all network calls
Publish progress to UI while executing.
Run Asynchronously
Easy to maintain and read.
Problems in AysncTask
When you rotate your screen, Activity gets destroyed, so AsyncTask will not have a valid reference to publish data from onPostExecute(). In order to retain it, you need to usesetRetainState(true) if calling from fragment or onConfigChanges() if calling from activity method of an activity.
If activity gets finished, AsyncTask execution will not cancelled automatically, you need to cancel them else they will keep on running in the background.
If any exception occurs while performing network task, you need to handle them manually.
Whereas AsycTask, Services, IntentService, Threads all run on different threads and all serve different purpose.
please read more detail here.
So you need to decide when to use which component while performing non UI operations.
What is the generally preferred method of using GCM in its current state?
The documentation only talks about using it with a BroadcastReceiver and only mentions Services in one sentence without further explanation.
In my application, I need to be able to react to an unknown number of successive GCM messages and queue them so I can process them one by one. This processing needs to be done in order the messages are received in.
This cannot be done with a BroadcastReceiver, as for every broadcast received, a new instance of my receiver class is created (this was the method I tried first as per the getting started guide). Can it be done with a service or, more precisely, is the instance of my service kept between messages received?
If so, when and how does this service need to be started, added to the manifest, etc.?
I do not need to interact with my main application/UI. The service can do its business on its own.
GCM message comes as broadcast so you must use BroadcastReceiver. If you need to queue them for any reason. just make your BroadcastReceiver hand the message to IntentService or anything else you find suitable for your task.
I have a small Android app that I have been working on that logs GPS data to my SD card in a GPX file. I currently have a main Activity that starts a Service to do all the background work. The service is kept in the foreground in the notification bar to make it the least likely thing to be killed by the OS. Currently I am requesting location updates from the service at the maximum frequency to get the most accurate route. The problem I am having is my User Interface is acting slow/strange. Correct me if I am wrong, but what I have concluded is that I have too much going on in the main thread of the app. My next thought is to try and move the service performing the acquiring and logging of data to a separate thread. I am new to Java/Android so the whole topic of interacting with separate threads is hard for me to wrap my head around. Initially in research I came across IntentServices, which are supposed to make threading easier, but from what I read these don’t seem to mix well with the Android location package because they don’t run long enough. I feel like I am running in circles with internet searches on this topic. I desperately need some guidance on how to achieve the following features for my programs service:
Separate thread from Main Thread
Fetching and storing of data must be the least likely thing to be killed by the OS and run indefinitely once started (don’t worry about battery I will have the device plugged in to power while running the app)
Eventually I will need the ability to interact with the User Interface
Thanks for any help you can offer!
this is a common problem that i have accomplished a lot on
in the launcher or main() ( what Android is calling an Activity ) you do as little as possible ( which amounts to saving the the refs they give you and maybe setting a few other things as long as you are there ) and do ^not^ drop in to a long-running activity
A Service is exactly what you need but instead of trying to pump it into a "hold on to it" state what you do is implement checks for nulls and handle as needed -- trying to "fix" a machine to make it run the way you want here actually involves rescinding you hold on the main thread and letting it go as fast as consistent with the Applicaton's general constraints.
To do this you can simply write a Service - reading everything available - then extend that service and implement Runnable then you run the constructor on that code from the Activity Constructor and do new Thead(yourClass).start(); in the onCreate() checking for Thread.isRunning() before starting it again ...
Service will have an onCompletion() call in it somewhere - it will go through an interface
All this is done in Android in something like start activity for result then you just to the UI stuff in that call or sorta figure out a way for the GUI to get called somehow at some time then check to see if Service is done an so report in the gui