Journey to App - Part 4: Prototyping your App

We have covered defining the requirements for the App in Part 1, wire framing in Part 2, and App development tools in Part 3 of this blog series.  In this installment, I will discuss prototyping.

In my app development process, I use prototyping to quickly ensure that the key functional requirements of the app can be met.  Depending on the needs of the app, you will typically prototype portions of the "business logic" and the "user interface". The term "Business Logic" is used to describe the key functionality that the App delivers.  The term "user interface" is used to describe how the user interacts with the app to use the functions.

For the Webpage to PDF app, we have defined 3 "business logic" functions; receiving a URL and converting it to a PDF File, displaying and managing PDF files, and keeping track of the URL history.  Because the app is using the ChariTi app framework, there is less to prototype on the user interface side.  

When prototyping, the goal is to quickly program solutions for the function that you are prototyping, with a focus on learning how to solve the problem.  Once all the key elements have been prototyped, you will often need to revisit the prototyped code and clean it up, to make it robust, error free, and ready for a production app.

The rest of this post will cover the prototyping of the apps key functions.  As the prototyping proceeds, I'll update the post and update the source code on GitHub at http://www.github.com/timalosi/Journey2App

Receiving URL and converting to PDF

For this function here are the items that I want to ensure works

1. Make sure that the user can launch (or resume) the app from safari or chrome
2. Make sure we can display a web page that the user can interact with before converting it to a PDF File
3. Make sure we can create the PDF file from the web page that is selected by the user.

Passing the URL

In order to pass the URL, we need to create a URL scheme and register it so that the device knows what to do with it.  As we are starting with web pages, we can expect that the URL will start with http:// or https://.  

To make it easy for the user, we will register a few URL schemes.  We want something easy to remember, so we will use pdf://, pdfs:// as well as pdfhttp:// and pdfhttps://.  That way a user can go to the address bar in the browser and change the URL from (for example) http://fivebytes.blogspot.com to either pdf://fivebytes.blogspot.com or pdfhttp://fivebytes.blogspot.com.  When the device detects these URL schemes, it will launch our app, and pass the URL to the app.

To set up the URL scheme handler (in Titanium), we will update the tiapp.xml file and include the following XML snippet.  When Titanium builds the app, it will encorporate the XML into the apps info.plist file.

<key>CFBundleURLTypes</key>

<array>

<dict>

<key>CFBundleURLName</key>

<string>com.snackableapps.gopdf</string>

<key>CFBundleURLSchemes</key>

<array>

<string>gopdf</string>

<string>pdfhttp</string>

<string>pdfhttps</string>

<string>pdf</string>

<string>pdfs</string>

</array>

</dict>

</array>

Handling the Passed URL

When the app starts or is resumed, your iPhone or iPad passes arguments to the app.  One of the arguments is a URL.  Since we registered our pdf(s):// and pdfhttp(s):// URL schemes, we can expect that a URL may be passed to the app, and if it is, we need to convert it back to the standard http:// and https:// and then display the URL in a web browser.  In Titanium, when an app is resumed, an event is fired.  We will listen for that event, and look for a passed URL.  (We will only look for a resumed event for this prototype, but will have to handle a URL passed on launch as well when we finalize the code).

Converting to PDF:

The ChariTi framework comes with a pretty decent "browser" built into it, but the default Titanium web view doesn't support the conversion to PDF.  I have modified this web view as part of another App (sorry, this is the only component that I haven't open sourced in this app yet ... but http://github.com/viezel/NappPDFCreator is a very similar approach that is open source).  The reason, I am not using the NappPDFCreator module, is I want the user to be able to interact with the browser before converting, and NappPDFCreator simply takes the URL passed to it.  We will use a enhanced WebView to convert the URL to a PDF File and store it to the Apps document folder

Screencast of the URL scheme prototype on YouTube at http://youtu.be/uvHIS6TohAM

Managing the PDF Files

For this function here are the items that I want to ensure work.

1. Displaying a list of files that were converted
2. Allowing the user to view a file and perform actions (print / mail / send to another app)
3. Allowing the user to delete a file

Displaying the Files

Like a computer, the iPhone or iPad stores files in folders.  For us to display the converted PDF files, we need to know what folder the files are in, and we need to be able to read all the files and then display a list.  I have a file utility script that is a good starting point, but for the App, I will need to add a few functions, specifically, creating a directory, and reading the contents of the directory and passing back an array of files.  Check out the FileManager.js file in the /app/lib folder of the GitHub repository.  One of the nice things about Titanium is that you can easily create re-usable utility scripts that you can include in your app and reuse.  In general, if you are doing a "generic" function like creating or reading a directory, it is often best to spend a bit of time to create a reusable function.  As you write more apps, this will definitely save you time in the future.

Interacting with the Files

Once the files are displayed in the TableView controller, we need to "listen" for user generated events.  The two event that we would care about are the "click" event and the "delete" event.  All TableViews will generate a "click" event, but to receive the delete event, you need to enable editing on the TableView.  Setting up event listener functions for these events will allow us to display or delete the file based on the user's actions.

Screencast of the PDF Management Prototype on YouTube at http://youtu.be/N1MJ7-JtHHY

Managing the URL History

Similar to managing the PDF Files, prototyping the URL History functions will focus on:

1. Displaying a list of URLs that have been converted
2. Allowing the user to view the web page associated with the URL (and convert it again)
3. Allowing the user to delete a URL from the history.

Managing the URL History

For managing the URLs, I will duplicate the interface for managing the PDF files.  There are two main differences that I need to develop.  First, unlike the files, there is no representation of the URL history.  To solve this, I will create a Model Collection in Alloy.  This will allow us to store the URLs in a database for display.  The second difference is that rather than displaying the file, we need to launch the Web Browser with the URL that the user selected.  For this, we will modify the WebBrowser that was already created to capture the URLs as they are converted and to notify the display that the history has changed.

Screencast of the Prototyped interface for managing URLs at http://youtu.be/_ZBcybzJ8OU

Part 4 - Prototyping Summary
The prototyping for the Web Page to PDF App was pretty straight forward.  The App has just a few defined functions.  But the act of prototyping still has value.  In almost every development project, there is some aspect of the App that you haven't done before.  If the key functions of the App depend on something that you haven't done before, you really should prototype it.  It is much better to "fail" quickly than to put in a lot of hours on an App to find late in the game, that you cannot deliver a key function.

UP NEXT: Now that the prototyping is done, it is time to take a look at how the User Interface (UI) will need to change based on whether the user is running the app on an iPhone or iPad.

Running Total Hours

Activities

• Prototyping URL handling and converting - 1.5 hr
• Prototyping PDF file management - 1 hr
• Prototyping URL history management - 1 hr

Total hours to date: 7.5 hr

Previous Part 3 - Tools 
Next Part 5 - iPhone and iPad