AsyncTasks are pretty useful. But when you submit them for execution, you should know what you’re getting yourself into. Regarding the order of execution for AsyncTasks, documentation states:
"When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution. If you truly want parallel execution, you can invoke executeOnExecutor() with THREAD_POOL_EXECUTOR."
Cool - seems simple enough. Calling execute() will queue your AsyncTask onto a single thread. But this can be problematic. Consider this example:
// this might take a long time AsyncTask fileDownloadTask = getAsyncTaskToDownloadLargeFile(); fileDownloadTask.execute(); // this should not take a long time AsyncTask databaseQueryTask = getAsyncTaskToMakeQuickQuery(); databaseQueryTask.execute();
What’s wrong with this? Your quick database query task we will blocked by your long file download task. This is bad.
How to remedy this? It’s easy: NEVER use execute() and ALWAYS use executeOnExecutor().
If you need things queued up serially pass SERIAL_EXECUTOR, otherwise pass THREAD_POOL_EXECUTOR. You’ll need to do a little more thinking, but the end result will be a deliberate choice that YOU make.
Why not always just use THREAD_POOL_EXECUTOR to avoid blocking other AsyncTasks? Using the SERIAL_EXECUTOR is an easy way to get the functionality of a barrier without actually using a barrier. If you need multiple pieces of information fetched before you can do something, you can queue them up on the SERIAL_EXECUTOR. When the last task queued is done, you know the others must have finished running too. That said, you should still call executeOnExecutor(SERIAL_EXECUTOR) instead of execute() in this case!
Happy safe – whether serially or parallel – coding!
I watched about a metric ton (i.e. 18 series) of anime in 2013. I caught up on some of the hot series from previous seasons so most of the anime I watched I really, really enjoyed. Here’s a breakdown ranging from must-watch series to skips:
Your life isn't complete until you watch
- Welcome to the NHK
Great - Definitely worth a watch
- Hataraku Maou-sama!
- Knights of Sidonia
- Madoka Magica
- Sword Art Online (Part 1)
Good - worth watching if you like the genre
- Aldnoah Zero
- Kill la Kill
- Log Horizon
- No Game No Life
- Shingeki no Bahamut
- Sword Art Online 2
Decent - would recommend these under specific circumstances
- Akame ga Kill!
- Angel Beats
- Psycho Pass 2
- Tokyo Ghoul
- Zankyou no Terror
Skip - I wish I could forget I watched this
- Sword Art Online (Part 2)
That’s a rough breakdown. I found myself moving stuff between the great and good group and just stopped after a while. Depending on your preferences some of these may be more or less appealing. Let me know if you have any questions or want to know my thoughts about any of these series.
On the horizon, I’m very pumped to watch the second season of Aldnoah Zero and Log Horizon!
Today, I removed all of my 2 star and 1 star reviews from Yelp. Why?
It’s not that these establishments didn’t deserve the reviews I gave them. It’s because I categorically refuse to let my words be used as ammunition for dirty practices.
For a while now, there have been complaints that Yelp was modernizing extortion by asking businesses to pay for advertisements – as in, we’ll make sure good reviews are seen more, and bad reviews are seen less. Like every other business out there, Yelp’s trying to make money. But I’m absolutely not okay with Yelp threatening businesses with my reviews. Businesses that got a shitty review from me don’t need to invest their money in ads: they need to invest it in cleaning up their fucking act.
Why not remove all my reviews and abandon the service altogether? I just can’t bring myself to do that right now because no other service compares to what the Yelp platform offers. Yes, these practices suck, but from now on, Yelp will get no bad reviews from me.
Removed reviews are available here for your viewing pleasure. Perhaps in the future I’ll spritz up their presentation. Any establishments getting a rating of 2 or 1 stars will henceforth be put in this notebook.
I know this may inconvenience some, but when I’m dishing out the unfortunate truth, I want to be in control.
The recommended way of building a Settings screen in Android is to define preferences in an XML file and then load that file in a PreferenceActivity or PreferenceFragment. But that only works if you know all your preferences at compile-time. And sometimes we don’t know them. Sometimes, we want to be a little more flexible with preference loading.
As expected of Android documentation, we are told, “Your app’s settings are generally pre-determined, although you can still modify the collection at runtime,” but then given no documentation as to how to add or remove things from the collection. Typical.
Fortunately, it’s not difficult to do this. Enter flexible_preferences – a short Android application that shows you how to do gymnastics with Android Preferences. Tricks include:
- Uses a custom layout file so you can show stuff besides the preferences like a loading spinner if you’re fetching preferences over the wire.
- Create preferences without an XML file!
- Hide and show preferences based on input (e.g. hide all other preferences if we toggle one particular preference to the off state).
And the best part (besides using the OP LinkedHashMap data structure) is it still leverages Android’s built-in preference functionality, so you get a lot of stuff for free!
My friend Spencer asked me if I could beta test Mini Audicle for iOS. I agreed and asked him if he had any performance monitoring tools set up. Long story short, I ended up integrating Crittercism (my favorite crash monitoring tool) into Mini Audicle iOS so he could collect crash data from every user.
One important part of the Crittercism integration process is uploading dSYMs - debug symbol files. For release builds, debug symbols are removed to reduce the binary size but this makes crash logs much less useful. Fortunately, dSYM files help us decode (symbolicate) these crash reports. It’s super important to upload dSYMs if you want to make any sense of stack traces.
Fortunately, Crittercism provides thorough instructions on setting up automatic dSYM upload, but it’s not all sunshine and rainbows.Read More