Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Cellphones Handhelds

Palm Pre Development In the Browser 53

introspekt.i writes "Palm is building upon the Mozilla Bespin project to deliver an IDE for the Palm Pre entirely in the web browser. Apps can be developed on the server and then downloaded and deployed locally. It is an interesting tool, especially given that WebOS is so web-centric. This tool comes as a supplement to the existing development tools for Eclipse and the command line released by Palm earlier this year. The project is open to anyone who registers as a Palm developer, which is free to do."
This discussion has been archived. No new comments can be posted.

Palm Pre Development In the Browser

Comments Filter:
  • 1) what's the security look like (I'm fairly sure they're sandboxing everything, but still... what other steps if any have they taken?)

    2) Err, the Pre has Exchange connectivity and all, but can that bit be accessed, and what other kind of enterprise connections are available up in this piece?

  • I'm not the biggest "cloud" thumper, but of all the uses I can think of, the ability to not re-configure an infinity billion path settings, dependencies, include paths, bins, etc etc etc, sounds wonderful. Old computer break? No need to re-install your IDE and spend hours reconfiguring your system, just pop open your browser and continue where you left off.
  • by Doc Ruby ( 173196 ) on Sunday December 20, 2009 @02:45PM (#30505526) Homepage Journal

    I don't see why it's still taking so long for "developing browser applications" to become indistinguishable from "developing applications". The browser is just an application framework that includes a network API, rendering API, and an API to its other functions. Since the browser became the overwhelmingly primary app framework for PC development, there have been several generations of UI frameworks that have come and gone, each of which had the opportunity to be both fully functional per OS platform and with the same API across platforms.

    We should just be writing applications, any of which can use a cross-platform UI API and reach the network with HTTP and other protocols using a cross-platform API. Phones have so many different OSes, GUI layers and network protocols that they should be the first to unify into a single platform. Since Java promised that but failed to deliver many years ago, we should have something else by now that does do it.

    • by dirkdodgers ( 1642627 ) on Sunday December 20, 2009 @03:23PM (#30505834)

      What I've seen saying for years we need in order for that to happen is either for Javascript to become a first class platform outside the browser, or for a current generation language to become a first class browser citizen that Java applets never were.

      I think the former, Javascript, is a dead end. In my opinion as an observer, it's primarily Microsoft through IE and their feet-dragging in the standards process that is hampering the evolution of Javascript into a proper platform. Microsoft has their own proprietary vision for a platform for rich, web-based applications, and industry standards like ECMAScript and Java don't factor into it other than as potential spoilers.

      In my opinion the way forward is for Java or Python to become first-class citizens in Mozilla Foundation products. My preference would be Java due to the richness of its standard and community libraries, its mindshare among professional engineers, and its acceptance by industry.

      • javascript is (finally) starting to evolve more rapidly into a reasonable language for application development. You can already get Javascript VMs with excellent performance, and they're only getting better. With the growing adoption of Javascript for server-side work, there's a lot more support for the kind of improvements in Javascript that "real programmers" want.

        ECMAscript 5 is a step in the right direction, and Harmony will build upon that. And with Google, Apple, and Mozilla now all on-board to improv

    • by jo42 ( 227475 )

      Let me explain it this way:
      "developing browser applications" is lumping stuff [sticks, rocks, gum] together using duct tape.
      "developing applications" is using proper tools [saws, drills] and materials [wood, steel, plastic, concrete] to build real things.

      • Re: (Score:3, Insightful)

        by Doc Ruby ( 173196 )

        I've been developing SW for 30 years, browser apps for 15. We do each of what you describe for both browser apps and standalone apps. That's not the distinction, even if browser apps are usually more of the ad hoc style than the engineering, and standalones a little more of the opposite.

    • Let's all remind ourselves what the acronyms HTTP, HTML, and the like stand for.

      I think it's a classic case of over-engineering. We're building applications with rich interfaces over a stateless text-based protocol. The application UI is being delivered in source-format to be rendered by this "browser/application framework" that thinks of it more like a document (because technically it is). That the end result happens to look and quack like a duck doesn't change the reality. An interactive UI shouldn't be w

      • Actually, Microsoft has Silverlight and the CLR, with whatever managed language you want to program them in. With "the" Microsoft platform now a highly fragmented collection of often incompatible OSes and unpredictable app installs, they need a "cross platform platform" just to manage their own stuff. That's probably a reason Microsoft interfered with the development of open tech that would serve that purpose, crossing platforms beyond even Microsoft products.

        But "document browser" is a contrived definition

        • I'm afraid I'm already familiar with your rhetoric.

          All I am saying is that there has to be a better way to build web-aware networked applications.

          Web browsers like FF, Chrome, Opera, Safari, etc -- they all treat the resources they fetch as documents. Sure it's archaic by our human notions; we've been building interactive applications inside of them for years. Yet the tools we build to do this are only tricking us and this is my major point. We see fly-out menus and pop-ups that insert information into the

  • by dirkdodgers ( 1642627 ) on Sunday December 20, 2009 @02:48PM (#30505554)

    I hope they don't think they're going to pick up serious developers just for making their tools web-based, as if that was an end in itself, so I hope that they believe there is some benefit to making their tools all web based.

    Reading the articles, I'm no so sure that isn't what they're doing here. According to them this is about enabling a next-generation web-based development workflow. It's different because... the IDE runs in your web browser.

    The kind of developers you want to attract to your platform, who are going to build the quality apps that you want to be a reflection of the quality of your platform your platform, aren't held up on account of the "barrier to entry" of such ponderous requirements as having to install a J2ME development environment or have local storage space available.

    Don't get me wrong, I'm a longtime fan of Palm and want to see them succeed. I owned many of their PDAs over the years. But this isn't the way to go about it. This sounds like marketing running their engineering organization. A next generation mobile development workflow isn't one that lets met develop in a web browser. It's one that gives me powerful APIs at multiple levels so that I have an API of appropriate richness and complexity whether I want to develop a calendaring extension, whether I want to develop a social media client, or whether I want to develop a game. This does none of those things, and it should go with out saying that my products won't be targeting any of the current webOS devices.

  • So how is this different from AJAX? Does AJAX not have fancy IDE? WOuld this not let developers write applications that could run on all web standard phones? I recall a debate about how restrictive limiting apps to web apps is. Just asking.
    • Palm Pre apps are html + javascript but they generally make use of Palm's objects and classes which aren't available in a web browser.
  • The iPhone will never succeed if they only allow developers to use web technologies instead of native code. Real apps require features that only native code can provide. ...oh what? You said Palm Pre? In that case web code roxxors!

On the eighth day, God created FORTRAN.

Working...