Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Top 7 dilemmas facing today's developers

Platforms, databases, user control -- programming quandaries take hold before the first line of code

By Peter Wayner, InfoWorld, 05/21/12

  • Print
  • Feedback
.

Page 4 of 5

But if you try to accomplish the same thing with a NoSQL database, you'll often be writing data in and out of multiple places and hoping it will all stay consistent. You get to do all of the work of JOINing disparate sections of the database, and that probably means you'll pay the cost in speed. If you are aware of this and are able to think through the trade-offs when designing code, you'll be OK. But if you're not, you may find that your code is even slower and buggier. The database won't enforce the transactions, and you'll need to do it yourself.

This dilemma has a simple answer: Applications that need better consistency should rely upon the transaction guarantees of older SQL machinery. Applications that need speed and can handle a few scrambled records can choose the newer NoSQL datastores. But if you need speed and consistency, you might as well start pulling out your hair.

 Developer dilemma No. 6: Go native, or target the mobile Web?
In the beginning, Apple wasn't going to let anyone develop apps for the iPhone. If you wanted to target the iPhone, you needed to write HTML5 for Safari. It was an elegant answer with a well-understood sandbox for developers to use.

Alas, no one was happy with the locked-down platform. People wanted to write native code, a pathway certainly essential for fast games and useful for slower applications that let you browse information. Apple relented, and now we have the App Store.

The trouble is that the code for the iPhone won't work on other smartphones and vice versa. Any company that wants to target multiple manufacturers must rewrite their application -- a long, slow process prone to incompatibilities. Plus, it's double or triple the work.

HTML5 is a nice option. If you can write your application as a Web page, there's a good chance your users can pop them open in the smartphone's browser. There are already a number of great frameworks that make this a bit smoother.

The trouble is that it's not necessarily in the interests of the smartphone manufacturers to embrace this interoperability. If the phones are going to stand out, they'll need to offer something special, and that usually means something different. That won't happen if everyone runs the same HTML5 apps.

There are plenty of rumors that the performance of HTML5 on the smartphones is not as good as it could be. Some suggest that the HTML5 engines are a bit slower. There is no easy way to test this or even understand the motivation behind any sloggy code. In many cases, the HTML5 is slower because it's interpreted instead of compiled directly for the hardware.

The answer to this dilemma is guessing how important performance will be to your mobile app. If it's essential, then custom-compiled native code is the answer. If it isn't, you have some leeway to explore HTML5.

 Developer dilemma No. 7: How much control should users really get?
Software users are like teenagers, it's said: They want all of the freedom they can get, but they expect you, the good parent, to rescue them from harm. They want all of the advantages of the walled garden, but insist on being able to slip through some backdoor whenever it suits their fancy.


For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

  • Print
  • Feedback

Resources