The easiest solution is to simply replace
android:nextFocusDown="@id/month"
with
android:nextFocusDown="@+id/month"
When the compiler parses your XML to add id to R.java, it just reads from top to bottom. When you have @id/month , it scans existing identifiers and does not find it.
However, if you do @+id/month , it creates a new identifier and refers to it. When it comes to android: id=@ +id/month in the current view of the month, it associates it with the same identifier that we have already created.
The question arises: if you can replace @id/ with @+id/ , and @+id/ will work regardless of the order of the elements, why even use @id/ ?
The reason for this is that the identifier does not exist, @id/ will throw a compiler error, and @+id/ will log a warning at runtime.
Consider this XML:
<EditText android:id="@+id/month" android:layout_height="wrap_content" android:layout_width="100dp" android:nextFocusDown="@+id/SOME_RANDOM_ID"/> <EditText android:id="@+id/year" android:layout_height="wrap_content" android:layout_width="match_parent"/>
The analysis creates a new id element SOME_RANDOM_ID . However, when Android tries to apply it at runtime, it cannot find an element with this identifier. If you look at Logcat, you will see the following:
W / View: Could not find view with id 2131689604
This log message is hard to find and hard to debug. One small typo in @+id/ and you will have an error that could be incredibly difficult to debug. However, if we did:
android:nextFocusDown="@id/SOME_RANDOM_ID"
Then we would get a compiler error, for example:
Error: (18, 36) A resource was not found that matches the specified name (in 'nextFocusDown' with the value '@ id / SOME_RANDOM_ID').
It is much easier to find and debug.
tl; dr: you can use @+id/ instead of @id/ and you can redirect the link, but note that this can make small typos incredibly difficult to debug.
You might be able to use RelativeLayout to make all views in reverse order in xml, but to me that seems redundant.