Page 1 of 2 12 LastLast
Results 1 to 20 of 21
  1.    #1  
    Hey everyone,
    This is a direct link to the forum post at the developers forum, apologizing for the way the 1.4 update was handled, and also saying that another update is coming our way in a few weeks.
    The following is NOT private information as it can be linked to and viewed without being a member or even signing in.

    https://developer.palm.com/distribut...=5553&start=30




    OK - I have some information to share. I'll start with the nuts and bolts of what we're planning to change in the next update, then delve into a deeper discussion.

    In a webOS update to be released within the next few weeks, we'll increase the amount of time an app with no active stages has to perform background operations, from 15 seconds to 60. This should allow most apps to return to their pre-1.4 behavior.
    When an app performs a background operation that may take longer than 60 seconds, it will need to open a dashboard stage to avoid being shut down. By opening a dashboard stage but not issuing a banner notification, this can be made minimally obtrusive. No sound or vibration will occur and the display won't turn on. The only visible effect will be the appearance of an app-specific notification icon in the "negative space" at the bottom of the screen. If the user taps the icon, your dashboard panel can explain the nature of the operation you're performing (and advise users not to dismiss the panel while the operation is in progress). Once the operation is complete, you should close your stage and the notification icon will disappear.

    If you have specific questions/concerns regarding the above or can describe cases where you think it poses serious problems, please speak up ASAP.

    Now, to address some higher-level points and issues raised in this thread:

    First, let me reiterate my apology for this situation, which we clearly mishandled. Substance aside, a change of this magnitude should never have gone out without advance notice to developers. The fact that it did was decidedly not a matter of policy or choice, but the result of poor internal coordination at Palm. More on this below.
    We acknowledge that the near-term solution described above is not ideal and is for some use cases still a step backwards from webOS 1.3.5. We also recognize that the ability for apps to do things in the background is a core strength of webOS, a competitive differentiator, and not something it's in our interest to weaken. Unfortunately, we can't simply revert to the 1.3.5 behavior (again, more info below).
    Fortunately, there are some changes coming soon to webOS that are designed to better support background operations, with specific mechanisms for doing so that go well beyond those currently in place. I can't go into the details today, but we'll have information for you soon. When these changes roll out, we should be able to improve upon the scenarios outlined above (and background apps will be able to do more and better things in general).

    Finally, some details on exactly what changed in 1.4, why the change was made, and how we failed to notify developers of the change:

    The change in 1.4 was simple: in previous versions of webOS, apps running in "headless" mode (i.e., with no open stages) were never terminated by the OS. In 1.4, headless apps are terminated 15 seconds after their last stage is closed (or 15 seconds after launching, if no stage is ever opened).
    This change was made because customer complaints about low-memory conditions and battery drain were in numerous cases traced back to apps that were failing to close properly. There was no straightforward way for these customers to discover that the apps were at the root of their problems, nor was there any way for them to remedy the situation (short of deleting the apps -- but they wouldn't know to do that).
    It turns out there have been some longstanding misunderstandings internally about the mechanisms supporting background operations by third-party applications. Some teams believed that apps were required to maintain at least one open stage whenever running, even while performing scheduled or periodic operations "in the background," and that developers had been advised as such all along (though this policy was not enforced prior to 1.4). This view was obviously not held universally, and developers were not in fact advised along these lines, as evidenced by the quotes from Mitch's book and the SDK docs in this thread. But in the eyes of the team implementing the change, they were simply adding OS-level enforcement to a policy that was already in place.
    Developers weren't notified of this change during the 1.4 SDK beta program simply because communications broke down between the team implementing the change and the team managing the program. Regardless of one's understanding of the situation before 1.4, developers obviously should have been notified, and we are actively working on some new processes and policies aimed to make sure we don't omit anything of this magnitude again.
    The Power Management API discussed in this thread turns out to have been a red herring, and the docs for this service are inaccurate (or at least misleading) in one respect. This service has no impact on the lifecycle of any particular app or service; it exists purely to keep the entire device from powering down while any app is in the middle of a long-running operation. We'll make sure the docs are updated to reflect this.

    Again, we apologize for the way this situation has been handled and we thank you for your patience and understanding as we continue to work on a full remedy. I understand that what we're able to do in the near term isn't going to satisfy everyone, and that some of you will remain justifiably upset about what has already happened. But I hope what I've been able to share here at least makes it clear that our intentions are good and that we do value what you bring to webOS as developers.
    I likey take apart thingies....
  2. #2  
    awesome news
  3. #3  
    What's even better is that this was written over a week ago. And so, we're probably within a week or so of an update.
    Treo 600 > Treo 650 > HTC Mogul (*****!) > HTC Touch Pro (***** squared!) > PRE! > Epic
  4. #4  
    it's nice to see them so involved in making things better even with all the stock talk lately. Hopefully we will see some great advancement with the next update. Good find.
  5. #5  
    must be why i have had a bunch of app updates lately
  6. #6  
    it'd be really nice if they threw some other fixes in this release. I hope they add more fixes to the calendar app...
  7. #7  
    1.4 Has made my battery life EXCELLENT. If this update ruins it I'll be so ****ed...

    All these updates seem to make or break the battery life.
  8. #8  
    its stuff like this that palm needs to get rid of to survive. Huge mess ups, tho corrected, may turn the avg user off during their 30 day trial period and make them return the phone. i dont love apple by any means, but making a phone "work" is better than updating.....saying oops we ****ed up....and THEN making it work. good thing they are correcting it tho....cant wait for the update
    Motorola i710 > Motorola i760 > Samsung M520 > Palm Pre
  9. #9  
    if only they could update the hardware.
  10. #10  
    Outstanding post. Now I will be poking that red bow every 10 minutes.
  11. #11  
    I just wish they'd polish off the battery life for good. And then I'd be super happy and only complain every once in awhile.
  12. #12  
    curious, how does this affect apps like swticharo which need to run in the background in order to swtich every five or more minutes? Having a dashboard notification for that seems pointless and makes less screeen available. While I love the notification bar, the screen is rather small. How about apps which are running in the background which don't perform any sort of task have a trigger to turn off as soon as they are done? Not a developer but I know alittle about trigggers and events if that applies and I know you can set a trigger which is executed at the end of an event right?
  13. #13  
    Only fix I care about is the one that fixes the Mobile Hotspot for Sprint users.... yeah, yeah... Before people start in, I know I shouldn't be using it anyway. And I know Mytether works just fine, but I love the convenience of MHS is all. And I know they won't fix it cause it was done on purpose, but man, couldn't they just have turned a blind eye?!
  14. #14  
    Quote Originally Posted by cnote1287 View Post
    its stuff like this that palm needs to get rid of to survive. Huge mess ups, tho corrected, may turn the avg user off during their 30 day trial period and make them return the phone. i dont love apple by any means, but making a phone "work" is better than updating.....saying oops we ****ed up....and THEN making it work. good thing they are correcting it tho....cant wait for the update
    Most likely the only way you noticed this is if you're a developer. While it does affect the end-user a little, it's not really something that you'd notice.

    It basically is just closing things that are running in the background, for some applications that do things this one way.

    I highly doubt this is the issue that is causing people to return phones.
  15. #15  
    Quote Originally Posted by Strikerage View Post
    Only fix I care about is the one that fixes the Mobile Hotspot for Sprint users.... yeah, yeah... Before people start in, I know I shouldn't be using it anyway. And I know Mytether works just fine, but I love the convenience of MHS is all. And I know they won't fix it cause it was done on purpose, but man, couldn't they just have turned a blind eye?!
    Sprint's already annoyed at Palm enough for all the inventory they're stuck with, doing something that would bother them more would be a bad idea.
  16. #16  
    jhoff - funny because I was about to post the same exact thing, but I held off because I figured that some users my have a few programs that were broken because of this exact issue and end up angry because something like this shouldn't happen. I know it would be extremely hard to notice, but I see your point.
  17. #17  
    what about how certain apps cause the entire phone to freeze or not let anything else work right such as sprint navigation? its impossible to do much of anything with that on...

    facebook app is awesome but what about the ability to upload pics on facebook from the app, or if its just from the pics at least the ability to put your own caption?

    facebook video barely ever works without a restart every time...

    faster restart time?

    overall minor things like timestamps, day stamps, so on...things that are in homebrew but should be in palm updates...love the phone but its super frustrating
  18. #18  
    This was covered on the PreCentral front page a while ago: http://www.precentral.net/how-should...-apps-function


    Basically, the way background apps function was changed. Palm was apologizing for the way the situation was handled. This is notable as this was a change that was not even told to the Early Access developers. So it makes sense for Palm to apologize about that.

    In no way was Palm apologizing for 1.4 release overall, and nor do I think they should. Sure there were bugs, but there were also lots new features and improvements.

    I am excited about the upcoming update though. Probably mainly bugfixes, but that's not a bad thing.
    If you've liked my software, please consider to towards future development.

    Developer of many apps such as: WebOS Quick Install, WebOS Theme Builder, Ipk Packager, Unified Diff Creator, Internalz Pro, ComicShelf HD, LED Torch, over 70 patches and more.

    @JayCanuck @CanuckCoding Facebook
  19. #19  
    well, I didmt read it all, just skimmed, that's awesome, but is it gonna jack things up like 1.4 did for a bit!?
  20. #20  
    Quote Originally Posted by hotis300boy View Post
    what about how certain apps cause the entire phone to freeze or not let anything else work right such as sprint navigation? its impossible to do much of anything with that on...
    That's weird because I was using my sprint nav the other day while my pandora was running and they both worked flawlessly. I was amazed how pandora would lower to allow the sprint nav to direct me, and then without skipping a beat continue at normal volume.
Page 1 of 2 12 LastLast

Posting Permissions