News about Pastebud:

• Copy and Paste Comes to iPhone – Wired News
  
• iPhone Copy and Paste Now Working Between Safari and Mail – Gizmodo

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

What does this mean to you?  This means that developers can now share to the world any technical articles or tutorials related to developing iPhone apps or web apps.  Now, I can finally proceed with publishing my iCopyUPaste technical article.

The main advantages of client based mobile Web applications are that they provide very good possibilities for graphic design of user interfaces and keep content available even offline. Furthermore, they often show faster reaction times and are sometimes easier to link to other telephone functions such as directories, camera, etc. The main disadvantage of every client-based solution is that they initially need to be downloaded by the user and installed on the mobile – a practice that will need to be repeated for every new release. Many users are prevented from taking this step due to technical problems, security issues and a lack of clarity concerning costs involved. Furthermore clients are always dependent on the mobile phone operating system and must often undergo costly adjustments for each individual terminal.

Mobile sites, on the other hand, do not require any installation. They are immediately available over the browser and the sites’ content and software are continuously updated unobtrusively to the mobile user. Mobile sites also provide a greater scope of outreach than clients do, as nowadays practically all mobile phones have a browser. Adjusting mobile sites and rich media content to various mobile terminals can be made 100 percent automatic. This means a massive reduction in development and testing expenses. User interface design is also no longer an obstacle. Modern mobile phone browsers enable use of AJAX and Flash, thus creating a user experience similar to that of PC Web. If a company is looking for a larger audience reach with as little hassle as possible, the mobile site is the clear winner.

I totally agree. The one thing that I advocate is to have some kind of markup language that allows the browser to have access to native device functions such as the PIM, camera, etc.

What does iPhone 2.0 offer that warrants an upgrade?  GPS, 3G, and slightly larger storage.  That simply is NOT enough to warrant the extra $30 / month I’d have to shell out to get the new iPhone 2.0.  I currently pay $55 incl. taxes and fees for my iPhone 1.0 plan, and I thought that was pretty hefty to begin with.  This new plan simply is highway robbery!  Apple and AT&T, no thanks, but I’m sticking with iPhone 1.0.

Why has Firefox surged to  the top?  Two things. Add-ons/extensions, and tabbed browsing.  I cannot even imagine browsing the web without these innovations.  Those two simple ideas have made my online experience a sheer joy.  My top ten add-ons include:  del.icio.us, Foxmarks, Adblock, Google Browser Sync, Google Gears, Google Notebook, Operator, Greasemonkey, Firebug, and User Agent Switcher.

The upcoming FIrefox 3 also promises new innovations to make browsing even more simpler and useful. The aptly named “Awesome Bar” is indeed awesome.  You just start typing in anything that you’ve accessed in your browser URL, and it comes up with possible suggestions.  Unlike type-ahead, the suggestions you get can come from any position in the URL (not just the first n characters). Also, the performance and security enhancements are much needed as pre-Firefox-3 browsers had started to become slow.  I remembered the primary reason that I had switched from IE to Firefox back in the day was because Firefox 1.0 was so much faster than IE 6.0.  Performance is as much part of the user experience as UI. You can have the prettiest user interface, but if the user has to wait longer to get their information, they will perceive the product as crap.

Mozilla’s next phase is to rule the mobile browser space. The space is already crowded with the likes of Webkit, Opera, Pocket IE, etc. How awesome will it be to be able to keep those Add-Ons while surfing the mobile web on any smartphone platform. That’s Firefox’s bread and butter.  That’s what will make them successful in the mobile web 2.0.

This type of location network awareness could be applied to many other applications. For instance, upon connecting to your Wi-Fi router at home, it could signal an action of some kind. For instance, if your smartphone sensed that your PC or Mac was online in your home network, it could synchronize your smartphone’s contacts, calendars, and music automatically over Wi-Fi. On the smartphone, there should be the ability to discover open hotspots, store those hotspots to location profiles, and take actions based on those location and network profiles.

The iPhone Safari browser, Nokia, and Android all use the same web browser engine called Webkit.  Webkit is a revelation in itself. The full web browsing experience on the desktop now available on the mobile device. Mozilla’s Fennec is based on the same Mozilla Firefox engine and also allows for the full browsing experience.  Windows Mobile has Internet Explorer and its also starting to move in this direction. See a trend?  Yep. The days of WAP browsing are slowing being numbered. Its not going away anytime soon, but it eventually will.

Of course, as a developer, you will also be faced with a choice of developing a mobile native application vs mobile web application. That decision is not an easy one to make. There are so many platforms to choose from. iPhone, Windows Mobile, Palm, BlackBerry, Java ME, Flash Lite, Symbian, and the list goes on. This tells me that in order to get the most market penetration for your application, targeting the mobile web is the logical choice. However, there are exceptions. Gaming apps, off-line storage, and integration with phone hardware feature set are all compelling reasons to target your application to a platform as opposed to the mobile web.  What Apple should have done to make this decision easier was to integrate phone APIs into the Safari Webkit engine. Create a subset of XHTML tags or JavaScript objects that allow the mobile web app to tap into the PIM, camera, or other mobile device native function.

• Zec Online Journal: Steve Jobs doesn’t understand mobility
• Steve Jobs Answers Walt’s iPhone Questions
• The iPhone’s Camera: Great Under Ample Light
• Finally Confirmed: What the iPhone Doesn’t Have

I have one comment about the iPhone’s announced rate plans. It works out the same as the current Cingular/AT&T voice plans plus the $19.99 unlimited data plan. There were rumblings that Apple and Cingular/AT&T would make it more expensive, but I think it was a wise decision not to charge more.

This is why mobile phones in N. America still suck compared to those in Japan. Let’s see how the Apple iPhone starts to promote changes needed to catch up.

My hope is that someday the mobile browser space will be advanced enough that it will rival that of the desktop browser space. That way, web developers can simply write their code once, and that it will render properly on all web browsers – desktop and mobile versions.

Web developers in the desktop world have had to deal with cross-browser incompatibilities when writing code. The same can be said for the old class of mobile handsets and their fragmented support for WAP, XHTML, JavaScript, and AJAX. To my knowledge, there are only a few mobile web browsers capable of rendering AJAX.

If your phone runs on the Windows Mobile platform, IE Mobile is the default web browser installed. According to the IE Mobile developer blog, AJAX is supported on IE Mobile. Unfortunately, the JavaScript DOM support is limited. Therefore, most AJAX toolkits out there will NOT render their AJAX widgets correctly on IE Mobile. Come to think of it, I am not sure that any AJAX toolkits even consider testing on IE Mobile or any other mobile web browser for that matter.

The Opera platform is probably the most well-known mobile web browser that is capable of supporting AJAX. The only thing slowing its adoption is the fact that it is not free, and it is a separate download and install. Opera does have a free version called Opera Mini, but it is not known to support AJAX. Opera Mobile is also only targeted for Symbian and Windows Mobile platforms. This leaves out Blackberry users, which is significant base of mobile web users out there. The only other way for Blackberry users and other handsets to adopt AJAX-like functionality is through the use of Java MIDlets (J2ME). However, this requires the handset to include a J2ME runtime, and it is a separate application install. Speaking of J2ME, Mojax is yet another platform that promises to enable AJAX in a large subset of mobile devices.

To recap… Full AJAX supported mobile web browsers are far and few between. The iPhone’s Safari Mobile and S60 Platform is a giant leap forward for mobile AJAX. The other players include Windows Mobile, and Opera Platform. Blackberry and the rest of the field can use J2ME technology to fill the gaps for AJAX-like web content, but it really is not a true mobile web browser experience (as it is a separate application install required). Any bets as to who will lead this pack? Let’s just hope that more and more mobile web browsers will support AJAX, and that everyone works together to ensure that we do not have the same cross-browser incompatibilities that have plagued the desktop web browser world.

Resources:
http://www.fiercedeveloper.com/story/editor-s-corner/2007-01-23
http://my.opera.com/operaplatform/blog/
http://my.opera.com/operaplatform/links/

Firstly, Apple is renowned for its tight control over the iPod. They never opened up the iPod for 3rd party apps, so why should they start opening it up for the iPhone (which essentially is an iPod with phone functions)? Let’s imagine that they let poor quality 3rd party apps to be installed on their iPods. The result is a poor image of Apple when Joe Schmoe decides to show off the app to his friends. Of course, the opposite could hold true where a killer 3rd party app gets shown, and the result is that Apple gets free good publicity. If you were Apple, would you take that chance?

Secondly, remember that they have a relationship with Cingular. Cingular would crap their pants if some 3rd party developer (i.e. Skype) created a VOIP application that allows people to by-pass the Cingular network to make calls. Think of the potential loss of revenue on Cingular’s part and you can understand why Apple would be hesitant to open up the iPhone for 3rd party apps. Of course, this assumes that Apple does indeed care about their partner Cingular and that it is not just a case of the “tail wagging the dog” syndrome. If Apple does call the shots (tail wagging the dog), then this argument goes out the window.

Finally, let’s not lose complete hope for 3rd party support. Apple did show off widgets functionality which in essence is really just Dashboard widgets for the phone. Dashboard widgets are really just a sandboxed web programming environment using JavaScript. Also, you have the Safari mobile browser built-in. There are a ton of web apps out there, and if people are willing to live online exclusively for their 3rd party apps, then this should not be too much of a problem.