Sun Seeker Sizzles!

The Sun Seeker app has continued to be enhanced and honed in a series of updates, the most recent being v2.8, which includes a modernised interface – yep, those are indeed flat button faces. 😉

Sun Seeker v2.8 compass screen
Sun Seeker v2.8 Compass Screen

These updates seem to have attracted a bit of positive attention resulting in several new blog reviews, culminating in the following fabulous review from top-notch reviewer John Martellaro (@jmartellaro) of The Mac Observer. This is a must-read review, not just because it is positively glowing, but also because John saw fit to include my detailed answers to his probing questions, including some inside information on how the app works, and especially importantly on how to ensure optimum compass calibration of your device.

Just to show a little more of the app here, my own favorite feature update is the ability to select date and time on the map view via a scroller.

Sun Seeker Map View

 

Advertisements

Sun Seeker Test Shots

Here are a couple of images from Sun Seeker put together (unsolicited) by a generous and enthusiastic New York based photographer/cinematographer – Hal Hansen.

He’s currently revamping his website and I’ll provide a link to it here when it’s ready. Thanks Hal!

I love the way he’s featured an iconic yellow cab which is a New York signature. Did anyone notice that it’s not actually the same cab in each shot? That’s clever photography! 😉

Sun Seeker Update v1.5

As part of a series of planned updates for the Sun Seeker augmented reality iPhone app, the latest update v1.5 has just been approved by Apple.

For a video demo of Sun Seeker see this earlier blog post.

The main changes for v1.5 are:

  • Enhanced performance for smoother compass dial rotation
  • Added new table of annual rise and set times
  • Added new table of sun’s daily azimuth and elevation
  • Added tap action to rise/set label to see local times instead of intervals
  • Better handling of disabled Location Services
  • More efficient use of GPS – now only used briefly on startup
  • Fixed some minor bugs and issues with date changes

[Note – v1.5.1 update has been submitted to fix OS3.0 backward compatibility and missing sunset times for some locations west of GMT.]

Following is a more detailed description of some of these items.

1. Enhanced Compass Dial Rotation

The compass dial in Sun Seeker includes text which retains its orientation relative to the device regardless of the compass rotation, and this means that at least part of the image needs to be re-rendered for each incremental rotation of that dial as the compass rotates. Previously the whole image was being redrawn each time, and that performance hit meant that the dial motion was quite jerky when it needed to make large rotational changes. The new implementation involves much less redrawing, and hence allows the compass to be much more responsive.

2. New Tables

The table of rise and set times spans the entire year, and hence allows you to look up rise and set times for any given date.

The table of the solar path lists the sun’s azimuth and elevation at 15 minutes intervals throughout the currently selected day.

3. Tap action to see rise/set time instead of intervals

This was added simply for clarity. Tapping on the rise/set labels on the compass screen toggles the display between showing the rise and set time in local time versus showing time duration between now and the rise and set times.

4. Better handling of Location Services status

A problem to date has been if the user has switched off the device Location Services or (perhaps accidentally) disabled them for this particular app. In these cases the app can only use its last acquired location data, and in this case the app shows data which is correct for that old location, but incorrect for the user’s current location.

This issue has been the biggest generator of email support requests to date, but I now expect that this will lessen considerably, because I have implemented clear warning messages which pop-up whenever location services are disabled, each time that the app starts up or resumes from background.

5. More efficient use of GPS

Previous versions of the app left GPS on continuously while the app was active (although off when inactive or in background), and this presented the app with ongoing positional updates while it was open. But for the sake of efficient use of GPS, it seemed unnecessary to leave it on once the location had been determined to a reasonable accuracy, so GPS is now only on as long as location has not been found to reasonable accuracy. However an important point here is that the app should re-query its location not only every time it starts up, but also whenever it resumes from background. The reason for this of course is that the device may have changed location while it was in background – for example it may resume from background after the user has traveled somewhere by air!

6. Future Updates

By far the most common request from users has been to allow selection of other cities/locations rather than just the current current, and this is the next major feature planned. But please note that it is not a trivial update! A particular difficulty here is in ensuring that the local times reported for other locations respect the correct timezones and daylight savings rules for those locations throughout the year. However, I do have a solution planned, and hope to be able to do this within a reasonable timeframe.

The next most common request has been for an Android version. Due to the particularly technical nature of the app, and the fact that I personally have no grounding in Android development, this is a much more difficult proposition. However I have been looking to outsource it. I apologise to those who have been waiting impatiently, and I can assure you that these plans are progressing.

In the meantime, I hope you continue to enjoy the app!

Dynamically adding UIActionSheet buttons

Every once in a while I come across a seemingly simple iPhone coding requirement, but Apple documentation just doesn’t seem to give enough pointers, and nor does web search throw up anything useful. It may just be my inability to find the right keywords to search for, but it might also be that no-one else has posted anything about it. So here is just one such thing in case it proves helpful to anyone.

The UIActionSheet is a very useful class, and I use it frequently in my apps, but its initialisation method doesn’t allow you to add buttons from an array. Instead you apparently typically just add them hardcoded as an initialiser parameter  – and almost all code examples on the web seem to use this method.

Standard example – hardcoded buttons:

- (void)testActionSheetStatic {
	// Create the sheet with buttons hardcoded in initialiser
	UIActionSheet *sheet = [[UIActionSheet alloc] 
		initWithTitle:@"Static UIActionSheet"
		delegate:self
		cancelButtonTitle:@"Cancel"
		destructiveButtonTitle:nil
		otherButtonTitles:@"Item A", @"Item B", @"Item C", nil];

	[sheet showFromRect:view.bounds inView:view animated:YES];
	[sheet release];
}

So that is all well and good if the option buttons are known in advance and never change. But what if I need to change them at runtime? It seems easy enough to add buttons dynamically instead, by leaving out those button declarations from the initialiser, and adding them afterwards instead, and the following code shows how you might assume this should be done.

Dynamically added buttons (first attempt):

- (void)testActionSheetDynamic {
	// Create the sheet with only cancel button
	UIActionSheet *sheet = [[UIActionSheet alloc] 
		initWithTitle:@"Dynamic UIActionSheet"
		delegate:self
		cancelButtonTitle:@"Cancel"
		destructiveButtonTitle:nil
		otherButtonTitles:nil];

	// Add buttons one by one (e.g. in a loop from array etc...)
	[sheet addButtonWithTitle:@"Item A"];
	[sheet addButtonWithTitle:@"Item B"];
	[sheet addButtonWithTitle:@"Item C"];

	[sheet showFromRect:view.bounds inView:view animated:YES];
	[sheet release];
}

The problem with this becomes apparent when you run it – the cancel button appears at the TOP of the sheet, whereas standard practice seems to be that it should be at the bottom. How to achieve this? I didn’t manage to find a way of doing this while adding the cancel button in the initialiser. Instead I eventually found a way of doing so by adding it also as a dynamic button.

Dynamically added buttons (also with dynamic cancel button):

- (void)testActionSheetDynamic {
	// Create the sheet without buttons
	UIActionSheet *sheet = [[UIActionSheet alloc] 
		initWithTitle:@"Dynamic UIActionSheet"
		delegate:self
		cancelButtonTitle:nil
		destructiveButtonTitle:nil
		otherButtonTitles:nil];

	// Add buttons one by one (e.g. in a loop from array etc...)
	[sheet addButtonWithTitle:@"Item A"];
	[sheet addButtonWithTitle:@"Item B"];
	[sheet addButtonWithTitle:@"Item C"];

	// Also add a cancel button
	[sheet addButtonWithTitle:@"Cancel"];
	// Set cancel button index to the one we just added so that we know which one it is in delegate call
	// NB - This also causes this button to be shown with a black background
	sheet.cancelButtonIndex = sheet.numberOfButtons-1;

	[sheet showFromRect:view.bounds inView:view animated:YES];
	[sheet release];
}

In this case the cancel button appears at the bottom, and all works as expected.

The main remaining question I had was what on earth the destructive button was (also apparently not explained in Apple documentation). Some experimentation seemed to show that it was effectively identical to a cancel button with the exception that it had RED background instead of a black one. So if you change the last example to set the destructiveButtonIndex instead of the cancelButtonIndex, then the only difference is that the button labelled “Cancel” would have a red background.

For completeness and sanity, this is the delegate code that goes with all of the above examples.

- (void)actionSheet:(UIActionSheet *)actionSheet 
		clickedButtonAtIndex:(NSInteger)buttonIndex {
	if (buttonIndex == actionSheet.cancelButtonIndex) { return; }
	switch (buttonIndex) {
		case 0:
		{
			NSLog(@"Item A Selected");
			break;
		}
		case 1:
		{
			NSLog(@"Item B Selected");
			break;
		}
		case 2:
		{
			NSLog(@"Item C Selected");
			break;
		}
	}
}

Oz Weather HD

Oz Weather HD is an iPad only version of Oz Weather. I’m delighted to announce its approval and release by Apple today, after an impatient 8 day waiting period.

It contains all of Oz Weather’s features including the pro level ones, in a much more accessible way than is possible on the iPhone’s limited screen size. The larger screen size has also made it possible to present many of those features more attractively than on the iPhone as well.

This app has been a long time coming – I would have liked to get it out there much sooner, but was earlier pre-occupied with updating other apps (Sun Seeker and See Breeze) to work as universal binaries (ie. on iPhone and iPad), not to mention also releasing a brand new iPhone app called Moon Seeker, which is a lunar calendar, compass, and augmented reality position finder.

After much agonizing over the design of Oz Weather HD, and several false starts, I’m really pleased with the way it has finally turned out. My criterion for a good design is one that I get a warm feeling every time I run the app and this is certainly true of this one. I can only hope that lots of others get the same buzz out of it! The crux of this design is the inclusion of some of my favourite cloud & weather photos as backdrops.

Here are a few screen shot thumbnails:

Sun Seeker Lite

I’m pleased to announce the arrival of Sun Seeker Lite – a free version of Sun Seeker (finalist in the 2009 Best App Ever awards), albeit without the augmented reality view!

After my recent experiments and experiences with in-app purchase, I’m now putting more effort into the Lite version concept. Although it requires creating a whole new app, in practice it is simpler and safer than the in-app purchase method, for a range of reasons. In fact I have already added an Oz Weather Lite version of the full Oz Weather app, and Sun Seeker Lite is my second Lite app.

That is not to say that the decision of exactly what features to put into a Lite version is an easy one. In this case I removed all augmented reality features, which is of course the big selling point of the full app, but on the other hand I’m pleased enough with the look and feel of the main screen’s flat compass view, that I think it will create the right impression for users, and persuade them that the quality is good enough to warrant purchasing the full app.

Despite the fact that it does omit the augmented reality view, the flat compass view in the Lite app can still be very useful in many situations. Please give it a go, and pass on the word to others if you like it, or perhaps even (gasp!) leave a positive review. 😉

Sun Seeker is Finalist in 2009 Best AR App Award

I have a vague memory of Sun Seeker having been nominated for something at some point… but then obviously forgot all about it. But today I received an email telling me it is a finalist in the “2009 Best App Ever Awards” in the category of Best Augmented Reality App.

I’m guessing that it wouldn’t have reached this stage without some people having decided that it was a worthy app, so this much is gratifying in itself. But if you have any inkling at all to offer some support for the public vote, please feel free to use the following link to place a vote, and augment the app’s chances against some of the other very high profile contenders. 🙂

Vote for
Sun Seeker: 3D Augmented Reality Vi…
in
Best Augmented Reality App

This is especially pleasing to me because I have found that most people (at least initially) don’t seem to understand what the app is useful for. But when they do finally get it, the response is of course much more enthusiastic.

BTW – I’m still intending to do much more with AR, and hope to be able to report on my progress later.