Er.... like almost all the time. Getting used to them means that you read code in a slightly different way as well, so I highly recommend it. That said, I do t

Er.... like almost all the time. Getting used to them means that you read code in a slightly different way as well, so I highly recommend it. That said, I do try to avoid them as long as it doesn't degrade user experience. However if you're going to build an app of any great consequence you're probably going to need them. A big help (if you're new to them) is viewing the threads as players in a turn based board game where your lines of code are squares on the board and everyone gets a random roll. Some uses (personal (of various sizes) and enterprise): - Background worker that wanders off, does some shit and then says: "yo, I finished". - Subsystems and services: Sometimes you just have "stuff" that is going on. An example would be a little doohickey I got monitoring the USB. It handles a little protocol so it can identify stuff our system knows about that gets plugged in (on any port). This is so when the "main" part of the app asks for an "external XYZ" device it can return the device (or a "null" Object if it is not connected). - To preserve your intentions: If you broadcast events with your own thread it is possible for a consumer to chomp on your thread's processing time, so sometimes you need to spin off a background thread/s to do the event firing to free you up so you get back to your job.