\u00a0![\"epg\"](\"https:\/\/the-plot.com\/blog\/wp-content\/uploads\/2015\/06\/epg.png\")
<\/a><\/div>\n
<\/a><\/div>\n<\/div>\n
\u2026 and with programme previews that look like this:<\/div>\n
<\/div>\n![\"preview\"](\"https:\/\/the-plot.com\/blog\/wp-content\/uploads\/2015\/06\/preview.png\")
<\/a><\/div>\n
<\/a><\/div>\n<\/div>\n
I\u2019m continuing the development, and it\u2019s already a pretty large codebase. It\u2019s not one that\u2019ll end up on GitHub [for reasons I\u2019ll get on to shortly], but I think there are some pretty interesting challenges that I didn\u2019t come across anything approaching kitform answers for, so I\u2019m going to pluck out the interesting parts for a deeper dive.<\/div>\n
<\/div>\n
The first and obvious question is where to get the Electronic Programme Guide data and, all importantly, data that is free. After some research, I settled on a service offered by the Radio Times, which uses a standard format called XMLTV. As I\u2019m not into hacking PVRs, I\u2019d never come across this standard before. The first thing to say is that the Radio Times variant isn\u2019t actually in XML, it\u2019s character delimited. The next is that it\u2019s very clearly identified as being for personal use only – hence I\u2019m not going to publish the app in full.<\/div>\n
<\/div>\n
First, let\u2019s deal with the data download from the per-channel URLs. Currently, I\u2019ve hard-wired the app to download 12 channels\u2019 worth of data, something that I ultimately plan on linking back to the UI so that the user can self select them. Each channel download contains two weeks of programme data, so over a mobile network, the overriding UX consideration is progress.<\/div>\n
<\/div>\n
Having previously lost a couple of hours to this in the past, trying to hook up a fancy UI component showing progress graphically, it\u2019s one to put front and centre when you\u2019re designing the networking component. Quite commonly, servers will be generating responses dynamically, in which case, there\u2019s a very good chance the Content-Length header won\u2019t be set.<\/div>\n
<\/div>\n
The progress indicator must have the total of bytes available to be able to calculate progress. The Radio Times site isn\u2019t setting the required header, so no fancy progress meters – sad face. This is actually a more complex use case anyway, because we\u2019d have needed to calculate the progress for a dozen downloads, and the progress of each is going to be interlaced.<\/div>\n
<\/div>\n
What I\u2019ve done is to initiate each download in a for loop using AFNetworking, and then in the\u00a0setCompletionBlockWithSuccess\u00a0block:<\/div>\n
\nNSData *channelData = (NSData *)responseObject;
\nChannelDataParser *channelProgs = [[ChannelDataParser alloc] init];
\nNSMutableArray *asProgObjects = [channelProgs programmeChunker:channelData andChannelName:thisPhoneChannel.channelName];
\n[self storeChannelProgData: asProgObjects forThisChannelName:thisPhoneChannel.channelName];
\n<\/code><\/p>\n<\/div>\nI\u2019ll come back to the parser in a second, but one point to focus on is the method to store the parsed results. As the network responses are interleaved, and they\u2019re all ultimately going to be written to the same Core Data entity, I\u2019ve wrapped the method in an @synchronized(managedObjectContext).<\/div>\n<\/div>\nIn that same @synchronized method, I increment a completed download counter, which I use to set a label in the UI. Pretty crude, but given the progress limitations, it seems like a reasonable compromise. I\u2019ve actually spent the vast majority of the time on the UI for the programme guide, so I might take another look at this later.<\/div>\n<\/div>\nBack to the parser itself. First up, for the NSData that contains the AFNetworking response for the channel, the first step is to convert it into a string, and then an array of strings divided by line breaks:<\/div>\n
\nNSString *stringFromData = [[NSString alloc] initWithData:channelData encoding:NSUTF8StringEncoding];
\n\/\/ The line break vs carriage return: done through experimentation:
\nNSArray *eachLineOfString = [stringFromData componentsSeparatedByString:@\"\\n\"];
\n<\/code><\/code><\/code><\/p>\n<\/div>\n<\/div>\nThe parsing was something that required trial and error, as the file contained some copyright info at the start, and then some carriage returns at the end:<\/div>\n<\/div>\n for (int progCount = 2; progCount <= [eachLineOfString count] -2 ; progCount++)
\n{
\nNSString *oneLine = eachLineOfString[progCount];
\nif (![oneLine isEqualToString:@\"\\r\"])
\n{
\n[.....]
\n<\/code><\/div>\n<\/div>\nWithin the loop, I then parse out the carriage returns, and finally split the data into an array, based on the separator character [a tilde]r:<\/div>\n
\nNSString *oneLineNoBreak = [oneLine stringByReplacingOccurrencesOfString:@\"\\r\" withString:@\"\"];
\n\/\/NSLog(@\"oneLineNoBreak is %lu long\", (unsigned long)oneLineNoBreak.length);
\nNSArray *oneProgrammeData = [oneLineNoBreak componentsSeparatedByString:@\"~\"];
\n<\/code><\/div>\n<\/div>\nI think I would have struggled with the whole \\r versus \\n thing if I hadn\u2019t been bitten with it way back in the old days of the \u00a0mid 1990s. I can\u2019t recall if it was FTPing files with the wrong transfer type or using Samba between Windows and Unix machines, but either way, you were prone to getting oddities with the control characters in text files. Anyway…<\/div>\n<\/div>\nAt this point we are ready to assign values, based on the content of the array conforming to the XMLTV standard. So the 0th element of the array is the programme title, then comes a subtitle, etc. I assign these to an instance of a custom class. I found it useful to add an additional three fields, all related to the UI. The first is the running order that the programmes appear in: once you save them to Core Data as individual records representing the programmes, they become unordered – standard database stuff. Next is a GUID: I\u2019ll get into this in more detail in a subsequent posting on the UI, but the summary is that it\u2019s to associate programme data with a button action. Finally, I also include the channel name for the programme: this is to do with a limitation in the UI design – again, I\u2019ll come back to this later.<\/div>\n<\/div>\nI cycle through parsing each channel, ultimately saving them to the core data in the @synchronised method I mentioned earlier.<\/div>\n<\/div>\nOne final point on the networking side. I do a simple check in a Core Data entity with a single value to see if it\u2019s the first run. If it is, I haul down the data before presenting the UI. I also haven\u2019t finished the part of the UI where the user can self select the channels. For now, it\u2019s hardwired. This list of channels and the corresponding URLs also gets written to another simple entity during that first run.<\/div>\n<\/div>\nI\u2019ll follow up with a description of the UI design\u2026.<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"[Edit: 12\/06\/2016. The source I used for the programme data, called Radio Times XML TV, is just about to be shut down and replaced with another service which restricts the amount of data that can be hauled down to 24 … Continue reading