All posts by shannah

Steve Hannah is a 28-year-old software developer currently studying and working at Simon Fraser University in beautiful Vancouver British Columbia. He specializes in web information systems and prefers Java, PHP, and Python as programming languages. He is a Christian and worships at Christ Church of China in Vancouver.

How I use the iPad

It’s been close to a year since I purchased my iPad, so I thought I’d post a short piece reflecting upon how I have ended up using it.

Things I tried that didn’t really work:

1. Word processing. – The keyboard is OK for typing short little things but it is just too cumbersome to try to write anything substantial. I think that even if I had the bluetooth keyboard it still wouldn’t be a good solution for word processing. Selecting text, copying and pasting, and even just trying to insert text at a different position in the document is just too difficult at this time.

2. Note taking – I tried taking the iPad to a few meetings for the purpose of note taking. It was a novelty but ultimately it is just easier to take notes on paper and then transcribe them on the laptop later.

Things I tried that really work:

  1. Reading the news paper. I use the Pressreader app which gives me access to 1700 newspapers from around the world for $30 per month. I generally read through the Vancouver Sun, Province, and 24 H, and the Washington Post every morning before I go to work.
  2. Reading books. (on the Kindle app – not iBooks)
  3. Watching Movies in bed. I use Web Lite TV to be able to stream my entire iTunes movie collection to my iPad. This effectively turns the iPad into my bedroom TV. I also use the Netflix app which works quite well when I want to watch a movie or TV show that I don’t currently have in my personal collection.
  4. Facebook in bed. Rather than use a Facebook App, I just added the Facebook site to my home screen (so it gets an icon and all and acts like an app). I much prefer checking facebook on my iPad to logging in on my computer.
  5. Reading Email in bed – I check my email from bed on the iPad. This allows me to make a mental inventory of things that I need to reply to. Short replies I will make on the iPad directly, but generally I’ll go to a computer to write more detailed replies.
  6. Browsing the web in bed. It’s just easier to use an iPad than a laptop in bed. And it’s pretty damn easy to browse the web on the iPad.

The iPad has secured a permanent place in my life – though it hasn’t threatened to replace the laptop in the foreseeable future. Of course, this is what Apple intended when they designed it.

Why do you need an app for that?

I have recently stopped using the Facebook and Mail apps for my iPad and iPhone in favour of the HTML equivalents offered through Safari. The reasons: Mobile-optimized web applications are now as good, or even better in many cases, as their native app equivalents. In the case of the Mail app, I have found that the gmail mobile version has a superior search feature and is much faster in loading my messages. For facebook, I just found the app limited and more buggy than the HTML equivalent.

In general, I’ve come to the conclusion that if you’re going to build a native app for something, you’d better have a good reason – and good reasons are becoming fewer as HTML browsers improve their support for HTML5. The only valid reason at this point is a requirement for significant client-side processing – e.g. a 3-D game. But as WebGL matures even this will be quite possible in HTML.

So here are some reasons for developing your mobile applications in HTML5:

  1. Increased productivity in most cases over development of native apps.
  2. Real standards-based, cross-platform support so you can write it once and have it work on all major platforms (Android, iPhone, Blackberry, etc…).
  3. True freedom of deployment. You are not locked into Apple’s (or the next would-be gatekeeper’s) store or subject to their sovereign choice of what can and cannot be installed.

The remaining reasons why you may still need to develop a native app:

  1. You want to use a platform specific feature that isn’t available through the web api. E.g. the accelerometer, or the contacts list, or push notifications, GPS, etc..
  2. You need more client-side processing power than you can harness through the web.

The compelling reasons to want to develop a native app:

  1. To get it into the app store and maybe make some money.
  2. Toolkits (e.g. XCode/Interface builder) are developed and promoted specifically for making apps target a specific platform. This can make it seem easier to break into the market since there are lots of learning resources on how to use these tools.

The biggest challenge right now facing HTML mobile developers is that the tools are less promoted and more scattered. This is because the major stakeholders (e.g. Apple) have a significant interest in getting you to develop your app natively so that it will be exclusively available for their platform, and they will get a cut of any revenue through their store model. If you look, however, there are tools out there for building slick HTML mobile apps that look and feel very much like native apps. Some examples include:

  1. Sencha Touch
  2. jqTouch

And there are more where those came from. If you still want to develop a native app and you would prefer to work with open technologies like HTML and Javascript you may want to look at Appcelerator which provides tools to develop applications in Javascript, HTML, and CSS that can be compiled into native apps all the major smart phones (e.g. Android, iOS).

Donald Trump for Panderer of the United States

I saw Donald Trump on Pierce Morgan last night where he declared his possible candidacy for President in 2012. Wow, does he ever have his finger on the pulse of the American people – at least those from the red states. He has clearly calculated his message to speak to “red” America in his hope to fill the leadership void that currently haunts the GOP. A paraphrase of a few of his panderous statements:

1. China is the enemy
2. If he were President he would enact a 25% tax on all Chinese goods – because they aren’t playing fair.
3. Too much money is spent on education at the federal level. Education should be handled locally.
4. He’s a military man. He would increase military spending if he were president.
5. America has become a joke internationally, and he would restore its honor in the world (he seemed to be hinting at doing that with the military).
6. He would stick it to OPEC. He’d go over there with the military at his back and dictate the terms under which they would provide the US with oil.
7. He would assign tough wall street negotiators to handle negotiations with other countries… not the diplomats.
8. The US should be charging South Korea for the protection they receive from the US.
9. He loves Sarah Palin. He just thinks she can’t win a national election.

Now some of these positions, I’m sure, are genuinely his. But it looks to me like these statements have been carefully crafted to appeal to the right. I’m sure that, over the next several weeks, he’ll be testing the waters with these ideas so he can assess his chances of winning an election.

.NET: The most unlikely savior of Desktop Java on the Mac

When Microsoft first introduced the .NET platform and its flagship programming language C#, I, like many Java developers, looked at it and said “They’re just copying Java”. Why would I want to develop on the .NET platform which is targeted exclusively at Windows, when I could use the more established Java language and deploy across all platforms including Mac and Linux?

When I heard rumblings of the open source version of .NET, called Mono being developed, I was curious but ultimately wrote it off as it was likely that, since .NET was married to Windows in so many ways, probably most of the libraries for .NET would be platform specific and wouldn’t run properly on Mono anyways.

The past 10 years have seen many new trends come and go, and quite a few shifts in mindshare between the different technologies. One stream of trends that I have been quite interested in as a Java developer and a Mac user, is the role of Java on the Mac.

When Apple first unveiled OS X, Java was at the center of it. They promoted Mac as an excellent platform for Java developers to deploy their programs. They pledged to provide a Mac-specific implementation of Java that would blend into the OS and work seamlessly with the slick new look and feel of Mac. Two key pieces of this puzzle were the Swing Aqua look and feel and the Java Cocoa Bindings. The Swing Aqua look and feel allowed all Swing (the default java UI toolkit) programs to look like native programs on the mac. The Java Cocoa bindings allowed even deeper integration by allowing Java programs to use the native Objective-C classes and widgets directly.

Fast forward to 2011. If you try a google search for Desktop Java on the Mac or related terms you’ll notice that there are lots of articles, tutorials, and documents from the period ranging from 1997 to 2005. But very little after that. This is due to a number of trends and developments during that timespan. Some of these include:

  1. Apple deprecating the Cocoa Java bridge. (Turns out that is wasn’t used very much anyways because Java developers could achieve an almost native look and feel using Swing and keep cross-platform compability).
  2. Java mindshare had moved predominantly to server-side technologies.
  3. The emergence of higher-productivity interpreted dynamic languages like Ruby and Python had stolen a lot of mindshare on the desktop.
  4. Objective-C through the introduction of the iPhone and iPod had drastically increased in mindshare – so more developers were familiar with the native tools and would forego trying to work with a language such as java for native applications.
  5. Sun seemed to be confused as to which direction it wanted to go – and years of progress were lost (* more on this later).

Nonetheless, during the period of 2005 to present, there have still been some good options for producing high quality desktop applications for the mac. After all it was the only OS with a large user base that shipped with Java. This meant that you could develop for Java and be certain that the target users would be able to use your software without having to download anything extra. Swing still has the Aqua look and feel, and all of those tools and widgets that were developed pre-2005 still worked nicely (except of course those tools that were built upon the Cocoa-Java bridge).

Unfortunately the writing was on the wall and Apple made it official in October 2010 when it announced that it would be deprecating Java on the mac and that future versions of the operating system would not ship with it. It would be up to the open source community and Java’s owner Oracle to provide a Java for the future of the Mac (and this future is still very much unfolding as I type).

So now, at a time when the future of Java on the Mac is as bleak as ever, an unlikely ally enters the fray: .NET – or rather its open source twin, Mono.

Mono has quietly been picking up a following over the past 10 years. It reached 1.0 status in 2004, and has facilitated the development of 2 separate projects, which, together appear to offer the best hope for the future of Java on the Mac:

  1. IKVM.NET – A Java virtual machine that runs on .NET and Mono. This tool is able to run Java byte code in Mono and use java libraries natively. It also includes tools to statically compile java as a .NET executable which can be used in .NET or Mono applications. This has opened many doors to both C# and Java allowing libraries developed with java to be quickly compiled a distributed for .NET (e.g. Apache’s PDFBox which is developed in Java but available for both .NET and Java).

  2. The Mono Mac project – An objective C binding that allows C# code to directly access the Mac Cocoa classes. The current versions of MonoDevelop (the Open Source Mono IDE) work seamlessly with Apple’s developer tools, especially interface builder so that developing and deploying an application for the Mac using C# is a first class experience.

These two projects together open up a myriad of possibilities for Java on the mac that haven’t been available since the deprecation of the Cocoa-Java bridge. If you have a large existing source base of java code and libraries, you can quite easily now compile them into a Mono library that can be used in a Mono Mac application – and then deploy it natively on the Mac and even distribute your applications in the Mac App store.

And this is how a Windows-Only competitor of Java has evolved into an unlikely ally in staying relevent on the Mac platform.

How to get a Java Application into the Mac App Store

I just received a reply from Apple support confirming that there is nothing in their guidelines that prohibits apps that include an embedded Java virtual machine. Therefore, Apple’s regrettable decision to deprecate Java and disallow apps that depend upon it from entry into their new App store is a mere speed bump and not the road block that I had originally believed it to be. So there are a number of strategies for getting Java into the Mac app store: 1. Embed a java runtime environment as part of the application bundle. Currently there are no Mac JVMs that can be distributed which support Swing with the Quartz UI (i.e. graphical Swing apps won’t look native, if you can even get them to work). However Oracle and Apple’s recent announcement that Apple will be donating source code to the OpenJDK project suggests that this will be resolved with Oracle’s release of JDK7 on the Mac. In the mean time it would be possible to embed third party JVM like Soy Latte or IKVM (a .Net implementation of java) and use Rococoa as the UI. 2.** Use GCJ (The GNU Java Compiler)** which can be installed via Mac Ports, in conjunction with Rococoa for the UI to compile your application into a native binary.

Resources

  • Mono for Mac Resource: This page shows some resources related to Mono support on the Mac. Why is this relevant? Because Mono is the open source, cross-platform implementation of the .Net framework and it supports IKVM, a fully-functional java virtual machine that runs on Mono. IKVM will allow you to convert your java applications into .exe files that will run on Mono, which can be embedded in your application bundle.
  • Example using Rococoa to use Quartz framework from java
  • Rococoa GUI Demo : This tutorial shows a short sample of how to use Interface builder to build an interface for your java application using Rococoa.

The Chrome App Store Swinging the Pendulum WAY open

I’ve been very critical of Apple’s recent moves in deprecating java and excluding java-based applications from their new Mac App store. Their restrictive policies seem to be strong-arming developers into using their closed set of tools (and allowing apple to take 30% of all sales). So when I heard about Google’s new Chrome App store, I was naturally excited about the promise of a more open environment where apps are not shunned merely because they were built with a non-approved tool.

Unfortunately, it seems that they have gone a little too far in the opposite direction of Apple. The Chrome App store is meant to be a marketplace for web-based applications (i.e. anything that runs in a web browser). It allows users to install web applications so that they are added to their dashboard and can be easily accessed. Google provides tools for developers to handle purchases through the app store and keep track of user’s licenses. Unlike Apple’s closed model where only Cocoa-built apps need apply, the Chrome store invites all technologies that run in a web browser including HTML5, Flash, Silverlight, and Java (applets and webstart apps). I applaud Google for taking this step and for keeping the market open to such a wide array of technologies, but the current state of store is a little disorienting because they don’t seem to be very strict about the applications integrating into the app store frameworks. Many of the “applications” are just glorified web pages that can’t really be called an “app”. Others that could be classified as apps aren’t integrated at all with the app store other than the initial link – so that when you click on the icon, you are just taken to the app’s homepage that contains all kinds of advertising and gives an option to register for an account or login. When you’re clicking on an “app” icon to open an application, you expect to be taken directly into some sort of app interface…. you don’t expect to have to fill out a registration form or log in every time you visit.

My suggestion to Google would be to become a little more discerning about what kinds of apps get accepted into their store. They should start with a set of rules about one quarter the size of the Apple App store submission guidelines to ensure that the user experience is as close as possible to using a desktop application. If users have to sift through too much garbage, they’ll just give up and the app store will become a glorified set of bookmarks.

Apple to shut down its download section -> Why I’m not submitting to the App store

I suspected this step was coming. Since Apple is making a push to get people into its new App Store for OS X, it is shutting down its download section. This is decidedly bad news and depending on how it affects the market, it may mark the end of my development for the Mac platform. We’ll have to wait and see.

Why not just add my apps to the app store then?

I use Java for much of my development

I really do prefer to work with Java vs using an old language like Objective-C that is limited in so many ways. Apple has cut off access for developers like me who don’t want to use their “approved” APIs.

Apple Takes a 30% cut

This commission seems a little high… Of course it depends if the app store generates more sales to make up for the commission.

I don’t want ALL of my upgrades and transactions going through the app store

Apple dictates that all updates and license keys must be managed through their store using their API. This ensures that apple gets their cut of any transaction….

I still want to be able to distribute my apps to Windows and Linux users

I don’t have the man power to rewrite all of my apps from the ground up for every platform. Mac’s Approved APIs don’t lend themselves easily to distribution on Windows and Linux where many of my users reside. This is, of course, a business decision by Apple to try to lock users in to ensure that most software is “Mac Only”.

I am extremely disheartened by the direction that Apple is taking with OS X. I truely hope that the App store is a failure so that the market, if nothing else, can reign them in.

Posthumously discovering JavaFX

It turns out that JavaFX is actually kind of cool. Sun had been pushing it to no avail for over 2 years before Oracle finally pulled the plug (sort of .. they’re killing the language and porting it to Java), but they seemed to do a lousy job of making it seem relevant.

Now that it is dead, I have gone back over the docs for a final look and have discovered that it actually looks kind of cool. Being able to lay out 3d objects in a scene graph, apply transformations and animations to any branch; binding variables to one another to keep them in sync. It actually makes for a nice system.

The problem is that I’m having trouble forming a complete picture of where I can use my JavaFX apps. They say it’s for all the screens of your life, but with no iPhone, no Android, limited to no Mac support, I’m not sure what I’m left with. I’ve seen the odd reference to Blackberry support, but nothing definitive yet.

A shame, really.

Apple’s assault on Java is an Assault Java Developers

Yesterday, Apple announced that its next version of OS X, called “Lion”, will include an App store to simplify the process of downloading, purchasing, and updating applications on the Mac.

This is great news!

Apple will take a 30% cut of all transactions performed through the app store.

I’m mixed about this. If the App store is able to increase the sales of my apps by more than 30%, then it might be worth it. Otherwise, this is just a 30% tax off the top of all of my app income.

In a much less hyped announcement, Apple has deprecated Java as of version 1.6 update 3, and may not continue to bundle Java with future releases of OS X.

This is bad news… and it could be terrible news if Oracle or someone else doesn’t pick up the slack and provide a Mac deployment for the Java VM. Although, this could be somewhat good news if the “new” steward takes better care, as Java on the Mac does lag behind other platforms in both performance and stability. Oracle taking over Java could be a good thing if it results in a better product.

One final non-announcement came in the form of a guideline for admission to the Mac App store: Applications that use deprecated API’s (e.g. Java) will be rejected from the App store.

This is terrible news! A betrayal of the first order. It appears that Apple now feels confident enough with its market position to close the doors on all but their faithful Objective-C developers.

I currently have 3 desktop Mac applications on the market, and 2 of them are written almost entirely in Java. I chose, and still prefer, Java as a language because it provides a fast, robust, multi-threaded environment that is easy to scale, and even easier to port over to different platforms. It took me about 4 hours to port PDF OCR X over to Windows, and most of that time was spent on the non-java portions.

I was actually intending to blog about my experience with Java and multi-platform application development and was going to advocate Java as a good platform for development on the Desktop.

In light of yesterday’s announcements, I must take a pause to consider my future. Since Apple seems to be dictating its terms in a heavy-handed way, my instinct is to stick it to “the man” (Apple) and boycott its App store and its products altogether.

But then I lean back and glance around the room at my iPad, iPhone, Apple TV, Mac Mini, and 2 Mac books…. and I question my resolve as they do indeed make nice products.

I watched from afar when Apple shut out Flash from its iPhone. But this didn’t affect me as I didn’t develop for the iPhone. And, after all, Flash runs down the battery life too fast so there was a logical technical reason for its omission. When they brazenly placed a prohibition on all advertisements served by competitors to their iAd service, I shook my head – but it didn’t really affect me. And since the iPhone was a new device, the fact that it was closed wasn’t too much of a concern, because we only had non-existence to compare to its “closed existence”, and a closed existence surely is better than non-existence

But with the Mac we are moving from an era of openness, and stepping into one that would appear to be much more closed, so I get the distinct and unpleasant feeling of having my virtual civil rights stripped away. For now, we will probably be able to download and install applications the conventional way, but such applications will likely be treated as 2nd class citizens, branded with a star, and forced to live in some hard-to-find ghetto folder. Once Apple has achieved wide-spread acceptance amongst users that the App store is the only acceptable way to obtain software, perhaps they’ll close the technical loop hole that allows those second class apps from even breathing the same air as Apple’s preferred class of fully-taxed App store apps, and we’ll be left with a completely closed, yet beautiful utopia of an operating system housing only the master race of applications that descend from Apple’s own genetic components (i.e. Objective-C) and bear the 30%-tax stamp of Approval.

Mister Jobs, you have stepped too far. I was a true believer. I am now agnostic.