Ajnaware’s Weblog

Web, Mobile & iPhone software development

Archive for the ‘iPhone’ Category

Sun Seeker Update v1.5

with 5 comments

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!

Written by ajnaware

Saturday, 19 March 2011 at 12:18 pm

Dynamically adding UIActionSheet buttons

with 6 comments

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;
		}
	}
}

Written by ajnaware

Saturday, 26 February 2011 at 9:21 am

See Breeze – Augmented Reality Wind Visualizer for iPhone and iPad

with 3 comments

Ajnaware’s latest app “See Breeze” has just been approved by Apple, and is now available from the app store. This app has a universal binary – so can be installed onto either iPhone 3GS or onto iPad from the same purchase.

Like Sun Seeker, this app pushes the boundaries of what augmented reality on mobile devices can be used for. The app description is as follows.

Provides both a FLAT VIEW COMPASS and an AUGMENTED REALITY 3-D VIEW showing the local wind and weather conditions with animated wind vectors.

Ideal For:
– Aviators, Sailors, Surfers, Windsurfers, Kite Flyers, Cyclists, Fire Fighters, Weather Hobbyists and any other outdoor enthusiasts

Main Features:
– Compass view showing animated wind vectors for nearest weather stations with wind, temperature and humidity readings
– 3-D augmented reality view with animated wind vectors
– List of local observation stations (up to 10 nearest), from which any may be selected for individual wind viewing
– Map view of all local stations with weather arrows showing direction, speed and temperature
– Uses official Bureau of Meteorology data within Australia, and NOAA metar data (from airports) for rest of world

Feature Device Dependencies:
– iPhone – interface runs only in portrait mode, 3-D View is shown as an overlay on the camera view
– iPad – interface runs in any device orientation, 3-D View is displayed with an opaque background (due to absence of camera)

I had the idea for this app about the same time as I had the idea for Sun Seeker, but I had to choose just one to do first, and even when I did start it, I found that it took a lot longer than expected due to the various technical challenges involved. The first major challenge was learning some OpenGL ES, and the second one was figuring out how to get OpenGL ES to respond correctly to device orientation and heading changes. Many thanks to Jeff LaMarche for some great blog articles on the former, and as for the latter, I pretty much had to figure it out for myself. I did post on Stack Overflow, but ended up answering my own question.

Adapting the app to iPad was also an interesting issue to deal with. I ended up with quite a few conditional branches in the code to deal with cosmetic differences. But the end result more than justified the extra effort. It looks superb on the iPad. Credit for the excellent app artwork goes to Peter Fellows once again, whose work on the Oz Weather program was brilliant. Here are a few screenshots from the iPhone app.

and one from the iPad app, which of course has much nicer mapping ability…

Written by ajnaware

Sunday, 11 April 2010 at 10:42 am

Plotting a Cold Change

leave a comment »

Saturday 23rd January 2010 saw a classic heatwave/cold front event occurring up the eastern coast of New South Wales Australia, and I observed from Sydney, watching things progress during the day via the internet, as well as from my own home, where I have a view across parts of Sydney.

Oz Weather v2.1 introduced graphing of weather history as a new feature, and the graphs from that day show the change very clearly indeed. The following graph is a composite of the different ones available in Oz Weather, although I have overlaid a transparent bar indicating the time when the main changed occurred.

A summary of the changes:

  • Temperature dropped from about 41°C to 22°C.
  • Humidity jumped from 10% to 85%
  • Wind jumped from 30km/h to 65km/h with gusts to over 95km/h just as the change came through, and the direction shifted from NW to S.
  • Interestingly, the pressure started to rise an hour or so before the main change, and there was a little rain from some thunder cells that developed following the change.

The Doppler (wind) radar also showed the approach of the wind change very clearly. Unfortunately I didn’t save a graphic from when the change was passing right through Sydney, but an earlier shot shows the change passing through Stanwell Park, to the south of Sydney.

The key point here is to note that blue indicates wind towards the radar location (centre of crosshairs) and yellow indicates wind away from the radar location. So this is showing strong NorthWest winds (blowing offshore) over the Sydney region, but from the South at Stanwell Park and below. This picture was a lot more striking as the change passed through Sydney itself, but I’ll have to wait for another event to show that off better!

Written by ajnaware

Sunday, 24 January 2010 at 8:53 am

Posted in iPhone, Weather

Tagged with ,

Sun Seeker Lite

with one comment

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. ;-)

Written by ajnaware

Saturday, 23 January 2010 at 5:26 pm

Sun Seeker is Finalist in 2009 Best AR App Award

with 3 comments

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.

Written by ajnaware

Sunday, 3 January 2010 at 6:26 pm

Oz Weather Apponomics – Birthday Edition

with one comment

This is the latest installment tracking the progress of the Oz Weather iPhone app in the iTunes app store. (Part 7 installment here.)

Oz Weather v1.0 arrived in the app store on 1st November 2008 (now at v1.7.1), so I now have a full years of stats to share with you.

  • Total paid app downloads: 64,500 (176 per day on average)
  • Net app revenue: AUD$99,600 (US$89,700) – net of 30% Apple share and 10% Australian GST
  • Average User Rating: 4 stars – from 1187 ratings of all versions
  • Average ranking: 17.5 – in Australian app store

[Stop Press – AUD$100k sales were reached on 3rd Nov 2009]

The following graph shows a complete history of one year’s worth of daily sales records.

SalesGraph_2009_10

The associated Australian overall paid apps ranking is as follows:

RankGraphAus_2009_10

So there have been a number of peaks and troughs. The single biggest factor causing those peaks and troughs appears to have been Apple promotions in the Hot / New / Staff Pick lists. But this has worked both ways – the biggest troughs have occurred when Apple has promoted competing apps.

The second biggest factor has been the weather itself. In Australia it seems that people are more interested in summer weather than they are in winter weather, hence causing an underlying annual cycle which peaks in summer (Dec/Jan/Feb) and troughs in winter (Jun/Jul/Aug).

Some individual weather events (eg. extreme heat waves, major rainfall events) seem to account for much shorter term peaks – especially noticeable around Feb 2009 when a major app update was also released.

Its also worth noting that during the course of the year the number of competitors has grown substantially. No doubt other developers have noticed how well weather apps seem to do in the app store ecosystem, and I would guess that my blogging about such attractive sales figures has probably encouraged some of the new ones into the game too. ;-)  However, most of the newer competitors have failed to get any significant visibility, at least so far, and overall I don’t regret my decision to be transparent and open with my sales figures. I am always delighted to read about the inside stories of other app developers’ successes and failures, and hope that my own story has been interesting and useful to others too.

Written by ajnaware

Sunday, 8 November 2009 at 5:54 pm

Follow

Get every new post delivered to your Inbox.

Join 790 other followers