Developing for the iPhone is the hype nowadays. However, one big obstacle that faces anyone who wish to write iPhone applications is learning Objective-C. After all, it is a high-level Object Oriented language. However, in my point of view, and for many people as well, the C family of languages is not suitable for application development. It is perfectly suited for writing system libraries and frameworks. This is because one should always take care of memory management, types and low level system calls.

Thats why we are here, quoted from the Jiggy official website:


What is Jiggy?


Simply put, Jiggy is the easiest way to create applications for the iPhone (or iPod Touch). With just Jiggy and a browser, you'll be able to write an awesome iPhone application in a matter of minutes. JiggyApps run natively on the iPhone, so there is no messing around with HTML and the limitations of Mobile Safari. At the same time, you don't need a compiler or even a Mac, because JiggyApps are written in JavaScript.


When you start writing an application with Jiggy you will find it very simple. However, as your application grows it will be so hard to maintain. Thats why I am writing the following guidelines, which if followed, will help you write large-scale, neat and maintainable Jiggy applications:




  1. Don't use the Jiggy IDE, prepare your development environment around ssh.
    If you already installed Jiggy on your iPhone, you will probably have noticed that there are 2 packages your are installing. First one is called Jiggy runtime. This is a set of dynamic-link libraries that encapsulate all native functionality. These are installed in the library path of the system (/usr/lib) and start with the prefix jiggy, as an example: jiggy.UIKit and jiggy.sqlite. The other package is called just Jiggy. This is the Jiggy IDE I am talking about. It is just an application server built on an HTTP server. You run it from SpringBoard, open a browser on your PC and point it to the iPhone IP to get the IDE working inside the browser. This is the simplest way to develop Jiggy applications. You only need a browser. Running into big applications, you will soon find that the browser is never meant to be a reliable IDE. It WILL crash more frequent than you expect. It will leak memory to the ground. It will freeze for seconds as you save and run the application. Moreover, to work on multiple files simultaneously, you have to open several tabs/windows. You can use this IDE as a fast boot but when you eventually develop seriously you need a more reliable environment. Install OpenSSH on the iPhone (but be careful if you need to change the root password). Next, mount the iPhone filesystem using sshfs:

    sshfs root@IPHONE_IP /mount/point -o allow_other

    You can download sshfs from its official site or if you are using Debian/Ubuntu by:

    sudo apt-get install sshfs

    or if you are using Gnome use the menu Places/Connect to Server... and select server type as SSH. Write the iPhone IP and root as the username. A shortcut will be placed in Places and on the desktop. Either way, you can browse through /Applicatoins/ and point to your application folder then double click on any Javascript file to edit using your favorite editor. I personally use gedit or vim. Just a note, be sure the iPhone is mounted before editing the files or the editor may get confused and hangs.

  2. Distribute required runtime libraries along with your applications, don't assume Jiggy runtime.
    These can be found in /usr/lib as discussed earlier. During the installation process, don't copy the libraries in the system /usr/lib in order not to conflict versions. It is safer to leave them in the application directory. By the way, I didn't try leaving them in the application directory yet :) On the contrary, you may prefer to distribute the libraries through Jiggy runtime. However, be very clear in the installation steps.

  3. For a more stable and collaborative environment, use a code repository and deploy on device as needed.
    When your code-base grows over time, you will discover that it is safer to use a code repostiory (Subversion of CVS). This will also enable you to share the application with other developers. Now you don't have to mount the iPhone filesystem using ssh as you will not be editing files in-place. You will have a working copy on your PC which is linked against some repository. Each time you need to run the application you will have to copy files over the iPhone, you can write a small shell script to do the copy commands. Till the time of writing this line, Jiggy is only available for the iPhone OS 1.x which has no official SDK or emulator from Apple. If Jiggy is ported to iPhone OS 2.x it would be easier to run applications on the emulator without the need of copying files on each run.

  4. Avoid using off-the-shelf libraries (prototype for example), you don't need larger useless interpretation times.
    Usually you won't need fancy mechanisms or drag-and-drop and alike functionality. If you need to use AJAX, write your own prototype-alike around the XMLHttpRequest object. If you are too lazy to write it, see mine.

  5. Don't start the application from SpringBoard (if you don't have to). Start it from an ssh terminal instead.
    Some functionality won't work if you don't start the application from SpringBoard (like the accelerometer). If you don' have to, ssh to your iPhone and change to the applications directory then launch the jiggy binary:

    ssh root@IPHONE_IP
    cd /Applications/MyApp.app
    ./jiggy

    This is a must if you need to see useful log messages from Jiggy native implementation. You can also write your own logs straight from Javascript using the global function log(). See my other post for a discussion on logging in Javascript platforms.

  6. Optionally generate a public/private ssh key-pair so that you don't have to enter ssh password every time you login to your iPhone.
    See the OpenSSH page or this good tutorial.

  7. Keep your main.js as small as 10 lines or less.
    This is always a rule-of-thumb for all programming paradigms. The general flow of the program should be readable by anybody. Throw away your implementations inside classes and throw these classes inside files other than your main.js. Even more, I do NOT write any flow in my main, its just a logic switch, or program selector:


    8. // main.js
    try {
    //include("test1.js")
    //include("test2.js")
    include("myprog1.js")
    }
    catch(e) {
    log(e)
    terminate()
    }

    Whenever I need to test any code or run any sample code, I just throw it in a file and switch to it in my main. When I am finished I uncomment back the original program.
    The try/catch is there to bust silly alerts that appears on-screen which if not dismissed normally by user, will freeze the SpringBoard.

  8. Create a test-harness because you will need to try various things first.
    You may create a new application for the sole purpose of testing code. Create any testing code in new files and switch between them in main.js. This way you don't need new applications each time you try any code. See the code of main.js in previous point as an example.

  9. Make your files self-contained, don't assume any implicit dependency.
    In Jiggy, there are 2 types of code dependency. First is Plugin dependency where you depend on a native plugin (Jigglin). Second type is Javascript dependency where you depend on other Javascript files. As an example for the first type, if you use the package Images don't assume that the UIKit plugin is loaded. In the beginning of the file check if it is not loaded and load it accordingly:

    if (typeof Images == 'undefined')
    Plugins.load('UIKit')

    Current Jiggy implementation does not check for loading same plugins more than once, and hence the check above.
    As an example for the second dependency type consider this:

    include('another.js')

    And in another.js put the inclusion guard which I borrow from C/C++!

    if (typeof __ANOTHER_JS == 'undefined') {
    __ANOTHER_JS = 0
    // write all your Javascript code here
    ...
    }

    10. This inclusion guard is recommended although not mandatory because re-interpretation of code may cause undesired logical errors.

  10. Use a central include path because you are going to make/use reusable components.
    Sticking to the Object Oriented design will render many parts of your code reusable. The straightforward way to reuse the components is to copy them over through different applications. However, you will be changing them frequently and you need a central place for them. You may place them in a separate directory and create symbolic links inside your application folder. I wish I could have time to patch Jiggy source so that it looks in a central include path if it does not find the file in the application directory. Did I hear someone offering help?

  11. Always remember the restricted memory resources, cache on disk if necessary.
    Don't write code that aggressively allocates memory. Don't let your arrays grow indefinitely. If you need large data-structures let them write their data on disk if they exceeded some limit, using sqlite if needed. If it is all about memory cache, let older values drop altogether.

  12. Don't forget your friend, the garbage collector (GC), you may know when to call it better than the engine does.
    Let the code be smart and invoke it in places where you are sure many objects have been released. Each time you release an object, or return from a function, increment released objects count and invoke the GC if it reached some limit. The AutoReleaseCache and ImageLoader are perfect examples for restricted memory management and garbage collection. There should be a global GC function when using them. Here it is:

    var GC_TRIGGER = 40
    var releasedObjectsCount = 0
    GC = function(force)
    {
    if (force || releasedObjectsCount++ > GC_TRIGGER) {
    releasedObjectsCount = 0
    log("-----------------------------------------------")
    log("running gc")
    log("-----------------------------------------------")
    gc(1)
    }
    }