As most of my friends know, I got an iPad.

Upon announcement of the device, I thought it was a pretty stupid product–simply an oversized iPod Touch with no excuse for omitting Java or Flash Player. Then I began to consider the possibility of it being a portable drawing tablet. I figured I’d get a Pogo Sketch stylus, try it out, and if it didn’t meet expectations I could sell it on eBay at a profit to someone in some foreign country still waiting for it.

After a week or so of using it, I must say I love the iPad. It’s replaced my iPhone in cases where I want to casually search online, and typing is much easier than I expected (though I miss the tab key), which has yielded the device to being an adequate and lightweight replacement for my laptop. I still think Apple’s blockade of Flash is childish, but you can’t win all the time. Onto the comparison!

Before I get into the pros and cons of the iPad, let’s look at the current options available for artists interested in illustrating digitally:

• PC tablets. Expect to drop a good $1,500 for a full-fledged computer here, not including software (I’m talking about stuff like the Dell XT2).
• Wacom tablets. I use mine every day, but there’s a slight disconnect between drawing on the tablet and following what’s on-screen.
• Wacom Cintiq. Yes, I’m spoiled, as I happen to have one of these. They are incredible, but not mobile–and not cheap ($2,000).
• Modbook. Turn your Mac into a Cintiq. Reviews have mentioned the performance to be slightly buggy, and again, it’s not cheap ($1000+ on top of the laptop cost).
• Mobile phones. A little too small of a screen for serious consideration, if you ask me.
• HP’s upcoming Slate or Microsoft’s upcoming Courier tablet. the key word here is “upcoming”. Sadly, these products might as well be vaporware until official release dates and prices are announced (I should probably mention that I’m skeptical of hardware in which the operating system wasn’t built from the ground up with touch and gestures in mind).

Screen comparison

For starters, the Cintiq is a resistive screen, whereas the iPad is a capacitive screen. Resistive screens recognize pressure, while capacitive screens register touch (unfortunately for us artists, capacitive is what’s “in” so our options will remain limited).

The winner? Cintiq by a mile. While using the iPad, I was easily frustrated with the bottom of my hand creating marks while I wanted to draw. I also found myself intuitively attempting to apply pressure as I drew, which, of course, didn’t matter with the iPad. Granted, the workaround is to continually modify stroke weights in conjunction with brush opacity, but it’s simply not on par with the Cintiq.

To the iPad’s defense, I will say that Apple typically chooses the best screens on the market (Samsung?) and is known for having some of the best capacitive screens.

Price

No brainer here. The iPad is much cheaper.

Stylus

You can draw with your finger on the iPad (but not the Cintiq), but regardless, drawing just feels more natural with a stylus. I went out and purchased the Pogo Sketch (slightly longer than the regular Pogo Stylus, since it’s for prolonged use) for use with the iPad. The tip of the stylus is much bigger than Wacom’s pen, and I believe this is due to the fact that the iPad requires a bigger imprint to register input.

I really didn’t like that Sketch on the iPhone, but it’s much better on the iPad (this may be due to the faster processor). Drawing requires more pressure than what feels natural, and I still don’t like how pressure can force the nub around (I’m always worried the aluminum will end up scratching the glass, though it never does). Unfortunately, unlike a Wacom pen, the Pogo cant have another tip on the opposite side that can be programmed as an eraser. In the end, it’s a workable device, though not as natural as the Wacom pen due to the thick tip.

Software

I’d actually call this a tie. The iPad doesn’t have Photoshop or Painter, but I’ve found Autodesk’s Sketchbook Pro ($8.99) to be a perfect substitute that can export layered PSDs. Of course, there’s also Brushes, as well as several other drawing apps available. I hope Adobe Ideas works in new features in the future, as it currently is the only iPad entry to allow for Flash-like vector drawing.

Conclusion

In conclusion, I’d disclaim to artists to not fool themselves into thinking that the iPad is a replacement for a Cintiq, but I’d definitely recommend the iPad as a drawing tool. Its portability paired with its affordable price eclipse its shortcomings, and despite some minor usability issues, the iPad has really impressed me as a drawing tool.

To paint a picture of my stance, I will say that:

1. I hope open-source OGG format replaces Flash video. Flash has standardized a ubiquitous video format for the Web, and it’s wonderful evolution we can’t deny. Gone are the days of multiple encodings for Quicktime, Real Player, and Windows Media, and I doubt supervision excluding a for-profit company would have succeeded. That said, I think the Web has evolved, and the fact that HTML 5 has dropped OGG as the definitive format is a politically-driven mistake. We, as the creators of the Web, should be embracing an open video format.
2. I’m not an Adobe fanboy. Flash provides a format of expression unlike any other, and while I admit that Flash work is my bread-and-butter (and that I’m coincidentally wearing Adobe-branded apparel as I write this), I recognize Adobe is a company that answers to its shareholders. Frankly, their Open Screen Project and claims of Flash being an “open” platform register strictly as propaganda to me, and I felt the need to point out this stance because of the opinions I’ve encountered at some Adobe user groups.
3. I don’t believe HTML 5 is the Messiah. I support universal formats that ensure consistency between browsers. However, formats, while well-intentioned, don’t always reach the Web–they are ultimately dictated by the market. If that wasn’t the case, we’d all be discussing XHTML 2.0 instead of HTML 5 and be visiting .MOBI sites instead of using Webkit on our phones.
4. Flash isn’t going anywhere. Flash is used for more than just the Web–it’s great for standalone applications, and its games can’t be successfully emulated with HTML + JS. Furthermore, it allows for data without browser refreshing, and provides a more media-rich interactive experience. Regarding standards, see #3.
5. I want to see Flash Player on the iPad and the iPhone, but I believe this responsibility falls to Adobe.

I think something many in the Flash community fail to realize is that Flash Player doesn’t play well on mobile, and it’s not exclusive to Apple products. I know firsthand, as I considered purchasing a Nokia N900 as a result of Apple’s embargo. I checked out Flash Player 9.4 on the N900′s browser while stopping in at NYC’s Nokia Store, and the performance was nothing short of atrocious. YouTube videos were so choppy that they weren’t viewable, and simple Flash sites crashed the browser.

I should mention that the N900 is powered by the same ARM Cortex-A8 processor as the iPhone 3GS (the 3GS is underclocked to 600 Mhz). Sure, there are videos of Google’s Nexus One playing Flash Player 10.1, however, I wouldn’t be surprised if the Nexus One’s Snapdragon 1 GHz processor is concealing Flash Player’s inherent memory issues.

Reinforcement for this argument is Mozilla’s decision to drop Flash Player support for their mobile Firefox browser just prior to launch. I’m still amazed that this hasn’t garnered as much press as the iPad announcement.

This brings me back to the title of this topic–the Future of Adobe Flash.

Personally, I wonder if Adobe might have lost its way. Their community support is excellent, and I use their industry-standard tools every day, however, they’ve seemingly become obsessed with supporting a proprietary platform instead of focusing on building excellent tools, and their evangelists seem to point outward for blame rather than looking within. As I mentioned in #5, I want to see Flash Player arrive on all of Apple’s products, however, I think this falls upon Adobe improving the player’s performance. As for my predictions:

1. Flash Player goes truly open source and somehow gets included in the HTML 5 spec. Sadly, this is unlikely, as Adobe licenses proprietary video codecs for HE-AAC and h.264. More importantly, it’d likely affect Adobe’s bottom line.
2. Adobe publishes an API for Actionscript that supports gestures. Gestureworks is already providing this, and Adobe’s not far behind. Personally, I’m holding my breath for official Flash SWF support.
3. Adobe starts building applications that publish content for HTML 5 and mobile platforms.

Obviously, #1 and #2 are less predictions than #3, but I think it’d be refreshing for Adobe to begin exploring these new mobile outlets as opportunities to provide new software. Can you imagine a software that publishes iPhone, Blackberry, and MeeGo apps–without doing translations from Flash? Now that would truly be interesting . . .

Furthermore, my iPhone wasn’t being recognized by iTunes. Coincidentally, this happened to me right after a friend on Twitter was complaining about the issue.

Here’s a solution I found to get iTunes to recognize your iPhone again:

1. Quit iTunes
2. navigate to System/Library/Extensions and delete AppleMobileDevice.kext (you may be prompted to enter your admin information)
3. Restart iTunes

Pretty simple, but here’s the official word from Apple Support, in case you want it.

1. The First Step: Choosing a Target Device
   • Good Advice: Start with a Base Build, then port (advice via Adobe dev article)
   • Covered Adobe Device Central
   • Check out the MOBI developer guide

2. Creating a Flash Lite Application
   
   • AS2.0 support – Flash Lite Language Reference
   • No _global.setTimeout();
   • fscommand2
   • Toolkits
     • Oxygen
     • Shuriken

3. Flash Lite Memory Issues
   • Garbage Collection runs a little differently
   • Runs every 60 seconds or when application memory increases by 20%
   • Use fscommand2(“GetFreePlayerMemory”) to check memory on specific device
   • Garbage collection can’t be triggered
   • Explanation of Dynamic Heap
   • Inherent memory leak with attach/removal of MovieClips
   • Memory Management by the book
   • Chumby has 8 MB of memory, plus widget refresh
4. Optimization Techniques – a Few Tips
   
   • Design
     • Determine target hardware
     • Minimize font usage
     • Use _sans
     • Avoid bold, italic
     • Don’t embed fonts—consider bitmaps
     • Find a balance between bitmaps and vector
     • Don’t compress movies
     • 12 – 15 fps
   • Actionscript
     • Simplify your code
     • delete or null objects no longer used. No
       need to do this on instance/method level.
     • Clear listeners
     • Condense package structure
     • Avoid inheritance
     • Minimize Math, String parsing
     • Test on actual device often!
5. Deployment
   
   • Bluetooth
   • Nokia Device Browser – a little-known yet handy tool
     
   • Adobe dev article: Creating SIS Files Manually
     
     • Uses makesis and Symbian SDK
     • Strictly places SWF in appropriate
       directory for Flash Lite standalone player to find file
   • Adobe dev article: Making Launcher + Icon
   • Installers
     • SWF2Go
     • Swf2Sis (discontinued in 3^rd Ed.)
     • Free Installers
       • Janus
       • KuneriLite
   • Web Runtime Widget (WRT)
     • Overview
     • How to package a Flash Movie Widget Tutorial
     • See my previous blog post on using a meta-refresh from MainHTML to avoid focus issues
6. Resources
   
   • Adobe’s Mobile Site
   • Forum Nokia
   • Engadget Mobile (for mobile industry news)
   • Flash Mobile Group (based in Boston, has listserv)
   • Sony Ericsson’s Flash Lite Site
   • Nokia Tips and Tricks
   • Adobe’s Wiki
   • http://blog.pikkle.com/
   • http://www.biskero.org/

7. Flash + Mobile’s Future
   • iPhone
   • Open Screen Project
   • Adobe AIR

I just posted Blackjack4All as a Web Runtime Widget for Nokia S60 devices as well as the source code under BSD license. It’s by no means 100% bug free, but served as a fun little learning exercise. Take a look.

• Download Blackjack4All Widget
• Download Source Code and FLA

If you download/run/play with the code and come across bugs please inform me so that I can correct and revise the files (better yet, fix them and share!).

I should also mention some of the challenges with developing in the WRT format. In the beginning, I was seeking a way to easily deploy my application to end users, didn’t want to spend the money on a 3rd party application like SWF2Go, and wasn’t satisfied with Adobe’s article on SIS installers or using Carbide.

I based my development on this post on Nokia’s Wiki and soon discovered several issues with the directions contained here. For one thing, the example provided doesn’t have any interactivity, and if you attempt to embed the SWF into the MainHTML page I found that the SWF has trouble receiving focus. This nearly made me consider doing some sort of JavaScript-to-SWF communication similar to this post.

According to the Wiki article, an alternative method to embedding the SWF is to modify the info.plist manifest file and set the MainHTML key as the SWF file itself. The problem I discovered when attempting this technique is that Symbian doesn’t interpret the SWF file properly and instead presents a blank white screen with an arrow cursor (as is discussed here). Setting the “MainHTML” key as an SWF file didn’t sound right to me, and the documentation of this Nokia S60 Widgets PDF reinforces what I thought. This PDF outlines the supported properties of the info.plist and also mentions that an HTML file is required.

Ultimately, I concluded that the best way to both solve the focus issue and satisfy the HTML requirement was to create a MainHTML file in my widget and place a meta-refresh tag that redirects to the SWF file. If you want to see how this is done, download the BlackJack4All widget, rename the extension to .zip and decompress the package.

Hopefully, some of you will catch this post and it’ll save you some time.

Ever since I ordered my Nokia 6682 I told myself that I was going to build a Flash Lite application for it. I purposely ordered an AT&T plan to subsidize the $600 phone cost and even paid Macromedia the $10 download fee for Flash Lite. The funny thing about working for yourself, though (and perhaps it’s the industry in general), is that you never make time for personal projects–regardless of all the personal promises and financial stability to do so.

Two years later, Macromedia is now Adobe, The Flash Lite player is free and is often pre-installed on phones (thank goodness), the latest Flash Lite Player version is 3, and I’ve since given away my 6682 and replaced it with an N95 North American edition. Oh, and I finally made the time to play around.

I decided to build a simple Blackjack game. After reading about Flash Lite’s processing limitations, I chose something rather simple. I initially intended to release the code for free under a BSD license, but have discovered the hurdles involved with Flash Lite deployment (they were hurdles I always knew to be there, but sometimes one  just needs to learn firsthand). I also considered inviting artists to create artwork for the playing cards, although I’m not sure it’s so worthwhile considering how small the cards are and how intensive bitmap caching is.

So, this will serve as Part I of an ongoing series of my experience working with Flash Lite. By the end of it, I hope to create some helpful resources for someone and possibly proceed with releasing the software for free.

Oh, and If anyone reading this is interested in learning more or testing our the beta application (and happens to have an S60 device with Flash Lite 2.1 player), I’m happy to provide it.

I’ve spent my free time learning the Objective C programming language, Apple’s Obj C-based Cocoa framework, and the iPhone SDK. It’s these subjects that drew me to the iPhoneBarCampNYC this past week in Brooklyn. I ended up leading a discussion on Objective C (me–up in front of a group–scary, I know).

Taking the time to learn all of this is a big gamble for me. North American demographics aside, I’m willing to bet that the usability of the iPhone will solidify its share in the marketplace and make it worthwhile to learn how to build applications for it. On the other hand, there are some counterpoints I consider:

1. Cost of Entry. Dropping $400+ on a cell phone is a bit much for most of the population. Furthermore, being forced into a single carrier (AT&T) is a turnoff even for me.
2. Lack of Standards. Sadly, this is what is making it so difficult to do things in the industry. Building a mobile application means building for niche audiences.
3. Lifestyle. Smart phones aren’t for everyone, nor will they be for a long time–if ever. Some people just don’t need all those features. Heck, I’ve noticed that when I’m back in Harrisburg I barely use my smart phone’s features (although having the Web anywhere definitely changes your life). Bottom line, the bells and whistles of mobile phones are tailored best for the commuting lifestyle.
4. History. Let’s not forget that Palm and Symbian OS came long before the iPhone. I think the iPhone’s usability will peak a more varied demographic of users, but am eager to see if anyone doesn’t reinvent the wheel.
5. The Web. Has the Web replaced the Mobile software industry? Are mobile applications dead as Michael Mace suggests? Is it worth building an application over and over to support different hardware when it could all just piggyback off of the Web and its standards?

As far as what I’ve learned so far–

• I wish Apple would have provided some extremely simple examples along with tutorials in their SDK. The existing examples are great, although their Hello World application is a bit more on the complex side.
• The MoveMe application example in the SDK seems out-of-date, making it a bit hard to follow.
• The SDK videos are complementary knowledge. It’s much more helpful when you have the basics of Objective C down first.
• As the I Hate the iPhone SDK blog points out, Interface Builder has very poor documentation. I’m leaving it alone for at least another version.
• I bought two books–the iPhone Open Application Development (Zdiarski) and Programming in Objective C (Kochan). Apple provides Obj-C 2.0 resources, but I’m a book learner. For anyone wondering, Kochan’s is a good book for learning the language, but is a bit dated (2004) given that Objective C 2.0 is out. Don’t expect it to cover anything on the iPhone, and I’ve pretty much disregarded anything XCode specific. Fortunately, a new edition is coming this May. Zdiarski’s book seems pretty good, but it’s already showing age despite its recent publication–it was released before the SDK and from what I’ve read some of the examples are contingent on having a jailbreaked iPhone. I’ve struggled with an example or two because of it and some deprecated code.
• I’m still searching for good community resources on iPhone-specific development. A grassroots community definitely helps the cause (I doubt Apple could sufficiently provide such a community given their stance on some iPhone hacks), but it seems like most people are too involved with the SDK at the moment. It makes me wonder how many people are working on competing apps prior to the store launch.

At the very least, learning all of this has given me the perspective of a beginner again, and seeing OOP implementations in another language never hurts. I might post some basic tutorials in the future to (hopefully) save some people the learning pains I went through.

My friend Mo made me realize this, so, like him, I felt compelled to choose something that better represents my individuality. I almost went with Soul Coughing’s Suzy Snowflake, but in the end opted for one of XOC’s renditions of the Super Mario World soundtrack.

I did a little audio trimming to get my ringtone under 30 seconds using Audacity (since I don’t have Garageband 4+), converted my new MP3 to AAC, renamed the extension to .m4r, dragged it into my iTunes Ringtone folder, and voilà, a ringtone just for me.

I’m not all about proprietary standards, but, naturally, I had to figure out how to do it for my own sites.

Basically, you create a 57×57 PNG file and host it on the top level of your domain. In the <head> of your HTML page(s), add a link (similar to a custom favicon):

<link rel=”apple-touch-icon” href=”/customicon.png”/>

You can get the full details at Apple’s developer site.