txeet is now available for iPhone

txeet has been approved by Apple and can now be downloaded from App Store!

Pitfalls of NSFetchedResultsController

I have recently used one of the most useful framework in iPhone 3.0 – CoreData.

There are many guides on using CoreData, such as from cocoadevcentral or Apple’s guide. But what I found lacking is that there was no discussion on the pitfalls of using CoreData, or its view controller, NSFetchedResultsController.

I learnt the pitfalls along the way, and there are 2 particular pitfalls that I would like to share with developers while developing txeet for iPhone.

1. Performance hit with predicate using one-to-many relationship

When using NSFetchedResultsController, we would often form our predicate (like SQL) to retrieve some table rows.

If you were to use a predicate that involves transversing a one-to-many relationship, the performance could be slowed down tremendously (as slow as 30 sec to run, or even crash!). Take for example a Template model that has a one-to-many relationship tags to Tag model:

The predicate above would require transversing to each Tag to find ‘love’. This is computationally very expensive.

The solution to this is to avoid transversing relationship. A faster way that CoreData could execute is to access the properties/attributes. For the above example, what I did is to add another attribute tagsAsAttribute to Template model. This property would store the tag names in a delimited format such as “;love;jokes;quotes;”. The predicate would then be changed to:

Note: This is not the best way to design the data model, as tagsAsAttribute has a dependency and is redundant.

2. User-driven updates

If you read the Apple’s guide to NSFetchedResultsControllerDelegate, please note of the section User-Driven Updates.

In short, if you have user-driven updates, you should write the following as the first line in every (only one is shown below) of the NSFetchedResultsControllerDelegate delegate methods:

And when there is a user-driven update, set the isStillUpdating boolean to true, and set false when the update is completed.

User-driven updates could be re-ordering of table rows, or inserting of objects.

SG 4D has added 20 years of 4D results!

SG 4D (mobile website) has added many more years of past 4D results!

Previously, the system has only results since Nov 2006, but now it has since May 1986! The mobile website has also added a date field (ddmmyy) for you to search for a draw easily.

If you have SG 4D app on iPhone or Android, please wait for the next release that exploit the 20 years more of 4D numbers

Did you know?

Singapore Pools 4D betting was computerised on 31 May 1986, and it got off an auspicious start with the first prize number coming out as 8838 (“8” is auspicious for chinese).

iPad keynote in 180 sec

Spare yourself watching the 1 hr long iPad keynote.

This is better, and it shows that if we repeat the same thing over and over in a presentation, the audience will bound to believe..

What are you working on?

Some of you might be wondering – what are you working on? Is there new releases of SG 4D, SG Toto, SG Wireless, or some other new app?

txeet, is what I am currently working on.

In Oct 2009, txeet was first released on Android. Thereafter, I have been working on an iPhone version. This screenshot is a preview:

In Feb 2010, the first version for iPhone should be released. I’ll pray hard, to Apple for its release..

SG 4D – Mobile website for all phones

This is a little secret. I have created a mobile website for 4D results at http://sg4d.just2us.com/

There is nothing special about it, other than that it was built with Google’s App Engine. Running on Google’s infrastructure and servers has its bonuses – Google ensures stability, performance and scalability.

Hey AppVault! You copied my Broken Apple graphics!

Late last night, we found out that AppVault has added a all-too-familiar-looking Broken Apple to their website – because AppBox complained that AppVault was too similar and infringed on their copyright. Here is the original website from AppVault:

But if you go to the website now, you would see the below instead. Spot the differences?

Hmmm.. they took away MY BROKEN APPLE graphics! I am fine with you infringing my copyright, just give me due credits, can?

@AppVault, can you not silently drop my case? You don’t just remove an infringed material from your App Store blog just because you can :p

SG 4D is no longer in Top 100

SG 4D was first released in Oct 2008. Since the first day it was released, it has been in the Top 100 free apps (in Singapore App Store).

But in Jan 2010, SG Live 4D was released. This 4D app is developed by another company (not by me). It is the fastest and coolest (reading the numbers in Hokkien?) 4D app in the app store. And therefore, it kicked out SG 4D from its throne

 
The new 4D app by Live4D

Ah.. but that is how the consumer market works.

When there is a better product, users will eventually flock to it. Even better if it is free. Take the case of Google’s free vs Nokia’s paid on the mobile. Nokia is taking action only because of tough competition. If there isn’t any competition, Nokia would continue to charge $$ to users. There is no reason not to earn..

Back to SG 4D. I am sure end-users will get better app when there are more choices. No doubt.

The Wonderful World of Ovi Store (Ad)

This a good commercial ad to Nokia’s Ovi Store.

The ad is good, but Ovi store is still inferior to Apple’s App Store.

How I do mobile application testing

There are a lot of guides to general software testing methodologies, but there is a lack when it comes to testing for mobile apps.

Through the years I had with mobile application development, I have formed a habit of sort. It was always a undocumented habit, with improvements along the way.

When I read about QA without unit testing, it struck to me as a familiar process and methodology and I have used.

Therefore, here is my documented habit on how I do mobile application testing.

1. Unit Testing

Unit testing is the most frequently mentioned type of testing in software testing. That is because it is automated, and it is a good modular test on the methods/APIs. But a lot of time and cost could be wrongly spent on unit testing.

Instead, I choose to only do extensive test cases for very isolated and error-prone methods. And for all others, I would have only a few simple test cases, which serve more for the purpose of demonstrating how to use the methods.

Unit testing should be minimal for mobile application development, as a lot of mobile code comes from view controllers, which are unsuitable for unit testing.

2. Sanity Testing

Sanity testing refers to testing the normal scenarios. It is use cases that normal users would encounter when using the mobile app. It includes the user interface that users would see and interact with.

Manually testing of each of the test cases is needed, and it is very important that these test cases and their steps are documented. A tester must follow the documented steps.

3. Monkey Testing

Monkey testing covers the abnormal scenarios, or extreme cases. It is cases where a user would try to do unusual things with the app.

It is also essential to document these unusual test cases, but the steps need not be rigidly documented.

Moreover, the tester should test like a monkey, trying to break or crash the app.

4. Performance Testing

I always keep in mind:

Engineering is about doing the best you can with limited resources

And mobile phones have very limited resources. It is very common to see mobile application crash or slowed to a crawl due to unforeseen scenarios that depletes resources.

Performance testing is to test and ensure that the mobile app will stand the test of time..