From a brief look... the blog is part aggregation and part original content. So that links to posts outside the domain are going to vary greatly in quality.
Most of the tutorials focus on how to mechanically get something done. For instance, reading a SOAP service, changing some fonts and backgrounds, and others. This will not tell you how to design a program. It just tells you how to accomplish some small task. There is no guidance on abstractions and code organization, just tips on getting some little thing done.
I don't know of any design-oriented android resources. The Google Dev Guide is quite good and offers a lot of advice. Read it like it is a book. The "Busy Coder Guides" are highly touted, but they are again about implementation and not design/organization. Also, I have Pro Android and it too suffers from this problem, despite being over 100 pages long!
My advice is keep it as simple as possible. Avoid too much abstraction and redirection unless you benefit from it; just build what you need today. If you ever write an object called ServiceFactoryContainerBundle then stop and simplify. And if you find yourself writing a "form generator" framework then stop and ask yourself "what is my product?". Unless you're trying to sell a form generator framework then again stop and simplify. Just my 2 cents.
The issues you address aren't Android specific though and probably shouldn't be addressed by "Android" tutorials since they aren't specific to the platform.
+1 for F#. it is a really great language and I learned a ton by spending about 250 hours with it. The book Expert F# is a really good resource. the first 200 pages are about the language (a complete guide) and the rest is just case studies of .NET junk. I wish they had made 2 books not one... 1st 1/2 is excellent though and worth buying.
No matter how many different classes require a paper to be written, always write one paper and reuse it for all classes. US Profs love creativity and when you come to them and ask if you can write about the "History of Religion" for your history paper they will always say yes. Then go to your religion professor and pitch the same paper. Et viola. Two classes with one paper. And since you'll have a little more time to write the one paper it will usually be better.
Also, always do the readings _before_ the class, not after. By offsetting your reading one week sooner then everyone else you'll have an advantage.
The same can be done with a project but writing two papers. I was taking courses in graphics and parallel programming at the same time. I took my graphics project and modified portions of it to run in parallel. Then I submitted one paper on the graphics and another paper on the transformation of serial->parallel and the performance gains.
But always get permission first. If professors find out that you're reducing your workload like this they aren't always pleased. However, if you're talk to them (and they're reasonable) then they'll almost certainly accept it.
This depends on the school's plagiarism policy - at my university, you're not allowed to reuse your own work. Auto-plagiarism. It's acceptable to cite previous work if relevant, but not to submit the same paper twice.
Careful with this. My school, at least, treats this as academic fraud unless you have agreed in advance with each professor that you will be multiple-submitting that piece of work.
Most of the tutorials focus on how to mechanically get something done. For instance, reading a SOAP service, changing some fonts and backgrounds, and others. This will not tell you how to design a program. It just tells you how to accomplish some small task. There is no guidance on abstractions and code organization, just tips on getting some little thing done.
I don't know of any design-oriented android resources. The Google Dev Guide is quite good and offers a lot of advice. Read it like it is a book. The "Busy Coder Guides" are highly touted, but they are again about implementation and not design/organization. Also, I have Pro Android and it too suffers from this problem, despite being over 100 pages long!
My advice is keep it as simple as possible. Avoid too much abstraction and redirection unless you benefit from it; just build what you need today. If you ever write an object called ServiceFactoryContainerBundle then stop and simplify. And if you find yourself writing a "form generator" framework then stop and ask yourself "what is my product?". Unless you're trying to sell a form generator framework then again stop and simplify. Just my 2 cents.