iOS Tutorial

I just released the first version of QwikTime for iPhone and I want to tell you about what it took to get this product out the door in a short period of time.

QwikTime is a time capture software for the Legal Industry. It was originally written for Blackberry smart phones and it allows its users to enter time while on the go. Time entries captured on the smartphone can be submitted for final review and posting in the enterprise’s time recording system if a network connection is available. When the time recording system is not reachable for any reason, time entries remain cached on the handheld .

Requirements For The iPhone Client

In order to build a version for iPhone fairly quickly, I went through the list of features available in the BlackBerry client and picked only the ones that are essential for the application to exist:

Ability to manually create time entries on the phone through a simple and easy to use interface.
Ability to store time entries on the phone, either for later review, or when an immediate upload cannot succeed due to an unreliable connection.
Ability to modify or delete entries cached on the phone.
Ability to upload time entries to the time recording system on a server behind the firewall.
Ability to download lists of recent projects, activities and actions that can be used to populate a time entry’s fields.

Reusing the Server-Side Software

I didn’t have to worry about the server-side piece because I am reusing the server software my team wrote for the BlackBerry version. This considerably reduced the effort needed to ready the iPhone client.

UI Prototyping

Knowing what features were going in this version, I used Balsamiq to create mockups of the screens or views of the application:

Writing the Source Code

The minimum requirements and UI mockups gave me a good idea of what I needed to do code-wise. I conceptually broke the source code into three distinct pieces: user interface, data model and network connectivity, and started writing them.

The UI piece was first. It takes care of displaying a few table views and dialogs, and controls the navigation from one view to the next. I found the UI so simple that I chose not to work with Interface Builder. Being used to writing BlackBerry code without a UI designer also helped me feel comfortable and I did not miss Interface Builder at all.

Next, I created a few classes representing the data model: time entries, matters, activities, actions and a few more. I also wrote some CRUD routines that operate against the on-device cache of time entries, recently used matters, activities and actions.

When the data model was ready, I connected it to the UI and was able to run the application with all its functionality, except the network calls, which I coded last.

The challenge when writing the network code was that I could not work with background threads like we are used to in the BlackBerry platform. But I quickly learned the alternative approaches and found myself enjoying writing the networking code as well.

Wrapping Up

I’m very happy with how QwikTime for iPhone was built. A list of essential features, focus on simplicity, and reuse of existing assets resulted in a nice product that was put together in a very short period of time. The app is now being evaluated by a few users and I expect to get helpful feedback really soon.

What do you think? Are you writing or planning to write mobile applications? Want to share your experiences?

An issue that too many times goes overlooked is the possibility that database queries return more data (rows) than what your application can handle.

It is typical for applications to send a query to the database and process each row of the result set. Often times, this processing is accompanied by the creation of a data structure (list, collection, etc.) that holds a one or more business objects derived from the query results.

Unbounded result sets are a threat to your mobile application

Do you know what would happen if your mobile application sent a query to the database and received a million rows instead of a hundred? Or if it made a request to a web service and received a collection with ten thousand objects? A cause of countless problems on application servers, unbounded result sets are also a threat to your mobile applications. Given the memory and processing constraints in mobile devices, paying attention to this issue is of particular importance.

Result sets without bounds are more likely to occur when your application makes a request without specifying what type of response it can accept and how much of it can process. You are also asking for trouble when your application blindly trusts the systems it calls, database server included.

An ounce of prevention…

So, what are some of the measures you can take to prevent the occurrence of unbounded result sets?

Limit the number of retrieved rows. If you have control over the data access code, limit the number of rows you retrieve in your queries. Remember Murphy’s_Law. Even when you know that a table will never have more than fifty rows, write your SQL code so it retrieves no more than fifty rows.

-- MySQL
select client_id, client_name from clients
limit 50

Limit the number of elements in retrieved collections. Design your web services routines so they accept a parameter indicating the maximum number of elements you are prepared to process.

int maxNumberOfClients = 50;
List<Client> clients = service.GetClients(maxNumberOfClients);

Break out of loops. When looping over elements of a result set or a collection, break out when you reach the maximum number of elements you can process. Although this measure does not avoid the retrieval of all the results, it stops the pernicious effects from propagating to other areas of your application.

int clientsCount = 0;
int maxClients = 50;
foreach (DataRow clientRow in clientsTable.Rows) {
    Client client = Client.FromDataRow(clientRow);
    clientsList.Add(client);
    clientsCount ++;
    if (maxClients == clientsCount ) break;
}

Conclusion

I hope you find this helpful. As usual, let me know your thoughts!

The Making of QwikTime For iPhone