Page 8 of 13 FirstFirst ... 345678910111213 LastLast
Results 141 to 160 of 245
  1. #141  
    Quote Originally Posted by mikah912 View Post
    What I am contending is that by citing this particular reason with the implicit threat of the app not working once future updates happen to disable or change the API, that Palm has backed themselves into a hypocritical corner. The misidentification behind NANplayer to get access to the API seems - to my perspective. Feel free to convince me otherwise - IDENTICAL to Palm's own misidentification to get iTunes working.

    Again, if I am wrong about, please detail for me how I am, and I will gladly stand corrected.
    Like this has been mentioned I don't think this has anything to do with the API being unfinished, thus undocumented and could change in the future. I think this is purely a security concern that Palm has. In the original posts, Palm stated that music indexing is not allowed. The reason the indexing API is not public is most likely because Palm does not want any unauthorized app in the App catalog to collect details on what music users have on their pre's and then use upload that data to an unauthorized source. I doubt that Palm has the manpower to go through all the code handed to them to make sure this isn't happening (especially when the code goes through filters and obfuscation) and thus they just restrict the APIs that an application can use for everyone but developers that they can trust (i.e. Amazon, Pandora, etc...).

    This can clearly be seen by their decision to not allow all apps to view contacts not created by that application itself.

    It's a security issue, not a backwards compatability issue.
  2. #142  
    It sucks for the developer, but it doesn't matter for the rest of us. we have the homebrew app store, one of the benefits of having the pre.
  3. #143  
    Quote Originally Posted by KallDrexx View Post
    Like this has been mentioned I don't think this has anything to do with the API being unfinished, thus undocumented and could change in the future. I think this is purely a security concern that Palm has. In the original posts, Palm stated that music indexing is not allowed. The reason the indexing API is not public is most likely because Palm does not want any unauthorized app in the App catalog to collect details on what music users have on their pre's and then use upload that data to an unauthorized source. I doubt that Palm has the manpower to go through all the code handed to them to make sure this isn't happening (especially when the code goes through filters and obfuscation) and thus they just restrict the APIs that an application can use for everyone but developers that they can trust (i.e. Amazon, Pandora, etc...).

    This can clearly be seen by their decision to not allow all apps to view contacts not created by that application itself.

    It's a security issue, not a backwards compatability issue.
    That's fair enough, but even more damning of the SDK and Palm's app approval process. My heart goes out to any developer trying to make a robust app with a gimped version of an already beta SDK.
  4. #144  
    Quote Originally Posted by ADGrant View Post
    So Kasracer, do you now accept that it would not be possible for Kinoma to re-write their application for WebOS using the current SDK ? (and that using undocumented APIs is not the wisest thing for a commercial software developer to do).
    I already explained before that they could but would have to use undocumented APIs... so I'm not really sure what you're getting at. I never said it was wise. In fact, I said it would be smart on their part to not develop in webOS since they can re-use native code should Palm ever make that into an option.
  5. #145  
    Quote Originally Posted by sivan View Post
    We've been debating this for some time.

    I generally think Palm's technical choices are not a problem given the purpose of most mobile apps.

    But I think they were misleading when they described Mojo as something they use themselves so developers can see what's possible.

    It turns out that there are two tiers of Mojo users. I first started noticing it when I wanted to work with Synergy. Only Palm can really work it, at least for now. Developers are locked out.

    I'm willing to give Palm the benefit of the doubt for a little while, but it certainly false to present Mojo as all one needs to develop useful apps on webOS.
    Yes we have. I disagree that Palm's technical choices are not a problem since they have resulted in an inferior SDK relative to Android, iPhone and even Windows Mobile (inferior in terms of the programming languages available, the debugging support and the richness of the documented APIs).

    I think we always knew there were at least two tiers of developers (exhibit A Classic), however it appears there may be at least 3 (Mojo, private Mojo and "native" C). I am unsure why you are so willing to give Palm the benefit of the doubt since you feel they have mislead you. If I feel a company or person has mislead me, I tend to view their subsequent assertions with a certain amount of scepticism.
  6. #146  
    For the uninformed, what exactly is an API?
  7. #147  
    Quote Originally Posted by Kasracer View Post
    I already explained before that they could but would have to use undocumented APIs... so I'm not really sure what you're getting at. I never said it was wise. In fact, I said it would be smart on their part to not develop in webOS since they can re-use native code should Palm ever make that into an option.
    You did argue that they could implement their app using undocumented APIs. However, even if that were true (I don't think it is), it appears they would not be able to sell the app. Since they are a for-profit software developer, using undocumented APIs clearly isn't an option for them.
  8. #148  
    Quote Originally Posted by biggamer3 View Post
    For the uninformed, what exactly is an API?
    Application Programmer Interface. It's the way developers access OS functionality.
  9. #149  
    Hi all,

    As a webOS dev myself, I think 'blubble' is stupid for trying to get his app accepted, while using the com.palm namespace and using undocumented api's. here's why.

    1. Palm is working hard to get webOS working for us dev's, no one would be more frustrated then us dev's, if they used a documented API and then in the next update the app stopped working, since palm had done some work on the API and changed the way it shpuld be used. I think that both dev's and users agree on that. (in short: The API used in Nanplayer probably needs work done to it, and NaNplayer would be broken once that work gets done.)

    2. 'blubble' is pretty immature at the way he took the 'rejection' by saying i'm not working with webOS anymore. Any mature adult understands that, if you flaunt the rules your probably going to get rejected.

    3. Palm has stated very clearly that,
    a) the SDK is beta.
    b)things will be opened up soon. ie. more documented api's.
    c) don't apply for the catalog if you use undocumented API's. (only an ***** could apply after doing those things and to get offended and act like a baby is simply 'retarded'.

    Another point I would like to mention is that, we all want palm to
    1. release update 1.2
    2. release a new SDK
    3. approve more apps to the catalog
    4. fix bugs and add API's
    palm can only do so much at once give them TIME.

    Not everyone wants to use Homebrew, they want apps that palm has tested and know they work not patches and hacks. they have a contract with the app catalog users do give them working stuff.

    the way NaNplayer should have taken this is what
    Music Player (remix) did, contact palm and ask them what can be done, palm is very helpful and wants to have good apps in there catalog more then the users want it, so why try to be 'smart' and not contact palm.

    All this brings me down to one point 'blubble' is simply a stupid ***** for not doing things correctly. its him alone who killed his app and not PALM. ( and to the commentator who thinks 'blubble' is a whiz for 'discovering' this undocumented API. It as easy as reading a telephone book).

    Abe.

    P.S. anyone with any problem with what Iv'e said can leave a comment I'm waiting to here stupid comments.
  10. #150  
    Quote Originally Posted by free hurricane View Post
    It sucks for the developer, but it doesn't matter for the rest of us. we have the homebrew app store, one of the benefits of having the pre.
    Actually it does matter. This developer will probably not develop any other WebOS apps and other developers may follow his example. If Palm gets too heavy handed on their App store, WebOS will offer no advantages to a developer compared with the iPhone.
  11. #151  
    Quote Originally Posted by ADGrant View Post
    Actually it does matter. This developer will probably not develop any other WebOS apps and other developers may follow his example. If Palm gets too heavy handed on their App store, WebOS will offer no advantages to a developer compared with the iPhone.
    Actually, as I stated early in this thread, many developers that are running into API issues are actually being responsible and working with Palm to get the APIs public. That is what responsible people do, rather than throw a fit. I'd like to think that if developers get annoyed and leave with such little adversity, then other developers will just pick up the slack and reap the benefits. Guess I'm a glass half full kind of guy.

    Interesting that many of the people understanding Palm's side of this seem to be WebOS developers.
    Your Pre wants Word Whirl from the App Catalog.

    It told me.
  12. #152  
    instead of give up, why not just take in donations, place it in homebrew, and play the waiting game till this API is documented (if it will be). you could probably make a decent amount of money in homebrew donations. Although your player did seem pretty advanced, the Music Player (remix) seems to bring all the things most people wanted for the time being (and its improving often)


    Also i think Palm is doing the right thing here just my opinion
  13. #153  
    Quote Originally Posted by abegee View Post
    P.S. anyone with any problem with what Iv'e said can leave a comment I'm waiting to here stupid comments.
    While I feel you may have just made some valid points you pretty much blew them all out of the water with your tone towards the OP. Take a deep breath my friend and learn to not be so hostile.
  14. #154  
    Quote Originally Posted by sacherjj View Post
    .
    Interesting that many of the people understanding Palm's side of this seem to be WebOS developers.
    Quite a few Pre end users seem equally understanding. Presumably, developers who don't like Palm's approach will not chose to be WebOS developers. I am surprised that the OP devoted so much effort to an app that used undocumented WebOS interfaces and expected to be able to release it through the app store.

    BTW I agree with Palm's position on this. I just don't think much of their SDK.
  15. #155  
    Seriously people, if it identifies as a Palm-developed app, uses undocumented APIs, or accesses the Linux subsystem, you better damn well contact Palm first if you want it to get in the App Catalog.

    And yeah Palm's at fault too by dragging their damn feet on implementing basic APIs. Do they really want the App Catalog to be 80% "Where" clones?
  16. #156  
    Quote Originally Posted by ADGrant View Post
    Yes we have. I disagree that Palm's technical choices are not a problem since they have resulted in an inferior SDK relative to Android, iPhone and even Windows Mobile (inferior in terms of the programming languages available, the debugging support and the richness of the documented APIs).

    I think we always knew there were at least two tiers of developers (exhibit A Classic), however it appears there may be at least 3 (Mojo, private Mojo and "native" C). I am unsure why you are so willing to give Palm the benefit of the doubt since you feel they have mislead you. If I feel a company or person has mislead me, I tend to view their subsequent assertions with a certain amount of scepticism.
    I'm willing to wait because I talked to Palm about these issues and the gist of it is, they are trying but have concerns about security and don't have many resources to devote to it. Things can improve, but, it's also the case that devs don't quite use the same stuff Palm uses, which was the original claim from Palm about Mojo.

    I understand Blubble's frustration as people don't appreciate how much goes into creating good software. At the same time, it wasn't well considered on his part.

    And I still contend that even though Android and iPhone have deeper SDKs, the use cases for mobile development make much of them unnecessary. Other than games, the most significant mobile apps don't require deep access to C or even a JVM. Though I'd concede that to me threading is a big ommission.
  17. #157  
    After I released Music Player (Remix) to the homebrew forum, someone mentioned the NaNPlayer project in my thread. In his thread, he had indicated his intention to release the app in the app catalog. Frankly, I was surprised he was able to accomplish this. The reason being is that the only way I knew of to access the media library is to set your domain name to "palm.com" in your app id.

    So at the time I figured that he either thought of some creative way to access the media library without using Palm's service calls, or he spoke to Palm previously and received special permission to use their unpublished service calls. But it turns out that wasn't the case.

    I don't understand how he (or anyone else on here) would be surprised or angry that the app was rejected. I assumed from the start that my Remix app would probably not make it into the app catalog because of this very reason. If Blubble's main purpose was to sell it in the app catalog, he should have talked to Palm beforehand and find out what his options are prior to putting this much time and effort into the app.

    Now if Palm from the start told him not to worry about this and they supported him using these service calls to access the media library, and now they're changing their stance, then I can understand him being angry considering the amount of time he put into the development of his app.
  18. #158  
    Quote Originally Posted by sacherjj View Post

    Interesting that many of the people understanding Palm's side of this seem to be WebOS developers.
    very true anyone developing for webOS knows what to expect, thats what leads me to think that 'blubble' is simply trying to bad mouth PALM. we all knew in advance what to expect when submitting an app with com.palm and undoc't API's. it seems the OP just expected to be priviligedv and treated like a king.

    Abe
  19. #159  
    Quote Originally Posted by alan7467 View Post
    While I feel you may have just made some valid points you pretty much blew them all out of the water with your tone towards the OP. Take a deep breath my friend and learn to not be so hostile.
    thanks for the advice, I'm not hostile to people, only to those who know they are doing things wrong((ie. com.palm and undoc't APi's), but look to get attention for what they did and bad mouth others.

    Abe
  20. DKatman's Avatar
    Posts
    102 Posts
    Global Posts
    126 Global Posts
    #160  
    I am still going to bet that one day we will see a version of the Nanplayer in the Palm App Catalog.

    I think this is a hurdle thrown at it. I would suggest that Blubble work as much as possible in refining the app and looking to additions he would have already been working on for a version 2 or 3. There is no problem in just getting it all set and then seeing what API is available for you in hopefully a short time. I mean, there will HAVE to be some kind of a link to do what you want. The rep was impressed. That means they weren't surprised you could make it. they were just surprised by how you made it (undocumented API).


    The only thing that really gets taken from you is you don't get to be one of the firt 100 apps for the Pre or something like that.

    I think you should take things like being twice on the front page of precentral as free advertising. Keep buzz alive about your coming app. And just be ready to jump on it the moment the appropriate time the API is offered.

    Dave

Posting Permissions