LIFX Light Bulbs and IFTTT

I am living with 6 LIFX light bulbs in my home – and I just love the way this allows me to redecorate my working and living space to my whim, both with simple and complex, dynamic lighting schemes. In fact, with these lights, I can’t see myself ever wanting to paint my walls with any particular color scheme again. It’s just no longer necessary – and now seems far too static and inflexible a way to make my home attractive.

I’ve had my fair share of teething problems with the bulbs – at one point, after lengthy email exchanges with LIFX tech support, I returned the entire batch for a new replacement set, after a seemingly endless series of problems with lights falling into and out of being unrecognised by the LIFX app. But to their credit, with the newer bulbs, and more recently with the migration of  LIFX to the cloud, the system is now working really nicely – almost glitch free.

In fact it is this migration to the cloud which has finally allowed the bulbs to achieve some of the amazing potential that they have to make life more fun and more beautiful. Amazing things were promised, but not delivered by previous incarnations of the LIFX apps, which could only perform simplistic local control functions. These were fine for setting up a lighting scheme manually, or showing off the bulbs via a brief light show, but simply didn’t allow any significant form of automation.

This is how my lighting system is set up

• Hallway – 2 lights (Door, Hall)
• Living Room – 2 lights (Behind TV, Couch Lamp)
• Office – 2 lights (Desk A, Desk B)

I have three “scenes” that I can set manually via the LIFX app on my phone

• Evening – Living Room lights switched to semi-dimmed warm (orange) glow (and all other lights switched to off) – this creates a warm,relaxed atmosphere
• Work – Office lights switched to bright cool (blue) glow – this helps concentration and aids clear seeing of detail
• Arriving Home – Hallway lights switch to semi-dimmed warm (orange) glow – this is helpful when coming home, especially at night, if the lights are off when I come in

So these formed the backbone of the system, and covered 8o% of my lighting needs – the remaining 20% of finer adjustments came by controlling bulbs individually, or just occasionally by selecting some of the special effects offered by the app – one my favourites being a dynamic northerns lights type display, which unfortunately seems to have dropped out of the latest version of the app. However, there is still plenty of scope for playing and fun with the effects provided, and realistically, this is more of a show-off feature than something I’d want to use on a regular basis.

But the pièce de résistance comes via the ability to add automation via IFTTT‘s LIFX Channel. So now I have added the following “recipes”:

Turn on lights at sunset

When the Weather channel notifies me that it is my local sunset time (trigger), the LIFX channel fades in my Office lights.

Purpose – This is designed to help me maintain good light when I am sitting at my desk, without needing to manually activate the lights.

Cons – If I am not at home, or not sitting at my desk, these lights come on anyway. In order to counter this, I need to take note of the iOS notification that I receive when the sunset trigger occurs, and then manually switch off the lights.

Turn off lights at sunrise

When the Weather channel notifies me that it is my local sunrise time (trigger), the LIFX channel fades out all my lights (if any happen to be on).

Purpose – This is designed to avoid leaving the lights on unnecessarily, if I happen to have gotten up early and switched on the Office lights manually before starting work. Without this, I often find later that the lights are still on despite having sun streaming through the window.

Cons – No major cons to this one. Perhaps if there is heavy cloud cover, then I wouldn’t want to lights to go right off, but it is easy enough for me to make a manual adjustment if I see the lights dimming themselves and want them brighter.

 

Turn on lights when I get close to Home

When the iOSLocation channel notifies me that I have entered the area around my home (trigger), the LIFX channel fades in my Hallway lights.

Purpose – This is designed to ensure that lights are on when I open the door, so I don’t have to fumble around in the dark, and use my phone to switch on the lights.

Cons – Unfortunately the IFTTT system doesn’t allow me to combine this trigger with a daylight/nighttime condition, so if it is still daylight, then I don’t actually need lights on as there is already sufficient daylight in the hallway, and in this case I have to switch them off manually after I get home. Another, more subtle, issue is that just occasionally (once in a few days), this trigger gets activated even though I haven’t actually left home. My best guess is that this is due to occasional inaccurate GPS readings which, momentarily, locate me far enough from my true home location so as to trigger the re-entry event once the accuracy improves again. It might be possible to reduce the likelihood of this happening by choosing a larger radius for the trigger area – I’ll experiment with this further over time.

 

Note that a common factor in the cons of these automation methods is the lack of ability to combine triggers. After all, it seems a fairly basic need to have your lights to come on automatically only once it is already dark. As the IFTTT system does not allow you to combine triggers from different channels, it seems that the only way to achieve this would be for LIFX to make an addition to their own IFTTT channel by adding an extra trigger condition i.e. whether or not it is currently daytime or night-time at your given location. I will be bringing this post to their attention. If you agree with me on this one – and it does seem to be a crucial issue for allowing LIFX bulbs to achieve more of their true potential – then please let them know you want this too: Submit request to LIFX

Advertisement

Sun Seeker for Android!

After a long development period I’m delighted to announce that Sun Seeker is now finally available for Android devices!

Click on this logo to see it in the Android Marketplace.

Is is real or is it Memorex? (You have to be of a certain age to remember that advertising slogan!)

Yes – it looks just like the iPhone version in most ways, and includes all the same features as the latest iPhone version.

I’m especially interested to see how sales go, and find out just how different the app sales may be between the two devices. Of course Sun Seeker on iPhone is well established, and it may take a while for the Android version to find its momentum. We’ll see!

OptimalClub – A Powerful Golfing Aid

OptimalClub is the latest iPhone app that I have developed, created in association with Todd Kos of QualityGolfStats LLC, who is the app publisher. Todd has a long history in golf software, being the creator of the industry-leading OptimalFlight desktop software, used for club fitting by the pros.

Official OptimalClub App Website

OptimalClub uses the very same physics simulation model as the desktop software does, but makes it available on your iPhone in real-time, along with live local weather observations, in order to provide an accurate simulation of the actual golf shot path superimposed onto local satellite imagery of the course, according to the clubs available in your bag. This allows you to see at a glance and select which of your clubs best suits the current distance required, and also shows how far to the left or right you will need to aim in order to adjust for wind deviation, which can be substantial, even in only moderate wind conditions. Below are four screen shots showing the effect on the the shot of the wind coming from four different directions.

In this case the best club selection varies from an 8 iron (when wind is directly behind) to a 1 hybrid (when wind is head on), and the aim varies from 32 metres to the right of the target to 26 metres to the left of the target when the wind comes from either side, instead. That’s quite a range! And that is just for a 27 kmh wind (17 mph). By the way, the units used for distances and weather are of course selectable in the app settings.

The weather engine used in the app is very similar to that used in the See Breeze augmented reality wind visualisation app. However, due to the possibility of very localised wind variations or sudden weather changes in some cases, we felt that we needed to offer the user the ability to override the weather reported by the nearest weather stations, and therefore there is an option to choose between automatic and manual weather settings.

In order to customise the app to your very own set of clubs and your own unique skill and style, you can enter details of your own clubs and the typical distances you get with them. The app then uses its advanced built-in shot physics simulation to estimate the club launch parameters (speed, launch angle and ball spin) for each and every club, after which it can predict, with surprisingly good accuracy, the actual shot path and distance you will get in the field for any given set of wind and weather conditions, as well as altitude variations and changes in elevation between the tee point and the hole.

Once your clubs are set up, all you need to do is to set up the individual shot you are about to take ie. to specify your shot origin point and your target, using the side-toolpanel.

As soon as you have specified origin and target, the app shows you the nearest 5 club distance arcs – again taking into full account the current wind, weather and elevation differences.

In the above example, the wind is from the left, and due to the short distance (62 metres), the nearest shots are all partial swings using a pitching wedge (from 30 to 70% swing effort). The arcs on the map are color coded to identify which club/swing they are showing. And once you select a club (by tapping on it), you will see the full shot simulation for that club/swing, as shown below.

The hole-in-one odds are also shown for your entertainment, if you have them switched on in the app settings. Good luck!

Of course I’ve only covered some aspects of the app here. Considerable effort was put into getting the map display right (which is even rotatable via finger-gesture), and the sequence of actions required to setup a shot with as few steps and as quickly as possible, so as to minimise interference with actual game play. All-in-all this is an app that I am particularly pleased with. It has taken considerably more development effort than any of the other apps I’ve worked on, and the result is something quite unique and powerful. Of course now the challenge will be to see how much traction and visibility this app may get now that there are 300,000 other apps competing for eyeballs.

To start things off we are offering a limited time introductory sale price – 50% off ie. US$9.99, so if you are at all interested, it may be well worth your while getting it now. (NB – Sale is still on at time of writing this article.)

Sun Seeker 3rd in Best App Ever Awards

The Best App Ever awards reached their fiery conclusion a couple of days ago.

I was very gratified indeed to find that Sun Seeker had been voted into 3rd Place in the Augmented Reality App category, not to mention slightly stunned. In fact I was so dubious about my chances that I didn’t even bother checking the results when I first saw that they were out.

Thanks hugely to all those who voted for Sun Seeker. Hopefully there will be more innovative apps like this coming soon!

Its well worth a look to see the full list of winners and honourable mentions. There are many very interesting apps in there – many of which you might otherwise have missed given that there are apparently now 150,000+ apps available in the store.

Five Good Reasons NOT to Implement In-App Purchase

I’m writing this in light of my recent experience with the Oz Weather iPhone app.

In mid-December I issued an update to the app, immediately after which there was a major app store glitch which caused a huge problem in its own right. But having already documented that previously, I will here discuss the new in-app purchase which was introduced to allow users to enable a set of “Pro” level weather features. In addition to this, I provided a 7 day free trial of the Pro features. As a result of these changes I’ve had a significant number of sales of those Pro features, but I’ve also had a spate of awful (even vitriolic) user reviews, which have significantly lowered the app’s average star rating, and the app’s ranking and new app sales levels have been adversely affected ever since. 😦

Reason 1 – It is not trivial to implement it well

There is plenty of sample code available that you can use to implement the in-app purchase process, but you still need to design and implement your own “storefront” which displays information about the purchase, how much it costs etc. You also need to make sure your app logic works correctly both with and without the purchased items having been activated, and although this might be straightforward in apps where the content is already well compartmentalized, it is much trickier in other types of app where different app features typically have some integration, and need to be separated out carefully when split into standard/purchased functionality.

Testing that the purchase process works correctly and that the purchased content is made available correctly, and if necessary also registers on your own server, is also much slower and more difficult than ordinary app debugging, as it requires using a test sandbox accounts and server interactions. You also ought to test what happens if the purchase process is interrupted, or the server connection is interrupted during purchase or after purchase confirmation, but before you have saved the app purchase status to your own server. All these things can and will happen sooner or later if you have any significant number of users, and you will want to make sure you can deal with them all, and at least recover gracefully later if they can’t be dealt with up-front.

Reason 2 – The developer must take full responsibility for correct delivery of the purchased item

With a normal app purchase the developer can wash their hands of the sale process. Apple deals with the entire sale process and installation of your app, and if something goes wrong with that, and a user loses or needs to restore their purchase, install it on a separate device, or has any other issue, then it is Apple’s responsibility, and you are within your rights to refer any complaints about this back to Apple.

However, with an in-app purchase you suddenly take on much more responsibility. Although Apple does keep track of in-app purchases itself, and can restore these to the user, you will probably also want to keep track of purchases too – at the very least a database of app ids which have made the purchase, so that if the user simply re-installs their app, the app can determine on startup whether the purchase was already made previously, so they won’t have to go through the in-app purchase process again to get it back. Of course if you want to offer a trial, as I did, then you will have to maintain a similar database to keep track of that too.

The most difficult scenario, though, is if your in-app purchase is a time-limited subscription. In that case, Apple has no record of whether or not the subscription has expired, and it is totally up to you to maintain correct reliable records which can be used to restore each users app state. If anything goes wrong with your implementation of this, then it is you who will be responsible for refunding your users! Will you be able to sleep at night knowing this?

Reason 3 – A lot more user support and interaction is required

Although most users will already be familiar with app purchasing paradigms, many users have not used in-app purchase before, and this means that you will likely get a lot of queries due to their inexperience with the process and its quirks and implications.

Here is a list of some of the types of new user issues I’ve had to deal with as a direct result of the in-app purchase, for example:

• Questions about why they get a message saying purchases are disabled on their device
• Questions about why they get a message about a “Test User” account when they try to purchase (jailbroken devices)
• Questions about why they get a message about “Sandbox Account” when they try to purchase (jailbroken devices)
• Questions about why the in-app purchase apparently did not register on their device
• Questions about how to restore the purchase if they load the app onto a different device
• Questions about why they are told they have to purchase the original app before they can buy the in-app item
• Questions about why the in-app purchase items are not free to them, given that they already paid for the app

And then there were more issues relating to the trial, rather than to the purchase per-se, for example:

• Questions about exactly what the new features contain, after their trial has finished
• Questions/complaints about why they have lost trial features they believed were part of the standard app

Reason 4 – Users who don’t/won’t pay for the in-app purchase can still leave a bad review about it

In my own case, this is the hardest one to deal with – and should give other developers plenty of pause for thought.

Apple has gone to some lengths to tidy up the user review system, and it has certainly improved a lot since the early days. However, there remains a glaring hole in the system – although users can no longer leave reviews for apps that they haven’t purchased they can still leave reviews relating to in-app purchase items that they have not (and obviously will not) purchase.

In my own case, most of the bad reviews are apparently due to misunderstandings by the user about the nature of the in-app purchase. Some people obviously thought that they were losing what they had previously paid for, and had to pay again just to keep the app.

Of course I have to take responsibility for any lack of clarity in how the in-app purchase has been presented to the user, and I have indeed attempted to tweak this. I suspect that the worst reactions have come from people who for one reason or another, did not see the message that appears at the start of trial, explaining what was happening, after which they assumed that the trail features were theirs to keep. I’ll continue to work on this, and this might help, but the basic issue will remain as a major potential problem for anyone implementing in-app purchases, and wants to maintain a strong app rating in the store.

Reason 5 – Some users have the impression that all app “upgrades” must be free

Quite apart from users who misunderstood the trial and in-app purchase structure, there are also a number who simply seem to feel entitled to any additions to the app for free, perhaps having misconstrued Apple’s free update system as meaning that all types of app updates in functionality must necessarily also be free.

In a way it a compliment of course – the fact that they are so upset about not having the extra functionality must mean that they really do want and value it. However, the fact remains that these people also leave bad reviews, and there is no shortage of others who find those bad reviews “useful” and vote accordingly, thus pushing them to the top of the review list.

In Summary

In-app purchase may well be a useful and rewarding system for some developers and for certain types of apps, but it comes with some disadvantages, not all of which are immediately apparent. In particular, if you have a high profile/high visibility app which relies heavily on having good user ratings, you should think carefully about the possible drawbacks before you add in-app purchase to it. So now I’ve warned you. The rest is up to you. Good luck!

Turbulence in the App Store

Oz Weather usually provides you with all the latest Australian weather information, but today is a little different. Oz Weather has itself been experiencing some app store weather – and its been a bit rough. 😦

Background

Oz Weather has so far been a very successful iPhone app in the Australian app store. You can read more about it here.

But this particular story started with an app update to Oz Weather.

Because I wanted to add many new features, I had been thinking about creating a new app altogether, and perhaps calling it Oz Weather Pro and of course charge a bit more for the extra features and work that had gone into it. But the problem with doing this is that Apple offers no upgrade route between apps. Consequently existing users of Oz Weather would have had to pay just the same as any new users, and that to receive a partial replication of the features they already owned and had paid for before. I thought that was hardly fair to all those customers who had so enthusiastically supported the app since its launch last year, and other developers who had done that were panned for it.

So I carefully devised a plan which would ensure that no existing user would be disadvantaged at all. And what’s more I thought I would attempt a little tried but oh-so-frequently requested feature – a fully working, but time-limited trial of the new features before you decide whether or not you want to pay for them via in-app purchase.

I was encouraged by the fact that some others had indeed already attempted this, and actually had their apps approved by Apple (eg. the Palettes app). All I had to do was implement it all.

This did turn out to be a bit trickier than I first thought, but I did manage to solve it all, and I may write a little more about that in a future post.

Planning the Release

Before releasing the app, of course I carefully reviewed what I had done in light of Apple’s approval process. I was keen to get the app approved before Christmas, so didn’t want to risk a rejection after two weeks, which then leads to at least another two week delay after a re-submission. Once thing that particularly concerned me was that one of the new features used the camera overlay API call, which was introduced in OS3.1. My concern was realistic, as it was based on the fact that the Sun Seeker app was initially rejected precisely due to this API, as a result of  the fact that I had provided backward compatibility for OS3.0 users. Even though doing this is within Apple’s guidelines, and is even recommended by them, it was rejected anyway, supposedly for “forbidden” use of camera overlay. I also took a quick poll about this issue on twitter, and the general consensus of other developers was that it would be risky to do this, and even though perfectly legitimate in practice, was quite possibly still going to be rejected.

From previous usage statistics, I estimated that about 25% of existing Oz Weather users would be excluded from an update that worked only with OS3.1+. However, I reasoned that there was nothing to stop me submitting a further update which re-introduced backward compatibility with OS3.0 after the initial OS3.1 update was approved. In that case, if the backward compatibility issue still resulted in rejection at that point, the initial update would of course still remain available to 75% of OS3.1 users.

So I took the executive decision, for the sake of quickest possible approval, that the update would have a deployment target of OS3.1+.

The Release

Dec 10th, 10am – I was notified of the approval. The review and approval process had taken 12 days – par for the course at the moment. I was relieved that it hadn’t been rejected, and delighted it had happened well in advance of Christmas. For a while, I felt quite contented.

Dec 10th, 11:30am – Received an email from a user saying that although iTunes had notified them of the upgrade to v2.0, when they downloaded it it still appeared to be the old version (1.7.1), even after several retries. How odd, I thought! I was puzzled, but reassured the user that it was probably a server caching issue, and it would probably resolve itself later.

Dec 10th, 1:30pm – By now I had received 10 similar emails. I created a standard reply, suggesting that they contact Apple to report the problem. I was quite concerned because it would be unusual for more than 1 in 100 users to contact me directly, so there could be thousands of users with this problem. And of course they would all be assuming it is an Oz Weather fault.

Dec 10th, 7:20pm – By now had received about 40 similar emails, but suddenly my server started showing that many users were starting their trial – at the rate of about 10 per minute, indicating that of course the correct new app update version was now being served to them. Phew, I thought! Glad to see the back of that problem!

Dec 11th – One of the users who had contacted me yesterday was reporting that he now had the new version, but that it was crashing on startup. I had several email exchanges with him to try to get to the root of the problem, and by incredible good fortune, he was expert enough to be able to follow Apple’s instructions on where to find a crash log, and sent it to me. Within seconds of opening the log file I saw the problem. His device was running OS3.0, and a 3.1 deployment targeted app can simply do nothing but crash on an OS3.0 device. But how on earth did he manage to get an OS3.1 app onto his OS3.0 device?! iTunes controls that! Uh oh! My heart really started sinking at that point.

No doubt, I realised, this must be linked to the fact that iTunes was initially serving all these users with Oz Weather v1.7.1 – which was an OS2.2 targeted version. What if iTunes had based its list of customers to serve the update to was based on v1.7.1, and NOT on v2.0? That would explain this user’s problem. And it would also suggest that the problem might be much more widespread. Uh oh! My heart sank even further. And yes, iTunes was already showing a series of very recently posted one star reviews, complaining that the app crashed on startup.

My life flashed before my eyes. One star reviews?! Every developer gets them of course, at least once in a while. You can never please all users. But suddenly I was getting a constant stream of one star reviews from irate users – and it was all totally beyond my control, due to some weird Apple server glitch. And this kind of avalanche of negativity could probably kill an app quicker than the blink of an eye! And this app is my lifeblood. Of the various apps I have created and worked on, this is the one that truly supports me, and makes it possible for me to continue my “career” as an independent developer.

I fired off an email to Apple dev support, requesting assistance and pleading the urgency of the situation. Later I sent another email to a local Apple marketing rep, pleading urgency and lack of response from dev support. To his credit he responded promptly that he had forwarded the issue to the USA. However, even now, three days later, I have still not had any further response from them.

Dec 12th – Now, to make matters worse, a number of users (who obviously had OS3.1 on their devices, and therefore had no problem running the update) were leaving very negative reviews about the in-app purchase.

I was aghast. I had really gone out of my way to find the fairest possible system, which disadvantaged not one user, which offered a free 7-day trial of all additional features, and which even offered enhancements over v1.7.1 to those users who did not want pay for the new features. And yet I was being blasted for it. Many users latched onto the term “double dipping”. But how can it be double dipping when the user doesn’t have to pay for anything they don’t want to, and even if they have just got more functionality than they paid for in their original version anyway? The only explanation I can find for this is that these people had either not read, mis-read or just misunderstood my explanatory words about the trial and in-app purchase system. Perhaps I just hadn’t made it clear enough?

After a while I began to notice a bit of a pattern. There seemed to be a link between the app crash complaints and the in-app purchase complaints. It was as if they were fueling one another – scathing one star reviews cross pollenising one another in a kind of feeding frenzy – along the lines of “wow this guy wants to double charge us for an app that crashes on startup!”.

This really looked terminal. How can an app recover from this? What was the chance of Apple actually removing any of the reviews that erroneously blamed Oz Weather for the download and app crash schemozzle? And even if they were to do that (which would be completely unprecedented as far as I know, and hence extremely unlikely), would they also remove reviews referring to the in-app purchase which had been influenced by the crash reviews? And for that matter, why is it that users who haven’t and obviously won’t use the in-app-purchase be allowed to leave a bad review for the app supposedly based on their disapproval of the in-app purchase being offered, at all?

So what could I do now? The first step was to quickly submit a backward compatible 3.0 version, and submit a request for expedited review. Fortunately this was a very quick step, because I had already expected to be submitting such an update very soon, as explained earlier. And if approved, and providing Apple’s servers didn’t mess things up again, that would at least allow 3.0 based users (currently with what appears to them to be a dud app) to actually get it working. But it wouldn’t help anyone using OS2.2. And perversely, it would also no doubt appear to users as if I had submitted a new app update because the previous version was itself faulty – rather than the reality that the update was being submitted principally to help work around Apple’s server mess-up. And hence it would implicitly appear as an admission of fault/guilt on my part, thus appearing to vindicate all the reviews that misguidedly chastised me for having submitted a “faulty” update in the first place.

Another step was to recommend that users upgrade to OS3.1, as presumably this would also remedy the app crash. But of course only a small proportion of victims of the crash would actually contact me about it, so this wouldn’t reach many. So I decided to edit the app’s description in the hope that at least new users would be able to see my explanation of the reason for the slew of terrible reviews. And then in yet another quirky twist of fate, very shortly after I had done this, Apple suddenly started deploying a new app store layout, and all of a sudden most of the app description was hidden by default.

Sometimes you have to wonder, when so many coincidences stack up against you, whether you are simply fighting a losing battle. So that was when I started thinking about pulling Oz Weather from the app store altogether, at least until some real solutions emerge. Wow, that seems so drastic. A bit like cutting off your own leg to save your body after you get crumpled by an avalanche. But what exactly would the consequences of this be? Would any existing users be disadvantaged eg. would the in-app purchase become unavailable, for those existing users who did actually want to have the new features? If so, that would be making things even worse.

Despite all this, and helping me to keep things in perspective, there were still people leaving five star reviews, who obviously did really appreciate the new version and features, had not experienced Apple’s server glitch (or at least had understood that it was a temporary Apple issue), and had not misunderstood the in-app purchase system. And in fact some reviewers were obviously going out of their way to counter the negative reviews. So my faith in human kindness has not been lost. (If any of you are reading this – thank-you!)

What Next?

At time of writing (Sunday 13th Dec 2009), I have heard from Apple via the automated iTunes Connect system that they will provide an expedited review of an app update (v2.0.1) I submitted two days ago, which provides backward compatibility for OS3.0 users. This is something that they occasionally do when a developer requires an urgent update – usually of course due to bugs in their own app rather than due to an Apple problem. However, this will not help any pre OS3.0 users who were served the app update by Apple. According to my own analytics, this means that up to about 1000 users could still have an app that will not run, even after (and if) Apple approves this new update.

How on earth can that problem be fixed? Does Apple even have the ability to restore the older version to those users? But apart from that automated reply from iTunes Connect, I have not had any response at all to my pleas for help to Apple’s advertised email addresses for developers and iTunes Connect users, and I am not even sure whether or not Apple is *still* serving the existing Oz Weather update to users running older OS versions. (I am assuming that they are not, because the flood of emails has decreased, but I cannot be certain.)

And even if and when Apple manage to remedy that problem, what about all the negative reviews that Oz Weather has acquired due to Apple’s glitch, and the consequent loss of sales and rankings – possibly permanent? Having a new app upgrade will of course relegate those reviews to the pool of reviews for non-current versions, but my observation is that irate users can and will update their bad reviews whenever new updates come out, anyway.

The iPhone device, its SDK and the app store environment have provided me with a fantastic creative outlet, and overall it has been very gratifying and rewarding. But right now its is all feeling a bit tenuous. There seems to be little I can do now but wait for Apple to do something. Or nothing. Judging by past experience I should certainly not be holding my breath.

App Store Fixed

It seems that the major problems with iPhone and iTunes app store pricing synchronisation have now been resolved – although still not a peep from Apple about what has happened or what was done.

How do I reach this conclusion?

• Firstly I observed that my app’s reviews jumped up from 77 to 94, after having been stuck on 77 since before Christmas.
• Secondly I observed that my earlier modifications to my app description had finally propogated to both iTunes and iPhone app store.
• Thirdly I made some further minor changes to my app description, and found that they correctly propogated to both iTunes and iPhone app store in less than 3 hours.

From this I deduced that the problems with app server synchronization were finally over. I then resubmitted my app price change (from $0.99 to $1.99). This change, along with further app description changes, propagated through the system within a couple of hours. So far I have had no customer complaints about being unable to purchase, and Oz Weather app ranking has remained at #2.

Hopefully we’ll eventually hear something from Apple about this. Or on the other hand they might just close the discussion thread about it on the Apple Developer Forums without a word. For the sake of supporting their developers, I’m really hoping it will be the former, of course.

TiVo – The Unit and the Customer Service

I’ve been through several HD set-top boxes in my time already. The first one was a Toshiba. Being my first I didn’t know what to expect, and was a bit shocked by some of the problems and bugs. For example, the display clock lost about 20 minutes per day. The only way it managed to record programs at the correct time was by turning itself on every few hours and re-syncing its clock with whatever channel it was last tuned to – and some of those didn’t even remember to switch themselves to daylight savings. And then there were frequent bursts of pixelation and occasional “lost” segments of 1/2 of minute or so in the recordings. These didn’t happen on the live TV – only on the recordings. But being so new I put up with that and enjoyed it anyway.

My next was a Foxtel iQ unit. This was much better. The recordings were no different from live shows – perfect quality, reliably labelled, easily accessible via the menu system. The only drawbacks were that it wasn’t actually HD and couldn’t easily record anything from the TV channels with which they had no commercial agreement in place. Another small gripe ws that the unit remained on permanently, and was always very hot to the touch – not so great in this era of global warming and need to minimise power usage. But again, I really enjoyed using it. I only gave it up because I decided that Foxtel didn’t offer enough content of interest to warrant continuing the subscription.

The third was a Sony unit. This one was a bit of a dog, I’m sad to say. When you recorded a program, there was no title saved with it. So you ended up with a list of programs identified only by date, time and channel. Great if you have a photographic memory of the TV guide! And navigating its menu system was a mind-numbing process – being both slow and convoluted. But it did work most of the time. Eventually though it developed a bad fault. It kept freezing during bootup – at least once per day, and required a tricky 20 second button push to reset it each time. Either that or just pulling the plug, which was quicker but didn’t sit too comfortably with me. It was this ongoing problem that led to the fourth unit – the TiVo.

In many ways the TiVo unit is bliss. By connecting it to the home WiFi, it downloads two weeks worth of coming program listings. And the menu system (although still with its quirks) is, by comparison with some of the others, a pure delight to navigate through. It even records various programs speculatively based on your previous preferences, so if you don’t like anything thats on live, you can browse through a list of what it recorded for you, and you might just be pleasantly surprised to find something you like in there. If not, nothing lost. They just get recorded over whenever you need the space.

But – all silver linings have a cloud, and the cloud here was that it started to reboot spontaneously within the first week of acquisition. The first contact with tech support (submitted via online form on their website) was promising – they suggested it might be due to corrupted files, and gave instructions on how to perform a “severe error” scan, which could fix the problem. An extract from the (fairly lengthy) set of instructions was as follows:

Reboot and keep the TiVo remote pointed at the front of the DVR so you can be prepared to do the next step as soon as the DVR begins to restart.

As the DVR restarts, all four LED lights on the front bezel of the DVR will be on at the same time. As soon as all four go out,  immediately (within 2 seconds) press and hold down the yellow Pause button on the remote. (If you are unable to catch the timing, you may also hold the pause button down continuously during the restart until only the yellow light comes on.) When the yellow light comes on,  release the yellow Pause button and then press 57 on the remote control. (You will have approximately 10 seconds to do this.)

If the numbers have been keyed in successfully, the DVR will restart.

I must point out here that rebooting takes about 4 minutes. So I sat there for 4 minutes, watching like  hawk, waiting for 4 red LEDs to appear. But they never did. Not even 1 red LED. I tried several times. But still no red LED.

Well, this led to a few more exchanges with tech support, and eventually they sent a modified list of instructions:

As the DVR restarts, keep your attention fixed on the front panel of the Tivo. After approximately 5 minutes you should see the green light go out for a second and then come back on. Following this the yellow and red light will be displayed also. Hold the yellow pause button down for 2- 4 secs and then press the number “57”.

The box will appear to be restarting and then “powering up”

I’m afraid that one was a bit off the mark too… After about half an hour of experimentation I finally found out how to do it, and wrote back to them with my (rather different) findings:

1) About 1 minute after reboot (during transition from first screen to “almost there” screen, the green light very briefly goes off and on, and the yellow light comes on. If you press the Pause button while the yellow light is on, the red light will also come on, and you can then release the Pause and enter 57.

2) Following this, there is no sign at all whether or not it worked – it appears to continue booting as normal. But after 15 to 30 seconds it then starts rebooting.

Phew! After all that it worked. It is to TiVo’s credit that they said they would use my feedback to update their help system – but I pity anyone else who may have got the same set of initial instructions that I got from them…!

But – although the reboot and “severe error” scan completed successfully, another spontaneous reboot occurred – so back to TiVo support. This time the only solution was to exchange the unit for a new one. And this is where I started to become really impressed with TiVo support. Firstly they sent a brand new unit to me via courier – arriving the next day. Then they sent an empty package with a courier form, and in my own time I was able to place the old unit into it, call the courier company, who promptly collected it. All free of charge, all simple and straightforward. No need for me to revisit the shop, or take the unit to a repair centre etc.

TiVo – take a bow! Too bad about the glitch, and the inaccurate instructions initially – but they were responsive and kept at it, never blamed me for anything, and got the problem fixed. Now lets just hope this meme spreads a little. This kind of service deserves to be contagious.

Virtualizing My World on an iMac

Having recently acquired an iMac, I find myself torn between the familiar Vista machine I use as my development machine vs the slick, shiny, performance-enhanced 24″ iMac. And I am wondering if this is what schizophrenia actually feels like.

Its hard to let go of so many years of sometimes painful Windows-based experiences, and the feeling (no doubt totally illusory) that I have somehow “mastered” PCs, and am therefore  optimally productive when I use one. And on top of that is the fact that so many of my essential and favorite software development and productivity tools are available only on Windows. But I do need the Mac to build iPhone applications. Can you see my dilemma?

So the glaringly obvious solution here is to move fully onto the Mac, and run a virtual copy of Windows as and when needed for the Windows-only stuff. But will it fly? What are the pitfalls? Is it a pipe-dream? Well I guess its time to find out!

First I installed VMWare Fusion onto the Mac. Quick and painless. My next step was to install VMWare Converter onto the PC, and use it to attempt to virtualize the entire PC, including 80GB used disk space. This bit already seem rather ambitious to me. Firstly I wasn’t sure whether an 80GB virtual machine could run with reasonable performance at all. Secondly I was using a wireless 802.11g network which could be something of a bottleneck in moving the virtual disk image onto the Mac. The latter issue was easily overcome by using an Ethernet cable to link the PC and Mac directly (no hub) – although I could only get this to work after I switched off the wireless link on the Mac. But it did increase the throughput by a factor of 10 – so well worth the experiment.

I set up VMWare Converter to run on the PC, convert the physical machine into a Mac compatible VMWare virtual machine file and write it via the network connection directly into the Documents folder on the Mac. Well, off it went, and (after a couple of hiccups caused by me foolishly switching the wireless connection back on during the process, and having to switch it off again and restart) the full conversion and data transfer took about 2hrs for the full 80GB file to be placed onto the Mac.

The next step was to start up VMWare on the Mac, and see if it would run. I should point out here that I only had 2GB RAM installed on the Mac (to get a quicker delivery), with the intention of upgrading to 4GB later if and when I needed it. Now was obviously that time, but being the impatient and perhaps over-adventurous person that I am, I gave it a go after setting the VMWare allowance to 512MB for the Windows virtual machine.

I was gratified to see that it did (quite slowly) start up. However, there were some glitches. For example I was informed that there was no known driver for device “IDE01” – perhaps the fingerprint reader? But basically it worked. The only problem was memory usage. Despite having installed 4GB physical RAM, and allocating 2GB to the virtual machine, Activity Monitor showed that things were getting very tight with only minimal applications open.

So my next move was to install a new OEM version of Windows XP Professional as a virtual machine. This started up and ran just fine even with 500MB memory allocation. Ramping that up to 2GB should allow me to run all the apps I need at once.

So now all I have to do is install all the development tools and utilities I need and am used to. However I will only install what I really need on Windows, and start to use more and more on the Mac. That will all take a while though – so I will report back later on to see whether the dream is becoming a reality or not.