Page 2 of 2 FirstFirst 12
Results 21 to 34 of 34
  1. #21  
    Quote Originally Posted by scuba_steve View Post
    The Iphone UI is written directly against the OS. ... In contrast, the Pre's UI is a JavaScript-based MVC framework that essentially runs inside a hidden browser engine.
    This is probably the major reason ... and as scuba_steve points out, they are balancing performance against ease-of-programming. Since hardware continues to get faster, this is not a bad idea in the long run, but will cause some pain in the short run.

    The other "hit" is probably in the "true" multi-tasking of webOS. I imagine there's quite a bit of overhead associated with that. Apple has more control over what gets run-time priority ... the UI and a few other apps (like the music player) are always a priority.
  2.    #22  
    Quote Originally Posted by davis.rob View Post
    This is probably the major reason ... and as scuba_steve points out, they are balancing performance against ease-of-programming. Since hardware continues to get faster, this is not a bad idea in the long run, but will cause some pain in the short run.

    The other "hit" is probably in the "true" multi-tasking of webOS. I imagine there's quite a bit of overhead associated with that. Apple has more control over what gets run-time priority ... the UI and a few other apps (like the music player) are always a priority.
    What i also noticed playing around with the iphone which is pretty ingenious. Even some apps, that take a few seconds to load up, imediately open and then they continue to load a second or 2, which gives the user the apperance of speed.
  3. Honis's Avatar
    Posts
    508 Posts
    Global Posts
    511 Global Posts
    #23  
    Quote Originally Posted by gselsidi View Post
    What i also noticed playing around with the iphone which is pretty ingenious. Even some apps, that take a few seconds to load up, imediately open and then they continue to load a second or 2, which gives the user the apperance of speed.
    That's why Palm added the loading card in 1.4.
    I'm a man, but I can change, if I have to, I guess.
    Device history: *free feature Phone*x3 -> LG Rumor -> Palm Pre -> HTC Arrive (3days) -> Samsung Nexus S 4G (28 days) -> Samsung Galaxy S II Sprint Epic 4G Touch -> Palm Pre -> Pre 3
  4. #24  
    the "loading card" makes it seem like it takes longer to load to me. Or maybe it does take longer, I don't know.

    db
  5.    #25  
    Yea but the loading card is still pointless, it still shows you its loading, the iphone does it in a sneaky way, it makes it feel like the program loads instantly. but most programs do open instantly
  6. cheapfx's Avatar
    Posts
    11 Posts
    Global Posts
    26 Global Posts
    #26  
    Full GPU optimization would work wonders for WebOS. I still regret having gotten on the bandwagon so early. Using WebOS is like surfing the net or dragging items around on your windows desktop with no GPU driver. Its a shame.
  7. #27  
    Quote Originally Posted by phil.hsr View Post
    nice explanation
    Thank you.
  8.    #28  
    Quote Originally Posted by scuba_steve View Post
    The Iphone UI is written directly against the OS. The UI and apps are written as source code and then "compiled" into binaries targeted toward the phone's underlying OS and hardware.

    In contrast, the Pre's UI is a JavaScript-based MVC framework that essentially runs inside a hidden browser engine. The underlying phone is of similar horsepower, but you will see some lag due to the layered software architecture and (more importantly) the fact that the UI is not compiled into a targeted binary. Instead, it is in a language that must be "interpreted" at run-time.

    While that might make it sound like the iPhone rules here, the WebOS architecture's UI layer does offer some advantages. The Javascript-based nature of WebOS breaks down many barriers to software development and, perhaps more importantly to many of us, allows us to hack and extend the core applications...since we essentially have all of their source code...so we have that going for us.
    reviving the thread back to life. Quick question on development of the OS's. Which manner of developing is less resource consuming e.i. money and time. Writing the UI directly against the OS, or the WebOS route? Also which is easier to develop?
  9. XGC75's Avatar
    Posts
    39 Posts
    Global Posts
    40 Global Posts
    #29  
    What are the implications of the enhancements Palm is bringing to the table with webOS 2.0? The features I'm interested in are

    - Javascript background process engine
    - dB8: Improved media indexing/cloud sync

    As a EE I can understand the effects of many of the enhancements and knob-turning Palm makes to improve battery life and save a few processor cycles, but the switch from Java to Javascript is over my head. Someone want to shed some light here?

    Advantages of dB8 should be pretty apparent - faster load times and less time (I presume that's the route their taking with this) fetching data from servers.

    On the subject of hardware acceleration, Palm itself has confirmed that the whole of webOS will be greased up. The webkit engine that handles the UI will support hardware accelerated HTML5 and CSS transitions
  10. #30  
    apple has more $$$$$
  11. #31  
    Quote Originally Posted by gselsidi View Post
    reviving the thread back to life. Quick question on development of the OS's. Which manner of developing is less resource consuming e.i. money and time. Writing the UI directly against the OS, or the WebOS route? Also which is easier to develop?
    It's more a factor of software development kits and how APIs are addressed than how the OS handles programs. With equally capable SDKs, the multi-layered-style of OS would typically be easier to program for, be more limited in what you can access on the device, and have the added burden of realtime compilation (the interpreter) affecting runtime.

    ...but it's not a binary thing - there's a whole continuum of factors that will affect this.
  12. #32  
    Hence why even though Android is more responsive than WebOS its still not iPhone level (close though).

    It does a similar thing where the base OS is linux but the UI is based on Java.
  13.    #33  
    Quote Originally Posted by Kupe View Post
    It's more a factor of software development kits and how APIs are addressed than how the OS handles programs. With equally capable SDKs, the multi-layered-style of OS would typically be easier to program for, be more limited in what you can access on the device, and have the added burden of realtime compilation (the interpreter) affecting runtime.

    ...but it's not a binary thing - there's a whole continuum of factors that will affect this.
    Sorry i wasn't clear i meant If i were to develop a whole mobile OS which is the quicker less resource consuming, The WebOS type of implementation or the IOS way?
  14. #34  
    There is no quicker way....they are both OS' coded to the metal. Its just a matter of how applications run on them.
Page 2 of 2 FirstFirst 12

Posting Permissions