StackOverflow Programming

Programming is my profession. I am doing this for a long time (damn, its over 30 years by now).

In the early stages of my career, the way to learn the trade, was by one of three ways:
- get subscription to some early stage hobbyist magazine (I fondly remember Byte magazine)
- get some books
- get a mentor

I was lucky enough to have a great mentor that introduced me to the field - my uncle Dani who was a programmer in the 70s doing really cool stuff (real-time, complex systems that were ahead of their time). He introduced me to object-oriented programming before it was IN, using languages as Forth, and Modula. He helped me get my first Mac (the cost of which was like a used car here).

Anyway, at that time you had to read a lot. From paper.

Fast forward 15 years, and the internet was taking the stage.

Now, knowledge quickly started to spread, be shared, and be available to everyone.

Fast forward 15 more years, and now our brains are re-wired. We don't remember anything we learn. We don't have to... (see the book "The Shallows" for more on this subject - link below).

Its the age of StackOverflow programming.

Sometimes, it is great. Sometimes its a dangerous, or problematic way... Here's a little anecdote.

Doing Android programming, I stored some long term values in the SharedPreferences object. Turns out that some examples on the internet tell you to use editor.commit() after you store or modify your values.
Well, if you don't need the result of this, you would be better off if you use editor.apply().

As the Android documentation say:

Unlike commit(), which writes its preferences out to persistent storage synchronously, apply() commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit()will block until all async commits are completed as well as the commit itself.

As SharedPreferences instances are singletons within a process, it's safe to replace any instance of commit() with apply() if you were already ignoring the return value.

You don't need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states

References: http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply()

Maybe the lesson here is really "Read the Documentation" and don't just code by copy and paste - at this age of Stack Overflow programming, spend the time reading. At least from time to time...

Edit: some people raised a concern that with apply() you need to worry about "race conditions" or other issues. Again, READ THE DOCS (as quoted above):

As SharedPreferences instances are singletons within a process, it's safe to replace any instance of commit() with apply() if you were already ignoring the return value.