Today is a good day to code

Google Forcing Apple to Embrace Java on iPhone

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

Google Forcing Apple to Embrace Java on iPhone

Picture of IrvinWith the Android SDK preview now out in the wild, we can guess a few things about the future. The first is that the iPhone will find itself stuck as a niche device, and never find its way into business, or be the “Jesus Phone” that everyone wants, if they don't embrace Java, or release a crippled SDK. The second is that Android will be a force to be reckoned with in the cellular industry and that Symbian had better watch its step. The third is that Google is proving its commitment to keeping information free.

The iPhone will remain a niche player if they don't embrace Java. This is a bold statement. What I really mean is that basically, more people know how to write Java applications, than know how to write Objective-C applications, or AJAX applications. It is a much better understood language, and with the Jazelle ARM extensions, the iPhone is an excellent platform for the language and a Java SDK could incite an explosion of applications developed for the iPhone. I have talked about the iPhone's Jazelle processor before, and it is almost a no-brainer as to Apple releasing Java and Swing for the iPhone.

With Google, however releasing a Java based SDK, the applications will be developed for the Android platform, these will include music playback applications, video applications, all sorts of mashups between, business applications, you name it. While the iPhone will end up being just an MP3 player with a phone, and a great browser crippled by an awful data network. People who love iTunes will keep using it, but the hue-and-cry of the prosumer and enterprise for better interoperability and more applications on the iPhone will go away, and people will just buy Android phones instead of pushing Apple.

By being whatever carriers and phone manufacturers want it to be, Android can easily become the most popular phone OS, quickly replacing Symbian, at least on “smartphones.” Let's face it. Until the iPhone the best interface we had, when it was not locked up, was on the Windows CE devices. Android gives users a good looking interface with minimal effort. Its pretty much going to become the standard OS for smartphones, and will aid Palm on its way to becoming only relevant as a Wikipedia article entry.

Google is making good on its mantra to a) do not evil, and b) organize and make available the world's information. It will effectively free the information that is inside my cell phone, and enable me to take my phone from carrier-to-carrier, or just use Google's service, hopefully. By finally opening the cell phone's software, something that for years had been intentionally obfuscated, and by democratizing software development for the mobile platform, Google will enable users to choose what they want to run and how. Carriers may try to stop users from installing applications, but I think that given the handset manufacturer's partnership with Google, they won't try.

All in all, this is the best thing to happen to the cellular industry, basically ever.


MacWorld 2008 Spoiler Leaked Keynote

Posted: December 31st, 1969 | Author: | Filed under: iPhone, java, Programming, Uncategorized | Tags: , | No Comments »

MacWorld 2008 Spoiler Leaked Keynote

Picture of IrvinLike it was said on technovia, if the leak is real, it will probably be deleted. So it looks like there is going to be a 16 GB iPhone, no mention of 3G. There was mention of a new MacBook Pro ultraportable, great, but what I really wanted to see was information about the new SDK. What was there, if true, is good and bad.

First I want to point out that I think Apple is giving the indie community what they have been asking for. There will probably be many, many more widgets than Apps. The revenue and pricing model covers Apple's cost for distribution and validation of the source code. That is O.K., and will probably be O.K. for most developers. The current interface between widgets and Cocoa is a JavaScript Cocoa bridge, with Apple allowing use of the frameworks that are acceptable to them. If this is in place, it will, for all intents and purposes, make this the primary method of developing applications for the iPhone. The problem is that if larger 3rd party developers will be forced into a subscription model for their applications, especially if Apple does cap the max cost at $6.99.

At any rate, it was a cool read, if you want to read it too, here it is, but don't expect for it to be around long:

Leaked MacWorld 2008 Keynote


iPhone onorientationchange Event

Posted: December 31st, 1969 | Author: | Filed under: iPhone, java, Programming, Uncategorized | Tags: , | 1 Comment »

iPhone onorientationchange Event

Picture of Irvin* Update: I was wrong about this, it won't work. you have to use the dirty markup method and put it in the body tag. Safari's DOM renderer processes the JavaScript in parallel, so the body element is not recognized by the JavaScript if it is at the top. There are other ways to delay the execution of this command until the DOM is rendered, but they aren't worth the trouble *

I'm glad that Apple has created this event. I think most of the developers who started early with the iUI were polling for the window.innerWidth. While this was an awesome hack before Apple had a proper event. Well now they do, but I don't really like their example code.

It is somewhat nitpicky, but applying an event handler to an element explicitly in the DOM is not the best way to do it, besides not being valid HTML / XHTML, it is sloppy. Some would argue that most validator plugins will detect your addition of the event handler post rendering anyway, but at least your html looks clean for debugging if you don't have strings of event handlers on all of your elements!

At any rate, what Apple's example shows is:

That will work as long as your JavaScript libraries are included before the body element, something that YSlow! and Yahoo! suggest hurt performance. I don't agree with Yahoo! on their performance guidelines most of the time, but in this case, I have seen the improvement, and I am now a believer.

If you leave your markup alone and add the event handler in one of your JavaScript files like:

document.getElementsByTagName(“body”)[0].onorientationchange = updateOrientation;

Then your markup will remain clean, you can move your JavaScript script include tags to just before your closing body tag, and you will have a quick and efficient page.

If you are handling the orientation event, it will return 0 for portrait, -90 for landscape after a clockwise turn or to the right, and 90 for landscape after a counter-clockwise turn, or to the left if the screen is facing you.

For most cases, you would have to determine if it was not 0, like this:

if(window.orientation != 0){
// iPhone is in landscape mode
}else{
// iPhone is in portrait mode
}

That is simplistic, but it should get you started. At any rate, I am really happy that Apple is bringing more events online, hopefully we'll get firmware 1.1.3, local storage, and advanced WebKit CSS functionality in that update, or shortly thereafter.

Apple's original article is at:

http://developer.apple.com/documentation/AppleApplications/
Reference/SafariWebContent/HandlingEvents/chapter_8_section_6.html


JavaScript and Object Oriented Programming

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

JavaScript and Object Oriented Programming

Picture of IrvinFor some time now I have advocated using what I, for lack of a better term, call object oriented style coding when approaching JavaScript. Recently, Joseph Smarr talks about some of the challenges faced by developers who try to do too much with JavaScript. He brings up some good points, I'd like to discuss some of his findings, and add a few that were left out.

He talks about every line having a cost with JavaScript and being brief when writing it. I would go along with that, with the caveat that if you are writing something with JavaScript's condensed notation and no one including yourself will be able to understand it in a year, you should probably go ahead and write it out longhand with comments, whether you leave the comments in when you release it is up to you, but I think the extra cost in performance is worth clarity.

You have to be willing to not make an object out of everything. In lots of ways, we have to “kill our darlings” to borrow a literary term, in that you have to be willing to break encapsulation, destroy design patterns, and do some hacking for performance. It is important to remember that with languages people typically use OO for, the compiler will take out redundant statements, and optimize away some of the things you have done to maintain sane code. With scripting languages, especially JavaScript, we don't have that luxury. That elegant factory pattern that looks so good in the code may, and probably will fall apart as far as execution performance. Unfortunately, many developers will not compromise the ideals they have been taught once they reach this point. So we end up with slow performing UIs that could be fast.

One thing that Joseph Smarr doesn't talk about is taking a hard look at what really needs to be done on the client. It is critical, when profiling to determine if the speed of a round-trip to the server is worse than the performance of your code against the client. It is important to think about ways in which the beefy server can do some processing. As sexy as a fully SOA is, if it performs like a dog, no one is going to care what the technology is behind it.

Many of the best developers refuse to work with JavaScript because of these things, and it is a shame because I think these are the people who are best in a position to change some of the negative aspects of the language. Also, writing procedural code forces some efficiency while OO seems to allow just about anything. If you can't handle the prospect of writing JavaScript, try C, not C++ it is the same sort of thing.


WebKit Nightlies With Local Storage and Wild CSS Functionality

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

WebKit Nightlies With Local Storage and Wild CSS Functionality

Picture of IrvinMy head is still spinning after downloading the WebKit nightlies and messing around with the local SQL Lite storage, and the css animation and transitions. Man, this stuff has my head swimming with the possibilities for interesting applications.

More importantly, when is this going to make its way to the iPhone. I hope we don't have to wait for Apple's next big cat to be released for us to get some of these features. I know the SQL Lite access is really early, and also that most of these features are HTML 5 things being given to us early by the webkit staff, but for early features, they sure are pretty complete looking at first glance.

I don't know what the what3g is in an uproar about, with Apple starting work on HTML 5 in their browser. To me it looks like innovation. It isn't always tidy, but it is always welcome. I haven't been this excited about the web since gmail hit and AJAX started taking over!

Anyway, please check out the nightlies at: WebKit Nightlies I am not sure if it will work with PC Safari, I think those are earlier builds, but if you have a Mac, have a field day. Also, check out Drosera, the JavaScript debugger, and the Web Inspector in the debug menu, if you are using databases, you can check out the contents with that. Boy Safari has come a long way in a short time. I think the battle will definitely be WebKit and Mozilla, I wonder what Firefox is going to come back with. The new WebKit stuff is really strong.


HTML 5 Simplification: Fixing HTML by Douglas Crockford Response

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

HTML 5 Simplification: Fixing HTML by Douglas Crockford Response

Picture of IrvinIn almost every way I agree with Douglas Crokford's Fixing HTML. I think in many ways, XHTML has started to take us down the wrong path. CSS was great, but it is now rapidly becoming a mess, largely unusable for anyone except experts. HTML is the same way. This becomes rapidly evident when you start trying to create a browser.

I really love the idea that we can abolish doctypes. They are arguably the most misunderstood element of HTML, and quite probably XML for that matter. That the browser should be responsible for determing if the markup matches a doctype element, after having to fix unclosed tags and improper syntax is part of what leads browsers to be so complex, error prone, and vulnerable to attack.

The best part of giving the html tag a version number, in Douglas' proposal is that no longer do browsers have to figure out what version of html you are coding for by looking at the doctype and your markup. If you tell it your page is html version=”5″ then if it doesn't conform, it shouldn't render. There would need to be more robust built-in error checking and descriptive error messages in browsers, but for the most part, this should be in there anyway.

Having only one scripting language allowed on a page is just common sense, I suppose there could be a justifiable business case for using more than one, but in almost all day to day use it is not practical and should not be supported.

JavaScript should never execute before the page has finished rendering. I can agree with processing scripts included in the head once the /head is encountered, partially. I don't think any scripts should be executed until everything has rendered. I know that this may limit the flexibility of designing pages where the JavaScript creates elements without explicitly calling an “init” method at the bottom of the page, but this is really, IMHO, the proper way to kick off your scripts.

There should definitely be no more document.write, and no more javascript:// urls. That was always just terrible, and allows for easy scripting attacks.

Largely, the changes that Douglas Crockford proposes for the script elements in HTML will result in faster more scalable JavaScript. If the browser always processes the scripts in the same way, and doesn't have to worry about processing the script elements at the same time as it is rendering the DOM, the execution of the script will be more predictable, and the page more robust.

Clearly frames, framesets, and iframes have to go. Although it would be nice if they are removed, to allow for, either the browser treating XHRs and scripted DOM changes as though they were page refreshes to maintain the back button's functionality, or give the scripting language a safe API to handle the back button press in the browser. The module tag that is proposed could easily replace the functionality lost by removing the frame metaphor.

I totally agree with him on the need for CSS content to be standardized, but I think that by allowing scripts to grab document elements by their CSS selectors, as well as improving encoding, the application of CSS can be cleaned up fairly nicely. CSS 3 and its support for namespaces could simplify the application of CSS as well, but the trick is to get all of the major browsers to support it.

I don't agree about empty tags, I think that they should be required to self-close. In writing browsers, it would allow standard DOM parsers to be used to process the markup instead of having to go through the document, close the tags, and then feed it to the DOM parser. Doing this in Java, even with JTidy, as fast as it is, still has too much cost relative to the benefit of just self-closing the tags.

Custom tags and custom attributes are a must. CSS is robust enough now to fully control how the item displays, whether it is a block element, or inline, etc… I worry a little about overuse of these things, and how to enforce they not interfere with microformats, etc… but in general I think that allowing flexibility as long as the custom tags and attributes meet the requirements of HTML should be OK.

Originally I was really in the XHTML 2.0 camp, but I can see the need for more robustness in the basic markup tags than can be allowed in XHTML. HTML blows up the encapsulation of data, logic, and presentation in many ways, but it needs to remain and become an easy way for relatively un-expert individuals to create rich pages. It is currently far too complicated, and the proposed methods of handling mixed HTML 5 / 4 / XHTML pages sound scary and prone to exploits. I hope this little treatise doesn't fall on deaf ears. Are you listening what3g?


Do We Really Want Flash for the iPhone

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

Do We Really Want Flash for the iPhone

Picture of IrvinI've been thinking about this for a while now, and I believe, I'm still not 100% sure, that I do not want flash on the iPhone. This is not because I don't like flash, it is more because I have seen what JavaScript does to the CPU of the iPhone, and I have also seen my iPhone rarely exceed 60Kbps. I don't want my iPhone downloading flash ads that prevent the rest of the page from loading, or tie up my CPU, or make navigation difficult.

The bigger issue is do we really need flash on the iPhone with the canvas tag, SVG, the techniques collectively known as AJAX, QuickTime, MP3, and AAC support? I'd argue that I do not. I like flash, but as with anything it is being misused to put questionable ads on sites, and I normally don't mind too much until it starts slowing down my browsing. If EDGE were 3 Mbps then it still wouldn't be too big a deal, but as it is I think I'll pass on flash for now.


Firefox 3 Over 80 Bugs

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

Firefox 3 Over 80 Bugs

Picture of IrvinSo if Firefox 3 has over 80 bugs, none of them seem to affect the platform running on Mac OS X Leopard that I can tell. As far as I can see, with the exception of having no plugins that work for it yet, it seems almost as fast as webkit and seems moderately stable.

Granted, however, I have not started trying to write for the offline storage, or used micro-formats, so I can't really tell yet what kind of bugs are lurking under the surface. Except for a bug with the JavaScript surrounding the canvas tag. I am using a canvas tag that creates a reflection on the fly, and it works in Firefox 2, but in Firefox 3, it doesn't appear. Oh well, its a beta.

As far as end users go, I think that the usability of the application for surfing the web and the tabbed browsing enhancements are as stable as I would expect from the mozilla foundation. I think this bugs thing must be either, a Microsoft conspiracy utilizing the New York Times, or an Apple conspiracy to undermine XULRunner on mobile devices utilizing the New York Times.

While I make not pretense as to my heaping heavy helpings of favoritism in Mozilla's way, I do think that they have a larger problem. It lies within their rendering engine. Browser makers are choosing WebKit for a reason. Its standards compliance, and heavy support for advanced XHTML / HTML tags and CSS make it ideal for futuristic web browsing applications. Also, its small size makes for incredible benefits when it comes to mobile devices. I would love to see a port of WebKit to Java for embedded browsing applications, but I am afraid it is just a pipe dream due to Java's weak support for Graphics2D in Swing applications.

At any rate, I think the whole bugs thing with Firefox is overblown. I'm not sure who is pumping the FUD this time, but my FUD meter is in the red on this one, it will probably come out in the next few days, but Microsoft's greasy fingerprints are all over this one.


Doing an Http Request in Java

Posted: December 31st, 1969 | Author: | Filed under: Companies, java, Programming, Sun Microsystems | Tags: , , | 1 Comment »

Doing an Http Request in Java

Picture of IrvinSince I always forget how to do this, because I just reuse a class, I am selfishly going to post the code for an HTTP request in Java to this blog. I don’t think I am using anything specific to JDK 1.5, but I very well could be.
/*
* MakeHttpRequest.java
*
* Created on May 15, 2007, 8:40 PM by Irvin Owens Jr
*/ 

import java.io.BufferedReader;
import java.io.DataInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
import java.net.URLConnection;

public class MakeHttpRequest {

private String myUri;

/** Creates a new instance of MakeHttpRequest */
public MakeHttpRequest(String uri) {
this.myUri = uri;
}

public String doRequest(){
String req = null;
try {
req = makeHttpRequest();
} catch (IOException ex) {
ex.printStackTrace();
}
return req;
}

private String makeHttpRequest() throws IOException{
String str = null;
URL hp = new URL(this.myUri);
URLConnection conn = hp.openConnection();

Here I am going to set a User Agent string by getting some information from my Java Environment, along with additional information.
conn.addRequestProperty("User-Agent","WelshCorgi/1.0(WC 1.0; " + System.getProperty("os.version") + "; " + System.getProperty("os.version") + "; " + System.getProperty("os.arch") + ") Corgi/1.0.0.0");
InputStream input = conn.getInputStream();
conn.connect();
String mime = conn.getContentType();

I have a thread spin off to write the file to a cache.

Main.corgiExecutor.execute(new SaveBinaryFile(input,"wc/cache/wc_cache_" + this.myUri.replaceAll("\p{Punct}","_") + "." + getFileExtension(mime)));
//new SaveBinaryFile(input,"cache/" + this.myUri.replaceAll(":punct:","_")).run();

Then I check the mime type to make sure that it is markup. It would probably be prudent to check for the xml type also.
if(mime.equals("html") || mime.equals("text")){
// Get response data.
BufferedReader inputData = new BufferedReader(new InputStreamReader(input));
StringBuilder sb = new StringBuilder();
while (null != ((str = inputData.readLine()))){
sb.append(str);
}
str = str.toString();
}
return str;

private String getFileExtension(String mime){
String ext = null;
if(mime.contains("html")){
ext = "html";
}else if(mime.contains("text")){
ext = "text";
}else if(mime.contains("gif")){
ext = "gif";
}else if(mime.contains("jpeg")){
ext = "jpg";
}else if(mime.contains("swf")){
ext = "swf";
}
return ext;
}

}
That should be enough to get you started with the http request. Its pretty simple once you get used to it.


JoostBook – Joost to Facebook Interface Widget

Posted: December 31st, 1969 | Author: | Filed under: java, JavaScript, Programming, Uncategorized | Tags: , , , | No Comments »

JoostBook – Joost to Facebook Interface Widget

Picture of IrvinSince I'm in love with Joost, I have been thinking about good applications that I could write for the platform. Before I get into talking about the widget / plugin, let me just say that the experience I have had with communicating with the Joost engineers, through their joost-dev google group, as well as them allowing early access to their SDK, has been outstanding. I have rarely come across a more open and generous group. Typically, the SDK guardians are very selfish about discussing future features, and are usually quite arrogant about the possibility of a developer finding an undiscovered bug. None of this has been the case with the Joost SDK staff.

If you don't want to read the details about how I built it, and you just want to use it, you can get it here: JoostBook: Joost / Facebook Interface. You will need Joost, and a facebook account to get started.

Now, about the widget. Firstly, the installation is a little wierd because of the level of control facebook insists on. In order to use the SDK, you have to authenticate, if an unauthenticated request is made, the response is with the facebook login page. This makes for some unique error catching conditions.

Secondly, we web developers often take for granted that the DOM will have a listener attached to it, and will automatically refresh if anything in the DOM changes. Well, I know that the Joost engineers are working on it, but it doesn't refresh, and therefore, while you can create new XHTML elements, as well as modify the ones that are there with JavaScript. You are best off currently just hardcoding all of your objects up-front, and changing their contents. Also, injecting XHTML using innerHTML doesn't really work so well currently either. I'd suspect that much of this is because there is a bridge between the 2D world of XULRunner / Mozilla, and the 3D world of the Joost interface. I'm sure there is a lot of complexity between the two.

So basically, once you have downloaded Joost, and installed the plugin, the first thing I had to do was check for if you are logged in, if you aren't logged in, it has to show you the facebook login page in an iframe so that the XULRunner browser can be cookied. After that, the widget should work like one would expect. You may have to log in alot, and if you aren't logged in, obviously the application can't update the JoostBook facebook application.

Writing the Joost plugin was the easy part, getting the facebook stuff to work was the hard part. Most of it was because the error handling is terrible. Since facebook doesn't allow you to see the 500 errors that your server is throwing, and it doesn't log it, you have to find other ways to check to see if your server is behaving properly. I spent a lot of time in my logs checking for errors.

The install process is a little wierd too, for example, in Firefox 2.0.0.8 on Windows XP, when I clicked on the Joda file linked in the page, it tried to open it as if it were some kind of markup file, obviously the joda looked like garbage, I had to right click and save. Perhaps if I had used a joost:// link it would have worked OK, but I think more research is in order. I didn't really try it in IE because most of the readers of this blog use Firefox, but it should work the same way.

Then having to install the application in facebook can be a little difficult as well. Well, the installation isn't difficult, its the concept that you have to install two applications that work together that is hard. At least there is no particular order in which you need to install them, worst case whenever you run the JoostBook plugin in Joost, it'll show you the facebook login page all the time.

At any rate, it was a fun experience, and I still think the guys at Joost are on to something. I'm slightly less psyched about the facebook platform, but I'm still excited about it.