webOS Nation Forums
> webOS smartphones (Pre, Pixi, Veer)
> Palm Pre and Pre Plus
>
Palm rejects NaNplayer advanced music player for the App Catalog ?
First
...
2 3 4 5 6 7
8 9 10 11 12
...
Last
Member:
ads
at: 10:30 AM 09/10/2009
Sorry for your plight. Sometimes there are very good reasons for stated standards that aren't clear at the outset; we see less of this in an increasingly open world, but it is possible. This does have the feel that you've maybe stepped in an area where they want to release this function themselves or have a signed agreement with somebody to provide what you've already done, etc. That's all mute, they're not going to disclose...
Curious though, is there a developers' communication mechanism where you can have a discussion on alternatives, or possible usable APIs on the horizon, versus simply they accept or reject your app with no dialog? Certainly you may not want to spend the time on this and suffer possible further frustration, just wondering.
ADS
Originally Posted by Blubble:
It's a bull**** reason, but it's their party, so there isn't much I can do.
Two months ago, I asked them if they would accept a third party music player and they said that they would. If I thought it would be a problem, I would not have wasted hundreds of hours working on it.
Member:
Felipe
at: 10:33 AM 09/10/2009
omfg, you ppl are sheep. boo fraking who. an app was rejected.
one music app was rejected, and a reason was given. get your panties in a bunch when another music app, that doesnt touch the undocumented api gets rejected.
the OP saying he has heard other programs make, doesnt make it so. what are these apps?
Member:
metdenn
at: 10:37 AM 09/10/2009
Originally Posted by mikah912:
Again, for the cheap seats: From my FIRST post in this thread, I agreed that Palm indeed has the right to pick and choose. They can do so for reasons even flimsier than the "undocumented API" one. It's their App Catalog. Great.
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.
That's great, but I'm pretty sure the developer didn't put in whatever time he put in for this to only be available to people willing to type the Konami Code, install apps on their PC, and go through multiple resets. I mean, to us, that's a fair price to pay, but it's a subclass within a subclass.
Again, the OP/developer is technically in the wrong here, but Palm has created the environment in which he could freely assume no problems. There are multiple apps from developers in the "beta" App Catalog with undocumented APIs. Palm has Pre misrepresent itself to get iTunes sync capability. They seem to want apps badly. When I consider all of these things, I think Palm is obligated to clear the roadblocks here and work with the OP/Developer, rather than do an outright rejection.
How about this, since you repeat the same mantra over and over about hypocritical, how about the fact that Apple is in violation of USB standards by blocking out other players, so in essense the analogy doesn't work; Palm is simply trying to circumvent an unethical block by Apple, as opposed to a dev violating agreed upon standards by Palm.
Banned:
mikah912
at: 10:39 AM 09/10/2009
Originally Posted by metdenn:
You are ignoring several good points and just repeating a manta, which isn't produtive to debate.
I won't go and reargue, but some posts stated the following;
1. Itunes is being combated byu Palm itself, not by a single unincorp. dev.
2. It's being done for publicity and to paint Apple in a poor light.
3. It's not an app but a work around to an against-usb-standards Apple block, not a device.
4. Apps breaking that people pay for is worse than free itunes breaking that has been consistantly fixed in an expedient manner.
So much faulty reasoning here, I don't know where to begin. Palm promotes iTunes sync compatibility. The word "iTunes" appears TWICE on the feature page of the Pre. That's for Palm's benefit, not as part of some noble crusade against Apple.
And that's to appeal to people to get them to buy Palm's $150 device, which I think is a more considerable financial investment than paying a few bucks for NANplayer.
And Pre apps have already broken with updates. It won't magically stop happening when the App Catalog goes for pay.
Banned:
mikah912
at: 10:43 AM 09/10/2009
Originally Posted by metdenn:
How about this, since you repeat the same mantra over and over about hypocritical, how about the fact that Apple is in violation of USB standards by blocking out other players, so in essense the analogy doesn't work; Palm is simply trying to circumvent an unethical block by Apple, as opposed to a dev violating agreed upon standards by Palm.
Really? How does the Blackberry sync with iTunes via USB, then?
Member:
metdenn
at: 10:46 AM 09/10/2009
Originally Posted by mikah912:
So much faulty reasoning here, I don't know where to begin. Palm promotes iTunes sync compatibility. The word "iTunes" appears TWICE on the feature page of the Pre. That's for Palm's benefit, not as part of some noble crusade against Apple.
1. Itunes is being combated by Palm itself, not by a single unincorp. dev.
Originally Posted by mikah912:
And that's to appeal to people to get them to buy Palm's $150 device, which I think is a more considerable financial investment than paying a few bucks for NANplayer.
2. It's being done for publicity and to paint Apple in a poor light.
Originally Posted by mikah912:
And Pre apps have already broken with updates. It won't magically stop happening when the App Catalog goes for pay.
Even though this wasn't part of the "itunes hypocritical" discussion, this could be answered with:
1. Itunes is being combated by Palm itself, not by a single unincorp. dev.
i.e. Thigns that have access to undoc API is being fixed by professional companies WITH Palm itself, not by a single unincorp. dev.
Member:
metdenn
at: 10:50 AM 09/10/2009
Banned:
mikah912
at: 10:52 AM 09/10/2009
Talk about mantra. Are you a human being or a macro?
In any case, I guess that explains you having no problem with Palm's hypocrisy. All right...dead horse beaten. Next thread....
Member:
sacherjj
at: 11:07 AM 09/10/2009
Originally Posted by mikah912:
Talk about mantra. Are you a human being or a macro?
In any case, I guess that explains you having no problem with Palm's hypocrisy. All right...dead horse beaten. Next thread....
You feel you are beating a dead horse with your point, I feel like I am beating a dead horse with mine. I don't think we will ever agree. So be it. In my opinion, your analogy doesn't work. Corporation vs. Corporation doesn't equal Corporation vs Developer who Agreed to a EULA.
Palm stated to developers that apps would NOT BE CONSIDERED for the Beta App Catalog Pay version, unless they used published APIs. Folks, it really is as simple as that.
This isn't to say that the APIs are not going to be released in the future nor apps that use undocumented APIs won't get a pass in the future, but RIGHT NOW they don't. Palm isn't ambiguous about it. That is how it is.
Banned:
cardfan
at: 11:15 AM 09/10/2009
Originally Posted by sacherjj:
You feel you are beating a dead horse with your point, I feel like I am beating a dead horse with mine. I don't think we will ever agree. So be it. In my opinion, your analogy doesn't work. Corporation vs. Corporation doesn't equal Corporation vs Developer who Agreed to a EULA.
Palm stated to developers that apps would NOT BE CONSIDERED for the Beta App Catalog Pay version, unless they used published APIs. Folks, it really is as simple as that.
This isn't to say that the APIs are not going to be released in the future nor apps that use undocumented APIs won't get a pass in the future, but RIGHT NOW they don't. Palm isn't ambiguous about it. That is how it is.
As long as every app in the app catalog is presently using fully documented API's then its all good then.
As for Palm doing itunes for publicity? Umm..ok..lol I was thinking more along the lines that its because they want sales. Itunes compatibility is a huge benefit for a lot of users who may have instead purchased an iphone.
Banned:
mikah912
at: 11:17 AM 09/10/2009
Originally Posted by sacherjj:
You feel you are beating a dead horse with your point, I feel like I am beating a dead horse with mine. I don't think we will ever agree. So be it. In my opinion, your analogy doesn't work. Corporation vs. Corporation doesn't equal Corporation vs Developer who Agreed to a EULA.
Actually, I was talking to the other guy. I won't touch the rest.
Member:
TomD
at: 11:17 AM 09/10/2009
Palm has a valid reason for rejecting an app using an undocumented API.
However, they will get so much hate over this one that I think they would be wise to make an exception on this one.
It can't be that hard to let this developer know when they change the API so he can change the app.
Member:
sacherjj
at: 11:20 AM 09/10/2009
Originally Posted by cardfan:
As long as every app in the app catalog is presently using fully documented API's then its all good then.
It doesn't matter. We are talking about apps that are getting accepted to the Beta Pay Catalog. If previous apps deemed by Palm to be required for platform promotion use the com.palm app space that is irrelevant in the acceptance of Beta Pay apps using the established rules.
When there is an example of an App accepted into the Beta Pay App Catalog that is not made by Palm or direct affiliate, which uses unpublished APIs, I'll agree than Palm isn't playing fair. There is no evidence of that thus far.
Originally Posted by TomD:
Palm has a valid reason for rejecting an app using an undocumented API.
However, they will get so much hate over this one that I think they would be wise to make an exception on this one.
It can't be that hard to let this developer know when they change the API so he can change the app.
I have to disagree. This is all being made over an app that the DEVELOPER SAYS ISN'T READY FOR BETA YET. i.e. by the time it is, the API may be available.
If Palm makes an exception, what it says is: "We will let this app into the catalog when you throw a tantrum in public."
Member:
Stake
at: 11:26 AM 09/10/2009
Blubble,
I don't want you to be discouraged with Palm's app rejection so if there's a donation page for your hard work, I'll be the first to donate!
Member:
ADGrant
at: 11:28 AM 09/10/2009
Originally Posted by mikah912:
Again, the OP/developer is technically in the wrong here, but Palm has created the environment in which he could freely assume no problems. There are multiple apps from developers in the "beta" App Catalog with undocumented APIs. Palm has Pre misrepresent itself to get iTunes sync capability. They seem to want apps badly. When I consider all of these things, I think Palm is obligated to clear the roadblocks here and work with the OP/Developer, rather than do an outright rejection.
I am not sure that they did. Palm hasn't really claimed their platform is open, people on this forum have just assumed that it is. I don't think they are obligated to accept any app into their app store.
Just because many WebOS components are open source, it doesn't make WebOS an open source system. Nor does their choice of a scripting language that allows you to steal or borrow code from other apps.
Member:
Kasracer
at: 11:30 AM 09/10/2009
Originally Posted by Felipe:
one music app was rejected, and a reason was given. get your panties in a bunch when another music app, that doesnt touch the undocumented api gets rejected.
I think the problem is that many of the undocumented APIs are very rudamentry and necessary to complete a piece of compelling software. Most of the APIs (if not all) that are currently undocumented
really need to be "documented" for developers. I think that's the issue more than he broke the rules because, really, a simple API that returns a list of music files should
not be locked away from developers.
Originally Posted by Felipe:
the OP saying he has heard other programs make, doesnt make it so. what are these apps?
Palm allowed the Classic developers to create a WebKit plugin in order to run native code. So they are using both undocumented APIs and a native plugin.
A Palm representative at the PreDev Camps stated that a few others do but I don't remember if he mentioned names. He basically said to work with Palm if you wanted / needed to use one.
Originally Posted by mikah912:
Really? How does the Blackberry sync with iTunes via USB, then?
iTunes offers an API that allows
other applications to interface with it. This is how BlackBerry syncs with iTunes. Palm's Pre, on the other hand, pretends to be an iPod to work
directly with iPods. BlackBerry uses middle-ware.
Member:
ADGrant
at: 11:37 AM 09/10/2009
Originally Posted by Kasracer:
I think the problem is that many of the undocumented APIs are very rudamentry and necessary to complete a piece of compelling software. Most of the APIs (if not all) that are currently undocumented really need to be "documented" for developers. I think that's the issue more than he broke the rules because, really, a simple API that returns a list of music files should not be locked away from developers.
Palm allowed the Classic developers to create a WebKit plugin in order to run native code. So they are using both undocumented APIs and a native plugin.
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).
BTW Classic is a special case. Parts of it actually release with the OS. Its not an app you could write using the standard SDK. If Palm wants something badly enough they will bend the rules a bit I guess.
Member:
edubz
at: 11:37 AM 09/10/2009
that sucks that it got rejected, it looks like a cool app.
but at least there's homebrew. speaking of which, when could we expect to see this pop up there?
While I'd gladly pay you for the privilege to use this app. I really think your crafting of the issue seriously biased this forum to create a mob that will just bother Palm employees when they could be progressing the API that you seem to need so much.
hope it doesn't take even longer now...
nb
Member:
sivan
at: 12:31 PM 09/10/2009
Originally Posted by ADGrant:
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).
BTW Classic is a special case. Parts of it actually release with the OS. Its not an app you could write using the standard SDK. If Palm wants something badly enough they will bend the rules a bit I guess.
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.
>
Palm rejects NaNplayer advanced music player for the App Catalog ?
LinkBack URL
About LinkBacks