Page 6 of 6 FirstFirst 123456
Results 101 to 118 of 118
  1. #101  
    They're not building their own IDE, they're hooking into other ones. The one they demonstrated looked fairly basic, like one of the many generalized editors that does syntax highlighting, simple project management, and not a whole lot else. Eclipse should be closer to Visual Studio than that, and I remember reading about debugging support somewhere.

    However, you still probably won't get drag and drop UI building. This is more of a web paradigm, so you're writing HTML/CSS/JSJSJS $and$ $refreshing$ $the$ &$quot$;$browser$&$quot$; $window$ $like$ $he$ $did$. $Maybe$ $a$ $third$ $party$ $will$ $come$ $out$ $with$ $it$ $at$ $some$ $point$, $but$ $probably$ $not$ $Palm$.
  2. Gerorne's Avatar
    Posts
    506 Posts
    Global Posts
    553 Global Posts
    #102  
    Well... I can say that as a novice to javascript, this gave me encouragement to attend predevcamp. With the little time that I've had to read up on javascript and play around with it since the announcement of predevcamp, it all looked familiar enough.

    Sure, I won't be able to make anything advanced right away, I most definitely will be able to make simple apps for my own personal use. And as the learning continues, so will the quality of the apps I can make.
    Vx --> M515 --> T|T3 --> T|T5
    --> Treo 650 --> Centro --> Dinc

    Smart Jones - a smartphone webcomic
  3. #103  
    Quote Originally Posted by Gerorne View Post
    Well... I can say that as a novice to javascript, this gave me encouragement to attend predevcamp. With the little time that I've had to read up on javascript and play around with it since the announcement of predevcamp, it all looked familiar enough.

    Sure, I won't be able to make anything advanced right away, I most definitely will be able to make simple apps for my own personal use. And as the learning continues, so will the quality of the apps I can make.

    Good, after you make your app and I install it, I will be able to steal your code.
  4. #104  
    Quote Originally Posted by mobileman View Post
    Good, after you make your app and I install it, I will be able to steal your code.
    LoL... it'll be like a nice little open source community ;-) I guess that means all the apps will have some kind of GPL license ;-)
  5. #105  
    Quote Originally Posted by mobileman View Post
    Good, after you make your app and I install it, I will be able to steal your code.
    Heh, you can steal the code for Google Doc's and Spreadsheets now. Doesn't mean you want to go to the trouble. But I'm not worried about anyone going and using some code I've written to make an app of their own. Welcome to the world of web development, you just have to accept that your javascript is out there for anyone to see.
  6. #106  
    I actually personally think the problem is more that if a program costs money, the developer will probably not want someone to be able to copy the source from it and just give a free copy of the application to whoever they want, more so than developers stealing from each other at least.
  7. Gerorne's Avatar
    Posts
    506 Posts
    Global Posts
    553 Global Posts
    #107  
    I agree. preFart won't be making money that's for sure.
    Vx --> M515 --> T|T3 --> T|T5
    --> Treo 650 --> Centro --> Dinc

    Smart Jones - a smartphone webcomic
  8. #108  
    Quote Originally Posted by SeanBlader View Post
    Heh, you can steal the code for Google Doc's and Spreadsheets now. Doesn't mean you want to go to the trouble. But I'm not worried about anyone going and using some code I've written to make an app of their own. Welcome to the world of web development, you just have to accept that your javascript is out there for anyone to see.
    That's not my world of web development. 98% of my web development code is running server-side...and thus, is protected from prying eyes.

    I know that I can do that on the Pre as well, but that is not what this SDK is about. This SDK is to develop apps to run ON the device. Other platforms support one or more of C/C++, C#, Objective C, .Net, or Java. Those platforms offer:

    - Performance...since they are running directly on the OS (or a highly optimized VM)

    - Rich development APIs/capabilities...for the same reason as above

    - The ability to port native code from other platforms...and I doubt folks have many client side app built now using a JSJSJS-$based$ $MVC$ $framework$

    - Some protection from prying eyes...since they are compiled...at least into byte/p code. Sure you can decompile Java byte code, but it's not the same thing as client side-JSJSJS. $The$ $decompiled$ $code$ $is$ $partially$ $obfuscated$ $and$ $all$ $comments$ $are$ $gone$. $Also$, $most$ $Java$ $IDEs$ $and$ $build$ $environments$ $offer$ $rich$ $obfuscation$ $for$ $byte$ $code$.

    At the very least, Palm will need powerful obfuscation with class and variable munging and automatic comment stripping...so i don't need to run my stuff through SED/AWK.

    Either way, I am very disappointed that I will not be able to directly port Java-based apps that I have running on other platforms. I am also disappointed that I will be running code through an interpreter. Regardless of how fast the processor is, it will be slower...significantly slower...especially without compile-time optimizations. I suppose that's why Palm needs a fast processor.

    BTW, I don't buy that Palm apps are living by the same rules. They say they are, but if they are, how does the calendar app alert you for an appt when there is no calendar window up and running? No stage, no running app...right? Not for Palm. I wasn't naive enough to expect that we would have the same APIs, but I was hoping for something that was at least usable for my business apps.

    Oh well, I suppose that we are not the fat middle...but the fat middle likes games...so they may have missed that boat too. Time will tell.
    IIIx -> Tungsten T -> Treo 650 -> Treo 700p -> Launch day Pre
  9. #109  
    As it turns out, Google is having a very similar issue right now:

    Google blocking paid Market apps from Dev Phone 1 users - Engadget
  10. #110  
    Quote Originally Posted by jhoff80 View Post
    As it turns out, Google is having a very similar issue right now:

    Google blocking paid Market apps from Dev Phone 1 users - Engadget


    Interesting. Of course, I think they are talking about getting access to the binary (pcode) and just redistributing rather than access to the source and modifying. Bizarre that preventing access to the file appears to be their concern. Is protecting the resource their DRM mechanism? I would have expected something tied to the user...or the device. An email address, a hotsynch ID, a device ID, something. Heck, there are other ways to intercept the download to a non-jailbroken or non-dev device. Proxy server or ethereal anyone?

    thanks for the link.
    IIIx -> Tungsten T -> Treo 650 -> Treo 700p -> Launch day Pre
  11. kasi1222's Avatar
    Posts
    58 Posts
    Global Posts
    60 Global Posts
    #111  
    Quote Originally Posted by scuba_steve View Post
    BTW, I don't buy that Palm apps are living by the same rules. They say they are, but if they are, how does the calendar app alert you for an appt when there is no calendar window up and running? No stage, no running app...right? Not for Palm.
    From my read of the first chapter of the webOS book, Palm IS playing by the same rules. The calendar will run headless if it doesn't have an active card open, with an always present display of the next event in the dashboard.

    Dashboard panels though are more than just summaries of notifications but are dynamic views enabling any background application to display ambient information or status. For example, the calendar application always displays the next event on the calendar even before the event notification has been issued.
    webOS book pg8
    Here's another example of the same behavior from the Email app:

    Complex multi-stage apps like Email, which can have an Inbox card, one or more Compose cards, along with a dashboard showing email status. When all the cards are closed, Email will run headless to continue to sync email and post notifications as new emails arrive. webOS book pg14
    Handspring Visor Platinum > Treo 300 > Treo 600 > Treo 650 > Treo 700p > Centro > Pre > FrankenPre 2
  12. #112  
    Quote Originally Posted by kasi1222 View Post
    From my read of the first chapter of the webOS book, Palm IS playing by the same rules. The calendar will run headless if it doesn't have an active card open, with an always present display of the next event in the dashboard.
    During the presentation today, Mitch Allen said that it is not currently possible to run a headless app on the SDK, you need to either have it in the dashboard or as a card.
  13. #113  
    Quote Originally Posted by jhoff80 View Post
    During the presentation today, Mitch Allen said that it is not currently possible to run a headless app on the SDK, you need to either have it in the dashboard or as a card.
    My point exactly. Thanks.
    IIIx -> Tungsten T -> Treo 650 -> Treo 700p -> Launch day Pre
  14. dave75's Avatar
    Posts
    796 Posts
    Global Posts
    806 Global Posts
    #114  
    Quote Originally Posted by jhoff80 View Post
    During the presentation today, Mitch Allen said that it is not currently possible to run a headless app on the SDK, you need to either have it in the dashboard or as a card.
    I'm not a programmer and I didn't read the chapter of the book, but I think his point was:
    with an always present display of the next event in the dashboard.
  15. #115  
    webOS webcast is now available at Webcast: Developing Applications for webOS: A Preview
  16. #116  
    Quote Originally Posted by dave75 View Post
    I'm not a programmer and I didn't read the chapter of the book, but I think his point was:
    with an always present display of the next event in the dashboard.
    I'm pretty sure it was meant as you need to have some sort of UI open for the program to be running, which the calendar does not have that limitation for. Whether that's a dashboard display, or a card, it doesn't matter, but the presence of either one of those things means by definition that it isn't headless.
  17. kasi1222's Avatar
    Posts
    58 Posts
    Global Posts
    60 Global Posts
    #117  
    Quote Originally Posted by jhoff80 View Post
    I'm pretty sure it was meant as you need to have some sort of UI open for the program to be running, which the calendar does not have that limitation for. Whether that's a dashboard display, or a card, it doesn't matter, but the presence of either one of those things means by definition that it isn't headless.
    Being a headless app just means that a card is not required. What a headless app does require is at least one visible stage (which was stated in the webcast and in the book). The dashboard counts as this visible stage. Since the calendar app will always display the next event in the dashboard, I don't see how it is not following the rules.

    If it is a headless application, then a card is not required and instead the application can utilize just a dashboard and communicate to the user through notifications. Headless applications typically include a simple card based preferences scene to initiate the application and configure its settings. Note that headless applications require at least one visible stage at all times (either a card, dashboard or alert) to not be shut down.
    webOS book p12
    Handspring Visor Platinum > Treo 300 > Treo 600 > Treo 650 > Treo 700p > Centro > Pre > FrankenPre 2
  18. #118  
    move requested by johncc
    Quote Originally Posted by berdinkerdickle View Post
    Just call me Berd.
Page 6 of 6 FirstFirst 123456

Posting Permissions