1 00:00:04,790 --> 00:00:07,040 So I finished the last video by saying 2 00:00:07,040 --> 00:00:08,148 that there's some important implications 3 00:00:08,148 --> 00:00:11,150 of the activity lifecycle, as it relates 4 00:00:11,150 --> 00:00:13,490 to our activity. Now one of them is that 5 00:00:13,490 --> 00:00:15,859 if we want to save some data so that 6 00:00:15,859 --> 00:00:17,330 it's available next time the app is 7 00:00:17,330 --> 00:00:19,670 launched, then we can't rely on code in 8 00:00:19,670 --> 00:00:21,560 onSaveInstanceState to do that. 9 00:00:21,560 --> 00:00:23,990 That's because onSaveInstanceState 10 00:00:23,990 --> 00:00:26,510 isn't always called. In fact, it's only 11 00:00:26,510 --> 00:00:28,699 used when Android knows that it may be 12 00:00:28,699 --> 00:00:31,250 relaunching the activity. The recommended 13 00:00:31,250 --> 00:00:32,989 place to put code to save your own app 14 00:00:32,989 --> 00:00:35,690 data is in the onStop method. Now the 15 00:00:35,690 --> 00:00:37,159 second thing is that Android will 16 00:00:37,159 --> 00:00:39,620 automatically save the state of widgets 17 00:00:39,620 --> 00:00:42,170 that it expects to contain data, and will 18 00:00:42,170 --> 00:00:43,760 restore that data again when the 19 00:00:43,760 --> 00:00:46,550 activity's restarted. Now the third one 20 00:00:46,550 --> 00:00:49,100 is less obvious, but it's the reason I've 21 00:00:49,100 --> 00:00:51,229 shown you all of this. If we want to 22 00:00:51,229 --> 00:00:53,179 save program state that Android doesn't 23 00:00:53,179 --> 00:00:55,549 know about, then we need to do that in 24 00:00:55,549 --> 00:00:58,459 onSaveInstanceState and restore it in 25 00:00:58,459 --> 00:01:01,219 onRestoreInstanceState. So the sort of 26 00:01:01,219 --> 00:01:02,809 thing I'm talking about here is the 27 00:01:02,809 --> 00:01:05,239 contents of the TextView. Now Android 28 00:01:05,239 --> 00:01:06,860 doesn't save the state of TextView 29 00:01:06,860 --> 00:01:09,290 widgets for us because users can't type 30 00:01:09,290 --> 00:01:11,930 into them, so they don't usually change. But 31 00:01:11,930 --> 00:01:14,150 in our case, ours does change, so 32 00:01:14,150 --> 00:01:16,130 ultimately that responsibility to save 33 00:01:16,130 --> 00:01:18,800 the state comes back to us, before the 34 00:01:18,800 --> 00:01:21,050 activity is destroyed. Now that's a bit 35 00:01:21,050 --> 00:01:22,820 arbitrary in this example, because it's 36 00:01:22,820 --> 00:01:25,160 possibly not clear whether the contents 37 00:01:25,160 --> 00:01:28,400 of the TextView are state or whether 38 00:01:28,400 --> 00:01:30,740 they're our applications' data. So in a 39 00:01:30,740 --> 00:01:32,810 calculator app, for example, the results 40 00:01:32,810 --> 00:01:34,970 are really state. I don't think many 41 00:01:34,970 --> 00:01:36,410 users would expect the previous 42 00:01:36,410 --> 00:01:38,090 calculation to appear the next time that 43 00:01:38,090 --> 00:01:40,550 they launch the calculator app. But if 44 00:01:40,550 --> 00:01:42,170 this was a data entry screen for a 45 00:01:42,170 --> 00:01:44,510 contacts app, though, then users may expect 46 00:01:44,510 --> 00:01:46,520 the details to still be present, even 47 00:01:46,520 --> 00:01:48,080 though they hadn't tapped a Save button 48 00:01:48,080 --> 00:01:50,690 to store them. So how do you define data 49 00:01:50,690 --> 00:01:52,790 that the users input into your app? Well 50 00:01:52,790 --> 00:01:54,350 that really depends on what the app does 51 00:01:54,350 --> 00:01:55,909 and what's being entered. 52 00:01:55,909 --> 00:01:57,770 So if our button click counter app was 53 00:01:57,770 --> 00:01:59,300 used to store a shopping list, for 54 00:01:59,300 --> 00:02:01,340 example, then those details should be 55 00:02:01,340 --> 00:02:03,740 considered as data. In other words, they 56 00:02:03,740 --> 00:02:05,270 should still be there the next time the 57 00:02:05,270 --> 00:02:07,850 app's launched. This section is about the 58 00:02:07,850 --> 00:02:10,068 activity lifecycle, though, so we're going 59 00:02:10,068 --> 00:02:12,799 to treat any input as state rather than 60 00:02:12,799 --> 00:02:15,709 data. We will be looking at saving your 61 00:02:15,709 --> 00:02:17,540 applications data, though, later in the 62 00:02:17,540 --> 00:02:18,080 course. 63 00:02:18,080 --> 00:02:19,970 Now one thing we've learned from 64 00:02:19,970 --> 00:02:21,770 students in previous versions of this 65 00:02:21,770 --> 00:02:23,810 course, is that it's not clear what we 66 00:02:23,810 --> 00:02:26,930 mean by state and app data. So when I 67 00:02:26,930 --> 00:02:29,390 talk about state, I'm referring to things 68 00:02:29,390 --> 00:02:32,030 like the values of our variables and the 69 00:02:32,030 --> 00:02:34,670 contents of the editText and the Text 70 00:02:34,670 --> 00:02:36,740 View widgets, while the program's 71 00:02:36,740 --> 00:02:39,350 running. Now when Android destroys our 72 00:02:39,350 --> 00:02:41,630 activity, we want it to return to the 73 00:02:41,630 --> 00:02:44,750 same state when it's recreated. What that 74 00:02:44,750 --> 00:02:46,400 means is that the editText should 75 00:02:46,400 --> 00:02:48,320 contain whatever it contained, before it 76 00:02:48,320 --> 00:02:50,990 was destroyed, and the TextView should 77 00:02:50,990 --> 00:02:53,690 also have the same text as it had before 78 00:02:53,690 --> 00:02:56,090 the app was destroyed. Now each time the 79 00:02:56,090 --> 00:02:58,520 user taps the button, their text is taken 80 00:02:58,520 --> 00:03:00,950 from the editText widget and appended 81 00:03:00,950 --> 00:03:03,410 to the TextView. And it's a bit grim that 82 00:03:03,410 --> 00:03:05,150 if they rotate the device they lose 83 00:03:05,150 --> 00:03:06,680 everything that they've typed in previously. 84 00:03:06,680 --> 00:03:09,110 So the state refers to the things that 85 00:03:09,110 --> 00:03:11,420 need to be restored, to make things like 86 00:03:11,420 --> 00:03:13,820 a device rotation appear seamless to 87 00:03:13,820 --> 00:03:15,830 the user. So I'm willing to bet that 88 00:03:15,830 --> 00:03:17,420 before you started programming for 89 00:03:17,420 --> 00:03:19,280 Android, you weren't aware that apps got 90 00:03:19,280 --> 00:03:21,100 destroyed when you rotated the device. 91 00:03:21,100 --> 00:03:24,080 Now your users are also unlikely to be 92 00:03:24,080 --> 00:03:26,209 aware of this, so we need to make sure 93 00:03:26,209 --> 00:03:28,670 that everything looks the same after a 94 00:03:28,670 --> 00:03:31,190 rotation, as it did before that rotation. 95 00:03:31,190 --> 00:03:34,040 So that's state. Your programs' data isn't 96 00:03:34,040 --> 00:03:36,230 the same thing. Now if the user 97 00:03:36,230 --> 00:03:38,150 starts to type some input into the edit 98 00:03:38,150 --> 00:03:40,340 Text, then uses the back button to close 99 00:03:40,340 --> 00:03:41,840 the app, they probably wouldn't be too 100 00:03:41,840 --> 00:03:44,300 surprised if that input wasn't still 101 00:03:44,300 --> 00:03:46,040 there when they launched the app again, two 102 00:03:46,040 --> 00:03:48,110 days later. But on the other hand, if 103 00:03:48,110 --> 00:03:50,270 they'd created a list of items in the 104 00:03:50,270 --> 00:03:52,520 TextView then tapped our Save button, 105 00:03:52,520 --> 00:03:54,980 they'd probably be very unimpressed if 106 00:03:54,980 --> 00:03:56,420 they couldn't load that list back up 107 00:03:56,420 --> 00:03:59,450 again, two days later. Now I know I 108 00:03:59,450 --> 00:04:01,070 haven't added a Save button, but 109 00:04:01,070 --> 00:04:02,540 hopefully that explains the difference 110 00:04:02,540 --> 00:04:05,630 between state and the apps' data. The data 111 00:04:05,630 --> 00:04:07,640 is stuff that users would expect to 112 00:04:07,640 --> 00:04:09,680 still be available when they launch the 113 00:04:09,680 --> 00:04:12,260 app again, days or even months later. If 114 00:04:12,260 --> 00:04:13,850 you typed a message into Facebook or 115 00:04:13,850 --> 00:04:16,310 Twitter, then minimized your browser, you'd 116 00:04:16,310 --> 00:04:17,810 expect the message to still be there 117 00:04:17,810 --> 00:04:19,399 when you restored your browser window - 118 00:04:19,399 --> 00:04:22,220 that's state. If you closed the browser 119 00:04:22,220 --> 00:04:24,440 without posting the message, you probably 120 00:04:24,440 --> 00:04:25,790 wouldn't be surprised that the message 121 00:04:25,790 --> 00:04:27,830 was no longer there when you logged back in, 122 00:04:27,830 --> 00:04:29,750 but on the other hand, if you'd clicked the 123 00:04:29,750 --> 00:04:30,430 post button, 124 00:04:30,430 --> 00:04:32,080 you would expect to see the message. 125 00:04:32,080 --> 00:04:34,510 So that's app data. So it's exactly the 126 00:04:34,510 --> 00:04:37,030 same message, the same text, but context 127 00:04:37,030 --> 00:04:38,020 is everything. 128 00:04:38,020 --> 00:04:39,850 So as I've said, we're not going to be 129 00:04:39,850 --> 00:04:41,620 dealing with storing data just yet. That 130 00:04:41,620 --> 00:04:44,170 will come later in the course. So for 131 00:04:44,170 --> 00:04:46,450 this app, anything the user types in 132 00:04:46,450 --> 00:04:49,600 won't be saved when they quit the app. We 133 00:04:49,600 --> 00:04:51,490 should make sure it's still there when 134 00:04:51,490 --> 00:04:52,990 they do things like rotating the device, 135 00:04:52,990 --> 00:04:55,660 though. So let's go ahead and do that. Al 136 00:04:55,660 --> 00:04:58,090 right so a bundle contains a list of key 137 00:04:58,090 --> 00:05:01,000 value pairs, and we can add new data to 138 00:05:01,000 --> 00:05:03,550 the bundle, by saving the data with a 139 00:05:03,550 --> 00:05:05,320 name that we use to get the data back. 140 00:05:05,320 --> 00:05:08,560 Now one way to think of a bundle is like 141 00:05:08,560 --> 00:05:10,990 the mail being delivered to a house. Each 142 00:05:10,990 --> 00:05:12,850 envelope will have a person's name on it - 143 00:05:12,850 --> 00:05:15,760 each name is a key. Inside the envelope 144 00:05:15,760 --> 00:05:17,890 will be the value that's associated with 145 00:05:17,890 --> 00:05:20,590 the key. Now when the people in the house 146 00:05:20,590 --> 00:05:22,660 want to get their mail, they'll use the 147 00:05:22,660 --> 00:05:25,180 key - their name - to pick up the correct 148 00:05:25,180 --> 00:05:28,240 envelope. The key was also used when the 149 00:05:28,240 --> 00:05:30,670 data was put into the envelopes - the name 150 00:05:30,670 --> 00:05:33,160 was written on the outside. So when we 151 00:05:33,160 --> 00:05:35,170 store a value in a bundle, we're 152 00:05:35,170 --> 00:05:38,200 associating the value with a key. When we 153 00:05:38,200 --> 00:05:39,610 want to get the value back out of the 154 00:05:39,610 --> 00:05:42,250 bundle, we provide the key to ensure we 155 00:05:42,250 --> 00:05:44,890 get the correct value. Alright, so we 156 00:05:44,890 --> 00:05:46,210 need to make some changes to our code 157 00:05:46,210 --> 00:05:48,280 now, and because we're going to be using 158 00:05:48,280 --> 00:05:50,260 the key name at least twice, we're going 159 00:05:50,260 --> 00:05:53,170 to create a constant to store that name. 160 00:05:53,170 --> 00:05:55,050 So we're gonna come down here, 161 00:05:55,050 --> 00:05:59,590 below the line 12. I'm going to change 162 00:05:59,590 --> 00:06:02,680 line 12, firstly, to a const. So I'm going 163 00:06:02,680 --> 00:06:05,110 to make that private const val and then TAG. 164 00:06:05,110 --> 00:06:06,670 We're going to leave that line as it is 165 00:06:06,670 --> 00:06:08,200 then. On the next line, though, we're going 166 00:06:08,200 --> 00:06:11,860 to add private const val and we're going 167 00:06:11,860 --> 00:06:13,390 to call this one, all in uppercase, TEXT 168 00:06:13,390 --> 00:06:20,290 _CONTENTS equals, we're going 169 00:06:20,290 --> 00:06:23,110 to call it TextContent. So now that 170 00:06:23,110 --> 00:06:24,550 we've done that, we can save the Text 171 00:06:24,550 --> 00:06:26,680 Views' content in the onSaveInstance 172 00:06:26,680 --> 00:06:29,250 State. So I'll do a search for that, onSave 173 00:06:29,250 --> 00:06:32,290 InstanceState, so down here. We're going 174 00:06:32,290 --> 00:06:34,420 to add some code in there to save that. 175 00:06:34,420 --> 00:06:37,540 So we need to put this code after the 176 00:06:37,540 --> 00:06:39,820 save dot, sorry the super.onSave 177 00:06:39,820 --> 00:06:43,090 InstanceState call on line 63. So we're 178 00:06:43,090 --> 00:06:44,100 going to type 179 00:06:44,100 --> 00:06:51,330 outState?.putString. 180 00:06:51,330 --> 00:06:53,919 Then we're going to use our new 181 00:06:53,919 --> 00:06:55,630 TEXT_CONTENTS 182 00:06:55,630 --> 00:06:58,949 comma, and we're going to type textView 183 00:06:58,949 --> 00:07:06,280 question mark dot text.toString. Now 184 00:07:06,280 --> 00:07:08,470 a TextView is a nullable type, so we 185 00:07:08,470 --> 00:07:09,940 need to put a question mark after its 186 00:07:09,940 --> 00:07:12,729 name, just as we did earlier. The same is 187 00:07:12,729 --> 00:07:15,250 true of the outState parameter. So it's 188 00:07:15,250 --> 00:07:17,889 declared as Bundle? and you 189 00:07:17,889 --> 00:07:20,800 can see that on line 6. So consequently, 190 00:07:20,800 --> 00:07:22,630 we have to use the question mark when we 191 00:07:22,630 --> 00:07:24,720 attempt to access its properties and 192 00:07:24,720 --> 00:07:28,120 functions. So we're adding the value we 193 00:07:28,120 --> 00:07:30,460 want to store to the bundle, using a key 194 00:07:30,460 --> 00:07:32,229 that we can use to get that same value 195 00:07:32,229 --> 00:07:34,900 back later. Now I used the constant TEXT 196 00:07:34,900 --> 00:07:36,909 _CONTENTS so I don't have to 197 00:07:36,909 --> 00:07:38,500 remember exactly what key I used. 198 00:07:38,500 --> 00:07:40,630 Otherwise I might spell it wrong or get 199 00:07:40,630 --> 00:07:42,250 capitalization wrong when getting the 200 00:07:42,250 --> 00:07:44,139 value back from the bundle, and the data 201 00:07:44,139 --> 00:07:46,389 wouldn't be read back. Now, keep in mind 202 00:07:46,389 --> 00:07:48,370 you can store multiple values in the 203 00:07:48,370 --> 00:07:50,169 same bundle. As long as they have 204 00:07:50,169 --> 00:07:52,630 different keys, you can get them back again. 205 00:07:52,630 --> 00:07:55,060 If you give two values of the same type, 206 00:07:55,060 --> 00:07:57,729 the same key, then the second value saved 207 00:07:57,729 --> 00:07:59,919 will replace the first one. So it's 208 00:07:59,919 --> 00:08:01,960 important to make sure that the strings 209 00:08:01,960 --> 00:08:04,570 we use for the keys are unique. Now 210 00:08:04,570 --> 00:08:06,219 notice that I've also called the super 211 00:08:06,219 --> 00:08:07,479 method. I mentioned that we put our code 212 00:08:07,479 --> 00:08:09,669 after that, so we've left that in on line 213 00:08:09,669 --> 00:08:12,550 63. And that's because the super method takes 214 00:08:12,550 --> 00:08:13,900 care of storing all the things that 215 00:08:13,900 --> 00:08:16,300 Android looks after, such as the contents 216 00:08:16,300 --> 00:08:18,130 of an editText that the user has 217 00:08:18,130 --> 00:08:20,500 started typing into. If we don't call 218 00:08:20,500 --> 00:08:22,570 super, only the values we store in the 219 00:08:22,570 --> 00:08:23,830 bundle will be retrieved. 220 00:08:23,830 --> 00:08:25,810 Now all that might make more sense when 221 00:08:25,810 --> 00:08:27,190 you've seen the code to get the data 222 00:08:27,190 --> 00:08:28,990 back. We're going to do that in the on 223 00:08:28,990 --> 00:08:32,020 RestoreInstanceState. So I'm going to 224 00:08:32,020 --> 00:08:33,458 come up here to onRestoreInstanceState 225 00:08:33,458 --> 00:08:37,299 and after the super call, we're going to 226 00:08:37,299 --> 00:08:41,260 type val space and savedString is 227 00:08:41,260 --> 00:08:44,169 equal to, and it's going to be saved 228 00:08:44,169 --> 00:08:49,020 InstanceState?.getString. 229 00:08:49,020 --> 00:08:50,980 It's going to be TEXT_ 230 00:08:50,980 --> 00:08:54,970 CONTENTS and two double quotes. 231 00:08:54,970 --> 00:08:57,269 Then we're going to use textView 232 00:08:57,269 --> 00:09:02,910 question mark dot text equals savedString. 233 233 00:09:02,910 --> 00:09:05,139 So this time the value retrieved our 234 00:09:05,139 --> 00:09:06,939 data from the bundle. We're providing the 235 00:09:06,939 --> 00:09:09,459 same key, which is stored in the constant 236 00:09:09,459 --> 00:09:11,500 TEXT_CONTENTS so that the 237 00:09:11,500 --> 00:09:13,000 bundle knows which value we want to 238 00:09:13,000 --> 00:09:15,279 retrieve. And if a string value with the 239 00:09:15,279 --> 00:09:17,110 key TEXT_CONTENTS doesn't appear in the 240 00:09:17,110 --> 00:09:20,230 bundle, that getString function, this 241 00:09:20,230 --> 00:09:21,850 code here on line 49, 242 00:09:21,850 --> 00:09:23,920 well that returns the default value 243 00:09:23,920 --> 00:09:25,540 we've specified, and that's an empty 244 00:09:25,540 --> 00:09:27,370 string so nothing will be printed. And 245 00:09:27,370 --> 00:09:30,100 again, that's if TEXT_CONTENTS 246 00:09:30,100 --> 00:09:32,350 doesn't appear in the bundle. Now that 247 00:09:32,350 --> 00:09:33,660 default value is probably unnecessary 248 00:09:33,660 --> 00:09:36,220 because the bundle should always contain 249 00:09:36,220 --> 00:09:36,939 our data. 250 00:09:36,939 --> 00:09:38,769 Remember that onRestoreInstanceState 251 00:09:38,769 --> 00:09:40,689 will only ever be called if data was 252 00:09:40,689 --> 00:09:41,170 saved, 253 00:09:41,170 --> 00:09:43,269 if onSaveInstanceState was called 254 00:09:43,269 --> 00:09:45,490 before the activity was destroyed, and we 255 00:09:45,490 --> 00:09:47,170 saved the data in onSaveInstanceState 256 00:09:47,170 --> 00:09:49,689 so it should always be present. So once 257 00:09:49,689 --> 00:09:51,579 we've got the value in our savedString 258 00:09:51,579 --> 00:09:53,769 variable, we set the TextViews' text 259 00:09:53,769 --> 00:09:56,889 property on line 50, to the string that we 260 00:09:56,889 --> 00:09:58,959 retrieved from the bundle. Now there's no 261 00:09:58,959 --> 00:10:00,670 need to store the value in savedString 262 00:10:00,670 --> 00:10:02,889 first, so it's actually more usual to 263 00:10:02,889 --> 00:10:06,160 write it this way. So I'm going to comment 264 00:10:06,160 --> 00:10:09,160 those two lines out. You don't want to 265 00:10:09,160 --> 00:10:11,430 just do something like this; so, textView 266 00:10:11,430 --> 00:10:15,910 question mark dot text equals save 267 00:10:15,910 --> 00:10:18,850 InstanceState?.get 268 00:10:18,850 --> 00:10:22,990 String, and it'll be TEXT_ 269 00:10:22,990 --> 00:10:26,259 CONTENTS and then two double quotes, as I 270 00:10:26,259 --> 00:10:28,540 mentioned. Alright, and I've left the 271 00:10:28,540 --> 00:10:30,550 original code in there commented out, so 272 00:10:30,550 --> 00:10:31,720 you can see it in the source code for 273 00:10:31,720 --> 00:10:33,879 this video, if you download it. But more 274 00:10:33,879 --> 00:10:35,230 importantly, let's now try and see 275 00:10:35,230 --> 00:10:40,139 whether this works. I'm going to run this, 276 00:10:40,139 --> 00:10:42,699 actually, we'll get our logcat showing as 277 00:10:42,699 --> 00:10:45,840 well. 278 00:10:45,840 --> 00:10:48,700 Alright, so we're going to put it in 279 00:10:48,700 --> 00:10:55,170 our familiar items again, so bread, milk, 280 00:10:55,170 --> 00:11:00,310 cheese. We're going to type in cream 281 00:11:00,310 --> 00:11:02,440 again, and as per normal, I'm not 282 00:11:02,440 --> 00:11:03,850 going to tap the button after I've typed 283 00:11:03,850 --> 00:11:05,590 cream so that we can test that we 284 00:11:05,590 --> 00:11:07,570 haven't broken anything. But now if we 285 00:11:07,570 --> 00:11:12,100 click on rotate, and I'll just click on 286 00:11:12,100 --> 00:11:14,680 back so we can see the, or we can get 287 00:11:14,680 --> 00:11:18,070 rid of the keyboard. We can see that now, 288 00:11:18,070 --> 00:11:20,050 we've actually got our three items 289 00:11:20,050 --> 00:11:21,370 showing back on the screen, the bread, 290 00:11:21,370 --> 00:11:25,360 milk and cheese. And looking at the log 291 00:11:25,360 --> 00:11:26,860 cat, you can see that onSaveInstance 292 00:11:26,860 --> 00:11:29,560 State was called, and also onRestore 293 00:11:29,560 --> 00:11:31,810 InstanceState was called. Now we didn't 294 00:11:31,810 --> 00:11:35,080 save the text ourselves, for what was 295 00:11:35,080 --> 00:11:37,000 in the editText, remember. That was 296 00:11:37,000 --> 00:11:39,760 taken care of for us, by Android. The list 297 00:11:39,760 --> 00:11:41,590 of items in the TextView was saved and 298 00:11:41,590 --> 00:11:43,390 restored by the code we added to the 299 00:11:43,390 --> 00:11:45,570 save and restore InstanceState functions. 300 00:11:45,570 --> 00:11:48,130 Alright, so at this point, our app now copes 301 00:11:48,130 --> 00:11:51,100 when a device's orientation has changed. 302 00:11:51,100 --> 00:11:53,590 Now that may look like a lot of work, but 303 00:11:53,590 --> 00:11:54,790 if you think about it, we really only had 304 00:11:54,790 --> 00:11:57,460 to implement the two functions; on 305 00:11:57,460 --> 00:11:59,770 RestoreInstanceState and onSave 306 00:11:59,770 --> 00:12:02,380 InstanceState. And also, we didn't have to 307 00:12:02,380 --> 00:12:03,820 write a lot of code in either of those, 308 00:12:03,820 --> 00:12:06,160 either. The other overridden methods are 309 00:12:06,160 --> 00:12:08,080 really only added so that we could see 310 00:12:08,080 --> 00:12:09,790 them being called, as the app went 311 00:12:09,790 --> 00:12:11,800 through its lifecycle. Now you might be 312 00:12:11,800 --> 00:12:13,660 wondering what all those methods are for, 313 00:12:13,660 --> 00:12:15,670 really. It's unlikely that Google 314 00:12:15,670 --> 00:12:17,140 included them just so we could see them 315 00:12:17,140 --> 00:12:19,170 being called, so they must have a use. 316 00:12:19,170 --> 00:12:21,760 There's actually all sorts of uses and 317 00:12:21,760 --> 00:12:23,740 it really depends on what your app is 318 00:12:23,740 --> 00:12:26,650 doing. The onPause method would be a good 319 00:12:26,650 --> 00:12:28,750 place to save any data that the user 320 00:12:28,750 --> 00:12:31,060 would want to keep permanently, as long 321 00:12:31,060 --> 00:12:33,040 as you're saving it locally, and you can do 322 00:12:33,040 --> 00:12:35,590 so quickly. Now we've saved the contents 323 00:12:35,590 --> 00:12:37,630 of the TextView to a bundle, but that 324 00:12:37,630 --> 00:12:39,880 wasn't permanently storing it - it was 325 00:12:39,880 --> 00:12:41,410 just a way to cope with orientation 326 00:12:41,410 --> 00:12:43,960 changes and the like. Having created a 327 00:12:43,960 --> 00:12:45,490 shopping list, or whatever, the user would 328 00:12:45,490 --> 00:12:47,590 probably want to store it somewhere, so 329 00:12:47,590 --> 00:12:49,630 they can use that list when they get to 330 00:12:49,630 --> 00:12:51,820 the shops. If we close the activity down 331 00:12:51,820 --> 00:12:53,260 without saving, they'd lose at all. 332 00:12:53,260 --> 00:12:55,300 Now the onPause method could save 333 00:12:55,300 --> 00:12:57,610 that data. onStop, on the other hand, can 334 00:12:57,610 --> 00:12:59,380 be used to cancel a data transfer over 335 00:12:59,380 --> 00:12:59,760 the internet, 336 00:12:59,760 --> 00:13:02,160 with onStart, perhaps, initiating it 337 00:13:02,160 --> 00:13:04,320 again when the app runs again. And it's 338 00:13:04,320 --> 00:13:05,970 also more appropriate to save data 339 00:13:05,970 --> 00:13:10,020 remotely here, rather than in onPause. Now 340 00:13:10,020 --> 00:13:11,580 it's hard to know which, if any, you'll 341 00:13:11,580 --> 00:13:13,800 need until you come to need them, but 342 00:13:13,800 --> 00:13:15,420 when you do you'll be able to work out 343 00:13:15,420 --> 00:13:17,040 which method is the most suitable for 344 00:13:17,040 --> 00:13:19,110 what you want to do, by looking at each 345 00:13:19,110 --> 00:13:21,030 method in the context of the activity 346 00:13:21,030 --> 00:13:23,580 lifecycle. Alright, so that's the end of 347 00:13:23,580 --> 00:13:25,860 our button click counter app. The only 348 00:13:25,860 --> 00:13:27,210 thing left for me to do now is, really, 349 00:13:27,210 --> 00:13:29,820 just come up here to the code menu and 350 00:13:29,820 --> 00:13:34,350 click on Reformat Code, and then we didn't 351 00:13:34,350 --> 00:13:35,400 need to do anything, as you can see 352 00:13:35,400 --> 00:13:36,750 there, everything was correctly formatted. 353 00:13:36,750 --> 00:13:38,280 I've done that just to make sure the 354 00:13:38,280 --> 00:13:40,770 code is formatted nicely, before I add it 355 00:13:40,770 --> 00:13:42,330 to the resources section for this video. 356 00:13:42,330 --> 00:13:44,340 So I'm going to finish the video by 357 00:13:44,340 --> 00:13:46,770 showing you the Google documentation for 358 00:13:46,770 --> 00:13:48,720 activities and the activity lifecycle. 359 00:13:48,720 --> 00:13:51,240 Now I definitely recommend you read 360 00:13:51,240 --> 00:13:53,040 those pages when you want to know more 361 00:13:53,040 --> 00:13:55,410 about how this all works. Now the first 362 00:13:55,410 --> 00:13:56,580 one I'm going to show, I'm just gonna open a 363 00:13:56,580 --> 00:14:03,450 browser here. This first one is the 364 00:14:03,450 --> 00:14:06,780 Activity page from the Android reference 365 00:14:06,780 --> 00:14:08,520 Docs, and the link will be in the 366 00:14:08,520 --> 00:14:11,010 resources section. And that also includes, 367 00:14:11,010 --> 00:14:13,080 if we scroll down a little bit, 368 00:14:13,080 --> 00:14:15,750 Google's diagram on the lifecycle. Now 369 00:14:15,750 --> 00:14:17,670 keep in mind, that Google also produce 370 00:14:17,670 --> 00:14:19,710 guides in their documentation, and the 371 00:14:19,710 --> 00:14:24,150 activities guide is also available, and 372 00:14:24,150 --> 00:14:25,830 there's the link to that, and again in 373 00:14:25,830 --> 00:14:26,900 the resources section. 374 00:14:26,900 --> 00:14:30,570 That's quite a useful page to 375 00:14:30,570 --> 00:14:31,710 find out more information about 376 00:14:31,710 --> 00:14:34,050 activities, and there's also the 377 00:14:34,050 --> 00:14:35,730 tutorials on the Android developer site. 378 00:14:35,730 --> 00:14:38,100 So you may find the one on Recreating 379 00:14:38,100 --> 00:14:39,750 the activity after the system's 380 00:14:39,750 --> 00:14:41,340 destroyed it, useful, and I'll give you 381 00:14:41,340 --> 00:14:46,370 the link for that one. 382 00:14:46,370 --> 00:14:48,630 That's also got some good information, 383 00:14:48,630 --> 00:14:51,720 but lots of good information on that 384 00:14:51,720 --> 00:14:54,360 page as well. And currently, the code 385 00:14:54,360 --> 00:14:56,880 snippets are only showing in Java, but 386 00:14:56,880 --> 00:14:58,410 I'm sure over time they'll update this to 387 00:14:58,410 --> 00:15:01,260 show both Java and Kotlin examples. But 388 00:15:01,260 --> 00:15:02,940 the documents are well worth reading, all 389 00:15:02,940 --> 00:15:04,740 the same. So happy reading 390 00:15:04,740 --> 00:15:08,269 and I'll see you in the next video.