One downside of the code I presented is that the actual reading and writing was still happening on the main UI thread. While this may not be a problem in a simple application, it is undesirable for complex documents.

The challenge is that we still need to be on the UI thread when we collect the data we want to save, but the writing itself could be on a background thread.

In this article I will cover a way to extend the API I presented previously, to allowing reading and writing via a background thread.

Reading on the background thread

One key tenet to reading in the background is that we need to load all of the data in before we update the UI. Think of a Microsoft Word document being loaded into memory in the background in its in-memory format, then only presenting it in the UI once the load has completed.

This is how we want to write our reading code:

FileAsync.Read<string>(KnownFolders.DocumentsLibrary, "myfile.txt",
    (fileSize, reader) => reader.ReadString(fileSize)  /* read in the background */,
    text => EditBox.Text = text  /* update the UI on the main thread */);

The example here is very simple, as our in memory “document” is a single string. In an application build using the MVVM pattern (Model-View-ViewModel), this would be a great way to load the Model in from a file, and finally bind it into the ViewModel once it has loaded through the two steps shown above.

Here is the implementation of the Read method:

public static async void Read<TDocument>(StorageFolder folder, string fileName,
Func<uint, DataReader, TDocument> reader, Action<TDocument> completion = null)
{
    StorageFile file;
    IRandomAccessStream stream;
    IInputStream inputStream;
    DataReader dr;
 
    file = await folder.GetFileAsync(fileName);
 
    stream = await file.OpenAsync(FileAccessMode.Read);
    inputStream = stream.GetInputStreamAt(0);
 
    uint fileSize = (uint)stream.Size;
 
    dr = new DataReader(inputStream);
    await dr.LoadAsync(fileSize);
 
    Task<TDocument> task = new Task<TDocument>(() => reader(fileSize, dr));
    task.Start();
    TDocument doc = await task;
 
    if (completion != null)
    {
        completion(doc);
    }
}

Here we used the new Task class, which is what underpins the await and async keywords.

Writing

Writing to the file involves creating the “document” on the UI thread (while may mean simply passing your Model if you are using MVVM). The Write method will then call you asynchronously to get the document written out.

FileAsync.Write<string>(KnownFolders.DocumentsLibrary, "myfile.txt",
   CreationCollisionOption.ReplaceExisting,
   EditBox.Text, /* pass in our "document" content */
    (w, doc) => w.WriteString(doc) /* write the "document" in the background */);

Much like the Read method, Write leverages Task to perform the writing.

public static async void Write<TDocument>(StorageFolder folder, string fileName,
    CreationCollisionOption collisionOption, TDocument doc,
    Action<DataWriter, TDocument> writer, Action<bool> complete = null)
{
    StorageFile creator;
    IRandomAccessStream stream;
    IOutputStream outputStream;
    DataWriter dw;
 
    creator = await folder.CreateFileAsync(fileName, collisionOption);
 
    stream = await creator.OpenAsync(FileAccessMode.ReadWrite);
    outputStream = stream.GetOutputStreamAt(0);
 
    dw = new DataWriter(outputStream);
 
    Task task = new Task(() => writer(dw, doc));
    task.Start();
    await task;
 
    await dw.StoreAsync();
    bool success = await outputStream.FlushAsync();
    if (complete != null)
    {
        complete(success);
    }
}

As you can see, the Windows Runtime makes it really easy to create asynchronously called code. With very little code we were able to take our earlier code, and with a little refactoring, enable the reading and writing to be fully performed on a background thread. Windows 8 should allow developers to create really great apps that stay responsive even when performing lengthy operations. When its this easy to achieve, this should become the rule rather than the exception.

This week at the Build Windows conference, Microsoft announced Windows 8 and introduced the new Windows Runtime APIs for the developers.

As a C# developer, one of the defining features of the Runtime is that a lot of the .NET Framework is “gone”, or moved to new namespaces. Nowhere is this more true than in System.IO, which is now fairly barren. The reason is that most of the file I/O APIs in the Windows Runtime are designed to be asynchronous, and as these new APIs are in the Runtime, they’ve moved into the Windows.* namespace.

As it turns out, reading and writing files using the new asynchronous APIs is a little convoluted. OK, its a lot convoluted, but I’ve put together some code that should simplify it for you, while also taking you through the steps involved.

When I think of reading or writing a file synchronously, I think of moving the reading or writing operation into a delegate that will be called for me when the time comes. For example, I would want to read a file asynchronously from our Documents library using code like this:

FileAsync.Read(KnownFolders.DocumentsLibrary, "myfile.txt", (fileSize, reader) =>
    {
        string text = reader.ReadString(fileSize);
 
        this.EditBox.Text = text;
    });

Let’s see what is needed to make this work.

First let’s pull in the namespaces we’ll need:

using System;
using Windows.Storage;
using Windows.Storage.Streams;

Now let’s create the shell of our class…

namespace SteveSaxon.IO
{
    public static class FileAsync
    {
    }
}

Next we’ll add support for reading files. This may seem overly complicated, but the await keyword is greatly simplifying it for us. In a nutshell, await allows you to make a call on a background thread, such that once it completes, the result of the call is dispatched back to the thread you made the call from. You get to write fairly natural looking code knowing that you’re never blocking the calling thread, but getting to take full advantage of all of the computing power in your system.

Better yet, if your asynchronous call ends up throwing an exception, this exception gets thrown in your calling thread too, so the exception case is also extremely elegant.

Here is the code for our Read method:

public static async void Read(StorageFolder folder, string fileName,
    Action<uint, DataReader> reader)
{
    StorageFile file;
    IRandomAccessStream stream;
    IInputStream inputStream;
    DataReader rdr;
 
    file = await folder.GetFileAsync(fileName);
 
    stream = await file.OpenAsync(FileAccessMode.Read);
    inputStream = stream.GetInputStreamAt(0);
 
    uint fileSize = (uint)stream.Size;
 
    rdr = new DataReader(inputStream);
    rdr.LoadAsync(fileSize);
 
    reader(fileSize, rdr);
}

The StorageFolder first parameter may seem confusing, but it is the return type for the constants in the KnownFolders class, such KnownFolders.DocumentsLibrary and KnownFolders.PicturesLibrary.

One thing you may have noticed in the sample I presented: I was setting the text of an control in the UI based on the data I read in. In order for that to work, our delegate must have been called on the main thread, and in fact that is exactly what happens when you use await. When you issue an await, the awaited code is called on another thread, then joined back to the main thread when it completes.

If we had not been on the main thread, we would have needed to use code like this to marshal it back to the UI thread:

this.Dispatcher.InvokeAsync(Windows.UI.Core.CoreDispatcherPriority.Normal,
            (dummy, args) => this.EditBox.Text = text, this, null);

Now you can see how elegant the await keyword is!

To simplify using the code with any folder on our disk let’s add the following helper function:

public static async void Read(string folderPath, string fileName,
        Action<uint, DataReader> reader)
{
    StorageFolder folder = await StorageFolder.GetFolderFromPathAsync(folderPath);
 
    Read(folder, fileName, reader);
}

Writing is even more steps than reading, but we’ll try to make it simple. I’ve included the folder helper here too:

public static async void Write(StorageFolder folder, string fileName,
        CreationCollisionOption collisionOption, Action<DataWriter> writer,
        Action<bool> complete = null)
{
    StorageFile creator;
    IRandomAccessStream stream;
    IOutputStream outputStream;
    DataWriter dw;
 
    creator = await folder.CreateFileAsync(fileName, collisionOption);
 
    stream = await creator.OpenAsync(FileAccessMode.ReadWrite);
    outputStream = stream.GetOutputStreamAt(0);
 
    dw = new DataWriter(outputStream);
 
    writer(dw);
 
    await dw.StoreAsync();
    bool success = await outputStream.FlushAsync();
    if (complete != null)
    {
        complete(success);
    }
}
 
public static async void Write(string folderPath, string fileName,
        CreationCollisionOption collisionOption, Action<DataWriter> writer,
        Action<bool> complete = null)
{
    StorageFolder folder = await StorageFolder.GetFolderFromPathAsync(folderPath);
 
    Write(folder, fileName, collisionOption, writer, complete);
}

Notice how the Write code allows us to pass in a delegate that is called once the writing is complete. This is because when you write your content out, it may get buffered and may not get committed right away. The completed delegate will be called once all of the content has been safely saved away. This might be important if you want to disable the Save button in your UI until the previous Save has completely finished.

We can now write back to our file using this code, in the same simple way our Read operation did:

FileAsync.Write(KnownFolders.DocumentsLibrary, "myfile.txt",
            CreationCollisionOption.ReplaceExisting, w =>
                {
                    w.WriteString(this.EditBox.Text);
                });

While asynchronous file I/O is still quite daunting in the Windows 8 Developer Preview, you can see how with a little work up front, it can be made quite elegant, while still retaining all of the power of its asynchronous nature.

In part 2 of this article we will look at how to make the reading and writing operations themselves be asynchronous too.

The purpose of the My Daily is to simplify entry into the Calendar for situations where you are given a daily schedule of back-to-back tasks.

The app allows you to set a daily start time. When you add an event, you pick the name from a list of names you define. Each name can be associated with a color swatch, allowing you to classify similar names with the same color.

Your first event will start at the daily start time, and subsequent events will start right after the previous event. Now you can add an event to your calendar by simply picking a name and clicking Save!

The neat thing is: if you delete an event, change its duration, or re-order the event, the start/end times are automatically updated. And the whole time, all of your changes are being synced into your iPhone’s Calendar, so you get all the same automatic alerts you expect.

And because My Daily syncs to your iPhone’s Calendar, each event can also have a reminder alert a few minutes before it is due to start. Reminders are also picked with a single click (no more navigating between screens).

* Update – My Daily is now live in the App Store.

The short version is: a pro-sumer iPad intended for users of Apple’s pro-sumer apps such as Final Cut Pro. The device is rumored to have a 2048×1536 Retina display (around 300dpi). I’d also expect to see 128GB of storage and LTE to store and move those big media files around.

Less sure is what it will look like. There were some rumors a few weeks ago that Apple was testing a black powder coat treatment for the MacBook Air, but then an alleged Apple engineer claimed it had been abandoned because of fingerprints. I guess I’m expecting the case to be black or dark grey to match the look of the pro-sumer apps, and to distinguish it from the regular (and much cheaper!) iPad 2. Apple even has an agreement to use LiquidMetal, which is darker than the aluminum on the “2″.

In other news, there was a rumor that Apple was looking to add a second manufacturer for the iPad alongside Foxconn, but this was quickly rebuffed with a statement to the effect of “Foxconn is still the exclusive manufacturer”. But what if what is happening is: Foxconn will start building the iPad HD at their Chengdu plant, while the existing Shenzen plant continues to build the iPad. So in that regard, the original rumor and the rebuff are both true.

Whatever it turns out to be, I know I’m going to want one.

One fairly simple way to achieve this is by enabling Screen Sharing via System Preferences:

Once Screen Sharing is enabled, you can run UltraVNC on your PC to connect to your Mac using the URL shown in the Screen Sharing window.

Now in Live Meeting, share your Desktop (or just share the UltraVNC window).

If you are doing this using a separate PC talking to your Mac, don’t forget you are simply sharing your Mac screen, so the Mac keyboard and mouse can be used to control the action, making it more responsive than trying to use the PC keyboard and mouse via VNC.

You can download UltraVNC here:

http://www.ultravnc.com/

One current limitation is you can’t directly leverage this to test your mobile web sites, although the Simulator does provide some boilerplate locations built in.

A workaround is to create a small Universal iOS app in Xcode, and tell it to load your mobile web site’s URL during applicationDidFinishLaunching.

- (BOOL)application:(UIApplication *)application
        didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    NSURL* url = [NSURL URLWithString:@"http://www.google.com/"];
    [application openURL:url];
 
    exit(0); // remove this to keep the debugger running!
 
    return YES;
}

I can now use Edit Scheme to set my location, or create multiple schemes each for a different location. When I run this application, the GPS will be initialized with my prescribed location, then Safari will be invoked to open the URL I provided.

(Notice how in the second image Google is providing the “See Places Near” using the London location I provided).

By removing the exit(0) statement, it should even be possible to leverage the GPS automation capabilities provided by the new version of Instruments to automate the location over time and have Safari pick that up, though I haven’t had time to test this.

An Update button causes the app to reach out to the server and reload the page.

The screenshots below show the app before and after updating:

The app is fairly simple. We wired up the RootViewController to use a UIWebView, and wired up the Update button all in Interface Builder.

In viewDidLoad we load the initial content:

- (void)viewDidLoad
{
    [super viewDidLoad];
 
    SSContentBundle* provider = [SSContentBundle mainBundle];
    NSString* docPath = [provider pathForFile:@"index.html"];
 
    NSLog(@"Path to index.html: %@", docPath);
 
    NSURL* url = [NSURL fileURLWithPath:docPath];
    NSURLRequest* request = [NSURLRequest requestWithURL:url];
 
    UIWebView* webView = (UIWebView*)self.view;
    [webView loadRequest:request];
}

When the Update button is clicked we perform the update:

- (IBAction)performUpdate:(id)sender
{
    SSContentBundle* provider = [SSContentBundle mainBundle];
 
    self.navigationItem.rightBarButtonItem.enabled = NO;
 
    [provider checkForUpdatesWithCompletionHandler:^(BOOL updateFound, NSError *error)
     {
         self.navigationItem.rightBarButtonItem.enabled = YES;
 
         if(error)
         {
             NSLog(@"Error removing old content: %@", [error localizedDescription]);
             UIAlertView* alert;
             alert = [[UIAlertView alloc] initWithTitle:@"Content Test"
                                                message:[error localizedDescription]
                                               delegate:nil
                                      cancelButtonTitle:@"OK"
                                      otherButtonTitles:nil];
             [alert show];
             [alert release];
             return;
         }
 
         if(updateFound)
         {
             // refresh the browser...
             UIWebView* webView = (UIWebView*)self.view;
             [webView reload];
         }
     }];
}

That’s about it… The server content has different HTML, and includes an image to prove that we can reference other files – they’re all just expanded onto the file system after all.

The changes are already live on github: https://github.com/ssaxon/contentbundle

It turns out that once you’ve gone through all of the ACS authentication process, a security token is generated. You need this token to authenticate yourself against ACS-bound web sites. However the ACS web site passes the token to you by calling window.external.Notify()

window.external.Notify("security-token-here");

While window.external.Notify is supported in Internet Explorer on the desktop and also in Windows Phone, it is not supported in iOS. Worse, while the WebView control on the Mac can call your Objective C code from JavaScript, the iOS UIWebView does not support this.

Another mechanism was needed. Here is how I solved it.

Extending the JavaScript object model

The first challenge was how to add in a new method under the built-in window object. What if iOS prevented changes to the window object? Well thankfully it doesn’t. And because objects in JavaScript are all just dictionaries, it is fairly easy to extend objects at runtime.

The second challenge was how to get information from the JavaScript back to my iOS code, particularly given that we don’t have access to the Objective C integration we have on the Mac. Actually there is really only one way, and that is by telling the browser to access some URL in a way that we can catch in our UIWebViewDelegate code.

Here is the JavaScript I wrote to extend the window object:

<script type=\"text/javascript\">
    window.external =
    {
        'Notify': function(s) { document.location = 'acs://settoken?token=' + s; },
        'notify': function(s) { document.location = 'acs://settoken?token=' + s; }
    };
</script>

The code above registers the “external” property on the window object, and adds two functions. Both uppercase and lowercase versions were required.

I ran into a third problem while trying to hook this JavaScript into the page generated by the ACS web site.

UIWebViewDelegate is fairly simple in what it provides:

@protocol UIWebViewDelegate <NSObject>
 
@optional
- (BOOL)webView:(UIWebView *)webView
     shouldStartLoadWithRequest:(NSURLRequest *)request
                 navigationType:(UIWebViewNavigationType)navigationType;
- (void)webViewDidStartLoad:(UIWebView *)webView;
- (void)webViewDidFinishLoad:(UIWebView *)webView;
- (void)webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error;
 
@end

I seemed like webViewDidFinishLoad: would give me an easy way to integrate this. The problem was that the ACS web site would attempt to call window.external.Notify() immediately after the page loaded, right before my delegate was called. Worse, webViewDidStartLoad: seemed to be too early! I needed to find another way.

Hooking my script into the UIWebView

The iOS UIWebView is very simple to use, but that simplicity means there are precious few hooks for doing this type of integration. In fact the only direct way to interact with the page is through the call below:

- (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;

It seemed in theory I could use this call to hook in some JavaScript, but as I mentioned, I couldn’t get this call in early enough to register it. I needed a more brute-force approach!

My only alternative was webView:shouldStartLoadWithRequest:navigationType:. However, this delegate call is simply telling me that the browser is about to load the content. I would need to load the content myself, prepend my JavaScript (so that it was guaranteed to run before the ACS JavaScript) and give it to the UIWebView.

This was my final version of the delegate call.

- (BOOL)webView:(UIWebView *)webView
     shouldStartLoadWithRequest:(NSURLRequest *)request
                 navigationType:(UIWebViewNavigationType)navigationType
{
    if(_url)
    {
        /* make the call re-entrant when we re-load the content ourselves */
        if([_url isEqual:[request URL]])
        {
            return YES;
        }
 
        [_url release];
    }
 
    _url = [[request URL] retain];
    NSString* scheme = [_url scheme];
 
    if([scheme isEqualToString:@"acs"])
    {
        // parse the JSON URL parameter into a dictionary
        NSDictionary* pairs = [self parsePairs:[_url absoluteString]];
        if(pairs)
        {
            WACloudAccessToken* accessToken;
            accessToken = [[WACloudAccessToken alloc] initWithDictionary:pairs];
            [WACloudAccessControlClient setToken:accessToken];
 
            [self dismissModalViewControllerAnimated:YES];
        }
 
        return NO;
    }
 
    [NSURLConnection connectionWithRequest:request delegate:self];
 
    return NO;
}

You can see this code is really doing 3 things:

• We remember the URL that was requested. We are going to have to load the HTML ourselves, then give it to UIWebView. When we do that it will call our delegate a second time. We need to recognize that, and treat it like a no-op, or go around in an endless loop.
• We need to detect if the URL was our “acs://” call made by our JavaScript hook, and if so, take the JSON URL parameter and use it to parse out the security token.
• Finally if it is a regular HTML load, we need to begin the process of loading it ourselves and tell UIWebView to not load it by returning NO.

I’m using fairly standard code for my NSURLConnectionDelegate handlers. The only thing out of the ordinary is that once the HTML has finished loading, I prepend the JavaScript we saw earlier and tell the UIWebView to load it.

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
    if(_data)
    {
        [_data release];
        _data = nil;
    }
}
 
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
    if(!_data)
    {
        _data = [data mutableCopy];
    }
    else
    {
        [_data appendData:data];
    }
}
 
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
    if(_data)
    {
        NSString* content = [[NSString alloc] initWithData:_data
                                                  encoding:NSUTF8StringEncoding];
 
        [_data release];
        _data = nil;
 
        // prepend the HTML with our custom JavaScript
        content = [ScriptNotify stringByAppendingString:content];
 
        [_webView loadHTMLString:content baseURL:_url];
    }
}

Final thoughts

While the mechanism shown here may seem a little convoluted, it is solving a fairly specific problem if how to hook into a web page’s JavaScript early enough to influence what happens.

I’m curious to know if there is a cleaner way to do this. Let me know.

Finally, here is the code I wrote for converting the ACS security token JSON into a dictionary without using an external JSON parser library such as SBJSON or YAJL. While not as general purpose a third party library, this was good enough for our needs.

- (NSDictionary*)parsePairs:(NSString*)urlStr
{
    NSRange r = [urlStr rangeOfString:@"="];
    if(r.length == 0)
    {
        return nil;
    }
 
    // the JSON-encoded token is after the = in the URL
    NSString* token = [[urlStr substringFromIndex:r.location + 1] URLDecode];
 
    // remove the leading and trailing { } characters
    NSCharacterSet* objectMarkers;
    objectMarkers = [NSCharacterSet characterSetWithCharactersInString:@"{}"];
    token = [token stringByTrimmingCharactersInSet:objectMarkers];
 
    NSError* regexError;
    NSMutableDictionary* pairs = [NSMutableDictionary dictionaryWithCapacity:10];
 
    // parse name-value pairs with string values
    NSRegularExpression* regex;
    regex = [NSRegularExpression regularExpressionWithPattern:@"\"([^\"]*)\":\"([^\"]*)\""
                                                      options:0
                                                        error:&regexError];
    NSArray* matches = [regex matchesInString:token
                                      options:0
                                        range:NSMakeRange(0, token.length)];
 
    for(NSTextCheckingResult* result in matches)
    {
        for(int n = 1; n < [result numberOfRanges]; n += 2)
        {
            NSRange r = [result rangeAtIndex:n];
            if(r.length > 0)
            {
                NSString* name = [token substringWithRange:r];
 
                r = [result rangeAtIndex:n + 1];
                if(r.length > 0)
                {
                    NSString* value = [token substringWithRange:r];
 
                    [pairs setObject:value forKey:name];
                }
            }
        }
    }
 
    // parse name-value pairs with numeric values
    regex = [NSRegularExpression regularExpressionWithPattern:@"\"([^\"]*)\":([0-9]*)"
                                                      options:0
                                                        error:&regexError];
    matches = [regex matchesInString:token
                              options:0
                                range:NSMakeRange(0, token.length)];
 
    for(NSTextCheckingResult* result in matches)
    {
        for(int n = 1; n < [result numberOfRanges]; n += 2)
        {
            NSRange r = [result rangeAtIndex:n];
            if(r.length > 0)
            {
                NSString* name = [token substringWithRange:r];
 
                r = [result rangeAtIndex:n + 1];
                if(r.length > 0)
                {
                    NSString* value = [token substringWithRange:r];
                    NSNumber* number = [NSNumber numberWithInt:[value intValue]];
 
                    [pairs setObject:number forKey:name];
                }
            }
        }
    }
 
    return pairs;
}

Perhaps your app will present cooking recipes, or First Aid information for folks that hurt themselves hiking far from cell tower coverage.

One challenge often faced in these types of apps is how to keep the content up to date. Of course you could simply ship an update to your app, but your customers may get annoying having to update your app every few weeks.

A better way is to have a means to update the content as it changes. The code I am presenting here is designed to do just that.

Introducing ContentBundle

The ContentBundle library aims to solve this problem by allowing you to embed content inside your application as a ZIP archive. When the application starts up the first time it will copy the contents of the ZIP file into your application’s Documents directory. All of the ZIP archive’s folders structure is pulled over intact, just as you would expect.

Once there you can use any of the built in file APIs to load content in, or even reference it inside of a WebView, which will be able to reference its HTML, CSS and images.

On subsequent startups the application will check its version against the already expanded content version, allowing updates of your application to deploy content updates.

But perhaps more than that, you can have the library reach out to your web site, determine if an update is available, and pull that update down.

To make this work we must first add a section into our application’s info.plist file:

This section is identifying that our content is in the test.zip file inside our app bundle. It’s version number is “1″. It will be expanded into our Documents folder in a sub-folder called “mytest”. Finally we have the URL where the library can obtain updates.

These settings, and the ZIP they references are what I refer to as a “content bundle”.

The library allow you to create multiple sections for different content bundles, which may be useful if some of your content will change more frequently than others.

To use the library in your code, first reference the library’s header file.

#import "SSContentBundle.h"

To reference content in a content bundle we might first access it.

The default bundle (which leverages the “SSContentBundle” key in our info.plist) is accessed via the mainBundle property.

SSContentBundle* provider = [SSContentBundle mainBundle];

You can obtain the full path of a file from the bundle thus:

NSString* path = [provider pathForFile:@"LiteUnzip.c"];
NSData* contents = [NSData dataWithContentsOfFile:path];

Web updates

At startup if you wish to check for content updates you can call the checkForUpdatesWithCompletionHandler: method.

[provider checkForUpdatesWithCompletionHandler:^(BOOL updateFound, NSError *error)
{
    if(error)
    {
        NSLog(@"Error removing old content: %@", [error localizedDescription]);
    }
}];

The block will be told if an update was found. If it was, the content ZIP file will have been downloaded, expanded and your old content replaced before the completion handler is called.

You may recall the content version URL was defined as:

http://www.stevesaxon.me/media/test/version.txt

This file contains the following:

3
test.zip

The first line is the server version number. Remember our info.plist said our client version was 1, so the server version is newer.

The second line is the relative URL to the server-based content update. In this case, “test.zip” is sitting in the same folder on the server as the version.txt file.

Under the covers

The TargetFolder key in the info.plist is used to identify the name of the target folder inside your application’s Documents directory.

It is also to identify the name of the version tracker file that is written by the library so that library knows the version of the content that is stored in the Documents directory. Initially the content of this file is written from the SourceVersion key in the info.plist, but it can be updated as part of a server content fetch.

The Documents directory may end up looking like this:

Note the mytest-version.txt, which is the version tracker file. The mytest folder contains the contents of the ZIP file.

When a new content ZIP is downloaded, this folder is deleted and the updated content expanded in its place.

Getting involved

The library and sample code is available from github.

https://github.com/ssaxon/ContentBundle

If you this useful, leave a comment. Or jump over to github and get involved!