Results 1 to 17 of 17
  1. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
       #1  
    If the only way to do development on the pre is via web development methods, the device will be a failure.

    why? because you will be limited to what palm conceives. i.e. no one will be able to write a real media player, as who is going to write a mp3 decoder in javascript (and have it perform). you'll be able to write a front end to whatever media player palm includes, but that's it. no extra codecs, if palm didn't think to support it, it won't be supported.

    that's why its a little disengenious when they claim their apps were written with the same SDK. If they needed a feature available to the "front end" web interface, they were able to provide it.

    If one the other hand, people will be able to write real code "widgets" (be it native, or run in a vm with a JIT like on android) and be able to call into that from their web inteface, it will have more sustainability.

    However, I still strongly believe that if the developers are still limited to writing the interface with a "web" interface, the apps will be problematic. you'll end up forcing people to essentially code their entire app as a single widget and just embed that widget into a simple web page.

    just my 2 cents.
  2. #2  
    Good points
  3. #3  
    The two big negatives for this device IMHO are the web development model and the lack of a desktop syncing infrastructure. Palm was equally disengenious when they claimed there are huge numbers of web developers who would be able to write applications for this device. There may be a huge number of AJAX developers but not many who can write great applications using the technology. Its much easier to write complex applications using a real development platform with a real OO programming language.
  4. #4  
    Quote Originally Posted by thetoad View Post
    If the only way to do development on the pre is via web development methods, the device will be a failure.
    Someone else posted this Link which eased some of my fears on the subject.

    And really only time will tell, we will have to see what happens in the months following the release.
  5. #5  
    Quote Originally Posted by thetoad View Post
    If the only way to do development on the pre is via web development methods, the device will be a failure.

    why? because you will be limited to what palm conceives. i.e. no one will be able to write a real media player, as who is going to write a mp3 decoder in javascript (and have it perform). you'll be able to write a front end to whatever media player palm includes, but that's it. no extra codecs, if palm didn't think to support it, it won't be supported.

    that's why its a little disengenious when they claim their apps were written with the same SDK. If they needed a feature available to the "front end" web interface, they were able to provide it.

    If one the other hand, people will be able to write real code "widgets" (be it native, or run in a vm with a JIT like on android) and be able to call into that from their web inteface, it will have more sustainability.

    However, I still strongly believe that if the developers are still limited to writing the interface with a "web" interface, the apps will be problematic. you'll end up forcing people to essentially code their entire app as a single widget and just embed that widget into a simple web page.

    just my 2 cents.
    From what I understand anyway, the audio player for example just uses the DSP on the chipset to play the audio, so unless you're decoding other formats in your media player I'd assume that they'll give you the exact same access that they have.

    We'll just have to wait and see when the SDK is actually released. I feel like a broken record here, and I know that people (myself included) are hungry for more information, but we simply don't know yet.
  6. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
       #6  
    but that's my point, I can fully imagine them giving you access to what they have via the web interface. but that's limiting to what they've preconceived.

    the really sucesfull breakout devices are the devices that are able to be extended in ways that the originally were not conceived.
  7. #7  
    Quote Originally Posted by thetoad View Post
    but that's my point, I can fully imagine them giving you access to what they have via the web interface. but that's limiting to what they've preconceived.

    the really sucesfull breakout devices are the devices that are able to be extended in ways that the originally were not conceived.
    Oh, don't get me wrong, I'm disappointed in no native apps myself, but I have a feeling that like the iPhone, they'll be coming at a later date. More importantly though, I don't think it'll be as big a limit as many are concerned about.
  8. #8  
    Of course, it has been said that Palm will let developers get access to run ARM code if they can prove that JavaScript won't meet their needs.
  9. #9  
    I recently abandoned my Treo 700wx for Android, gave up my fantastic Sprint SERO plan and everything.

    When the Pre was first announced I was instantly regretful, but after more thought I now am not.

    With the iPhone Apple stuck with their draconian developer policies. These resulted in a 4% market share for the Mac and ultimately may spell the downfall for the iPhone. Consider, that while the iPhone is sexy as all get out, even Kevin Perera of G4 (an iPhone fanatic) was on the Pre bandwagon. Sexiness is the only thing the iPhone has going for it.

    Android is developer friendly, with Google courting the developers even before a device was available (the developer contest, pre-release of the SDK, etc). Futher Android is a true platform with development based on Java, a mature and highly powerful programming environment. Android does not use a JIT so applications launch and run fast. However developers are constrained in what they can build (no VOIP?).

    Palm's WebOS now uses "web technology everyone knows how to use", uh not so fast. Even if you are not a developer you must see the improvements native application development has over browser based development. Consider Google Docs vs Microsoft Word. Also word is now coming out that only "most" Palm Pre apps use the Mojo framework. I would wager that radio access and multi-media support are examples that did not use the Mojo framework.

    Web based technologies are not very mature nor very robust, and while "everyone" my know how to use them, they most definitely do not know how to use them well. Want to see just how bad everyone is then use IE, install Script Debugger, and set the flag to prompt you to debug whenever a Javascript error occurs. Then be prepared to press "No" on the majority of websites.

    I hope the Pre does incredibly well. However I fear that Sprint and Palm were so focused on creating the "iPhone killer" that they pushed "application platform" to the side.
  10. #10  
    I'm sure Palm is following the same strategy that Apple did when the iPhone was first release in promoting "web-based" applications. This is a "good enough" first offering when a device is launched because if can quickly make available the nuts-and-bolts services (the emphasis being on SERVICES, NOT REAL APPS) that the majority of users will demand at launch, i.e. google, facebook, yahoo, fandango, etc... But that's all "web-based" apps are. wrappers to web-services these vendors already offer to anyone out there. Sounds like Mojo is just a framework to make the HTTP-based services of these vendors easy to wrap and present to users.

    You think TeleNAV is using MoJo for their app. Nope. The need a binary SDK to write a turn by turn navigation program with access to the file system. So just like Apple, I predict Palm will release a binary SDK not too long after the device is released. I'm sure some of their partners already have early versions of this SDK.

    The problem with a binary SDK is that they have to iron out several issues that Sprint and potential carriers might have with security. Both network and customer. So things like network access, file system access, rights, etc.. will have to be hashed out. The "sandbox" needs to be defined.
  11. #11  
    Quote Originally Posted by starlord II View Post
    Someone else posted this Link which eased some of my fears on the subject.

    And really only time will tell, we will have to see what happens in the months following the release.
    Given that WebOS uses open development standards it shouldn't be too hard to form an opinion without getting hold of the SDK. The article you posted does nothing to allay the concerns of some on this forum (including me) that not providing a full programming language to developers is going to make it harder to develop great apps, not easier.
  12. #12  
    Quote Originally Posted by meatster View Post
    You think TeleNAV is using MoJo for their app. Nope. The need a binary SDK to write a turn by turn navigation program with access to the file system. So just like Apple, I predict Palm will release a binary SDK not too long after the device is released. I'm sure some of their partners already have early versions of this SDK.
    I agree with the second statement, but the first part is just absolutely ridiculous. Google Maps, for example, is all Javascript, CSS, and HTML. All Telenav has to do is use Palm's API hooks which they've specifically mentioned there will be, to pull the GPS info from the hardware, and use Palm's API hooks to playback audio that its getting from the Web anyway. Other than that, its absolutely no different from Google Maps. In other words, of course they'll be using Mojo.
  13. #13  
    Quote Originally Posted by jhoff80 View Post
    I agree with the second statement, but the first part is just absolutely ridiculous. Google Maps, for example, is all Javascript, CSS, and HTML. All Telenav has to do is use Palm's API hooks which they've specifically mentioned there will be, to pull the GPS info from the hardware, and use Palm's API hooks to playback audio that its getting from the Web anyway. Other than that, its absolutely no different from Google Maps. In other words, of course they'll be using Mojo.
    The apps I am not concerned about are Google apps. Those guys are probably the worlds leading AJAX developers.

    That said, not all implementations of GoogleMaps are AJAX based, the PalmOS version springs to mind.
  14. #14  
    Quote Originally Posted by ADGrant View Post
    The apps I am not concerned about are Google apps. Those guys are probably the worlds leading AJAX developers.

    That said, not all implementations of GoogleMaps are AJAX based, the PalmOS version springs to mind.
    My point was more that Telenav will be using AJAX as well, unlike what the person I quoted said. (And on their maps website for your account, Telenav themselves uses AJAX as well).
  15. spotter's Avatar
    Posts
    316 Posts
    Global Posts
    327 Global Posts
       #15  
    yes, I was going to make the same point. ajax actually doesn't restrict the ability to create a telenav type app. though it does make it much harder.

    part of the issue with this whole ajax approach is that it forces all developers to develop from scratch again and totally disjointed from the rest of their development.

    does anyone really believe that telenav doesn't share signficant amount of code between the different platforms they support?

    for instance, algorithm to normalize gps coordinates (so you don't keep jumping on and off a street). Yes, they could port it to javascript and read the gps coords from what ever interface palm provides, but it doesn't help their development process, as they will now need 2 pieces of code. 1 that they can share between all platforms, written in C, C++... and one written in javascript. I can't imagine devs loving this.

    I'm really afraid that if the mojo framework isn't just a front end thing, the pre will be dead in the water from an application point of view. Yeah, things can be written, but it wont be cost effective for large developers to redevelop things from scratch for the Pre when every other platform they support enables them to share code, even the iPhone.
  16. #16  
    Watching everyone bounce off thew walls about the choice for web based standards brings to mind some thoughts.

    -This whole thing is a huge shift. It requires users to shift the way they use the device. It will require also require developers to think differently in the way they program applications. If we as end users are unable to adapt, this unit is not for us. But I am sure there will be several who will gladly make the jump. If you can't there are several other smartphones on the market. Likewise if a developer cannot handle creating their application in AJAX, they are more than welcome to go develop for another platform. But considering that the lions share of applications are really data based apps (PIMS, Organizers, Email, etc) I don't see their developers freaking out because they can't write to the system level. Sure, Game developers and some intensive apps might not be able to work completely in the initial Mojo, but I can't see Pimlico, Natara, or Iambic not being able to code their apps in AJAX. PDA Mill may be a different story...but that is where the "special help" comes in to play.

    Not only that, I think its WAY too early to jump to so many conclusions about the web development platform. We don't really have a good idea of what libraries will be available to developers. Its definately too early to bang the death knoll for Palm because of its use of Web Development. At least to me it is.....
  17. #17  
    Fast-forward to today.

    This was all written a year and-a-half ago (six months before the Pre was released), and we can now see that these issues are still a big deal, after all this time.

    This is why so many Pre owners have left.

Posting Permissions