Tag Archives: development

Can you do JavaScript development with just an iPad at hand?

I recently headed off on a five day vacation and though I do have my priorities in order (eat, see the sights, take photos, walk a lot, read a lot) there is inevitably some downtime as the days go on. I didn’t want to lug along a laptop on this vacation so I resolved to see if there was any practical way to play with AngularJS and Ember.js (two frameworks I’ve been interested in recently) using only my iPad and an inexpensive Bluetooth keyboard.*

iPad and Bluetooth keyboard

For those who wish to skip ahead, the short answer is that it is possible, but it’s not much fun figuring it out so I’ll tell you later how I did it. As for whether it’s practical, I don’t think I’d consider it for anything except a small test project and the reason why comes down to one simple thing: debugging. If you’re a modern JavaScript developer you’re used to wonderful tools like Firebug and the Chrome Developer Tools for debugging and while Safari on iOS once had access to some basics like the JavaScript console those have been removed from iOS 6 in favor of a new remote debugging method. The new solution relies on a remote connection to Safari on Mac OS X. I’m sure it’s a much more sophisticated solution but why did we need to lose all JavaScript debugging support on iOS to get it? If I have to have my Mac along to do debugging I might as well do the JavaScript work on OS X in the first place…

That leaves your only debugging option as Firebug Lite 1.4, a project which has basically been abandoned due to lack of funds or interest or something and when I tried to combine it with AngularJS I was never able to get it to appear within the browser. I had more success with Ember.js because it both appeared and showed all the console messages from Ember, however the script tab was unable to show me the contents of any of the JavaScript files I was including locally. Due to the slow performance of the wi-fi at my hotel I pulled firebug-lite.js, jquery, handlebars, ember, etc. all down to my iPad and put them in the same location as the index.html file and the main.js file I was editing. Due to some form of security restriction with how the files were being loaded into the local browser Firebug Lite was unable to show any of them to me.


That means that you’re going to be flying completely blind with AngularJS unless you’re prepared to handle logging via some other mechanism and even on Ember.js, are we really looking forward to something that’s reduced us to debugging entirely via log messages?


I promised that I would say what I found worked best for development work and it was Textastic. It will let you create directories, fill them with files, edit them, and then view them with a built in instance of the iOS browser. It’s simple and straightforward and I was able to paste in sample AngularJS and Ember.js pages and they worked just great. I just couldn’t ever debug them properly. It does cost a few dollars but if you’re just looking for some easy way to play with HTML, CSS, or some simple JavaScript when all you have is an iPad (and hopefully a paired keyboard) then it’ll do in a pinch.

BTW, Cloud9 IDE looks like it would be an even better solution to this problem but they use the Ace editor and for whatever reason, it doesn’t work well on an iPad. I had problems with cursor position being one place while actual editing was another, it didn’t want to work well with my keyboard, it seemed slow, etc. There needs to be some work done on either the editor itself or on the iPad browser (or perhaps both) to make that a more viable solution.

Textastic - Ember.js plus Firebug LiteP.S. Most of this blog entry was written on the self same iPad/keyboard so don’t think the iPad is useless for any form of content creation, it just doesn’t do software development well at this time.

* Specifically a third generation iPad and the AmazonBasics Bluetooth Keyboard.

Easy background images for your iOS views

On an iOS game I’m developing I wanted a background image on some of my views. That’s an easy thing to do in the interface builder by simply adding a UIImageView stretched to the full extents of its containing view. However, I’ve layed it out for the four inch form factor of an iPhone 5 or the equivalent iPod Touch, how will it react to the form factor of an iPhone 4, 4S, or the older Touch?

The answer is that thanks to Auto Layout your controls can be made to adjust quite nicely, however, you’re going to have some issues with that image. By default the image view adjusted its size to the size of the containing window and squeezed my background image. Ick.

The fact that you may have two versions of the image, one Retina and one not (that is, background.png and background@2x.png) doesn’t save you because there are older devices that have both Retina displays and smaller screens. What you need is a solution that works with 4″ Retina, 3.5″ Retina, and 3.5″ non-Retina screens.

The background.png isn’t an issue. It should only come into play for non-Retina screens and to my knowledge there are no four inch non-Retina screens. Go ahead and just lay it out for 320 by 480 and be done with that one. Then, if the background is one where you can design a version that can safely lose 176 pixels in the long dimension (via a border or other area that can be safely clipped), then lay out a background that is 640 by 1136 with 88 pixels at the top and bottom that will be clipped off when it is viewed on the smaller screen. Then you can change one small setting on the image view so it will center and clip the image rather than squeeze it and you’re done.

The background image as it would appear on an iPhone 5 (640 x 1136).

The background image as it would appear on an iPhone 5 or similar 4″ Retina device (640 x 1136).

The same image automatically cropped top and bottom as seen on an iPhone 4 (or similar Retina device with a 3.5" screen).

The same image automatically cropped top and bottom as seen on an iPhone 4 (or similar Retina device with a 3.5″ screen).

The mode setting that makes it work. By default it's set to "Scale to Fill", change it to "Aspect Fill" and it will keep the width full but center and crop the image.

The mode setting that makes it work. By default it’s set to “Scale to Fill”, change it to “Aspect Fill” and it will keep the width full but center and crop the image.

Two images + One setting = Something that gives you easy backgrounds for all small iOS devices

But, if that’s not cutting it for you, there’s another choice. Have a third image ready. iOS has naming conventions for images (you saw some of them above with the @2x) that helps them load the right image for Retina or non-Retina and iPhone/iPod Touch vs iPad. However, they didn’t include a naming convention for the different form factors of 3.5″ vs. 4″.

So an alternative is to load a different image specifically for the Retina 3.5″ and let the non-Retina 3.5″ and Retina 4″ be handled automatically by the image naming conventions. Here’s some sample code that could go in the viewDidLoad to override and load an alternate image:

- (void)viewDidLoad {
  [super viewDidLoad];

  // Do any additional setup after loading the view, typically from a nib.

  // We're relying on automatic loading of background.png and
  // background@2x.png to handle the non-Retina 3.5" devices and the Retina 4"
  // devices.
  // So we're manually detecting Retina 3.5" devices and loading a special
  // image just for those.
  if  ((UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) &&
    [[UIScreen mainScreen] scale] > 1.0 &&
    [UIScreen mainScreen].bounds.size.height != 568.f) {
      [self.backgroundImageView setImage:[UIImage imageNamed:@"alternateBackground.png"]];