# Starting on Android
After learning a few (mostly web) frameworks over time, with Django powering most of my every day work in the past few years, and playing with iOS a few years back, I finally started spending some serious time learning Android.

<img height="360" src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Android_dance.svg/1200px-Android_dance.svg.png" alt="Android dance.svg">

I've been using a few resources, including [Udacity's Android course](https://www.udacity.com/course/developing-android-apps--ud853) targeted at non-beginners, and the great and constantly updated Android guide and reference at [Commonsware.com](https://commonsware.com/).

Being used to understanding framework internals it's pretty hard going back into treating most of a (huge) framework as more or less a "black box". This is potentially unavoidable when you first start learning something, as you have to break it down into levels:

* Gain general understanding of what the high-level components are and how they are meant to interact though their high-level features.
* Become able to use these features to build a basic application. Implementation of new requirements and debugging is still hard.
* Start clarifying some best practices for developing on the platform, such as the separation of responsibility between these components, code organisation, respecting compatibility and device limitations.
* Get a more detailed understanding of the framework,  be able to build common features without stress and be able to relatively easily debug many problems by looking at the framework code.
* Start looking into other subjects like stricter platform-specific publishing guidelines, enhancing performance, maintainability, localisation etc.
* ...

Udacity's program is interesting as they make you work on a side-project/assignment, as you're progressing through the course, which requires you to *develop an app from scratch, given specific requirements* (a simple movie recommendation app).

I'm currently working on that and it greatly frustrates me that I don't yet have a good picture of what the framework really does under the hood, but I'm positive that I'm learning quite a lot in the process!

To be continued :)

----
# The Internet

Turns out if you use [Picasso](http://square.github.io/picasso/) to load images from URLs into your views it might silently not load them if you don't have internet permissions:
```xml
<uses-permission android:name="android.permission.INTERNET"/>
```

----
# Variable Scope
## (for python developers)
A bit of a Java refresher, this is a thing that's actually fairly different from Python.

Even where logically in Python a variable would always be defined when it is accessed further down in the flow of your program, the Java compiler will not necessarily agree with you:


![Screenshot 2016-02-09 14.53.49.png](/media/391/Screenshot%202016-02-09%2014.53.49.png)



(this isn't just a code inspection thing, actually trying to compile this will report the same error).

This might be annoying in some cases but it makes sense the way that scopes work in Java:

**`foo` is declared and only lives inside the `try`/`except`/`finally` blocks. It's a `local variable` and therefor inaccessible anywhere else.**

The solution would be to declare the variable outside of these blocks:


![Screenshot 2016-02-09 15.10.21.png](/media/390/Screenshot%202016-02-09%2015.10.21.png)

The function will the normally return `"boom"` as the it's set in the `finally` statement :)

----
Fragments, fragments, fragments
===========================

Sometimes deciding whether to use fragments vs activities and their infinite combinations for layout and navigation feels really daunting.

Things get even more complex when you want to support different layouts based on screen size/orientation.

[This guide](http://guides.codepath.com/android/Flexible-User-Interfaces), which is similar to the official documentation, was particularly useful for using combinations of activities and fragments.

There are, however, people who advocate against using fragements, and it's also very interesting to see [what they have to say](https://corner.squareup.com/2014/10/advocating-against-android-fragments.html) (in this example coming from the Square tech blog).

There are **practical alternatives** to using fragments all over the place, such as the [Pankcakes](https://github.com/mattlogan/Pancakes) library.

----
# The Datetime Library strikes back

I wonder whether a language will ever exist that has good, in-built support for datetime objects.

So here's the latest gem I discovered in `util.Date`:

![date_init.png](/media/405/date_init.png)

![date_get_year.png](/media/406/date_get_year.png)

So basically getYear() returns 116 for this year (2016). I don't know who would use it today, or why it was ever built like that, or what sort of backwards compatibility demon forces us to keep it there.

D:

Apparently people these days use things like [Joda](http://www.joda.org/joda-time/).