Continue reading »]]> If you’re talking to a server or service over HTTPS. This isn’t a problem for servers where the SSL certificate have been signed by a trusted authority, but on occasion, these certificates are self-signed. By default all browsers complain if a certificate has not been signed by a trusted authority and the iPhone is no different. This is a little tricky when an application is communicating with a server as you don’t want to be asking the user whether or not they want to continue with the request as you just want to get on with it.

The method I am going to describe allows you to accept the self-signed certificate without adding a ‘pem’ file to the keychain and uses the CoreServices Framework.

First up, we have to create a CFHTTPMessageRef reference using the CFHTTPMessageCreateRequest from CoreServices.

    CFHTTPMessageRef request = CFHTTPMessageCreateRequest(
        kCFAllocatorDefault,
        CFSTR("POST"),
        (CFURLRef) [NSURL URLWithString:@"https://--your site url--/"],
        kCFHTTPVersion1_1);

Next up, we need to grab the stream for this request of type CFReadStreamRef.

    CFReadStreamRef stream = CFReadStreamCreateForHTTPRequest(kCFAllocatorDefault, request);

Now, with for this stream, we need to tell the iPhone to not bother if presented with a self-signed certificate.

    CFMutableDictionaryRef securityDictRef = CFDictionaryCreateMutable(kCFAllocatorDefault,
        0,
        &kCFTypeDictionaryKeyCallBacks,
        &kCFTypeDictionaryValueCallBacks);

    if (securityDictRef != nil) {
        CFDictionarySetValue(securityDictRef, kCFStreamSSLValidatesCertificateChain, kCFBooleanFalse);
        CFReadStreamSetProperty(stream, kCFStreamPropertySLLSettings, securityDictRef);
        CFRelease(securityDictRef);
    }

And there we go. Essentially we’re telling the CFReadStreamRef we do not want the certificate chain validated. We also have the option of using kCFStreamSSLAllowsExpiredCertificates for allowing expired certificates through, kCFStreamSSLAllowsExpiredRoots to do the same for expired roots and KCFStreamSSLCertificates to add in a certificate of your own. For more details, check out the “CFStream Socket Additions” documentation.

Continue reading »]]> This article was originally posted on our old blog and has been migrated here to keep everything in one place

The UITableViewCell is great for laying out information to be displayed in a UITableView (obviously), but there doesn’t seem to be a simple way of getting the NIB you have created within the Interface Builder and your UITableViewCell. Thankfully, it’s quite simple.

Create your UITableViewCell

@interface MyTableViewCell : UITableViewCell {
    IBOutlet UILabel *exampleLabel;
}

And add a layoutSubviews method within the implementation section; ie -

- (void)layoutSubviews {
    exampleLabel.text = @"This is my example!";

    /*
        You may also have a little more control over your font here also
    */
    exampleLabel.font = [UIFont boldSystemFontOfSize:12.0];
}

Now, create a new empty XIB file and call it whatever you want – I will use MyTableViewCell to match the Obj-C class. Open this XIB up using Interface Builder and look at the two items in the doc window: File’s Owner and First Responder. In the inspector, change the File’s Owner class to be UIViewController if this isn’t already set. From the library, drag a Table View Cell into the doc window after the First Responder. Change the class of this new Table View Cell to be MyTableViewCell. Now associate the main view with the Table View Cell by clicking on File Owner and then on the Connections Inspector on the entry for ‘view’, drag a line from the empty circle at the end of this line onto the ‘My Table View Cell’ entry in the doc window.

OK, now let’s set up the label. Double click on the ‘My Table View Cell’ entry in the doc window. Drag a label from the library into the view of ‘My Table View Cell’ that should have been opened. Within the outlets group in the connections inspector for the table view cell, drag a line from the circle at the end of the ‘exampleLabel’ line onto the label we just added to the table cell. Save the view.

That’s all great, but we haven’t yet told our code how to load up the XIB for this table cell view yet. We need to have a view controller conforming to the UITableViewDelegate and UITableViewDataSource protocols (which we won’t go into here). Within the ‘- (UITableViewCell *)tableView:(UITableView *)TableView cellForRowAtIndexPath:(NSIndexPath *)indexPath’ method, we need to create our UITableViewCell implementation.

- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath {
	static NSString *MyIdentifier = @"MyTableViewCell";

	MyTableViewCell *cell =
            (MyTableViewCell *)[inTableView dequeueReusableCellWithIdentifier:MyIdentifier];

	if (cell == nil) {
		UIViewController *c = [[UIViewController alloc]
                        initWithNibName:@"MyTableViewCell" bundle:nil];

		cell = (MyTableViewCell *)c.view;
		[c release];

                // code here to set whatever values in MyTableViewCell
	}

	return cell;
}

Obviously this is a pretty basic example, but the code follows the same principle for all other elements you may wish to add to your UITableViewCell.

Continue reading »]]> This article was originally posted on our old blog and has been migrated here to keep everything in one place. 

Another update that’s slightly off the ‘Seam’ topic, but it’s useful information anyway. This post is going to take you through installing Subversion (SVN) onto Linux (Ubuntu 8.10 server) and use a database running under PostgreSQL 8.3 for authentication.

First up, install Ubuntu. I’ll leave that one up to you to figure out, but I did not install the LAMP server option, just the PostgreSQL option as I don’t need MySQL on this server.

From this point, we need to update our repositories for apt-get.

sudo apt-get update

You can just run a sudo su to just log in as root.

Once that has completed, it’s time to install the SVN server, apache, libapache2-svn and the libapache2-mod-auth-pgsql modules

sudo apt-get install subversion
sudo apt-get install apache2
sudo apt-get install libapache2-svn
sudo apt-get install libapache2-mod-auth-pgsql

and give apache a nudge to restart with the modules

/etc/init.d/apache2 restart

OK, so let’s do some work with PostgreSQL. First we need a database to store the SVN access details in. This database will have two tables, svnuser and svngroups. The first table will store the details of the user; login name, password, first name, surname and an email address along with an ID.

Let’s create the database and the user for that database. Using psql as the postgres user:

create database svnusers;
create user svnuseradmin with password '<your password>';
grant all privileges on database svnusers to svnuseradmin;

Now quit psql and check that the above user works.

psql -U svnuseradmin -W -h 127.0.0.1 svnusers

You’re probably wondering why I’m specifying the loopback IP address as the host of the target database. Well, if you have a look at your pg_hba.conf file (under /etc/postgresql/8.3/main) and scroll to the bottom of the file, you will see that there are different rules for authenticating users connecting to the database depending on where they come from. By specifiying the IP address, you force PostgreSQL to perform MD5 authentication with the password you enter when trying to login rather than expecting ident or sameuser to work. If you don’t want to do this repeatedly, then change ‘ident sameuser’ to ‘md5′ and restart PostgreSQL using /etc/init.d/postgresql restart.

Now you’re on the database, let’s set up our two tables.

create table svnuser(
    login varchar(20) primary key,
    password varchar(60) not null,
    firstname varchar(100) not null,
    surname varchar(100) not null,
    email varchar(255) not null);

create index svnuser_login_idx on svnuser (login);

create table svngroups (
    login varchar(20) not null constraint svngroups_login_fk references svnuser (login),
    svngroup varchar(50) not null);

create index svngroups_login_idx on svngroups(login);

alter table svngroups add constraint svngrousp_login_svngroup_unique unique (login, svngroup);

Now, we are going to have a group for the admins who will have access to every project and one group per project. Let’s create a admin first.

insert into svnuser values (
    '<your username>',
    md5('<your password>'),
    '<your first name>',
    '<your surname>',
    '<your email address>');

insert into svngroups values ('<your username>', 'admin');

OK, let’s set up repository. I have placed the repositories under /var/svn so move to that directory after you have created it. Once there, let’s set up the repository as root.

svnadmin create test

Now, I want to be able to log into this repository using the user we have just created over HTTP (using WebDAV) so let’s do that.

Still as root, cd to /etc/apache2/mods-available and move dav_svn.conf and dav_svn.load to /etc/apache2/mods-enabled, then copy 000_auth_pgsql.load to /etc/apache2/mods-enabled/auth_pgsql.load. You can use the contents of dav_svn.conf to work out what’s going on, but I usually clear this file and start from fresh.

Add the following to the file:

<Location /test/svn>
  DAV svn
  SVNPath /var/svn/test

  # Turn BASIC auth off and point it at a blank file,
  # or you get a whole bunch of garbage in the logs
  AuthBasicAuthoritative Off
  AuthType Basic
  AuthName "Test SVN Repository"
  AuthUserFile "/dev/null"

  Auth_PG_hash_type md5
  Auth_PG_host localhost
  Auth_PG_port 5432
  Auth_PG_user svnuseradmin
  Auth_PG_pwd <your password>
  Auth_PG_database svnusers
  Auth_PG_pwd_table svnuser
  Auth_PG_uid_field login
  Auth_PG_pwd_field password
  Auth_PG_grp_table svngroups
  Auth_PG_cache_passwords on

  Auth_PG_grp_user_field login
  Auth_PG_grp_group_field svngroup

  Require group test admin
</Location>

And restart apache.

Now, from a remote machine and using a browser go to:

http://<your server hostname or IP address>/test/svn

You should be prompted to enter a user name and password for authentication so enter the username and password you inserted into the svnuser record and then you will see the 0 revision of your test repository.

Continue reading »]]> This article was originally posted on our old blog and has been migrated here to keep everything in one place. 

Well, in response to Max’s comments on the RHDS entry, I’m currently working using JBoss Tools on the Mac!

Here are the steps taken to get this working:

1) Download the latest version of “Eclipse IDE for Java EE Developers” from the eclipse website
2) Download the latest nightly build of JBoss Web tools
3) Download the version of Seam you’ll want to use and a version of JBoss AS also from here and here- I’m using Seam 2.0.0CR2 and AS 4.2.0-GA as they were on my machine
4) Unzip AS and Seam into locations that suit you and make a note of where you’ve saved them
5) Unzip Eclipse
6) Unzip JBoss Tools and drag the contents of the features and plugins folders into the plugins and folders directories in your fresh Eclipse folder created in the previous step.
7) Point Eclipse in the direction of your downloaded JBoss Seam and JBoss AS locations when starting a new project.

And get to work.

Or at least that’s the theory. Unfortunately, I’m being plagued with crashes during operation of this. If I don’t start up JBoss AS and stay away from the JBoss JSF editors, then it’s OK, but then what’s the point in using the JBoss Tools? I’ve spent more time restarting when Eclipse has either fallen over in a heap or hung solid than I’ve actually done any coding so far, so it’s all been a bit disheartening.

Never the less, I’ll keep plugging away. I do seem to have some success if I only have one of the JBoss editors open and don’t start up the JBoss server, after this, I have to resort to editing JSFs by hand, or stopping the whole thing and starting up again. I have upped the heap size to 1.7Gb but it doesn’t seem to make a whole lot of difference too.

Continue reading »]]> One of our current clients is a large media organisation based in the UK. As part of their remit, they have to ensure that their content reaches as many people as possible on as many media outlets as possible. As such, this means that their content has to be made available to people with disabilities, including partially sighted folks.

We have been working to ensure that one of their iOS apps provides the necessary accessibility functionality using UIAccessibility.

Where to Begin?

The first port of call with UIAccessibility is to open up Interface Builder. For the majority of the items within your NIB you can set the Accessibility options by selecting the element, tapping on the Identity inspector (alt+cmd+3) and then scrolling down to the “Accessibility” pane.

Accessibility options in Interface Builder

From this pane, you can select a number of options for your element. The first of which is whether or not this element will be exposed to a user using accessibility. It is possible to ‘hide’ elements if they are confusing to users with accessibility especially blind users. This may sound harsh, but there are some elements that might be almost impossible to make work as their layout might be so visually oriented that simply adding accessibility labels will just make the experience confusing for such a user. You should always strive to provide an alternative experience in this instance, but time pressures may dictate this is a job for the ‘next release’.

Just don’t forget about it!

So, let’s go through rest of the elements.

The Label is what is announced using voiceover when the user lands on the UI element. If we have a label of “name input” then voiceover will say “name input”. The Hint should be used to describe to the user what they will get when actioning this element. So, for a shopping type app with an ‘add to basket’ option I would consider using:

• Label: add to basket
• Hint: adds this item to the basket

The traits section allows you to set how the element behaves or how it should be treated. The UIAccessibility Protocol Reference is the best place to find the descriptions of these traits, but they are mostly self explanatory.

Think About What Makes Most Sense

The important thing to realise is that apps are very rarely static. This means that you will have to programmatically assign values to the UI elements at runtime. As such, it is also important to realise that what makes sense on screen does not always make sense using voiceover.

Say for example you have a list of UILabels that are generated dynamically based on the content of an NSArray where the array contains alternating ‘heading’ and ‘value’ objects; eg.

[NSArray arrayWithObjects:@"Width", @"23cm", @"Height", @"15cm", nil];

Which would then display the following:

• Width
• 23cm
• Height
• 15cm

Visually, you can (pretty much, although this is a crude example) work out that ’23cm’ has some correlation with ‘Width’. And if you were cycling through the elements using voiceover you could probably work out that because ’23cm’ would follow ‘width’, that the width was 23cm (although 23cm would be announced phonetically rather than as ’23 centimetres’, but we’ll revisit this later). However, if you have a fairly complex UI layout, it is possible that iOS will cycle over the elements in a seemingly random order meaning that you may get the ‘width’ announcement, then the accessibility label of another element, then ’23cm’. Obviously, this is confusing for the user.

One solution to this is to disable the accessibility of the heading element and modify the accessibility label of the value element. In our example, this means we would perform the following:

headingLabel.isAccessibilityElement = NO;
valueLabel.accessibilityLabel = [NSString stringWithFormat:@"%@, %@", heading, value];

Meaning that for our example here, voiceover would announce “Width, 23cm” which is a much better experience.

Phonetics

As mentioned previously, Voiceover will read what it’s given. It doesn’t know what you mean by ‘cm’ and will simply read out ‘cm’ to the user. It does not know that you mean ‘centimetres’. This means that you should really give careful consideration to what you are adding in to your accessibility labels and how they will be perceived when read out. In our above example, we should  set our value to ’23 centimetres’ rather than ’23cm’. This will give a better experience to our users and make the meaning of the data clear.

This is equally important for times. Given 03:00 voiceover will read ‘zero three zero zero’ which is meaningless. Roman numerals also. For 2012, the Roman numeral string is ‘MMXII’ which, when read out is ‘em em eks eye eye’.

For times, consider using NSNumberFormatter using the NSNumberFormatSpellOutStyle format to produce a string that spells out the time. Again, consider splitting the hours and minutes into separate elements so that 23:00 has some meaning. I like to have this produce a string of

11 o'clock, PM

But your needs may vary.

Ch-ch-ch-ch-changes

If you have a UI that is non-standard and uses UIViews as a sort of overlay rather than pushing another UIViewController using a UINavigationController, then you need to tell the user that the layout has changed. And you should also let iOS know!

iOS does a reasonable job of working out which elements should be accessible if the view has changed, but it needs to be told using the following code:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);

Usually this will sort out which UI elements can be cycled through when using voiceover but if you are changing the layout in such a way where this is necessary, then you should also announce to the user using voiceover so they know that something has changed using.

UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification,
        @"<description about what has changed>");

Finally in this section, if you are purposefully hiding an element (by completely removing it from the view for example) for any reason you should really listen for the UIAccessibilityVoiceOverStatusChanged notification and modify your UI to reflect the current status of voiceover. You can check the status of voiceover with the

UIAccessibilityIsVoiceOverRunning()

function.

Start From Scratch

It’s always easier to add in UIAccessibility while the UI is being created. Retr0-fitting this in later is often painful. There may be times when you simply cannot convey any useful meaning to the user with your current design. In this case, you should consider having a view that you use when voiceover is running. The stock UITableView with headings is great for accessibility as it gives you a great number of accessible elements for free (the headings are particularly useful) and is relatively simple to implement.

Conclusion

UIAccessibility is baffling at first. There’s no two ways about that. If you have to add accessibility into an existing app, then you have pain ahead of you if the design is non-standard or uses any ‘tricks’; especially custom alert views and elements that are revealed by horizontally swiping on a UITableCell.

Apple’s stock components do a reasonably good job with voiceover, but there’s always room for improvement in terms of thinking about your data and how it sounds when read out by a computer or iOS device.

Continue reading »]]> Quite a bit of the work we have undertaken recently involves the MDM Protocol used to managed iOS devices. It’s a fairly simple protocol to use, but there is not a great deal of information on the internet so we’ve put together a few hints that might help you with your MDM implementation.

This document expects you to have a copy of the ’Mobile Device Management Protocol Reference’ document from Apple (from this point, called the MDM Reference). As this document is covered by NDA, this page will not detail elements contained within the MDM document from Apple.

Description of the fields in the iPhone Config Util:

If you use the development APNS server, you will have to configure your server send the APNS push messages to the ‘sandbox’ APNS URL.

The process flow is as follows:

The user obtains the configuration profile from somewhere (website/email) and installs it, the device then talks to the server (to the check-in URL if configured) and upload XML; the ‘Authenticate’ and ‘TokenUpdate’ documents detailed in the ‘Mobile Device Management Protocol Reference’ document.

The PushMagic and UnlockToken from the TokenUpdate document should be retained and associated with the UUID for later use. The contents of PushMagic is required to send an APNS message to the device to instigate the MDM process. Once you have the PushMagic, you create a JSON string as per the MDM Reference, this should be signed as per a normal APNS request. There are a number of APNS libraries available to assist with this and the MDM Reference details the steps you will need to take to export your MDM certificate.

Once the device has received the APNS message, it will send an XML document to the URL defined in ‘Server URL’ in your configuration profile. This document is detailed on page 12 of the MDM Reference. From this point, you can send back a single MDM command if there is one for the device. If the command was correctly formatted and accepted by the device, then it will send back a command response. The response is dependent on the command and these are detailed in the MDM Reference.

If there are no more MDM commands for the device, then the server should respond with an empty response.

Some more points

You should be using a HTTPS server for your MDM communication. If you are, life will be considerably easier for you and your users if you use a signed certificate from a Verisign or other signatory. iOS requires a few more steps to use a self-signed SSL certificate or a certificate signed by a private CA.

Keep the iOS console open while you are testing your server, it will help immensely. Use the iPhone Config Util or Xcode to view the console.

MDM configuration cannot be installed within a profile that limits removal. If you have the ‘General/Security’ setting configured to anything other than ‘Always’ then iOS will reject your profile.

Now, unfortunately we cannot be more specific on the details on a blog, however our team are available for MDM consultancy where we can go into more details. Feel free to get in touch using the comments or our contact us form.

Continue reading »]]> It’s probably going to be a while off, but we are thinking of things we would like to see in iOS 6 that would be cool or make our lives a little easier as app developers.

Download Manager

We see this working as an iOS level background service. Your app gives the manager a URL, asks that it is downloaded and the manager takes care of this and sends a local notification to the app when the download is complete. The user will be able to set preferences for the download manager in ‘Settings’ to set whether they want to download via 3G (disabled by default), whether they want multiple downloads to take place at once, whether to send a notification in completion and so on.

Apple TV Apps

This would be a game changer. Being apple to run apps on the TV would make the Apple TV an absolute must-have device.

UI Themes

Having a style sheet type scenario for apps would cut down on a bunch of boilerplate code to set colours and text styles. It would also mean that white label apps would be quicker to turn around for subsequent releases.

So, just three for now but what do you think?