Just a quick follow-up to a post I made a while back iPhlash or just a flash in the pan.

Well as I suspected Apple were not going to let this happen blindly!
Mike Chambers has just announced Adobe will be removing this feature due to Apple’s latest SDK terms.

In fact what is almost humorous about this is that Apple have forced Adobe into removing this functionality just before Adobe publicly release their upcoming “give me another $1000″ (CS5).

With Adobe’s announcement last week at Adobe MAX that they have added export to iPhone in an alpha version of Flash CS 5, there has obviously been a lot of discussion about this.

There are various strands of discussion, however the strand that interests myself is that of whether Apple will actually allow this.

Some background…

Apple have from the start had a very closed environment for developing iPhone applications.
Amongst many things:

• Developers must sign-up (and pay) for the privilege of being able to publish to the iPhone.
• Developers must use only documented API’s from the Cocoa API.
• Developers must not publish anything that can load in other code (eg a runtime such as the Flash Player, and this point has been the most problematic to Adobe).
• The only way to get an application onto the iPhone is by submitting it to Apple who check it conforms to all their rules before it goes onto the app store (which is the only way to distribute iPhone applications).

One of the reasons for this closed environment is so that 3rd party applications all look and work in a similar fashion, are all stable and wont interfere with other aspects of the iPhone.

The obvious problem for Adobe is that this means they cannot get the Flash Player onto the iPhone and Apple have not bowed down to the sometimes very public pressure Adobe have been putting on them to put/allow the Flash Player on the iPhone.

So what Adobe have done is found a way to allow its users to output native iPhone applications from the Flash IDE – therefore not requiring the actual Flash Player.
However, and importantly, these output applications are not Objective-C Cocoa Touch applications.
There is also as yet no information whatsoever from Apple as to whether this technique of bypassing the runtime is to be endorsed.

This last point is very important. Apple has historically been very tough when it comes to getting applications through their approval process. They have created an environment whereby they retain a very tight control of the applications that get onto the devices. And while there would be no actual Flash runtime on the device, there would be an ecosystem of iPhone development that Apple had much less control of.

The two biggest concerns for Apple would be a) performance and b) lack of look and feel.
Regarding performance, obviously to a large degree this comes down to the developer. But if the byte-code Flash spits out is of poor quality, then its down to the tooling (Adobe).
Regarding look and feel, this again in largely down to the developer, however Adobe is working on a mobile version of the Flex framework (codenamed Slider) and it would be highly likely many iPhone apps would make use of this and therefore not look and feel like iPhone apps but look and feel like Flash apps. And from a user experience perspective, this is very bad for Apple. Apple have always been keen advocates of precise and consistent user experience, as always reflected in their Human Interface Guidelines.

So all said, do you really think Apple are going to quietly let this happen?

I really hope Adobe are doing this with the full support from Apple. If this is the case, we have some great things to look forward to from Adobe. If not, well, just a flash in the pan.

Over the last month there has been quite a bit of movement in the ‘smart’ phone market.
We have Nokia’s eagerly awaited N97, the Apple iPhone 3G S and the news of the upcoming Android phone, the HTC Hero.
To top this off, we have a new version of Eclipse which has a package, Pulsar, aimed at easing J2ME development to multiple target devices.

So lets start with the Nokia N97…

I have been a happy Nokia user for some time. The N95 was in my view the best smart phone around. It ticked all the boxes for me. Then the update to N96, which was to be honest just a new-look N95, so still a decent phone. However, with the splattering of touch-screen phones now on the market, Nokia needed an update to enter this space too – the N97.
The pre-release photos and news showed a super looking touch-screen phone that also has a slide-out qwerty keyboard (very useful with a touch-screen phone for giant hands like mine).
However, first reviews are awful (here is one from The Register). From poor keyboard to poor display to poor build quality to poor software with lots of bugs. A real shame. If they had gotten this device ‘right’ it would have been a real contender in its market place.

The iPhone 3G S…

Well, to be fair, this is a well built device. The operating system is also pretty solid. Nothing mind-blowing added, well, apart from the compass that is. How did we all live without a compass on the Jesus Phone!
The most interesting thing is really the version 3 of the iPhone’s operating system which now has parental controls. What this equates to is Apple allowing the creation of ‘adult’ applications.

The HTC Hero…

This is important because it will be an Android based phone that doesn’t look like a geek phone (not that I personally dislike the look of the G1). It looks slick, has good specifications and hopefully will work well and be built well. Importantly it looks like Android will continue to spread.

And so finally Eclipse Pulsar…

It is well known in the J2ME development community how darn difficult it is to target multiple J2ME devices. Pulsar aims to make it much easier to install the relevant SDK’s and create Java based applications which target them.
I have yet to try this package out, but if it works well, we will likely make a move towards using it. More on this one soon.

The accelerometer in the iPhone allows for lots of interesting new methods of user interaction (here’s a good list of examples.)

We’ve recently been making an iPhone app which required a tilting back and forth mechanism — essentially the ability to ‘nod’ and ‘shake’ the iPhone. A tilt back and forth on the x-axis being a nod, and on the y-axis a shake (the app runs in landscape orientation.)

To watch for a nod or a shake, you can’t simply observe the present accelerometer values — you need to watch a range of them over time. Once you’ve got a set of data over time, you can do a bit of analysis on a particular window and see if it matches the gesture you’re after.

The free Context Logger app is very useful to watch the incoming data from the accelerometer and see what the data looks like for the gesture you’re after. For our gesture, a nod or shake, you get some kind of oscillating waveform. In an ideal world with ideal user interaction you’d get a nice
smooth sine wave with a fixed amplitude and frequency every time — not likely though in real life! You’re more likely to get some kind of triangle or saw wave with all kinds of bits of noise.

If you could really force the user to do one kind of nice wave for you, you could probably do a fourier transform to look at the incoming data and check for a spike at a certain frequency (e.g. suggestions here.) I do think there’s something to be said for forcing the user to conform to an expected input gesture — you can’t possibly capture every user’s interpretation of what a nod or a shake is — but at the same time you have to give a bit of leeway.

So in our case we tried to be more general. We simply watch for oscillations (ensuring the peaks are over a certain amplitude to ignore the low-level noise you always get) and if we get enough in our window on one axis we take it to be a nod or shake. We take an oscillation to be a change from a negative deviation from the mean of the values in our window, to a positive deviation from the mean, or vice versa.

One thing we’ve found in creating iPhone apps and running them on a Jailbroken iPhone to test them is that the directory fetching calls often return a different location from what you’d have in the simulator, or on an actual iPhone – and this target difference makes calls to file writing methods fail.

To get the Documents folder for your application, a typical place you’d want to write files, you’d call something like:

NSArray *paths = NSSearchPathForDirectoriesInDomains
(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *folderPath = [paths objectAtIndex:0];

And then would append your file name to the folder path for your calls to the writeToFile method.

Apple’s documentation states that these differ based on being in a Simulator or on an actual phone – on the phone:

/var/mobile/Applications/30B51836-D2DD-43AA-BCB4-9D4DADFED6A2/Documents

And on the Simulator:

/Volumes/Stuff/Users/johnDoe/Library/Application Support/iPhone Simulator/User/Applications
                                            /118086A0-FAAF-4CD4-9A0F-CD5E8D287270/Documents

However, with a Jailbroken iPhone, it tends to write in slightly less intuitive places – the version we’re using causes the call to return

/var/mobile/Documents

This directory doesn’t exist by default, so you’ll need to both create it, and also give permissions to it – this can be achieved through using mkdir and chmod

After that, your file writing should start working correctly!