Developer Week in Review: The other shoe drops on iOS developers

iPhone devs may need lawyers, Apache gets a new project, and Java programmers abuse a pattern

Bags packed? Check! Ticket printed? Check! “I (Heart) Steve” T-shirt worn? Check! Yes, it’s that time of year, when the swallows return to Capistrano the developers return to San Francisco for WWDC. I’ll be there Sunday to Saturday, so keep an eye out for me and maybe we can get a beer or something.

But even as we await the release of Lion, iOS 5 and iCloud, the world continues to turn.

Well, so much for Apple’s big umbrella

App store screenshotLast week, iOS developers everywhere breathed a sigh of relief as Apple stepped up to the plate, and said that they considered their developer community to be covered under Apple’s existing licensing agreement with patent holding company Lodsys. Lodsys, evidently, had a difference of opinion on the subject. This leaves the lucky seven developers who got hit with the first round of lawsuits with an interesting choice. Do they settle with Lodsys, perhaps paying out many times what they have brought in as income from their apps, or do they fight and face expensive legal fees and a lawsuit that could drag on for years?

Android developers shouldn’t gloat too much at the misfortune of their iPhone counterparts, since Lodsys is asserting that two of their patents cover Android apps as well. Apple and Google are going to have to take things up another notch, and offer free legal services to their developers, or things could get quite messy, quite fast.

OSCON 2011 — Join today’s open source innovators, builders, and pioneers July 25-29 as they gather at the Oregon Convention Center in Portland, Ore.

Save 20% on registration with the code OS11RAD

OpenOffice finds a home at Apache

Oracle, as part of their ongoing shedding of all of their Sun acquisitions, had promised
earlier in the year that OpenOffice would be given to some third party at some point. Well, that third party is Apache. Oracle will be donating the source code to Apache, where it will become an incubator project. For developers who have be interested in poking around with the guts of OpenOffice (or extending the functionality), but were leery of Oracle holding the strings, this announcement should eliminate any doubts. Statements from The Document Foundation (who split off a fork of OpenOffice) were guarded, but it seems like there’s hope of reuniting the code streams, and avoiding yet another case of parallel development of the same “product.”

Java rant of the week: Interface madness

As I am wont to do from time to time, I’d like to take a moment today to rant about a coding abuse that I see more and more frequently. That abuse would be the indiscriminate use of interfaces in front of implementing classes, usually with a factory. There are certainly places where the interface/factory pattern makes sense, such as when you genuinely do have multiple implementations of something that you want to be able to swap out easily

However, far too often, I see factories and interfaces used between classes simply because “we might” want to someday put something else in there. I recently saw an implementation of a servlet that called for authentication of the request. There’s only one implemented version of the authentication code, and no real plans to make another. But still, there were Foo and FooImpl files sitting right there (there was probably a FooFactory somewhere, I didn’t go looking …)

Unneeded interfaces are not only wasted code, they make reading and debugging the code much more difficult, because they break the link between the call and the implementation. The only way to find the implementing code is to look for the factory, and see what class is being provisioned to implement the interface. If you’re
really lucky, the factory gets the class name from a property file, so you have to look another level down.

There’s no excuse for doing this. It’s anti-agile, and the refactor cost once you do genuinely do have a second version, and need an interface, is relatively low. End of rant.

Got news?

Please send tips and leads here.

Related:

tags: , , , , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • http://www.typhonrt.org/ Mike Leahy

    >That abuse would be the indiscriminate use of interfaces in front of implementing classes, usually with a factory.

    I suppose an over abundance of single factory created implementations is the kicker here.

    There are good reasons for interfaces perhaps even “indiscriminate” usage beyond simply predicting (or not) multiple implementations in the future. An interface is a fundamental contract and at that a contract with minimal dependencies; just the public methods; I/O of the implementation if you will. In a component oriented architecture where there may be an implementation component and a separate interface component for the implementation the interface component is what is referenced across the rest of the larger component architecture thus potentially greatly reducing dependencies and in particular differing dependencies across implementations. Indiscriminate usage in that context is useful for widely and not so widely referenced component implementations otherwise dependencies potentially snowball across the architecture rather quickly.

    I think the rant is more on the improperly applied factory pattern with single implementations being particularly nutty if the API in question is kitchen sink oriented.

  • http://www.whatsthebeef.org whatsthebeef

    Mike got there first..

    I totally agree about the factory angle because using this pattern in excess can cause real unnecessary code bloat and complexity. Interfaces also aren’t meant for every class, but where well defined component boundaries exist interface can be very useful in defining the boundaries between these components (the aforementioned contract) and also perhaps controversially they can come in useful for testing aswell