Skip to content

Faq

Jump to bottom
Yigit Boyar edited this page Nov 14, 2013 · 8 revisions

Why not use AsyncTask or Loaders?

They are OK to offload work to background threads but are not OK to make web requests which are quite unreliable. On the other hand, they are really good to load data from disk, which you should use them for.

Why jobs don't have a callback?

Well, technically you can have jobs which can have a callback field as long as job is not persistent. On the other hand, callbacks are very dangerous, especially when they are used to update UI (thus bound to context). It is so easy to leak activity context due to a background operation taking too long. + if configuration changes, the callback is obsolete. You need to keep a weak reference to your callback not to leak the context but then you also need to ensure that there is a strong reference to the callback from the context so that callback won't be GC'ed by mistake. These are things which will work 95% of the time and you'll hit your head to walls when that 5% happens. (e.g. GC runs). This is why we highly discourage usage of callbacks and we never use them other than loading data from disk (which takes fairly determinate time) or we want to block the user and OK to manage activity lifecycle manually.

Why not use just a Service ?

  • First of all, you can run Job Manager inside a service, it is completely up to you. We didn't want to enforce anything. If you want to compare Job Manager with a simple service, here are the extras you get:

    • Job Manager takes care of persisting your jobs on disk. So if your user sent a comment, when job's onAdded method is called, you know it is on disk and will eventually get synced back to your server.

    • You can mark your jobs as requires network. In this case, Job Manager won't try to run them until network is recovered.

    • You can fine tune job manager depending on your environment. You can change # of concurrent consumers depending on circumstances.

    • You can group certain jobs not to run in parallel. For instance, if you have a messaging client, you can use receiver id (or conversation id) as the group id of the job so that any message that is sent to that receiver will be sent 1 by 1, first come first serve. On the other hand, if there are messages sent to different conversations, they will be sent in parallel, maximizing network utilization w/o corrupting data.

Clone this wiki locally