I have an Asynctask class and two activity classes. First activity handles authentication and second is for chatting.Now i want to share same AsyncTask with both activities without loosing connection to server.I tried it with each activity and it works fine but when i switch activities it keeps sticking to first activity.I want to get results in both activities. What is the proper way to use AsyncTask class with multiple activities?
And what about using service instead of AsyncTask.
You may try one host Activity with AsyncTask and two Fragments (authentication, chatting). Fragments will get result indirectly from the host Activity.
Be aware of AsyncTask pitfalls.
In your case the cleaner way is to use service.
Related
I was looking at saving some data to my Room database and was reevaluating as there are some places in my repositories where I am extending AsyncTask (I'm still using Java) and wanted to check on the state of things to see if it was a good time to swap them out. I saw this reference in the Android developer site on Approaches to background work.
All persistent work: You should use WorkManager for all forms of
persistent work. Immediate impersistent work: You should use Kotlin
coroutines for immediate impersistent work. For Java programming
language users, see Threading on Android for recommended options.
Long-running and deferrable impersistent work: You should not use
long-running and deferrable impersistent work. You should instead
complete such tasks through persistent work using WorkManager.
I started using WorkManager for an API which needed to be called, but for which I could not rely on network connectivity. Because I'm using Room, which is persistent, it seems like I should be using WorkManager.
It defines persistent work as:
Persistent work: Remains scheduled through app restarts and device reboots.
A database insert/update/delete is persistent by this definition. Scheduled throws me off a little, as I want it to be immediate, but according to this chart that would still apply.
Is anybody using WorkManager as the mechanism for CUD operations in their repositories and if so, do they have an example?
It would be great to see how this all works in an update fragment. If a single item is selected and I am viewing it in a fragment, when changes are made I would need to update the database using a Worker class and view the data using a LiveData object, correct?
Inserts and returning the id (or object) would be interesting to see as well.
I have noticed that some applications like firefox/iexplorer/windows image viewer etc are not creating new processes for new instances of the application. To explain what i mean i would expect that when opening two instances of firefox for example there would exist two different processes. Some other applications i tested had a process per instance.
My first question is why would someone use the one process multiple instances model? It seems a lot more complex to me than having an instance per process. I suppose that one reason may be resources usage.
My second question is how would you implement something like this? Assigning some threads to the new instance for example?
Firstly, one process for multiple "instances" keeps all the processes memory in one place, removing the need to use IPC to send messages between different "instances".
To implement something like this you can use the CreateMutex API here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
If the mutex already exists and another instance of your app is launched, you can just forward the app open call to the existing instance of the app.
I have an app which needs almost no user interaction, but requires Geofences. Can I run this entirely within a background service?
There will be an Activity when the service is first run. This Activity will start a service and register a BroadcastReceiver for BOOT_COMPLETED, so the service will start at boot. It's unlikely that this Activity will ever be run again.
The service will set an Alarm to go off periodically, which will cause an IntentService to download a list of locations from the network. This IntentService will then set up Geofences around those locations, and create PendingIntents which will fire when the locations are approached. In turn, those PendingIntents will cause another IntentService to take some action.
All this needs to happen in the background, with no user interaction apart from starting the Activity for the first time after installation. Hence, the Activity will not interact with LocationClient or any location services.
I've actually got this set up with proximityAlerts, but wish to move to the new Geofencing API for battery life reasons. However, I have heard that there can be a few problems with using LocationClient from within a service. Specifically, what I've heard (sorry, no references, just hearsay claims):
location client relies on ui availability for error handling
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread
When I've investigated, I can't see any reason why this would be the case, or why it would stop my doing what I want. I was hoping it would be almost a drop-in replacement for proximityAlerts...
Can anyone shed some light on things here?
The best thing would be to just try it out, right? Your strategy seems sound.
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread.
I know this to be not true. I have a Service that is started from an Activity, and the connection callback is called.
I dont know about proximity alerts; but I cant seem to find an API to list my GeoFences. I am worried that my database (sqlite) and the actual fences might get out of sync. That is a design flaw in my opinion.
The reason LocationClient needs UI, is that the device may not have Google Play Services installed. Google has deviced a cunning and complex mechanism that allows your app to prompt the user to download it. The whole thing is horrible and awful in my opinion. Its all "what-if what-if" programming.
(They rushed a lot of stuff out the door for google IO 2013. Not all of it are well documented, and some of it seems a bit "rough around the edges").
I am currently writing on an application which requires me to compute something which will take some time to complete. Therefore, I am doing this computation in the background. I now implemented a solution which starts new Threads for each such request via an ExecutorService. These threads regularly report their progress back to a (volatile) IModel. Additionally, I am using an AjaxSelfUpdatingTimerBehavior which updates the website by printing the progress which is represented by this IModel to the screen. By doing so, the website stays responsive, the task can be interrupted by a button click and the HTTP request which was requesting the long lasting task does not time out.
However, Wicket does not like non-Serializable references in its WebPage or Panelinstances and I wonder what would be the best way of solving this problem. For now, I wrote a little manager class which uses a cash which is referenced by a static variable which is how I am avoiding the serialization restriction. The WebPage instance which was triggering the task now only holds a reference to a unique ID which was assigned to it by my manager class when invoking the task.
Of course, with this approach I have to clean up after myself and I am also concerned about security, since I did not yet take actions to avoid interferences of tasks started by different users. Also, it just feels wrong to me, since I want to keep this task on the scope of the WebPage instead of letting the task escape into a global environment. I am sure, there is a better way to do this!
Thanks for any thoughts on this matter and for sharing your experience!
Your approach sound perfectly reasonable: Pass the task-handling to a non-web instance (could be a Spring managed singleton) and just keep an identifier in your component/model.
What is the purpose and usings of shared services in prism ?
What things can make me think that I have to use shared services instead of EventAggegator?
Looking at EventAggregator from an event subscriber point of view, it's good for getting notified about certain events that occur in the application. This way you're performing an operation passively, i.e. whenever someone else publishes an event. You'd like to use EventAggregator when you need to react to something happening in your application.
On the other hand, with shared services you can actively perform operations and request data. For example, you could have a shared service that exposes a GetData() method, and you could resolve this service and ask for the data actively, any time you need it.
I don't know how other using it but I used it a lot for modularity of my app. For example in Silverlight application for security reasons only OpenFileDialog could return Stream to file. So I just build an IOpenFileService service and plugged it in constructor to any ViewModel that need to open a stream to file. It's also suitable for various Loggers and even Database layer.
Another useful part of services is that they could be build and tested independently from other modules. MEF/Unity will provide all the glue to insert ready objects inside constructor or properties of other objects.
And don't forget that the service class itself could use MEF/Unity magic and insert other services to itself.
And for EventAgregator: You code could became overloaded with various Event definitions very quickly. For example Resize event. On Silverlight app initialization the PRISM Region controls is slow process so the Regions was attached to VisualTree very late and somehow they missing the initial Resize event . I provided the internal Resize event for Region (via EventAgregator) and then another Resize event that each Region control will send to it's children to resize themselves to Region control boundaries. It's 2 Event classes just for Resize...
We have used both, but generally use shared services when the functionality is more than just a simple notification - we also use EventAgregator from within our services in some cases.
For example we have a service for scanning in documents :
public interface IDocumentScannerService
{
}
public class DocumentScannerService : IDocumentScannerService
{
}
This would be a pretty bad design to try and implement this with EventAggregator.