There is some BroadcastReceiver , which is registered in the onStart method of onStart and deactivated (unregister) in the onStop method.

There is a service that sends an intent that should catch the given BroadcastReceiver and output data from it to the activit, of which the class is a field.

If the service sends an intent when the screen rotates, that is, when the receiver is deactivated, but not registered yet, then the data from the service will not reach activation (a similar situation will occur if the application is banal-minded during the download).

Tell me, please, how to handle this situation correctly.

Ps. Maybe in this case any other way of communication between the service and the activation will work. To be more specific and simplify the task, it looks like this:

In the activation, we press the button, the service starts, which downloads the text from the Internet and gives this text back to the activation in which it is displayed. The main goal is to deliver data from the service to the activation.

The task is quite common, I am sure that many have already solved it, but for some reason I cannot find a good solution.

  • The receiver needs to be registered through the manifest of your application, then it will always work, and not just when the activation works. - pavlofff
  • @pavlofff, In this case, if I understand correctly, the receiver needs to be implemented in a separate class, but it will not have access to the activation fields, and I need to update the activation from the receiver. - Burence

1 answer 1

Well, you can not connect the receiver and activate it, but in the fragment with setRetainInstance(true); - this command will prevent the re-creation of the fragment when the screen rotates. This is a practice recommended by Google for storing data in activation. I think for your problem this solution will do.

You, in general, need to store somewhere a state (for example, yes, in a service or a fragment of this) and display this state when activating. In general, for all this there is an architectural decision of the type MVP MVC etc). You can implement it yourself or use it. Mosby, Moxy, a lot of them. The essence is as follows: during the restoration, the actuation requests the service / presenter / singleton in the current state (there is data / no / in the boot process) and displays the status. In this case, the entity for storing the state, of course, should not be destroyed when turning. Such an entity can be the above mentioned fragment, singleton, service, presenter. No silver bullet. It is fashionable now to use the MVP approach. I personally use mosby liby. In the presenter, the state — in the life-cycle methods of activation, I request it from the presenter and display it.

  • If I use retain fragments, then the need for service, in my case, will disappear altogether. Yes, I know about headless fragments, but I don’t really like this solution. - Burence
  • @Burence, supplemented the answer - YuriySPb ♦
  • one
    This task is purely educational, designed for beginners and set in such a way that it needs to be solved only with the tools out of the box, so I think that there is some fairly simple and more or less correct way that I do not know about. In practice, yes, you can ( need ) use good third-party solutions, but I would like to solve this problem within the framework of the standard SDK. The singleton version is still appealing to me the most, but maybe someone will offer other options. Thanks for the detailed answer! - Burence
  • @Burence, try ServiceConnction to build. Those. You will have a callback connection with the service. And in the service all the data + state. Here in this callback and get everything you need from the service instance. So the receiver will not be needed at all. - Yuriy SPb ♦
  • As I understand it, there will be no sense from buying in this situation. With the help of this mechanism, you can call the service methods from the activit, but not vice versa . I also need to notify the activation from the service after it has loaded the data .. - Burence