G'day everyone, welcome back.
There are a couple of things I still want to discuss
before we finish with dialogues. The first one is that version number that
we're displaying. Where did it come from and what is this BuildConfig?
Let's start by having a look at it, by control clicking on BuildConfig in our code.
That's command click if you're on a Mac.
The first thing to note is that the file
is generated as part of the build process, and we shouldn't go changing
anything in it. It's futile for one thing, because any changes we make will be lost
when the project's next built - for example, the next time we run it. In fact,
if I make a change by deleting the zero from the version name string,
we get a message telling us that the changes will be lost. It's still useful to see what's
in here, and that string that I just changed is the version_value
that we used in our code. We also used the debug value earlier in this section,
when we threw an assertion error if there was no task ID when the
onPositiveDialogResult function was called. So, this is where our code gets
the values from, but how do they get in here?
We know this class is produced by the build system, so where does that get the
values from? The answer is, it's from the build.gradle file, which you'll find
under the Gradle scripts heading in the project pane.
We've looked at both these files a couple of times now. The one of interest
for the build version is the build.gradle module app. If you prefer to
have your project pane in Project view rather than Android view, then it's the
one in the app folder that you're interested in. Let's have a look in the file.
Some of these entries at the start are added when you create the project;
things like the minSdkVersion, for example. When you specify the minimum API level
when you're creating a new project, this is where the value's stored.
Android Studio also creates a default value for the version code and version name entries.
These default to 1 and "1.0", respectively. You're free to change these values.
In fact, you should change them whenever you publish a new version of your app on the
Google Play Store. Let's have a look at what Google says about them at
developer.android.com/studio/publish/versioning.html.
We'll be coming back to this document, when we look at deploying our apps to the Play Store,
so I won't go into a lot of detail at the moment. Basically, version
information is important. Google go as far as to say, it's a critical component
of your app upgrade and maintenance strategy. It's certainly true that you
should take a consistent approach to versioning your app. If you release new versions,
you can't guarantee that all users will always upgrade to the latest version.
So if they report a bug, you'll need to know which version they're using,
otherwise you could waste time trying to find a bug that was fixed in a later version,
and the opposite's true as well. It may be a bug that you introduced in a
later version. OK, the important bits at the moment, are a bit further down, where
the version code and version name settings are defined.
The version code is an integer and must increase with each release of your app.
That's important, and we're going to see what happens if you reduce this value.
You shouldn't show this version code to users. Instead, the version name is the
value that they'll see.
The maximum value for the version code is specified
in that big red warning call-out, and it's big.
If you increase it by one with each
new release, that's a lot of releases. It does allow you to do things like, 103051646 as a build number.
The initial one is the first year of release.
0305 represents the fifth of March
and 1646 means the build was performed at 16.46 in the afternoon.
So, if you want to use a scheme like that, then you can
I don't think Google really expects anyone to produce over 2 billion
versions of their app. Version name is a string, so you can put anything you want
in there. If you want to include the word beta or rc2, for release candidate 2,
or something like that, then you're free to do so. This is the version that users
will see and, going back to our code, that's the value that we're showing in
our About dialogue. We can change the version information in the build.gradle file,
so let's do that and see what happens. We haven't finished the app yet,
so let's make the version name version 2.0.1 beta,
and also change the version code to 2.
Whenever you make a change to the build.gradle file,
the build system notices and suggests that you sync now. So do that before trying to run the app.
When we run the app, we'll see the new version information in our
About dialogue.
So that's how you set your apps version number. As the document says, the version
code should increase with each new release. Let's see what happens if we
change it back to 1, then sync now and run the app.
That's not too good, and if we insisted that users lose all their data every
time they upgrade our app, they're not going to be too happy. That version code
number must never go backwards in a released version of an app. I don't want
to lose all my timing data, so I'll cancel the installation, which is
probably what most of your users will do too.
Don't reduce that version code once
you've released your app. I'll change the version code back to 2, and we can run
the app again without having to uninstall it first.
The second thing I want to cover, is a slight improvement to our About dialogue.
At the moment, it can only be dismissed by tapping away from it on the device screen,
but it's also usual to dismiss this type of dialog, by allowing the user
to tap the dialogue itself, or providing an OK button. We'll look at both ways to
implement that, in the next video. I'll see you there.