I have to acknowledge that most of our approaches in dealing with new projects is first by scouting the existent adjacent solutions. So there is a pattern of looking at open source applications, existent applications, failed attempts or dead-end/collapsed applications. In mobile applications, because we are multilingual, we scan Google Store, and even MS Store for that reason.
Another scouting way is to read books in the domain (heard of Game Programming Gems ?). With Android there is the pain, where most of the books are rehashed facets of the documentation with short incursions in attacking real life problems. I will exemplify with a notorious example of using AsyncTask .
The main problem with using AsyncTask is the fact it crashes as it was originally designed. And here comes your ingenuity of sidestepping the problem which were not even envisioned when the API was designed (the solutions were suggested by third parties, our effort was just to collect and judge them):
- use a static fragment to retain AsyncTask during screen rotation or configuration changed
- pass an interface to the AsyncTask instead of the context base of the activity
- use weak references and check if the post back calls have an end-point listening (mainly screen updates)
So what we wonder is why the API designers are not exposing (after N months of crying wolf from app developers) the problem and create an update version ? I don’t want to talk about authors of Android books who leave them without updates for years (hey Google map users, did you like version 2.0 ?).