1 00:00:04,520 --> 00:00:06,760 G'day everyone, welcome back. 2 00:00:06,760 --> 00:00:09,139 There are a couple of things I still want to discuss 3 00:00:09,139 --> 00:00:13,910 before we finish with dialogues. The first one is that version number that 4 00:00:13,910 --> 00:00:19,720 we're displaying. Where did it come from and what is this BuildConfig? 5 00:00:19,720 --> 00:00:25,260 Let's start by having a look at it, by control clicking on BuildConfig in our code. 6 00:00:25,260 --> 00:00:29,140 That's command click if you're on a Mac. 7 00:00:29,140 --> 00:00:31,600 The first thing to note is that the file 8 00:00:31,610 --> 00:00:35,960 is generated as part of the build process, and we shouldn't go changing 9 00:00:35,960 --> 00:00:41,329 anything in it. It's futile for one thing, because any changes we make will be lost 10 00:00:41,329 --> 00:00:46,190 when the project's next built - for example, the next time we run it. In fact, 11 00:00:46,190 --> 00:00:52,580 if I make a change by deleting the zero from the version name string, 12 00:00:52,580 --> 00:00:58,120 we get a message telling us that the changes will be lost. It's still useful to see what's 13 00:00:58,129 --> 00:01:03,260 in here, and that string that I just changed is the version_value 14 00:01:03,260 --> 00:01:08,149 that we used in our code. We also used the debug value earlier in this section, 15 00:01:08,149 --> 00:01:13,310 when we threw an assertion error if there was no task ID when the 16 00:01:13,310 --> 00:01:18,470 onPositiveDialogResult function was called. So, this is where our code gets 17 00:01:18,470 --> 00:01:21,020 the values from, but how do they get in here? 18 00:01:21,020 --> 00:01:25,579 We know this class is produced by the build system, so where does that get the 19 00:01:25,579 --> 00:01:31,009 values from? The answer is, it's from the build.gradle file, which you'll find 20 00:01:31,009 --> 00:01:36,219 under the Gradle scripts heading in the project pane. 21 00:01:40,830 --> 00:01:45,450 We've looked at both these files a couple of times now. The one of interest 22 00:01:45,450 --> 00:01:51,000 for the build version is the build.gradle module app. If you prefer to 23 00:01:51,000 --> 00:01:56,400 have your project pane in Project view rather than Android view, then it's the 24 00:01:56,400 --> 00:01:59,910 one in the app folder that you're interested in. Let's have a look in the file. 25 00:01:59,910 --> 00:02:04,430 Some of these entries at the start are added when you create the project; 26 00:02:04,430 --> 00:02:10,860 things like the minSdkVersion, for example. When you specify the minimum API level 27 00:02:10,860 --> 00:02:15,560 when you're creating a new project, this is where the value's stored. 28 00:02:15,560 --> 00:02:22,800 Android Studio also creates a default value for the version code and version name entries. 29 00:02:22,800 --> 00:02:29,010 These default to 1 and "1.0", respectively. You're free to change these values. 30 00:02:29,010 --> 00:02:34,050 In fact, you should change them whenever you publish a new version of your app on the 31 00:02:34,050 --> 00:02:39,290 Google Play Store. Let's have a look at what Google says about them at 32 00:02:39,290 --> 00:02:47,140 developer.android.com/studio/publish/versioning.html. 33 00:02:47,140 --> 00:02:52,020 We'll be coming back to this document, when we look at deploying our apps to the Play Store, 34 00:02:52,020 --> 00:02:56,300 so I won't go into a lot of detail at the moment. Basically, version 35 00:02:56,310 --> 00:03:01,260 information is important. Google go as far as to say, it's a critical component 36 00:03:01,260 --> 00:03:06,720 of your app upgrade and maintenance strategy. It's certainly true that you 37 00:03:06,720 --> 00:03:11,600 should take a consistent approach to versioning your app. If you release new versions, 38 00:03:11,600 --> 00:03:16,440 you can't guarantee that all users will always upgrade to the latest version. 39 00:03:16,440 --> 00:03:20,720 So if they report a bug, you'll need to know which version they're using, 40 00:03:20,720 --> 00:03:26,340 otherwise you could waste time trying to find a bug that was fixed in a later version, 41 00:03:26,340 --> 00:03:30,900 and the opposite's true as well. It may be a bug that you introduced in a 42 00:03:30,900 --> 00:03:37,320 later version. OK, the important bits at the moment, are a bit further down, where 43 00:03:37,320 --> 00:03:43,840 the version code and version name settings are defined. 44 00:03:43,840 --> 00:03:50,000 The version code is an integer and must increase with each release of your app. 45 00:03:50,000 --> 00:03:54,220 That's important, and we're going to see what happens if you reduce this value. 46 00:03:54,220 --> 00:03:59,410 You shouldn't show this version code to users. Instead, the version name is the 47 00:03:59,410 --> 00:04:03,220 value that they'll see. 48 00:04:03,220 --> 00:04:06,550 The maximum value for the version code is specified 49 00:04:06,550 --> 00:04:10,820 in that big red warning call-out, and it's big. 50 00:04:10,820 --> 00:04:13,140 If you increase it by one with each 51 00:04:13,140 --> 00:04:39,640 new release, that's a lot of releases. It does allow you to do things like, 103051646 as a build number. 52 00:04:39,640 --> 00:04:45,020 The initial one is the first year of release. 53 00:04:45,020 --> 00:04:49,140 0305 represents the fifth of March 54 00:04:49,140 --> 00:04:56,100 and 1646 means the build was performed at 16.46 in the afternoon. 55 00:04:56,100 --> 00:04:59,940 So, if you want to use a scheme like that, then you can 56 00:04:59,940 --> 00:05:04,419 I don't think Google really expects anyone to produce over 2 billion 57 00:05:04,419 --> 00:05:09,490 versions of their app. Version name is a string, so you can put anything you want 58 00:05:09,490 --> 00:05:16,779 in there. If you want to include the word beta or rc2, for release candidate 2, 59 00:05:16,779 --> 00:05:21,520 or something like that, then you're free to do so. This is the version that users 60 00:05:21,520 --> 00:05:25,960 will see and, going back to our code, that's the value that we're showing in 61 00:05:25,960 --> 00:05:31,420 our About dialogue. We can change the version information in the build.gradle file, 62 00:05:31,420 --> 00:05:35,259 so let's do that and see what happens. We haven't finished the app yet, 63 00:05:35,260 --> 00:05:48,560 so let's make the version name version 2.0.1 beta, 64 00:05:48,560 --> 00:05:55,760 and also change the version code to 2. 65 00:05:55,760 --> 00:05:59,680 Whenever you make a change to the build.gradle file, 66 00:05:59,680 --> 00:06:10,540 the build system notices and suggests that you sync now. So do that before trying to run the app. 67 00:06:10,540 --> 00:06:14,280 When we run the app, we'll see the new version information in our 68 00:06:14,289 --> 00:06:17,069 About dialogue. 69 00:06:25,730 --> 00:06:31,160 So that's how you set your apps version number. As the document says, the version 70 00:06:31,160 --> 00:06:36,110 code should increase with each new release. Let's see what happens if we 71 00:06:36,110 --> 00:06:42,040 change it back to 1, then sync now and run the app. 72 00:06:57,300 --> 00:07:02,880 That's not too good, and if we insisted that users lose all their data every 73 00:07:02,880 --> 00:07:07,830 time they upgrade our app, they're not going to be too happy. That version code 74 00:07:07,830 --> 00:07:12,720 number must never go backwards in a released version of an app. I don't want 75 00:07:12,720 --> 00:07:17,070 to lose all my timing data, so I'll cancel the installation, which is 76 00:07:17,070 --> 00:07:21,840 probably what most of your users will do too. 77 00:07:21,840 --> 00:07:24,360 Don't reduce that version code once 78 00:07:24,360 --> 00:07:29,550 you've released your app. I'll change the version code back to 2, and we can run 79 00:07:29,550 --> 00:07:34,610 the app again without having to uninstall it first. 80 00:07:42,040 --> 00:07:47,580 The second thing I want to cover, is a slight improvement to our About dialogue. 81 00:07:47,580 --> 00:07:52,580 At the moment, it can only be dismissed by tapping away from it on the device screen, 82 00:07:52,580 --> 00:07:57,109 but it's also usual to dismiss this type of dialog, by allowing the user 83 00:07:57,109 --> 00:08:02,419 to tap the dialogue itself, or providing an OK button. We'll look at both ways to 84 00:08:02,419 --> 00:08:07,659 implement that, in the next video. I'll see you there.