==================[ Layout practicalities ]==================

See cheatsheets in cheatsheets/ for Views and Layouts at a glance.

LinearLayouts can be nested to create quite complex geometries of
views. Just like with HTML, you can create rows and columns as you
need, placing elements either side-by-side with a horizontal
LinearLayout or under each other with a vertical one, and nest these
groups to align them.

You can control alignment of a layout element's contents (internals)
by setting  android:gravity  attribute on the layout. You can control
the alignment of individual children with respect to the parent's
bounds by setting  android:layout_gravity on them. Combining these
attributes with  "match_parent"  or  "wrap_content" for the width
and height, you can do a lot, even though not always easily.

One good rule of thumb to remember about layout_gravity attributes is
that in LinearLayouts they work in the direction orthogonal to the
layout's orientation. That is, in a vertical layout it's easy to shift
pieces left and right or center them horizontally with layout_gravity;
in a horizontal layout, it's easy to shift them vertically up or down.

For example, getting a text label aligned to the right rather 
than to the left (the default) in a vertical LinearLayout can be done so:

<LinearLayout android:orientation="vertical"   <<<<<<<<<<<
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.netfluke.sergey.greeter.EditActivity">

    <TextView
        android:id="@+id/textView2"
        android:layout_width="wrap_content"    <<<<<<<<<<<
        android:layout_height="wrap_content"
        android:text="What's your name, neighbor?"
        android:layout_gravity="right"         <<<<<<<<<<<
        />
...

BTW, if you choose "match_parent" for the label, gravity will have no
effect, because there's nowhere for the full-width box to shift inside
the parent (whose width it's matching).  I tried this today in class,
to no effect (predictably).

Note that a horizontal LinearLayout packs its elements one after
another in a row (and a vertical one in a column). If you want some
space breaks between them, you'll need to use margins, e.g.,
android:layout_marginRight="16dp"  for a 16-point space between
this element and the next one in row. Then you can shift the
row glued together in this fashion to the center, left, or right
using  android:gravity  on their parent. This way you can center
a group of several buttons with some gaps between them.

The problem with this approach is that nesting layouts makes
for slower drawing. So using one Layout object to manage the whole
screen is encouraged by Android.

So there's the TableLayout, which gives you something very similar
to HTML tables, and eliminates the need for nesting LinearLayouts
to get a two-dimensional grid: 
  https://developer.android.com/guide/topics/ui/layout/grid.html

There's also RelativeLayout, which, instead of using rows and columns,
lets you specify the relative positions of elements w.r.t. each other.
Where a vertical LinearLayout would give you a "ladder" of buttons
one under the other (see 
http://sandipchitale.blogspot.co.uk/2010/05/linearlayout-gravity-and-layoutgravity.html),
a RelativeLayout can simply place them in the same row, and 
stick one to the left margin and one to the right:

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal">

        <Button
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:onClick="onClick"
            android:text="Thank you kindly"
            android:layout_alignParentLeft="true" />

        <Button
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:onClick="onButton2"
            android:text="I have a Ph.D."
            android:layout_alignParentRight="true" />
    </RelativeLayout>

For many simple designs such as Greeter's, a single Relative 
layout suffices; no other grouping of views is needed.

If you also case about splitting up the empty space between
your elements, ConstraintLayout is your friend. See 
https://medium.com/exploring-android/exploring-the-new-android-constraintlayout-eed37fe8d8f1 
for beautiful animations,
http://www.techotopia.com/index.php/Working_with_ConstraintLayout_Chains_and_Ratios_in_Android_Studio
on how to control this layout's spring-loaded chains of views. 

==================[ Fragments ]==================

Fragments are a more recent addition to Android. Earlier Android platforms
had small screens and it made sense for a GUI task to take up the entire
screen, obscuring other activities and yielding control back to them
when done. Hence the concept of the Android activity backstack and the
intent-based flow between activities.

Yet this model did not allow for the familiar desktop model of having
many interacting windows on a single screen, or multiple panels in a 
single application that are coded separately but also work together.
Think Android Studio and its many panels.

So when tablets and larger phone screens became a thing, Android came
out with its own solution to this: Fragments.

In XML, you lay out a Fragment exactly like you lay out an Activity,
but the Fragment can get attached _inside_ another View on the screen,
taking only a part of the screen, or appear as a dialog (it may also
take the full screen; there's no rule against that). In doing so, the
Fragment _attaches_ to an activity, and operates in its context. 

These things are important to remember about Fragments:

   - A Fragment attaches to an Activity

   - A Fragment is inflated into a View in this Activity (called
       its container)

This is essential. Without an Activity a Fragment is not a thing.  If
created from XML, it must get inflated into the Activity with the
Activity's inflater, into a container whose child it is in the XML tree.
If created programmatically, it still needs to be inflated into
a view whose insides it will replace.

This can be clearly seen from the signature of the function a Fragment
must define:

public static class ExampleFragment extends Fragment {
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        // Inflate the layout for this fragment
        return inflater.inflate(R.layout.example_fragment, container, false);
    }
}

Read https://developer.android.com/guide/components/fragments.html
to understand this design idea.

Also: 
  https://developer.android.com/training/basics/fragments/index.html
  https://developer.android.com/training/basics/fragments/creating.html
  https://developer.android.com/training/basics/fragments/fragment-ui.html
  https://developer.android.com/training/basics/fragments/communicating.html

-----[ In-class example: picking Fragment based on orientation ]-----

The code is in examples/Frag/ . I added a bit of color and centering,
to show off the  gravity  attribute.

In this example, the app starts with an empty layout. Depending
on the screen's current orientation when onCreate(..) is called,
either a Fragment1 or a Fragment2 instance is created, and replaces
the (empty) content frame of the app with itself. On flip, onCreate(..)
is called again, and the other Fragment is chosen and inflated
into view.

Note the use of inflators: they are the crucial and necessary step
from XML to a Java object that can be displayed by the Android virtual
machine. Inflators do a lot of work: they create the objects from XML,
load them, attach them to their parent objects as determined by the
XML file or given in arguments to the inflator, and connect the
listeners like onClick. See my NoXmlLayout example for that logic.

Note also that there's a way to prevent destroying the activity 
on flip. A special activity property specified in Manifest 
changes this behavior, instead calling onConfiguraionChange()
callback rather than onStop(), onDestroy(), etc. 

This example is too simple, but it demonstrates how a Fragment 
can be attached and replaced dynamically. Instead of doing this
to the main content frame, we could do it to any View on the screen.

-------------------[ Fragment Transactions ]-------------------

Replacing, adding, or removing Fragments to/from an Activity means
changing one or more parts of the screen (except when the Fragment
takes over the whole screen, as in examples/Frag/).  What if some
parts of the change go through but some turn out to be impossible or
fail? The user would end up with an inconsistent screen (desktop
applications also fail like that).

So Android implements the idea of transactions for fragments:
you get yourself a ledger object from the FragmentManager, which
records what you want to replace, add, or remove. That ledger object
is called a FragmentTransaction. Your actions are accumulated by
it, and are carried out when you call .commit() on the transaction,
but no earlier.

This adds complexity, but protects from the failure mode of
having a disjointed screen that half-loaded and half-failed.
You might be surprised how often this kind of failure happens
in critical software that lives depend on.  

Transactions are a core concept in databases, where they are used to
protect integrity of inter-related records. Either all changes go
through or none do; this way, e.g., a bank transfer implementation
ensures that if money is taken from some account, it ends up in the
target account, or the original state of all accounts is restored if
any error happens on the way.

===================[ Fragments and Activities ]===================

An Activity that wants to call code in another Activity typically
sends a broadcast Intent that the other activity sets up its
intent-filters to listen to. A Fragment, on the other hand, can just
call its getActivity() and then call whatever methods in the
activity. Of course, it needs to be attached to an activity, otherwise
getActivity() in it returns null.

There's a wrinkle here that has to do with Java's filesystem. 
getActivity() in Fragment returns an Activity object. But if
the Activity has some special public functions for the Fragment
to call, then the Java type checker must be made aware of them.

So the design pattern looks as follows:

1. A new Fragment class extending Fragment defines an Interface with
   these extra functions;

2. The Activity that intends to attach this type of Fragment 
   implements this interface;

3. After the Fragment is attached to the Activity, it calls
   getActivity(), casts the result to that Interface type,
   and calls the special functions. 

Easy to understand, but somewhat convoluted to express in Java.
See the Fragment part of the Dialog example, and 
  https://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity   
  https://developer.android.com/training/basics/fragments/communicating.html

===================[ Simple camera operation ]===================

This code is very simple, and is only good for taking a small bitmap
image for a profile picture, not a full resolution image (which is
impressive for Nexus 6 and even better for Nexus 6P). Still, it works
for your Lab1 task, and we'll do better in the following tasks.

The code is in example/SimpleCam, and follows 
  https://developer.android.com/training/camera/photobasics.html

All it takes is sending an Intent via startActivityForResult(..) to
whatever app might be listening with its intent-filters. Normally,
this is Android's standard camera app. The picture-taking activity
from this camera app gets pushed on top of the activity backstack, you
take a picture, then accept it or discard it and take another. When
you accept, the camera activity calls finish() and you end up in
onActivityResult(..) and extract the taken picture from the "data"
extra of the data intent. Then you set the received bitmap to 
show in the ImageView.

Note that on flips that picture gets lost, because the ImageView gets
destroyed and recreated together with the activity. To keep it showing
after you flip the phone, you must _either_ save it in the Bundle (the
helpful callback to do this is onSaveInstanceState(..))  and restore
it from the savedInstanceState bundle (the callback for this is
onRestoreInstanceState(..)). 

Another alternative is shown in the Frag example: declaring in
Manifest that orientation changes must produce a callback, not
activity destruction and re-creation.

Read
https://developer.android.com/training/basics/data-storage/index.html
on how you can save the picture (and any other data) to permanent
storage. We'll discuss it on Monday.