DigitalNeurosurgeon.com

Last week Apple introduced the iPad, a tablet device in the middle between iPod/iPhone and MacBook computers. Immediately there were many responses on the web, both positive and negative. Let’s start with the funniest one that touches the topic we’ll discuss in detail.

A comment that kept coming back in many reactions, is the lack of Flash support. Whether the topic is 8 Things That Suck About The iPad or iwantflash.com, the message is the same as the blogs from Adobe people like Serge Jespers and The Flash Blog: Flash should be added to the iPad!

But should it? Apple’s official comment after iPhone release has been that Flash was too resource consuming, and for a phone that comment has been accepted. In the meantime anyone who has been following the App Store development and Steve Job’s keynotes knows that the App Store is a lucrative initiative, and allowing websites to display Flash-based games (especially games) will reduce Apple income. All right, that’s business, isn’t it?

The Apple iPad has been described as “impossibly fast” with Apple’s own A4 processor. BBC has high expectations of the new device, as has The Guardian. And from a medical perspective, opinions are mixed. John Halamka, CIO of Harvard Medical School, is in doubt about the success in healthcare, doc2doc is more negative. The same can be said for Healthcare IT Squad.

What is my opinion, as an IT-minded medical doctor? I am looking forward to the iPad, but in the first place because I want an affordable color-enabled e-reader for scientific literature. Second, this e-reader (or iReader, as you want) is programmable to perform tasks. Which could support guideline implementation. Whether you call this e-guidelines or clinical decision supporting systems, is up to you. As long as we both know what we’re talking about.

Is Flash necessary for that? No, but it would help. I fully agree with the excellent post of John Nack, and as a Flex-developer I definitely would like to program in Flex and ActionScript. I am really not fond of Objective C, it’s unneccesarily complicated. Who needs a separate @interface and @implementation?

Adobe’s initiative of the Open Screen Project is good. Even better, I think it is very good, and I am glad that companies like Google, HTC, Nokia and RIM are supporting it. On the other hand, depending on the sort of application, Flash may be just “too much”. I work on a new MacBook Pro model, but remaining battery really goes down if I have some Flash sites open. As much as CPU usage and core temperature goes up. So it perfectly understandable that the new mobile Firefox will disable the Flash plugin as the default setting. Reason: too much energy consuming. Although Mozilla offers a good alternative: you can choose to enable it, but then on your own responsibility.

So I do have some suggestions for developers, Apple and Adobe.

To developers: I have high expectations from Adobe’s Flash Player 10.1 in combination with the Open Screen Project. I think Adobe’s technologies are very promising, targeting almost all devices, except the iPhone and the iPad. For those latter two, you have alternatives besides XCode. Flash CS5 will provide export as native iPhone apps, OpenPlug’s Elips Studio 3 seems a fantastic tool for Flex developers who want to do iPhone development, and there is always the alternative to keep apps purely web-based. This skips the App Store, which you may like for reasons described on O’Reilly Radar here and here, as well as on Adobe’s Flash platform blog.

To Apple: you make wonderful hardware and software, and in the first place I think it is your right to determine how you want to incorporate your software on your hardware. But for the future, I think you do need to offer people choices. You have been criticized for coupling the iPhone to just one telecom provider, and you had to let go of your strict criteria. Don’t make countries create laws for open and accessible platforms. Offer people choices. If you want them to pay for that, that’s your right. But let them choose. Look at what Firefox did, and learn a lesson. Allow people to install Flash on their own risk, of wich decreased system performance might be the major one for badly designed websites. These are included in the web experience you promise us on the iPad, but that’s not delivered now.

To Adobe: stop whining. If Apple decides not to offer Flash, that’s too bad for all of us, but let’s find an alternative then. Your CS5 iPhone efforts and OpenPlug’s efforts show one opportunity. Google Web Toolkit (GWT) shows you the other. For the App Store, converting ActionScript code for rich media content to Objective C is the best you can do now. Focus on that, because Apple will allow native iPhone apps in the App Store. Of course. For web content, find a way to do the same with ActionScript that GWT does with Java: convert it to HTML, CSS and JavaScript. That won’t work for everything, but I think that many decent Flex apps could work this way. Then you can win the battle: rich media content goes the the App Store with a separate notice on the website, if viewed on the iPhone. Flex-driven apps can be translated “a la GWT” and are visible as well. Maybe with some inconsistencies due to different browsers and JavaScript versions, but that’s still beter than no Flash (or no up to date Flash) at all.

So to answer my own question: bashing or flashing the iPad? Neither of both! Looks like a nice iReader+ to me, with basic web capabilities and some iPhone features. One that’s fast, has no booting time, and with a large screen. And one that runs Papers! That’s not bad, is it?

It took me some time before I had it working: automatically resizing an image in the iPhone’s UIWebView component.

I want to load the image in a UIWebView instead of a UIImageView, as I get all the multitouch functionality (especially zooming) automatically included. Suppose this is my interface (.h) file:

1
2
3
4
5
6

@interface TestImageStretchViewController : UIViewController {
	IBOutlet UIView	*imageView;
	IBOutlet UIWebView *imageWebView;
}
// ... rest of interface content including function (IBAction) declarations
@end

Now, in my first version, I loaded the image directly in the UIWebView with the loadRequest instance method:

1
2
3
4
5
6
7
8
9
10
11
12
13

/*
 ** Display image in UIWebView using loadRequest
*/
- (void) showImageWithLoadRequest {
	// Create URL request for image file location
	NSString *imageName = [[NSBundle mainBundle] pathForResource:@"test_image" ofType:@"png"];
	NSURL *imageURL = [NSURL fileURLWithPath: imageName];
	NSURLRequest *imageRequest = [NSURLRequest requestWithURL: imageURL];
 
	// Load image in UIWebView
	imageWebView.scalesPageToFit = YES;
	[imageWebView loadRequest: imageRequest];
}

This works fine, but with one disadvantage: the image is displayed smaller than its actual size. If the user double taps on the screen, the device fits the image to the size of the UIWebView. Why can’t I do this automatically? I tried setting the UIView’s autoresizingMask property to UIViewAutoresizingFlexibleWidth, but this did not solve it. I also tried setting the UIWebView’s scalesPageToFit to YES, but again: no difference. The only difference I found, is when scalesPageToFit is disabled, double tapping does not make a difference: the image remains small.

The solution came after reading this forum item on iPhoneDevSDK.com. The idea is that UIWebView cannot determine the size of the image, this has to be provided in HTML code. So the suggestion was to use loadHTMLString instead of loadRequest, and to set a value for the width of the image in HTML.

1
2

NSString *html = @"<html><body><img src='http://www.domain.com/path/to/your/image.jpg' width='100%' height='100%'></body></html>";
[webView loadHTMLString:html baseURL:nil];

In my case, this was not successful, but it did offer the key to the solution. I found that setting the width to 100% did only work when scalesPageToFit was disabled. This was not what I wanted to do, because this disabled zooming as well. So -arbitrarily- I set the width to 900 and I got great results for all images (charts) that I use in the SLIC app. Funny value, because I expected that 320 should be fine (the iPhone’s width resolution), but this was too small apparently.

So here is how I do it now:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/*
** Display image in UIWebView using loadHTMLString
*/
- (void) showImageWithLoadHTMLString {
	// Create URL string for image file location
	NSString *imageName	 = [[NSBundle mainBundle] pathForResource:@"test_image" ofType:@"png"];
	NSURL	 *imageURL	 = [NSURL fileURLWithPath: imageName];
 
	// Create HTML string from image URL
	// Width-value is arbitrary (and found experimentally): 900 works fine for me
	NSString *htmlString = @"<html><body><img src='%@' width='900'></body></html>";
	NSString *imageHTML  = [[NSString alloc] initWithFormat:htmlString, imageURL];
 
	// Load image in UIWebView
	imageWebView.scalesPageToFit = YES;
	[imageWebView loadHTMLString:imageHTML baseURL:nil];
}

Mission accomplished! :-)

Apple is really driving me crazy with their provisioning profiles. This means that the iPhone application I am developing will get some delay in being publicly available. So far the bad news, there is some good news as well.

After an interesting conversation I recently had on artificial intelligence (AI), I started looking at my book on Prolog again. Nice, but Prolog needs a software environment to do its work. And as far as I have seen, Java seems a nice choice. All right, C++ as well, but for some reason I prefer Java (hint: memory management….).

It turns out that the book “Objects First With Java” is an excellent work on teaching how to apply object oriented programming (OOP). I read many books on programming in different languages, but never fully grasped the OOP concept. This one may change that situation. I would not recommend the book for a beginning programmer without a coach, as the book’s pace is rather high. I must confess that I do not use BlueJ but the NetBeans IDE. I really like the book’s approach to introduce classes and objects directly in the beginning, even before real code comes in. It helps to change your mindset from procedural programming to OOP; the code comes later.

I am looking forward to improve my OOP skills, and get some hands-on feeling with AI programming.

After the discussion in this blog post I decided to follow your advise and keep the summary-section in the old format. For a technical reason I used the other approach in the Background information part: there is an issue with the width of the screen, I am not able to use it completely. In the current approach it is not too disturbing. For me, it’s fine for now.

The main change is that the Background part does not contain HTML anymore (I used to display it in a UIWebView) but it is just a table with plain text now. The reason is only related to speed of data entry: this is much faster! I expected some advantage of the UIWebView approach when I chose it, but it made things rather complicated. Not anymore! ;-)

Click for large version

As you can see in the image, I added a category checklists, on which I will come back later. I think it might be the most important category in the app. There’s even a chance that it might be the only category in the final app (with the rest as some form of subcategory).

As I re-entered clinical practice now, I am discovering some issues in which I want to have help. If I can build it into the iPhone, I will do it if it improves the quality of my patient care. So stay tuned, I expect more to follow during the next 1-2 months on this.

In my previous post on the SLIC scale for subaxial cervical spine injury I posted some screenshots within my iNeuroMind iPhone project. However, this scale is that important that I think it deserves a special app – and orthopedic surgeons might be interested as well.

I needed to find out how to work with the iPhone’s plist format in setting up some kind of decision tree mechanism that I earlier used on other mobile devices. Done! Adding some nice visual effects, and all possibilities from the iPhone, and you get a result like this (click for large version):

SLIC decision supporting system

There we go! The autorotation component is supported as well, and will remind you of the original SLIC scale in case you cannot remember it by heart (like me). I still need to implement the actual decision trees, but at least the technology behind it is working now as it should.

Actually, I am quite proud these days! I managed to get my first iPhone app working in the way I wanted. Now I can expand its content!

Continue reading »

Finally! I have some screenshots available from my first iPhone application. It is working in the simulator and on the device itself. My license for Apple’s Developer Program has been accepted.

Continue reading »

After the previous experiments with Flex 3 and ActionScript 3.0 I also wanted to take a closer look at development for mobile devices. Why not target the most fascinating of them, which is the one I am using for the last year: the iPhone!

Continue reading »

I wanted to use Apple’s Cover Flow technique for a future e-learning application about neuropathology. After some initial frustration, I have it working now!

Continue reading »

Sometimes I like to use abbreviations in NeuroCards, to prevent the text getting too long. Now I’ve added a tooltip to the text panel. If you meet an abbreviation that is in the list, it will automatically show you what it means.

Continue reading »