We’ve submitted the first update of iSEND today. After working very hard on the update we finished the programming and testing last night at 2:00 am. The update addresses the picture display problem and includes also enhanced data transfer speeds, some interface tweaks and a startup help screen. We’ll let you know as soon as the new version of iSENDu becomes available in the iTunes Application Store.
Your ikangai team
After fixing the image rotation bug, we decided to make a proper update and we added a few new features. However, this proved to be a bit more difficult than expected. We encountered a well known problem in computer science, co-called race condition. Simply put, this happens if two or more processes access and update a common resource and this update leads to inconsistencies. This is typically difficult to debug, because debugging itself might change the execution of the program by introducing execution delays. This can either lead to a race conditions or not – it’s a bit like the famous Schrödinger’s Cat.
As you can imagine, fixing such a bug is not easy. In the case of iSENDu we experienced this when sending large amounts of data using bluetooth from one iPhone to another iPhone. The data receiving iPhone used a progress bar to indicate the overall progress of the data transmission while the sending iPhone did not. As a consequence, the receiver spent a bit more time on processing the data (and updating the progress bar). In the meantime, the sender continued to send the data at unchanged speed which lead to conflicts at the receiver (data was received before the data was processed and the receiver simply crashed). The funny thing was, that this behavior didn’t occur always and the insertion of debug messages in the code only made things worse and even less predictable. We noticed that if there are a lot of debug messages on the debug screen, the execution of the application gets slower. As we understood it, the main reason for this is the low level implementation of the delegate method
- (void) receiveData:(NSData *)data fromPeer:(NSString *)peer inSession: (GKSession *)session context:(void *)context
This method is called if data from another peer arrives. There is no buffer and data arriving to fast can lead to application crashes – at least we experienced such a behavior. One solution is to implement a raw data handling buffer that waits until all data has arrived. The other solution (as we did it) is to implement sender and receiver in the same manner (both showing a progress bar).
We will investigate this issue further and keep you posted about our findings. Sample code will be available as soon as we’ve submitted the new version of iSENDu.
Your ikangai team
In a longer session (well into the early hours of the morning), we managed to resolve the problem concerning the display of images in iSENDu. Yep, we did it! We will update iSENDu as soon as the Developer Connection is available again, which should be the case on December 28th.
The bugfix includes some additional graphical tweaks and as well as a new feature.
Your ikangai team
Merry Christmas from the ikangai team! We hope that you enjoy the holiday season and have a good time!
Your ikangai team
An interesting article was postend on Gizmodo yesterday. It was about the Apple way of preventing leaks using – euphemistically speaking – harsh methods. We don’t if this is true, but after our own experiences with Apple we tend to believe this kind of things could really happen at Apple….
Another, Apple hardware related story was posted here. It’s about Israeli security officers, putting several bullets into a Macbook during a security check.
Your ikangai team
