Hard to tell which one to choose when everything you want to know about the choices is unavailable. Should I get the “Lego Y..” or, mmmmm, the other “Lego Y..”?

Compare to Amazon, who manage to fit the full name in without issue:

If you’re going to allow a certain number of characters for a value, assume all of those characters may be important at some point. And make sure somewhere on your interface you let them all get their moment in the sun.

Turns out this “feature” is decided by Apple based on your region. They believe Australian weeks start on Sunday so that’s the way it is. To change the day, change your region.

For Australians wanting their calendar to start on a Monday:

1. Launch settings
2. Select General > International
3. change region format to Namibia

This bizarre choice seems to have the best option for calendar setting, as well as changes it makes to keyboards (what currency symbol you see), date and time formats, even which google you default to when you search. Namibia appears to leave all the other settings “just like Australia”, and still default to google.com.au for searching in Safari.

Thanks to the clever chaps on the Whirlpool forums, particularly dokh22, for uncovering this. Now how long before Apple gives us a calendar setting to do it properly?

This post was inspired by a colleague who had not uncovered that fact, and so had spent time arduously linking separate views with timers. This post shows how to use a single view and 3 lines of animation code to do all the work.

What to do?

What we’ll do as a test is animate the blinking eyes on a tennis-playing ninja splash screen. To trigger the animation will add a “blink” button on the same screen.

Don’t ask how we ended up with that as the example (thanks to the friend). But you can download the entire project, or just the images if wanting to join in.

• download the project
• download the images

The steps:

1. prepare the images
2. create the project
3. create/update a XIB with the image and button
4. add the animation code and link to the same image and button

All the neat animation stuff is described in the 4th step, so feel free to scroll straight to it. The previous three steps cover all that’s needed to get your project ready to animate. I’ve included it because I hate reading articles that assume you’ve covered all the basics already. Or worse just dismiss it with one line (first step, invent time travel).

Note this process was captured in xCode4/IOS5. None of the code in here has changed much in recent releases but you may have to adjust some of the steps if running an earlier setup (one thing that has changed in this version is the options when creating a project).

(1) prepare the images

Your imagery is limited only by your artistic talents, or abilities to search Google Images or Flickr (remember to honour their copyright, boys and girls).

Only suggestion is to limit the animation element to the smallest possible; keeps sizes small. For example, for the blinking ninja, instead of 3 different ninjas with different eye positions (open, half closed, closed), I created one ninja with no eyes, and then three images of just the different eyes. What we’ll do in the project is then add the main ninja as one image view, and put the eyes over the top in a separate image.

Whatever approach you take, ensure all the images that will be animated are the same size. This will ensure when animated they appear over each other.

create the project

Crack open Xcode and choose File > New Project. I’m in the latest and greatest (4.2) so your options may vary, but for this version:

• choose Single View Application
• choose not to use storyboard (so we get a XIB to mess with)

Once created we have a simple project containing the key source files:

• appDelegate.h
• appDelegate.m
• ViewController.h
• ViewController.m
• ViewController.xib

The good news is we’re only going to be editing the three ViewController files. Which means you can pretty much follow all of these steps to add an animation to an existing view within your current application; just join in from the next step.

Now add your animation images to the project. Either right-click in the folder view and select Add Files To.., or choose File > Add Files To.. from the menu.

(2) create/update XIB with the image and button

Our XIB has already been created in the project. What to do now is setup the images and buttons we meed, including the outlets needed so we can communicate with them from our code.

Firstly the images. Remember we need to add two: 1 as the background (which we don’t need to interact with) and one for the animated eyes (which we will need to talk to).

To hook things up let’s create the outlets first, and then link in the XIB. Open ViewController.h and add our definition (new text in bold):

#import 

@interface ViewController : UIViewController {
    IBOutlet UIImageView *eyesImage;
    IBOutlet UIButton *blinkButton;
}

@property (nonatomic, retain) IBOutlet UIImageView *eyesImage;
@property (nonatomic, retain) IBOutlet UIButton *blinkButton;

@end;

Then switch over to ViewController.m (tip: 3 fingers down gesture if using a trackpad) and synthesize them:

@import "ViewController.h"

@implementation ViewController

@synthesize eyesImage;
@synthesize blinkButton;

Remember if we create them, we should also destroy them:

- (void)viewDidUnload
{
    [superviewDidUnload];
    // Release any retained subviews of the main view.
    // e.g. self.myOutlet = nil;
    self.eyesImage = nil;
    self.blinkButton = nil;
}

That gives us our outlets so we can link to, and manipulate these items on our XIB.  Note we don’t currently need to manipulate the button but the outlet is there just in case (for example if needing to disable the button at some point).

The only other item to add in the code before we edit the XIB is the method to be called when we click the button.

Back into viewController.h and add the definition:

#import 

@interface ViewController : UIViewController {
    IBOutlet UIImageView *eyesImage;
    IBOutlet UIButton *blinkButton;
}

@property (nonatomic, retain) IBOutlet UIImageView *eyesImage;
@property (nonatomic, retain) IBOutlet UIButton *blinkButton;

- (IBAction) blink;

@end;

And then back to ViewController.m, and insert the method somewhere in the list:

- (IBAction) blink {
  //blink
}

Save the files and we’re ready to connect them to elements in the XIB.

Firstly open the XIB and drag an imageView onto the work area.
Set the size and content to be our background/static image for the animation.    Don’t worry with any outlets as we never need to talk to this image.

Now add a 2nd image view to the work area.  Set its position and size to match where the animation is to be presented.  If it helps you with positioning, set the default image to the first of your animation frames.

Once the animated image view is in place, hook up the outlet.  We need to link this to our eyesImage outlet so we can manipulate it.  Just select the Outlets panel for the view, click in the circle for Referencing Outlet and then drag to File’s Owner on the left side of the work area.  if all has worked you’ll then get a dropdown list in which you can select eyesImage.  Once selected your outlet will be added.

That’s all you need to do for the animation.  Now for the button.

Drag a Round Rect Button onto the work area and position somewhere appropriate.  Then add a suitable label (“blink” comes to mind).  View the Outlets panel for the button and drag from the Referencing Outlet to File’s Owner (as we did for the image) and select the blinkButton outlet.  And then, to link to our blink method, drag from the TouchUpInside outlet to the same File’s Owner.  If all has worked you’ll then be able to select blink and connect it up.

So that’s all the XIB sorted.  We’ve got a background/static image.  We’ve got a smaller image with an eyesImage outlet for the animation.  And we’ve got a button that when clicked will trigger our blink() method.  Only one step to go.

Save your XIB and then run your project.  You won’t see anything moving but at least your background image should be in view.

add the animation code and link to the image and button

Now for the fun part.

To animate an image we load up the image view with an array of images, set some parameters for how fast and how long the animation runs, and then start it off.  For efficiency we’ll put all the animation setup into viewDidLoad (so done once when the view first appears), and then just trigger the animation each time we click the button.

So back into viewController.m, let’s first setup the animation:

- (void)viewDidLoad
{
    [superviewDidLoad];
    
        
       //setup animation
    NSArray *eyeFrames = [NSArrayarray];
    eyeFrames = [[NSArrayalloc] initWithObjects:
                 [UIImageimageNamed:@"eyes1-open.png"],
                 [UIImageimageNamed:@"eyes2-half.png"],
                 [UIImageimageNamed:@"eyes3-closed.png"],
                 nil];
    eyesImage.animationImages = eyeFrames;
    eyesImage.animationDuration = 0.25;
    eyesImage.animationRepeatCount = 1;
    [eyeFrames release];   
    

}

We’ve added an array of three images to our eyesImage outlet. The animation will take a quarter of a second and will only run once.  Once implemented you’ll return to these settings (often!) to get the appearance just right.

Once setup, triggering it is just one line of code:

- (void) blink {
    [eyesImage startAnimating];
}

Save and run your project. Then everytime you click the button, magic happens.

Conclusion

While it took a while to get there, animating our image took only 7 lines of code.  Armed with that code you are limited by only your graphical capabilities.  Just build your images, repeat the 7 lines, and then spend an age tweaking the duration to get it looking right.  

After a while you may find this approach a bit too limited as it scrolls through the image frames at a regular pace.  If wanting a bit more control over the animation  pace, then you’ll need to step up and start using proper animation blocks.  Next time.

However what wins is the wireless synchronisation feature. Now I can update my library (songs, books, tv) on my computer and click Sync. And the iPad gets updated while not connected. While not even switched on. While in my briefcase in another room.

Sweet.

[Although I'll admit it's probably sweet because Apple kept us tethered for far too long!]

When I’m editing frame properties, don’t present a tooltip that has the unerring habit of appearing directly over the top of where I’m trying to type!! B!@#y annoying.

This article expands that earlier introduction with some tips and tricks we collating when implementing this for one client:

• working outside Sharepoint
• presenting a URL
• sorting items
• grouping items
• showing a message if a filter set is empty

Note: You can download sample XML and XSL here. These files show all the techniques described in this article.

the original XML	filtered view	grouped view

Working outside SharePoint

It can be painful to develop your XML/XSL solution in Sharepoint because of the need to upload new versions (or edit webparts), then refresh to see the results, or lack thereof. Easier to work outside and just upload when done.

To link your XML and XSL outside SharePoint edit your XML file to include a link to your XSL file:

<!--?xml version="1.0" encoding="utf-8"?-->
<!--?xml-stylesheet type="text/xsl" href="calendar.xsl"?-->
....

Now when you open your XML file in a browser it will use your XSL to present.

Save your XLS as a file with a name to match the XML link and you’re nearly there. The only other change you may need to make is to extend your XSL so it generates a full webpage, not just a fragment.

For example our standard calendar presentation XSL generates a paragraph:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="calendar">
<p>
<xsl:for-each select="event[program='Leadership Foundations']">
...
</xsl:for-each>
</p>
</xsl:template>
</xsl:stylesheet>

To work outside SharePoint it needs to generate a proper page; make it do so by simply adding HTML and BODY tags:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="calendar">
<html>
<body>
<p>
<xsl:for-each select="event[program='Leadership Foundations']">
...
</xsl:for-each>
</p>
<body>
<html>
</xsl:template>
</xsl:stylesheet>

Just remember to remove these bonus lines when re-inserting into your SharePoint site.

Presenting a URL

If one element you’re recorded in your XML is a URL then chances are you’ll want to use XSL to convert that into a link. And the obvious approach you’d think would be the simplest:

<a href='<xsl:value-of select="link">'>link text</a>

Other than the issue over nested quotes, all looks pretty straightforward. Except it doesn’t work.

The solution is to use a different format for the URL selection:

<a href="{link}">link text</a>

Now it works fine.

Sorting items

One feature we wanted to implement was the automatic sorting of results. This meant anyone maintaining the master XML list did not need to worry about where to add individual items to preserve their order. They could just add anywhere in the file and be confident they’d appear in the correct sequence when displayed.

To sort results, add the <xsl:sort> command as the first element within your loop. For example to sort by a date element:

<xsl:for-each select="event">
    <xsl:sort select="date" />
    ...
</xsl:for-each>

Check W3Schools if wanting to do something more complicated than an ascending text order.

As you can see from this example, what we were wanting to search on were dates. And early on we’d decided that users would enter dates in “human” format (ie ’23 May 2011″, not 20110523). One issue we had on sorting dates was the chestnut of how to sort “2 May 2011″ to appear before “15 May 2011″. Our solution was to require all dates in the XML to be two characters (“02 May 2011″ not “2 May 2011″) and then use XSL to remove the ugly leading zero when displayed. The code to remove that zero is straightforward:

<xsl:choose>
    <xsl:when test="substring(date,1,1)=0">
         <xsl:value-of select="substring(date,2)" />
    <xsl:otherwise>
</xsl:choose>

You have to use the <xsl:choose> construct because while XSL does have an IF statement (not surprisingly <xsl:if>), it does not have an equivalent ELSE.

Note: The alternative would be to define the date in a nice sortable format (I vote for YYYYMMDD). And then use similar XSL transformations to present in a more readable format. Either way you’re putting some overhead on the user. We stuck with this simple approach because it was (a) less user effort and (b) allowed a wider range of dates to be acceptable. For example we had some programs that only specified a month. Sorting this way meant we could accept “May 2011″ as a valid date.

Grouping items

Now this I thought would be easy. Since we’re working on a calendar, let’s group entries according to the month. ie:

April 2011
- This course (12 April, London)
- That course (19 April, Helsinki)
May 2011
- That course (2 May, Romford)
- The other course (30 May, Malaka)

After several false starts, all roads do eventually lead to a fabled Meunchian method. Trouble is, even after building it, I’ve no idea how it works. Of all the articles uncovered to try and explain it, this one came closest. Cut&paste their approach (or our example using it) and you should be able to get it to work.

Showing a message if the filter set is empty

In the first article we covered how simple it is to present a subset of your entries. However once implemented we discovered we needed to address the situation where a subset was empty. Rather than just showing a blank list we wanted to show a messsage directing the visitor to other sources.

Simplest way to implement this is to repeat the same filter query used to generate the subset. Just place within a COUNT() and use as a test:

<xsl:choose>
     <xsl:when test="count(event[program='First Program']) > 0">

          <xsl:for-each select="event[program='First Program']">
          ...
          </xsl:for-each>

     </xsl:when>
     <xsl:otherwise>
          <xsl:text>No events recorded for this program.</xsl:text>
     </xsl:otherwise>
</xsl:choose>

Only potential issue may be around your formatting. Be mindful of where your layout tags appear depending on which data is presented.

Conclusion

With just these techniques you can present and manipulate your content in quite ingenious ways. Just good luck trying to understand the Muench.

You shouldn’t have to invent your own language (“Favorited?”) to make your UI work.

What I had was one file per chapter, divided into sections. So my content.xhtml looked like this:

<h1>Chapter Title</h1>
<h2><a name="part1"></a>First Part</h2>
...
<h2><a name="part2"></a>Second Part</h2>
...
<h2><a name="part3"></a>Third Part</h2>
...

This was then accessed from toc.ncx as follows. Important link bits in bold:

...
<navPoint playOrder=11><navLabel><text>Chapter Title</text></navLabel>
  <content src="chapter.xhtml" /></navPoint>
<navPoint playOrder=12><navLabel><text>Part 1</text></navLabel>
  <content src="chapter.xhtml#part1" /></navPoint>
<navPoint playOrder=13><navLabel><text>Part 2</text></navLabel>
  <content src="chapter.xhtml#part2" /></navPoint>
<navPoint playOrder=14><text>Part </text></navLabel>
  <content src="chapter.xhtml#part3" /></navPoint>
...

None of these TOC links work when published as an ePUB (testing in Adobe Digital Editions).

Bit of digging (this helped) and testing, and issue is with the “name” piece. These are not recognised. Instead you need to use IDs.

The good news is you don’t have to change the toc.ncx references, or any other references to the sections. Only the targets need to change. Edit your content from:

<h2><a name="part1">First Part</h2>

To any of the following:

<h2><a id="part1"></a>First Part</h2>
<h2><a id="part1" name="part1"></a>First Part</h2>
<h2 id="part1">First Part</h2>

Obviously the third option (add the ID to the heading itself) is the cleanest. However the first option is the one easiest to implement via global search and replace. Which means it was the one I chose.

• maintain a master calendar and view it (or part of it) in a subsite, or
• maintain a calendar in the subsite and “roll it up” with other subsite calendars to a master view in the main site.

Apparently this is rectified in Sharepoint 2010 but if you’re unable to upgrade, and aren’t allowed to build your own webparts, you’ve to look elsewhere for a solution:

• use a 3rd party webpart (can recommend the Bamboo Solutions offering having used it elsewhere), or
• hacking together via the page viewer webpart (I never got this to work but your mileage may vary)

However this article describes a 3rd option we implemented which met the requirement by not using calendars at all.  Instead we used XML.

An XML solution in three parts

The XML solution allows a single, master, calendar to be published in multiple subsites, optionally filtering entries to particular subsets.  To implement you need three elements:

1. source calendar (in XML, not a SharePoint calendar)
2. presentation/design code (XSL), and
3. webpart that links the above two together on your site.

Without advanced CSS skills this won’t get you much more than an event list on any site.  But if that’s all you want, and more important is the ability to reproduce that one list on multiple sites, then this approach might work for you.

Source calendar (XML)

In XML a calendar is simply a series of events, with varying parameters that include a date and a name, collected in a parent element.  For our basic implementation we ended up with just that:

<calendar>
 <event>
  <date>12 August 2011</date>
  <title>Integration testing starts</title>
 </event>
 <event>
  <date>23 November 2011</date>
  <title>Integration testing ends</title>
 </event>
 ...
</calendar>

To make it valid just add a definition on the first line:

<?xml version="1.0" standalone="no"?>

From this basis you can obviously add whatever other values you want to note for each event. For example if you want to present or filter by project, or responsibility, just add appropriate values to the XML.

presentation/design code (XSL)

The XSL code is what converts your XML into HTML that can be presented on your Sharepoint page. With the simple calendar schema adopted here this is only a few lines.

First set the scene:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 ...

 </xsl:stylesheet>

Then add the XSL proper inside the above framework. The following code will first match our calendar parent element using template-match, before traversing each of our events by using a for-each loop.

 <xsl:template match="CALENDAR">
  <table border="0">
    <xsl:for-each select="EVENT">
    <tr>
      <td><xsl:value-of select="title" /></td>
      <td><xsl:value-of select="date" /></td>
    </tr>
    </xsl:for-each>
  </table>
</xsl:template>

This code puts each event (the “EVENT” elements) into a separate row in a table, with two event values “title” and “date” presented in separate columns.

This code gives you the basic framework for manipulating your XML. However XSL, and HTML/CSS are must more powerful than this example demonstrates. Feel free to research further on how to leverage this approach to really fine-tune the delivery of your calendar data.

For now, however, I will describe one of the most common XSL functions you’ll want in this solution: the ability to present a subset of your calendar entries based on a parameter recorded with each event.

Filtering records

In XSL you filter records by adding a comparison operator to your for-each statement. For example, if we add a “project” attribute to our events, the code to filter to a specific project is a simple change to the for-each command:

 <xsl:for-each select="EVENT[project='Project A']">

This will now only list events that are for “Project A”.  And how do you get entries to be categorised as “Project A” – just add to the XML:

<calendar>
 <event>
  <project>Project A</date>
  <date>12 August 2011</date>
  <title>Integration testing starts</title>
 </event>
 <event>
  <project>Project B</date>
  <date>23 November 2011</date>
  <title>Integration testing ends</title>
 </event>
 ...
</calendar>

Linking webpart

To pull the XML and XSL together on your Sharepoint page, add an XML Webpart.

In this webpart you simply specify the XML and XSL you need to use. You can enter your details directly into the webpart (which negates the whole sharing theme for the XML, and can cause consistency issues with the XSL). Or you can link to external files. With the advantage that those files can exist anywhere in your site architecture.

Conclusion

Using XML to share a single calendar is not for everybody. It's harder to maintain the entries, and the presentation is never going to be sexy. But as a quick way to stop yourself repeating yourself, it's worth considering.

If you do have an .OPF file but get this error, then the issue is not with this file at all, but with container.xml (which lives in the META-INF folder). This file does little more than point to your .OPF file. The error therefore arises if it points in the wrong direction.

In my instance the issue was caused by using an ePUB template/shell with a different default value for the filename and path to the .OPF. Note if I’d been paying attention the error message gives you all the information needed to resolve the issue since it reports a different filename for the .OPF to the one created. If they don’t match then container.xml is the culprit.

Here’s the all important line in container.xml. Make sure the name and match match your own construction.

<rootfile full-path="OEBPS/content.opf" media-type="application/oebps-package+xml"/>