Creating a SD card image
In both the 1.1 and 1.5 version of the SDK there is a tool called mksdcard located in the SDK Install Dir/tools folder. Simply run

./mksdcard 128M my128MbCard

to create a 128Mb SD card with the name my128MbCard.

Mounting a SD card image in Linux
To be able to put content on to the card you can mount the card in Linux. It will then simply appear as a folder in the filesystem.
First make a directory in the /media folder:

sudo mkdir /media/mycard

Then mount the card as a loopback device:

sudo mount -o loop my128MbCard /media/mycard

Adding content to the card
With content we usually mean media content like images and videos. Images and videos are located in a folder called /dcim/Camera. You could of course add any content to the card. When you are done copying your files be sure to umount the card otherwise it will not be usable from the emulator.

sudo umount /media/mycard/

Using the card in the emulator
Google added something called Android Virtual Device (AVD) to the SDK 1.5. To create a new AVD using our newly created SDcard image run the following:

./android create avd --name myAVD --target 2 --sdcard my128MbCard

Target 2 means that we want to use the 1.5 API features in the device. Now we simply fire up the emulator and start using our content:

./emulator -avd myAVD

More information about the new SDK can be found here: SDK

A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.

This is true as it stands, but I think the main reason why Apple can keep a pace and a high standard of inovation is because of how they manage the Lowest Common Denominator. And iPhone OS with App Store is the crown jewel.

Technology vs. User Base

The lowest common denominator is always of interest when developing applications and services for the end user with profit interests. The lowest common denominator is what defines your user base, and it is a hard game of balance. Sticking to the newest technology will allow you to progress faster with more elegant solutions, whereas using a more commonly available technology will give you a larger user base.

So the lowest common denominator should be as high as possible, while still economical. With Java ME a bold effort to rise the bar of the lowest common denominator is the MSA JSR-248. An effort to give Java ME developers a guarantee minimum of features. A noble effort, but in reality up to a year ago only Sony Ericsson was MSA compliant, making the aged MIDP 2.0 the de-facto lowest common denominator for any developer targeting a the majority of Java ME devices.

The lowest common denominator for an average Java ME developer is the MIDP 2.0 spec from 2002.

iTunes as a Hub

Apple has a different situation, largely due to it's decision to use iTunes as the hub for all mobile devices, iPods as well as iPhones. All iPods and iPhones charges the battery by plugging in the USB-cable to your computer, this have some large but not obvious benefits.

Most notably Apple knows with 100% certainty that all users will have their devices on a reliable and controlled connection often, in most cases on a daily basis. As the users also use iTunes to synchronize their media, any other synchronization is not a hassle but rather a bonus on top of something they already requested.

Adding software updates on top of synchronizing media and data content through iTunes is just genius. It is a two click operation for the user, and as a result Apple virtually guaranteed that all iPod and iPhone users have the very latest software installed on their device.

Back-porting Software

Apart from the technology decision with iTunes as a hub, Apple have also made a business decision by always back porting their latest software to all iPhone OS powered devices. iPhone OS 2.0 can be installed on any first generation iPod Touch or iPhone, and with iPhone OS 3.0 this summer all three generations will be supported.

This back-porting model is the total oposite of almost all competitors, where instead new features are explicitly locked to the latest hardware in order to sell devices. So if the end users can get all the new iPhone 3.0 as a free download, why should they buy new hardware? Will not Apple loose revenue on unsold third generation iPhone devices?

In short term probably will, but the big win is the Lowest Common Denominator. Whereas the competition have a common lowest denominator of several years, almost a decade, Apple and all of Apple's third party developers have a lowest common denominator of virtually weeks.

Conclusion

With a simple software distribution model that guarantees the lowest common denominator Apple has guaranteed that the common lowest denominator is the current software, period. This allows Apple, and all third party developer creating applications and services for their devices, the luxury of discarding all effort for backward compatibility, and technological compromises.

Apple and we are allowed to innovate with full steam ahead.

One area that, in my opinion, could still be improved is the development environment. It may be a heck of a good build system Liferay has come up with, but at the bottom line it takes time to learn it and to just start studying it you easily become a bit uncertain. It consists of homegrown ant scripts. To have a flatter learning curve for newcomers Maven 2 might be suitable.

Anyway, I sat down one evening some time ago and looked into how Maven 2 could be used for creating Jsp Portlets for Liferay. Some hours later the work had resulted in a new archetype for creating Liferay Jsp Portlets.

The structure and content of the standard Liferay Jsp Portlet can be viewed here.

So, what did I do?

1. I followed these instructions to manipulate the Jsp Portlet part of Liferay's plugin SDK into a maven archetype:

http://maven.apache.org/guides/mini/guide-creating-archetypes.html

This involved editing these property and xml files:

liferay-plugin-package.properties
name=${artifactId}
module-group-id=liferay
module-incremental-version=1
tags=
short-description=
change-log=
page-url=http://www.liferay.com
author=Liferay, Inc.
licenses=MIT

portlet.xml
<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">
<portlet>
<portlet-name>jspPortlet</portlet-name>
		<display-name>${artifactId}</display-name>
<portlet-class>${groupId}.JSPPortlet</portlet-class>
		<init-param>
			<name>view-jsp</name>
			<value>/view.jsp</value>
		</init-param>
		<expiration-cache>0</expiration-cache>
		<supports>
			<mime-type>text/html</mime-type>
		</supports>
<portlet-info>
			<title>${artifactId}</title>
			<short-title>${artifactId}</short-title>
			<keywords>${artifactId}</keywords>
		</portlet-info>
		<security-role-ref>
			<role-name>administrator</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>guest</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>power-user</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>user</role-name>
		</security-role-ref>
	</portlet>
</portlet-app>
 

to insert ${artifactId} and ${groupId} for the portlet name and package structure. These files are part of the file list finally being wrapped up within the archetype and used to generate the resulting portlet from Maven 2.

2. I ran 'mvn install' on that particular archetype to have it installed in my local repository.

3. I used the archetype to create a new Liferay Jsp Portlet artifact:

mvn archetype:create -DarchetypeGroupId=com.liferay.maven.archetypes.portlet.jsp
  -DarchetypeArtifactId=liferay-jsp-portlet
  -DarchetypeVersion=1.0-SNAPSHOT
  -DgroupId=[my.package]
  -DartifactId=[MyFirstLiferayJspPortlet]

4. I stepped into the artifact and ran 'mvn install' on it which generated my MyFirstLiferayJspPortlet-1.0-SNAPSHOT.war.

5. I then uploaded the war file to my portal instance via the Liferay admin GUI Plugin Installer.

6. Et voila. It worked, showing up in the portal.

And of course, worth mentioning, to have a development environment up and running in eclipse in seconds this is all you have to do:

1. mvn eclipse:add-maven-repo -Declipse.workspace=[full-path-to-workspace]

2. mvn eclipse:eclipse

To have the archetype play with the existing build situation of Liferay it would probably need to be generated from some ant target and be based on the portlet template in subversion located at "plugins/tools/portlet_tmpl/" to have it follow updates of Liferay.

Here you can download the final result, as a zipped archetype.

If a generated archetype like this was to be uploaded to a public maven repository, working from above point #3 and down is what would be necessary for a developer to have a project and all the necessary property and xml files (correctly edited with package structures and all) in place for a Liferay Jsp Portlet development environment. It could at least become a complement to the Plugins SDK. And yes, it could for sure still be enhanced. For example, there is no JSPPortletTest class generated for the JSPPortlet class.

The sessions are confidential so I will keep this post vague on the technical parts, not revealing any thing that might or might not come to an iPhone or iPod touch near you in the future. And I can not mention any specific sales numbers, but I do can say that any predicted numbers you might have seen; is probably an underestimation with a margin and then some.

The sessions where on a high level, not going too deep on technical details. Instead the sessions concentrated on the overall design philosophies, and common gotchas. For the nitty gritty details Apple engineers where available, and I missed half a session discussing the ins and outs of the UIToolbar class with Alberto Arauz. Alberto is one of the european software evangelist, and was most impressed, and interested, when I described the successful Mobile 2.0 track at Øredev 2008. Apple's overall impression with Scandinavia has so far been a mostly cold hand regarding anything with Apple, going as far as only six people registering for a Tech Talk in Oslo two years ago.

Apart from the speakers and engineers, Apple also brought a video-team. So yours truly has been intervjued about the applications I have on App Store, and my experience with the iPhone SDK. The video will be cut and edited for promotional purposes, and hopefully me mentioning both Malmö and Jayway will not be cut out. The odds of my short talk being included is quite good, as most developers seems to be focusing on games, not utilities as I and Jayway has done.

The best part to take home is not technical, just solid advice for any development, not even under NDA, and the sole point repeated by Apple over and over: Developing great applications is not about adding features! The trick is not to cram in as many features as you can, the trick is to know what features to leave out, so that time can be well spend on the key features that do make the cut. And this is tenfold as important on a mobile device where real estate is limited. A quote from Mark Twain:

I apologize for writing you a long letter, but I did not have the time to write a short.

Writing short, and cutting features is hard. How to decide on the features to drop or implement? Apple uses a simple technique, called a product statement. The product statement for the Photos application is for example; "An easy to use photo sharing application for all iPhone users". Any feature that do not help fulfilling this statement do not make it. How about simple photo-editing? Nope, does not comply with statement. The wording of the product statement is important, by simply changing it to "An easy to use photo sharing application for professional photographers", would be a completely new application. Only when the product statement is agreed upon, can an approved list of features be made. An omnipresent Steve Jobs approving and dismissing features, is an exaggeration, this simple method is what do the trick.

Now this might sound both obvious, and counterintuitive. Surely adding that last nice feature would add value? Not at the expense of a cluttered user interface, that is meant to be used while standing in line for 30 seconds. Features thought to be must haves, most of the time are not. Some features thought to be must haves are MMS and video recording. Looking at the raging success of the iPhone, it is very obvious that they are not must haves. We as software engineers must at long last learn that it truly is quality over quantity.

And lastly a personal reflection; from a developer's point of view the best part about iPhone SDK is that it is not an UI framework, it is an Application framework. It do not settle with providing the tools for collections, persisting data, displaying a UI, and then leave the rest of the architecture to the developers. The iPhone SDK supports all three parts of the Model-View-Controller paradigm equally well, and that is what makes it so productive.

Not only the provided Frameworks are polished even in beta, so are the tools. Mac OS X 10.5 Leopard, and Xcode 3.1 is required! If you can live with that works perfectly, with zero setup; double click install package and you are done. Several project templates provided as starting points. Only drawback I find is that the Simulator is not an emulator of the actual hardware, eg. it is running 32-bit x86 not ARM, which makes an Java JIT-compiler undebuggable on the Simulator. Good news is that there is transparent on-device debugging, bad news again; it requires the 2.0 beta software on the phone.

My second reaction is that it is complete. The SDK, as well as the underlying system. It truly is the same system as on desktop Macs running on the device. The same kernel, the same Frameworks. Just a bit more restrictive memory, and screen size.

The documentation is impressive, ranging from conceptual books and a wide range of subjects such as as Human Interface Guidelines, Memory Management, introduction to Objective-C for beginners, writing games using Open GL | ES, security, and much more.

It is obvious by looking at the documentation provided that special care has been taken to cater for the needs of developers without previous experience of Cocoa, or Mac OS X development. Two thirds of the documentation is very basic for anyone with more then a few months experience with Cocoa. And the last third is in depths iPhone OS specific. Most of the documentation is also shared between iPhone OS and desktop Mac OS X, my gut feeling is that Apple want to use iPhone as a lure for developers to embrace Cocoa on Mac OS X as well.

Apart from documentation there is also over 4 hours of video tutorials, ranging from basic overview to optimizing OpenGL | ES games. As well as over 40 example projects, including complete applications. Bot the "show a feature" type that Android have in bounty, and "show a solution" that gives a better feel for how an application should be organized.

And organizing an application is important. Just as with Cocoa for Mac OS X, Cocoa Touch for iPhone OS gives the developer allot for free, provided you follow a few guidelines, and best practices. These are however few, and clear, so anyone can get the hang of it in a matter of hours. Cocoa's inherent talkative API:s with descriptive class, method and constant names, encourages developers to both use and follow "good style". A method named applicationDidLaunch is very hard to misinterpret (It is however misspelled as ApplicationDidLaunch in the iPhone OS Development Introduction ).

And my last reaction; it is beta! Interface Integration is not yet included. That means that you will have to create your UI in code, not using the drag-n-drop as shown on the Keynote last thursday. I miss it dearly, but try to tell myself it is a good thing to first learn how it works under the hood . That and a short list of known bugs, is really the only things I can see standing in the way of a 1.0 release.

I have as a tutorial for myself rewritten the URLyBird assignment for my Java Developer certification with the iPhone OS SDK. Minus the remote server it is up and running beautifully in less than 8 hours of coding.