Displaying PDFs via the iPad

Tue, 24 Aug 2010 12:57:40 +1200

I used the iPad’s external screen output for the second time today (the first was trying out Chopper 2 with the TV as the screen and iPhone as controller) - this time not just as an experiment. I have a set of revision worksheets (all PDFs that I inherited many years ago - I might have Word documents somewhere, but I’m not sure where). Going over the questions in class, I can simply read the question out loud (but people don’t listen well enough and can’t ‘go back’ to it), or write it on the board (slow, handwriting code is problematic when you’ve got messy writing), but ideally it’s projected. The classroom does have a projector - in previous years I’ve hooked up my aging laptop and put the PDFs up to see. My hope was that I could use the iPad this year (since it’s meant to be replacing the laptop in most circumstances). The first problem is that I don’t have an application that shows PDFs that will use the external screen (e.g. iBooks ignores the external display). This is pretty annoying, and I hope it gets changed with an update in the near future. It’s not hard to imagine a business meeting where everyone has iPads and wanting to show a PDF that has been created (an advertisement, a manual, etc) to everyone at the meeting. Basically the only application I do have that will use the external display to show a document is Keynote. So the next step was creating a Keynote document with the same content as the PDFs. The next problem that arises is that I can’t copy the text from the PDFs on the iPad (not in iBooks, and not in Stanza, which is the only other PDF reader I have installed). I could see it perfectly well, but there was no way to extract the text. I hope this changes too. Just enabling select+copy in iBooks would be great. It’s not hard to imagine use cases here, either: select text, copy it, and tweet a quote from a document. (Ok, there are DRM issues with books, but just do something like leave out “select all” - even just enabling this for PDF would be ok). I resorted to using the laptop. I copied the PDF content to a PowerPoint (no Mac here to use OS X Keynote) document, and then (via Dropbox, since I don’t have a computer to sync with here) and opened it in (iOS) Keynote. The final steps, which did work, were very nice. I formatted the slides using Keynote (very simple, didn’t miss a mouse or keyboard at all), including inserting a few images via Safari. When the time came to use the slides, the projector accepted the iPad’s output without problems (although the position and location of the cable meant that the iPad was in an awkward location - buying the Keynote Remote application and using an iPhone/iPad Touch would have improved that). (For some reason, I couldn’t get the “laser pointer” functionality working at the time, although this has worked fine when I’ve tested before. I didn’t really need that). Overall, it’s a pretty good experience if you already have Keynote (or PowerPoint) material. It’s a pretty terrible experience if you have something else (e.g. code!) that you want to display. Thankfully, that can be addressed in software - even in third-party software.

D520 - Week Six

Mon, 07 Sep 2009 21:31:20 +1200

Chapter 6 of IronPython in Action covers “properties, dialogs, and Visual Studio”. This seemed an obvious place to insert the material on user-interface design that is normally covered in the course, and to look a bit more deeply than the textbook does at Visual Studio itself (and the Windows Forms controls and their properties). I only scheduled a single week to cover this, but I suspected that it might take more than one (I left an empty slot in the schedule to cover one such over-run), and that was, indeed, the case. The students received notes [PDF], slightly longer this week (covering the UI design material not in the textbook, as well as the usual chapter summary, key points, and examples, and the steps required to install IronPython support in the ‘Experimental Hive’ Visual Studio SDK), and a fairly simple lab exercise [PDF]. The recommended reading for this week (which I didn’t get a chance to mention, but is listed in the course material) is a very light-hearted comparison of different programming languages (somewhat old, so the students probably don’t actually know many of these, but I like the underlying truths - I guess I should have tried to add languages like Ruby, PHP and Javascript myself) and a Wil Shipley article about the fast/good/cheap trade-off. I really enjoy Shipley’s style of writing, but even if I didn’t, I’d include this article: the point about there being many dimensions (brevity, features, speed, time, robustness, flexibility, …) and that you can’t have them all is really important for starting developers to understand. However, even more than that, I really agree with Shipley’s contention that you should always start with brevity. The first half of the class is straight from previous offerings of the course (although a little condensed), and is basically just a 90 minute talk about user-interface design, aimed at non-designers. As previously, I use the points from Tog’s First Principles of Design as the outline, although I talk about more than just what’s in the article (and only skim over some parts of it). The course isn’t really about UI/UX design, but it is an important element, and I try to emphasise it in some way each week (and many of the recommended reading articles are about some sort of UI/UX design). For the two projects, the students will have to complete not just a development design document, but also a UI design, including an explanation of why they made the decisions they did. Historically, this is notoriously badly done for the first project, with most students (despite my emphasis when outlining the project, and giving them a marking schedule) submitting nothing more than a screenshot of a Visual Studio mock-up. For the first project, all I really need to see is that they’ve considered something, rather than just thrown things together - by the end of the course, I expect that they should be able to put something together that is a reasonable UI. There has historically been an examination question on this topic as well - something along the lines of “outline three important considerations in user-interface design”. The biggest issue was in installation - again! I carefully tested running through the installation on a clean copy of the Windows image they have. It was slow (so I recommended doing it before coming to class, and planned to kick it off at the start and only start using it a couple of hours later, after the UI talk), but worked fine. I forgot, however, about the Northtec proxy server that blocks so much Internet functionality. There were basically three steps required to get the “Experimental Hive” version of Visual Studio running with IronPython (1, unfortunately) support: install Visual Studio 2008 SP1, install Visual Studio 2008 SDK, compile the IronPython sample. The Visual Studio SP1 installer is one of the “stub” installers that are popular in some circles - i.e. it’s a very small installer that then downloads whatever is necessary to complete the installation. While there are some merits in this approach, it doesn’t work well in all situations: this was one of those. It seems that the service pack installer only support proxies that provide auto-discovery, which the Northtec proxy does not. That left two alternatives: force the students to download and install the service pack (many hundreds of MB) outside of the lab, or use the .iso version of the SP. I downloaded the .iso (830 MB!), and that installed without problem in the lab. However, I don’t really have a convenient way to distribute files of that size among the class (generally the files I provide are quite small) - if I had realised this in advance I could have had it added to the file server, but that wasn’t really feasible in the time available. I had to fall back to copying the files on to a USB drive (1GB, so max’ing it out) and distributing them via sneakernet. Figuring out all of this (around the actual teaching) took most of the class, so when I left I had only got this far (i.e. halfway through step 1 of 3). The SP installation should be trouble-free (but will probably take 30-60 minutes), so the students should have that done by next class. We’ll continue with the SDK installation (~120 MB standard installer) and IronPython compilation at that point. Next year, I’ll make sure that SP1 is installed on the image, side-stepping this whole problem (I hadn’t got to testing software installation when the images were created this year, because I knew that I wanted the students to do installation themselves). Of course, I could be really lucky, and Visual Studio 2010 might include built-in IronPython support. We were able to use Visual Studio in the method described in IronPython in Action, however (creating class libraries in Visual Studio and subclassing in IronPython). I think the students found this less appealing that I do - moving the generated .dll around was problematic for some of the students, for example. I suspect that even though using IronPython directly in Visual Studio is problematic (e.g. stuck with IronPython 1) many students will elect to do that. To me, properties seem a bit like decorators and lambdas, in that they are slightly advanced Python, and perhaps a bit ahead of where the students generally are in D520. However, we certainly covered properties in Visual Basic, and the fundamentals are the same, really. The MultiDoc example was very useful here, in that it uses properties to implement observers, so there was a practical use for properties, rather than the toy examples that are often used in explaining why you’d want to hide your attributes behind getters and setters. I think that the students understood the general idea. As part of this, I briefly covered the observer pattern, as outlined in the textbook - perhaps it’s just the work that I’ve done, but I come across observers all the time, so I tried to get across the importance of this idea. My plan at this stage is to find somewhere in the schedule where I can insert an “Advanced Python Refresher”, where the students can take another look at decorators, properties, lambdas, and anything else that comes up along these lines. I doubt many (maybe any) students will use these techniques in their projects, but I do expect that they’ll feature in the final examination - and will probably be a good indicator of the good programmers (those that really understand programming and might end up doing it professionally) versus the good students (those that put in enough effort to get through, but are really suited for other IT jobs - sysadmin, testing, managing, etc). Chapter 6 has nicely thorough coverage of the very versatile MessageBox, but it’s not really overly complicated to use, if you have a list of the icon and button options available (as in the book, or on MSDN). Since we’ve seen MessageBox a few times already, I skipped over this material, focusing instead on the custom dialogs. The chapter also has a section on serialising in .NET - the students are already familiar with the pickle module, so this is really just a .NET version of something they already know. I originally intended to cover this next week, but if time is short again, I might just skip it completely (since they can easily use pickle instead). We ran out of time before I could really go over the MultiDoc code from Chapter 6, so I left that for the next week. The lab exercise was just redesigning the Airline application used in earlier labs. There were two aims here - firstly to get the students to try out the various controls that are available (it’s easier to explore in Visual Studio, even if you end up using the controls in hand-written code). Secondly, the students must design their projects, including the UI, and submit that design. This doesn’t just mean ‘sketch the UI’ - it means consider and explain the reasons behind the UI decisions - hopefully the lab started students on the road to doing this properly in the project.

Problems on Tony Andrew Meyer

Displaying PDFs via the iPad

D520 - Week Six