0 1 00:00:00,360 --> 00:00:08,850 Now, you can see that if I collapse this, we're only getting 15 items back, so 15 tweets back from the API 1 2 00:00:08,850 --> 00:00:09,760 requests. 2 3 00:00:09,810 --> 00:00:12,780 Now, why is that and how can we increase it? 3 4 00:00:13,260 --> 00:00:20,430 So let's head back to our Twitter documentation because all queries relating to any sort of API we're 4 5 00:00:20,430 --> 00:00:27,570 using, we have to try and find the answer in the API docs. And if you read through all of these parameters, 5 6 00:00:27,720 --> 00:00:30,270 then you come across one called count. 6 7 00:00:30,270 --> 00:00:35,670 You can see this is an optional parameter so you don't have to specify a value for it. But if you do, 7 8 00:00:35,820 --> 00:00:44,550 then you can specify the number of tweets to return per page up to a maximum of 100, and it defaults 8 9 00:00:44,640 --> 00:00:45,600 to 15. 9 10 00:00:45,600 --> 00:00:53,670 That's why we're getting 15 results back. So we can increase it to 100 so that we can reach the maximum. 10 11 00:00:53,670 --> 00:01:00,330 And, obviously, the more tweets that we use and we process through our sentiment analysis, the more accurate 11 12 00:01:00,540 --> 00:01:03,410 our overall feel of the topic is, right? 12 13 00:01:03,480 --> 00:01:10,110 If we've got the sentiment of how people feel about Apple using our search of @Apple and it's only 13 14 00:01:10,110 --> 00:01:15,570 based on 15 tweets, then it's obviously not going to be as accurate as if we did it on 100. 14 15 00:01:16,110 --> 00:01:22,380 So let's go ahead and add this count parameter to our search tweet method. 15 16 00:01:22,380 --> 00:01:28,350 So I'm going to add it just after the part where it says "using," and I'm going to say "count," and I'm going 16 17 00:01:28,350 --> 00:01:32,620 to increase it to 100. 17 18 00:01:32,730 --> 00:01:40,040 So, now if we rerun our app, and you can see that it was printing for a little bit longer, 18 19 00:01:40,100 --> 00:01:46,910 but let's go ahead and copy all of that and, again, place it into our JSON editor. 19 20 00:01:47,000 --> 00:01:56,210 And again, of course, go right to the top and delete these parts from the debugger and put it over here. 20 21 00:02:11,390 --> 00:02:17,690 And then let's hit the right button and let's try and turn it into a JSON, and we can see we now have 21 22 00:02:17,840 --> 00:02:21,250 a 100 results in our array. 22 23 00:02:21,320 --> 00:02:27,470 So we've now managed to successfully increase to the maximum number of tweets we can get back from Twitter. 23 24 00:02:28,160 --> 00:02:33,050 And, of course, if you needed even more tweets to come back from your search, you can either perform the 24 25 00:02:33,050 --> 00:02:40,550 search multiple times increasing the date range, for example, or you can go to one of the premium plans 25 26 00:02:40,580 --> 00:02:45,680 or the enterprise plans, and they'll allow you to fetch back more results as well. 26 27 00:02:45,680 --> 00:02:49,120 But for our purposes, this should be more than sufficient. 27 28 00:02:49,190 --> 00:02:54,680 Now, the other thing that you might notice when you have a look at the text of the tweets that we're 28 29 00:02:54,680 --> 00:02:58,800 getting back is that some of them are not in English, right? 29 30 00:02:58,820 --> 00:03:02,920 For example, this one looks like Turkish, I think. 30 31 00:03:03,170 --> 00:03:12,860 And remember that our sentiment analysis, analyzer rather, was trained on English tweets, so we can only 31 32 00:03:12,920 --> 00:03:15,890 interpret the sentiment in English. 32 33 00:03:16,010 --> 00:03:23,390 So instead of getting back, you know, lots of tweets in different languages, we can try and only ask for 33 34 00:03:23,720 --> 00:03:31,430 the tweets that are in English. And that, of course, is yet another parameter that we can include which 34 35 00:03:31,430 --> 00:03:33,010 is called language. 35 36 00:03:33,200 --> 00:03:39,140 And this will restrict the tweets we get back to the given language given by an ISO code. 36 37 00:03:39,470 --> 00:03:47,660 So if you go ahead and click on here, you can see the ISO codes for all of the countries, and English 37 38 00:03:47,960 --> 00:03:51,960 is usually across the board denoted by "en." 38 39 00:03:52,030 --> 00:03:57,340 So let's go ahead and add that parameter to our list of parameters. 39 40 00:03:57,500 --> 00:04:03,890 Now, the place where you add it kind of matters because if you place it behind the "count"--let's see. 40 41 00:04:06,710 --> 00:04:14,150 You'll see that you get an error here from Xcode, And it says that the argument language must precede 41 42 00:04:14,270 --> 00:04:18,980 the argument count and it is giving you an automatic suggested fix. 42 43 00:04:19,010 --> 00:04:24,740 So let's go ahead and fix that. And you can see it's basically moved this parameter and its value to 43 44 00:04:24,740 --> 00:04:26,780 before the one that says count. 44 45 00:04:26,960 --> 00:04:34,640 And that's because in the method that is searchTweet, they've specified the order that all these parameters 45 46 00:04:34,640 --> 00:04:39,470 must come in, and the order follows the order that you see them in this table, 46 47 00:04:39,470 --> 00:04:46,100 so geocode comes before language, language comes before locale, et cetera. But Xcode's quite helpful in 47 48 00:04:46,100 --> 00:04:50,230 this case, actually, pointing it out to you and fixing it for you. 48 49 00:04:50,240 --> 00:04:58,670 So, now if we run this again, specifying that we only want the tweets that are in English, then you can 49 50 00:04:58,670 --> 00:05:02,300 see if I go again over to JSON editor 50 51 00:05:07,030 --> 00:05:14,700 and I delete all of that, and here I'm actually getting a parse error here. And this is because the location 51 52 00:05:14,700 --> 00:05:20,660 of a particular tweet is in this format, it's actually Halifax Nova Scotia. 52 53 00:05:20,790 --> 00:05:25,390 But in this particular JSON editor, it doesn't like that format. 53 54 00:05:25,590 --> 00:05:30,780 So we can go ahead and try to locate it line 5188. 54 55 00:05:30,780 --> 00:05:34,140 So let's try and find that 5188. 55 56 00:05:34,140 --> 00:05:36,030 You can see it's got a little cross next to it. 56 57 00:05:36,390 --> 00:05:42,360 So let's just go ahead and delete that because we don't really care for it anyways. 57 58 00:05:42,390 --> 00:05:45,010 Let's go ahead and click right button. 58 59 00:05:45,060 --> 00:05:48,500 So, now we have our 100 tweets. 59 60 00:05:49,020 --> 00:05:52,710 And if you look at them, they should all have text 60 61 00:05:52,830 --> 00:05:54,720 that's in English, right? 61 62 00:05:55,920 --> 00:06:03,810 So this will make it much easier for our sentiment analyzer to be able to process the tweets that we 62 63 00:06:03,810 --> 00:06:05,070 got here. 63 64 00:06:05,070 --> 00:06:11,220 Now, the next problem that you might notice if you look through a lot of these tweets is that the text 64 65 00:06:11,250 --> 00:06:18,910 that we're getting back is occasionally truncated, and it gets cut off at 140 characters. 65 66 00:06:18,960 --> 00:06:25,480 So if you don't remember this dramatic piece of news, don't worry, it wasn't that dramatic. 66 67 00:06:25,500 --> 00:06:35,170 But, recently, Twitter lifted the count for the number of characters from 140 to 280. So when you make 67 68 00:06:35,200 --> 00:06:44,040 a standard search request to the Twitter API, it gives you all the text back in 140 characters. It truncates 68 69 00:06:44,500 --> 00:06:50,830 at the 140th character. But, of course, because people are able to tweet at 280 characters, 69 70 00:06:51,160 --> 00:06:53,500 occasionally, you're getting missing bits of text. 70 71 00:06:54,010 --> 00:06:55,780 So what can we do? 71 72 00:06:55,780 --> 00:07:04,300 Well, we can either trawl through this documentation and, eventually, you'll find a guarantee, the part 72 73 00:07:04,450 --> 00:07:06,990 that tells you why this is and how you can fix it. 73 74 00:07:07,480 --> 00:07:12,970 But as a developer, you're going to come across these situations that you've never encountered before 74 75 00:07:13,270 --> 00:07:17,210 and you have to remember that your best friend is Google and Stack Overflow. 75 76 00:07:17,230 --> 00:07:24,160 So let's try and see if we can come up with a succinct and concise description of our problem and give 76 77 00:07:24,160 --> 00:07:26,640 it to Mr. Google to try and figure out. 77 78 00:07:26,740 --> 00:07:34,130 So "twitter api search tweets truncated." 78 79 00:07:34,180 --> 00:07:35,320 Let's see what we get from that. 79 80 00:07:35,860 --> 00:07:41,860 So the first result we get back is a Stack Overflow question that says, "Twitter api text field value 80 81 00:07:41,860 --> 00:07:45,600 is truncated," which is pretty much exactly our problem. 81 82 00:07:46,210 --> 00:07:53,320 And you have to remember at all times that it's very, very rare that you will ever come across a problem 82 83 00:07:53,350 --> 00:07:55,810 that nobody else has encountered before. 83 84 00:07:55,810 --> 00:08:02,920 So it's just a matter of getting to the right keywords or finding where somebody has posed that question 84 85 00:08:03,130 --> 00:08:05,830 or answered that question for you. 85 86 00:08:05,860 --> 00:08:13,420 So they have exactly the problem that we're describing. Over here, you see their tweet in the text property 86 87 00:08:13,540 --> 00:08:16,660 is truncated and they want it to be the full text. 87 88 00:08:16,690 --> 00:08:22,900 So the first answer with 28 upvotes is saying that the Twitter API has been recently changed to support 88 89 00:08:22,900 --> 00:08:27,810 the new rule regarding 280 character limit. To get the full text, 89 90 00:08:27,820 --> 00:08:34,960 we have to add the parameter tweet_mode with a value of extended to your request parameters. And instead 90 91 00:08:34,960 --> 00:08:40,420 of looking for text in the JSON response, we look for something called full_text. And there's a link to 91 92 00:08:40,420 --> 00:08:41,530 more info. 92 93 00:08:42,190 --> 00:08:48,880 If we scroll down here, you can see that there is a parameter called result_type and it's, again, an optional 93 94 00:08:48,880 --> 00:08:55,060 one. But it allows you to specify what type of search results you would prefer to receive. 94 95 00:08:55,060 --> 00:08:58,060 So we need to add this parameter tweet_mode. 95 96 00:08:58,060 --> 00:09:07,810 If we go back to our searchTweet method and if we, again, pull up that full method by going to swifter 96 97 00:09:08,230 --> 00:09:14,500 searchTweet and we automatically insert all of that, and I'm just going to comment it out because I'm 97 98 00:09:14,500 --> 00:09:21,640 not going to use it as code, I'm just gonna use it as a reference, and you can see that one of these parameters 98 99 00:09:21,730 --> 00:09:27,830 is something called tweetMode. And this comes just before the success callback. 99 100 00:09:28,060 --> 00:09:30,220 So we can add it right here. 100 101 00:09:30,670 --> 00:09:39,730 So it's called tweetMode. And it's expecting something with the data type of tweetMode. 101 102 00:09:39,770 --> 00:09:48,570 So here, what we need is to say .extended. And you can see as you start typing, you're getting that 102 103 00:09:48,570 --> 00:09:52,450 tweetMode being suggested to you. 103 104 00:09:52,470 --> 00:09:59,910 Now, at this point, you might wonder, how did I know to use an enum for the tweet mode using .extended 104 105 00:10:00,540 --> 00:10:05,520 because I can see that it's expecting something of class TweetMode, 105 106 00:10:05,520 --> 00:10:08,960 but I don't know what it is and what are the options. 106 107 00:10:09,000 --> 00:10:16,170 So one of the things that you can do inside Xcode is, instead, of using the option key where we try to 107 108 00:10:16,170 --> 00:10:23,970 look at the Discussion and Summary and Definition, one of the other things you can do is hold down the 108 109 00:10:23,970 --> 00:10:28,140 command key and click on a method. 109 110 00:10:28,350 --> 00:10:34,320 And this gives you a number of things, such as change the name of the method, or go and find the place 110 111 00:10:34,320 --> 00:10:36,770 where it was called, or show quick help. 111 112 00:10:37,050 --> 00:10:45,390 But there's another one called Jump to Definition, and this takes you to the place where that method 112 113 00:10:45,750 --> 00:10:47,160 was created. 113 114 00:10:47,550 --> 00:10:54,510 So in this case, this is a file in the Swifter framework called SwifterSearch.swift 114 115 00:10:54,510 --> 00:11:05,130 and this is where the definition of the searchTweet function is declared. And this function has a parameter 115 116 00:11:05,160 --> 00:11:09,630 called tweetMode and it's normally set to default. 116 117 00:11:09,630 --> 00:11:12,830 Now we can see this thing called TweetMode. 117 118 00:11:13,020 --> 00:11:20,070 If you hold down the command key again and jump to its definition, then you can see where that enum was 118 119 00:11:20,070 --> 00:11:21,220 created. 119 120 00:11:21,420 --> 00:11:31,500 And you can see all of the cases that you can use, for example, .default, .extended, .compat, and 120 121 00:11:31,500 --> 00:11:38,850 the one that we want is, of course, extended so that we send this to the Twitter API and we get back the 121 122 00:11:38,850 --> 00:11:41,570 full text of the tweet. 122 123 00:11:41,580 --> 00:11:48,660 So, now let's head back to our ViewController and try and run our app now with the tweetMode set as 123 124 00:11:48,660 --> 00:11:49,460 extended. 124 125 00:11:50,250 --> 00:11:58,320 And if you remember previously, we had the 29th tweet showing a truncated text. 125 126 00:11:58,350 --> 00:12:05,190 So, now if we copy the new result that we got from that running and paste it in here 126 127 00:12:08,650 --> 00:12:15,280 and, again, deleting that part, and fixing the error on 8026, 127 128 00:12:20,590 --> 00:12:28,390 and we look through these tweets, you can see that we're now getting a much longer number of characters 128 129 00:12:28,510 --> 00:12:36,460 up to 280, and it's now under a property called full_text rather than the previous one which was text. 129 130 00:12:36,460 --> 00:12:42,310 So, now that we're able to get all the tweets we want in the format that we want, it's time to run our 130 131 00:12:42,310 --> 00:12:48,760 machine learning model on it to start predicting what is the sentiment in each of these tweets. 131 132 00:12:49,030 --> 00:12:55,630 And you can see, as a human, I'm reading this tweet and I feel like it's a tad negative talking about 132 133 00:12:55,630 --> 00:12:56,980 how Apple never tweets, 133 134 00:12:56,980 --> 00:12:58,880 they just promote their ads. 134 135 00:12:59,020 --> 00:13:05,980 And although you could also argue that it's neutral, but let's see what our model thinks, and let's run 135 136 00:13:05,980 --> 00:13:08,140 it through to see what we get. 136 137 00:13:08,170 --> 00:13:09,520 So in the next lesson, 137 138 00:13:09,520 --> 00:13:11,170 that's exactly what we're gonna be doing. 138 139 00:13:11,170 --> 00:13:15,560 We're going to be applying our prediction to these tweets. 139 140 00:13:15,580 --> 00:13:18,280 So for all of that and more, I'll see you on the next lesson.