How Many Taps?

I think that most iPhone users would agree that iOS settings are not the most user friendly of screens to navigate and by definition, I don’t think that they can be, as they cover tweaks and tunings that the average user won’t even know are possible. That’s not to say that settings are never visited; I just think that if a way was found to make it easier for a user to toggle their wifi/bluetooth or turn off 3G, then it would be embraced by users and developers alike.

Currently if you want to toggle your bluetooth settings, assuming you are already on your homescreen…

1. Tap Settings
2. Scroll to General
3. Tap Bluetooth
4. Toggle button

How about turn off your 3G connection…

1. Tap Settings
2. Scroll to General
3. Tap Network
4. Toggle 3G

Most things are 4 screens away. If an app used bluetooth and bluetooth was switched off, then the user would be asked to quit the app and follow the above instructions. It would be a lot easier and cleaner from a usability point of view if an app could send the user directly to the bluetooth settings, if the user so chose.

Please give a warm welcome

In iOS 5, Apple made it possible to go directly to the settings area you wanted with one URL call. This can be done in your own application using:

1

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"prefs:root=TWITTER"]];

or the URL could be called from within mobile Safari.
I don’t know who first found these, but they have been well documented and a quick google for ‘iOS settings URL scheme’ finds various sources of information.

Try them out

My latest app started out as a settings shortcut helper (I’ve previously blogged about its inception) and I open-sourced the settings functionality of it.

Swiping down into notification center and having your settings there is the easist use of these shortcuts IMHO, so if you are able to sign your own applications then I’d recommend trying it out. If not, then the images should give you an idea of what I’m talking about. Github - Settings Swipe

Enhancement request

In the latest iOS 5.1 beta’s, these URL’s are no longer available.
Maybe they will make it in the next official release but their future is unknown. In the meantime we can try and show Apple that there is sufficient demand for this feature by requesting an enhancement request via their bugreporter.

If you find them useful, please duplicate rdar://5864941
The open radar comments are at Open Radar - URL scheme

Back in November 2011 I started working on a new app that used the Notification Center in iOS 4+ to launch other apps and perform daily tasks (compose iMessage, Tweet, mail etc).

iPrefs

It started life as an app called ‘iPrefs’ and the catalyst was the Settings URL scheme that became public knowledge at the iOS5 release. (e.g. prefs:root=AIRPLANE_MODE)

It made launching your settings easy, bluetooth was one swipe and a tap away, as was airplane mode. The app was fully localized in French, German, Italian and Spanish, would be free with one saved notification shortcut (in-app purchase for max of 10), worked great and was a really nice looking app, very similiar to the notification center.

Before I submitted to Apple for review, I checked the Store for any other apps using the prefs URL scheme and found one other, so thought that the prefs URL’s were ok to use.
-25th November - app uploaded.
-2nd December - app rejected. ‘Non public URL scheme’ was the reason for rejection. (I had other bugs to fix but on subsequent resolution center queries was made aware that under no circumstances could I use the prefs: urls, even to help a user add a Twitter account when none was available in iOS5)

The original code for iPrefs is available on Github.

OK, fair enough I thought. I understood that URL’s could change in the future, so I decided to just move on.

App Swipe

I still knew that Notification Center had great potential (I now know that I wasn’t alone, @drbarnard @artysx @skorebrits were all working on similiar apps around this time) and decided to use its functionality for iPrefs.

With Apple not allowing the use of the settings URL scheme, I decided to use notification center as a quick way to launch my favourite apps.

So I set to work, updating iPrefs to enable the user to choose from a small list of apps, including email, SMS, FaceTime, Facebook and various Twitter clients. You could choose a contact to start the call/sms with, compose a Tweet template, open Ebay or Facebook etc, basically making iPrefs a frequently used task list.
With the apps appearing in notification center, you now had a really quick way to switch between apps that didn’t involved double tapping any homescreens or sideways swipe navigations, which was a win in my book.
I just needed a new name ;-)

Pre-Xmas Opening

-9th December - I was cutting it fine for the Xmas closedown of iTunesConnect when I submitted App Swipe but I needn’t have worried.

-13th December - I received my first ever “Your app requires additional review time” email. Gutted! There was nothing I could do except be very polite and ask via the resolution center if there was anything I could do to help speed things up.

-21st December - Apple emailed me to discuss my app submission. My use of notification center to create ‘quick links’ was the main reason for my rejection (reference app review guidelines 2.4). I had also used an image that resembled the notification pull down screen as my app icon, which they also didn’t like.

iTunesConnect was still showing my app as in review so I rejected the binary, removed the ability to use notification center for shortcuts and changed the offending images.

Pre-Xmas Shutdown Frenzy

-21st December - I re-submitted close to midnight, requested an expedited review, emailed the nice chap who I had spoken to earlier in the day and crossed my fingers. My expedited review was declined which made sense as I didn’t have a major bug or anything that would cause a bad user experience (lesson learned for expedited requests).

-4th January - App Swipe stayed in review until I received a very nice ‘Your app App Swipe has been reviewed, but we are unable to post this version’ email. I’m unable to access the resolution center as this is now resolved but I had a good few pages of back and forth with the very helpful review team. (no sarcasm intended!).

It’s Groundhog day, again

-11th January - rejected.
-17th January - rejected.

App Review Guidelines 10.4 was now my nemesis.

‘Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected’.

IMHO App Swipe was very similiar in functionality to other ‘launcher’ apps on the store. I now didn’t have a clue what I could do to the app to make it acceptable and pass review. So I appealed. I don’t have the exact wording of the appeal as I didn’t save a copy, but I’m pretty sure I didn’t beg or grovel. However, I did base my case around the fact that any shortcut was placed explicitly on the screen by the user and not hard wired into the app (man, I wish I’d kept a copy).

Good Feeling

-20th January - My first bit of good news, a positive appeal outcome.
This kickstarted the ‘move to live’ process and App Swipe was available within 24 hours. App Swipe Twitter Status 20th Jan

Updates

-11th February - App Swipe 1.2 submitted for review. Includes a new look and notifications for task reminders.

-19th February App Swipe 1.2 was rejected. Knowing that just a slight variation in how I was handling notifications could be the reason I’m not yet on the store, I took another look at how App Swipe handled various scenarios in relation to the latest rejection reason

It would be appropriate to remove any functionality that includes, or enables the user to create, shortcuts to the Notification Center.

Initially I was baffled, then after further testing and re-reading of the rejection reason, Apples use of shortcuts in the plural jumped out at me. If a user had created multiple reminders and not fired them in notification center then they had effectively a number of application shortcuts ready to be used. So I changed the code to remove additional notifications when the app was launched directly or via a notification. Fingers crossed this will be acceptable.

I still think from a users point of view removing the extra notifications is wrong but Apple must see this differently, so if you agree that this should be the outcome from use of notification in this way, please dupe my enhancement request rdar://10609497)

I received a response that my rdar was a duplicate but as I don’t know the exact wording of the original below is the summary of my enhancement request posted on the 20th December 2011. The original id is rdar://10380471
Notification Center functionality is not fully utilised at present. Pull down gesture could be used to aid user shortcuts to other applications, (does anyone really double tap the home button to switch apps!?) to launch the in built Tweet Sheet for iOS5, to call a friend, open iMessage compose view etc.

Final Update

-18th March - v1.2 was recently approved for sale and is now available on the AppStore. On reflection I believe a number of factors played a part in the long review time. Notifications were only one factor. The timing of my submission co-incided with the new iPad release and I believe the App Store reviewers were likely working double time trying to get as many iPad retina apps ready for launch day.

I’m now a happy camper, and work on 1.3 continues, in fact its awaiting review as I type, this version enhances the UI and adds weekday scheduling.

1.4 is underway and for this version I’ll be refreshing the logo (and maybe a name change) amongst other thing.

Happy Swiping. Nik

I’m developing a Twitter tool and needed to grab the latest tweets in the public timeline and chuck (technical term) in a tableview for testing.

I’d also appreciate any comments if anyone spots any bad coding habits or would like to improve it.

Copy the code into your project making sure the calling class registers for the in its header file.

Then instantiate the class using your URL, I just use the standard Twitter Public Timeline Timeline API:

1
2
3
4

latestTweets *lt = [[latestTweets alloc] initWithTwitterURL:@"http://api.twitter.com/1/statuses/public_timeline.json?include_entities=true"];
lt.delegate = self;
 
[lt release];

I’ve recently updated my companies website and had added a blog section as an afterthought using Wordpress. Github is something I use regularly to view open source projects but had never used as originally intended, (I just download the zip file), as I’d always viewed the git process as having too steep a learning curve. Since I found out about Octopress last week, this has replaced my mediocre blog with something very elegant and also put me on the way to understanding and including git into my daily development workflow.

The process was relatively simple, but being new to Git and Ruby I had a few problems along the way. I hope this post helps you if you also choose to host your octopress on github.

(Update - 23rd September 2011 - The Octopress team have made this even easier since I did my install last week. There is a custom rake script (is that the correct terminology?) to do the tricky git stuff for a github install.)

Steps

-Things to do before installing Octopress: (from within Terminal)