In the Sept/Oct 2011 issue of CODE Magazine, I wrote about Xiine for Android. Let me remind you that Xiine is an electronic reader application for CODE Magazine. It was originally written in C# using WPF and is based on SOA architecture. With this software, all subscribers (it’s free) can read CODE Magazine issues on a PC. You can download Xiine at http://www.xiine.com.

Xiine is popular for digital content. There are desktop, Web, WebOS, and of course, the Android edition, which is now being distributed by Android Market and Amazon Marketplace.

There was one platform missing, though: the iOS version. That's the reason we decided to write Xiine for iOS and share this new experience. Because CODE is a magazine, the same version should be supported on both the iPod Touch/iPhone and the iPad.

Xiine for iOS was CODE’s very first Apple project and we passed through some roadblocks.

We wanted the users to have a good UI experience, just like the Android version so we made a list of goals:

  • Authenticate Xiine users.
  • List available brands and respective issues.
  • Make clean and intuitive screens.
  • Display user information.
  • Enable reading articles.
  • List already read articles.
  • Zoom in and out on an article page.
  • Save a history of what has been read.
  • Use up minimal code-writing time.

What Went Right

Because we’d already done a lot of technological work, this project seemed fairly painless.

The Architecture

We took advantage of the existing architecture for the Android project.

The architecture is very simple (Figure 1):

Figure 1: The architecture for Xiine service is simple.
  1. Apple devices access the REST service at xiine.services.com, requesting a JSON object.
  2. The REST server responds to the device, which understands the JSON object and converts it into real information.

/

Creating a Similar User Interface and Re-using Code

The login screen on the Android version should be similar to the iOS version. Due to different resolutions, it's not possible to be exactly the same, but we could have the same simplicity and functionality: Enter the user name and password.

After the log in, the user can see the available brands (see Figure 2). The iOS version is much the same as the Android page and shows the title and description on the list.

Figure 2: These are available brands as viewed on the iPhone.

/

After the brand is chosen, a list of magazine issues with complete information is displayed when a magazine is clicked (Figure 3). It’s a little bit different on the iOS version, but not much.

Figure 3: This is a list of magazine issues on the iOS.

/

Like logging in and choosing a brand, there is minimal difference between the Android and iOS versions for choosing an article from the list.

There wasn’t much work to do to write the code for the interface because we could base the iOS on the Android code that already existed.

Because we already had the Android version, we didn't need to worry about layout and how the objects would fit in different screen resolutions. We already had the layout set and even though Objective-C was a brand new language for us, it was learnable.

Because we already had the Android version, we didn't need to worry about layout and how the objects would fit in different screen resolutions.

Just like when we built the Android version, the usage of the JSON library was one of the most important parts of the project, as all the information needed was available from a WCF service. Also, we had already made the changes needed for the Android version, so we didn't have to touch a single line of code!

Easy Tools

X-Code is easy to use even if you’re new to it. It includes a complete set of tools to run, build, and debug programs.

Like Android, iOS has SQLite built in. And although SQLite is not a professional database, it does what it says it will: It stores information. It's also very easy to configure and use. Because it's a light version, you don’t have to worry about special field types. The most complicated type is the BLOB, and even that is straightforward. We used SQLite to store the history feature.

Local and Remote Repositories

Mercurial is a local repository where you can keep track of changes. You can get specific versions, commit, delete, merge, and so forth.

BitBucket is a remote repository, where you can store and share source code to everyone or to a specific group or person. X-Code source code was easily stored on BitBucket, just like the Android version.

Using the iOS Emulator

Unlike the Android emulator, X-Code has an awesome emulator! It is fast and reliable. You might wait at a full minute to start debugging on Android emulator, but X-Code launches and runs the emulator instantly.

Things That Went Wrong

Okay, so nothing’s perfect. There were a few things that might have gone better.

Gotta Get a Mac

If you want to write applications for iPhone/iPod touch or iPad, you need to have a computer that runs Mac OS, although there is a way to emulate the Mac OS on a PC. We have tried this emulation method and it works. But it doesn't have all the same features as the real thing and it is not very stable. It freezes once in a while. And because it's an emulation, sometimes it was really slow. So we had to buy a Mac.

Coding

Coding was the largest roadblock because Objective-C is not C#. We were very tempted to use alternative tools such as MonoTouch, but decided NOT to because most iOS developers don't and this it would have been non-standard iOS development. Also, there were some legal issues regarding the use of this tool in the past.

Coding was the largest roadblock because Objective-C is not C#.

Pagination

Just like the Android version, iOS does NOT support pagination natively. This means that everyone interested in making multiple pages must write a new engine. Unfortunately, that’s not an easy task to accomplish and it’s one of advantages of the desktop edition that was written in WPF (Figure 4).

Figure 4: The paging system of Xiine for the desktop.

/

Memory Management

It’s not that the memory management didn't go well. But we did need to be careful when using variables or instantiating objects. Unlike C#, we had to allocate and de-allocate memory manually. Objective-C doesn't have a garbage collector and the software can crash if you don't de-allocate properly or if you forget to release an unused object.

Testing on Various Devices.

One thing that didn’t go very well was distributing among various devices before publishing to the Apple store. We wanted to test the application on different devices, such as iPhones 3G, iPhones 3GS, iPhones 4, and iPads, but ran out of time looking for an easy way to do it. In order to test on a real device, we had to attach a personal iPhone and iPad to the Mac and deploy directly there. We were pretty sure that we wouldn’t have problems running the application on other devices, but we weren’t 100% sure about performance. There’s a website (https://testflightapp.com/) that explains how to use a free service to test iOS applications, but we ran out of time to dig into that.

Summary

Using existing services was a big deal! We could take advantage of the whole service for either the Desktop or Android version to build features without having to write any extra lines of code on the server side.

The iOS itself has a large knowledge base easily available from the community. We found libraries, samples, and code to run HTTP calls, consume REST services, handle JSON objects, etc. In the beginning, we thought the iOS development would be hard to learn and understand - not so! Because C# was the primary language, memory management was one of the biggest challenges, because your system can crash if you don't handle it appropriately.

We are now certain that we can implement exactly the same features on either Android or iOS. Each has different ways to accomplish the same results, but in the end, it will hit the target.