Good Practice Fragment and Service

Asked

Viewed 332 times

0

So personal the question is the following..

I have an Activity connected to a service.

I want to start a fragment and that fragment will perform functions within the service.

What would be the best practices to perform functions in the service ? Some example ?

  • Could you tell us what functions the service will perform to help us better understand the problem? Another thing, keeping an Activity coupled to a service has poor performance, I suggest rethinking this architecture, maybe using Broadcasts.

  • @Piovezan, really it is not good to do bind of Service in Activity? Do you have any sources to back up?

  • @Wakim Just my own experience. It caused slowness in devices low and mid-end. Perhaps it was characteristic of the application, which performed coupling/decoupling of activities to a service throughout the life cycle of the same. In any case, I switched to Broadcasts and improved a lot.

  • Well I use the service as follows. So when creating the service I start a new thread that gets every time makes an online check. This same service is also in charge of updating a database. Once the service finds new data it inserts into the database and gives a broadcast warning the application if it is active to update the new data. Fragment uses the service connection in case bind to query the database ( basically to read the messages )

  • Isn’t it worth taking a look at Loaders (instead of making bind)? You would have a Loader + Contentprovider (connected to the bank), when the Service updates the Bank using Contentprovider, it can notify the Loader and updates the Fragment automatically (through callbacks).

1 answer

1

There are several points to weigh.

In fact @Piovezan not bad, depends on what needs to be done.

If you need to perform functions independent of Activitys create the service without bind, so even with the application closed the service will continue running.

Now if you really need to switch information from Activity to the service it needs to be bind and not add a fragment to it just relay the information.

  • The bind is not mandatory but ensures that at the end of Activity the service also stops, in case of dependency avoid errors.

The problem of using Broadcasts is the runtime that should be up to 10 seconds to not lock the application, so it is not feasible to do this unless from the receipt you create an Asynctask or make sure that the execution will not go beyond that!

  • The problem with 10 seconds is that after that time the system kills the receiver. In the case I used service Broadcasts for Activity, and there were no problems because it was just a quick stream of information. There was no reverse route from Activity to service, so I didn’t have to worry about that, but if I did it would be by Intent.

  • In both cases Broadcast would not be recommended if it was not sure of the execution time. As in your case you were sure of this information, you really won’t have any problems. One thing I noticed about low devices when you stay it off (off screen) for a long time on the back it ends up taking longer than usual. An Activity or service that sends Broadcasts on Screen On will give error. What not always occurs but occurs!

  • A while after the screen shuts down the CPU enters Sleep mode. However, off screen and CPU in dormant state are two different situations. For the broadcast to work it is important that the CPU is awake, which has nothing to do with the screen being on or not, because the CPU may be awake even with the screen off depending on the Wake lock that is used, or when data arrive via mobile network. The error you talk probably has to do with the CPU not running the broadcast due to the dormancy state.

  • I explained in the other post how I defined the use of the service.

  • This is if you use Wake Lock. It is not recommended by Google itself unless it is really necessary. A basic application should not use Wake Lock.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.