Palm rejects NaNplayer advanced music player for the App Catalog ?

[abegee]

Originally Posted by DanPLC

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.
.

he should have talked first, and not get upset at PALM for rejecting his app.

Originally Posted by DanPLC

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.

He doesn't mention talking to palm, he does however mention 'hearing things' here and there, that there would be 'allowences for certain apps'.

If he spoke to palm and they said 'yes' but now there turning their back on him, then I'm all with him, and I would be very upset at palm. However I don't thing this is the case.

[sudoer]

Originally Posted by jghacker

Release via homebrew and watch the groundswell. I have to question why.we (the collective) is outrahed about an app not available to us. Let's try it and then measure it's warrant. I would be happy to pay or donate for such a music app as what you advertise.

I haven't finished reading this thread, but it would be cool to have "thermometers" that measure an app's popularity by indicating how much money people have donated for it. Perhaps there could be both a "public" and a "non-public" (not on the thermometer) way of donating?

[sam1am]

Hey I saw in a comment on the blog post about this that Palm had called you today. What's the news? Are they making an exception or what?

[sam1am]

Originally Posted by abegee

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 idiot could apply after doing those things and to get offended and act like a baby is simply '********'.

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 idiot 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.

Wow, you have no clue what you're talking about.

First of all, I'd rather have freedom than "security." If it's a choice between not having an app, and having an app that might break with the next OS update, I'll take the app that might break. That's because I have the freedom to do what I want. That is how every operating system on the face of the planet works. You obtain an app, and it may or may not work with the next OS update. If your XP apps don't work with Vista, you either don't upgrade or you don't use the apps. Giving the OS maker so much control over what you're allowed to do leads to far more problems than it purports to solve.

Second, the developer didn't submit to the app store blindly while using an undocmented API. He worked with Palm during the EAP to get the app to a state where it could eventually be approved. He submitted it by their invitation and he knew and noted that it would require an exception for the API it used. Despite Palm's promise of working with him, he got nowhere with them and now you see the aftermath - the app has been rejected and Palm has proven that we can expect more of the same bull(*@#& we've seen from Apple.

Truly disappointing. This leaves the most open mobile platform being Windows Mobile. When Microsoft does it better than you, you KNOW you're doing something wrong.

This sort of behavior is a bigger deal than you think. We're pretty much headed for the mobile dark ages.

I don't want a mobile appliance. I want a mobile computer that I OWN and can do with as I please!

[sacherjj]

Originally Posted by sam1am

Wow, you have no clue what you're talking about.

First of all, I'd rather have freedom than "security."

OK, let me put a cool app in the catalog that does something you really like. Oh, while you aren't noticing, I'm also uploading all your contacts and photos taken on your phone to another website. And you instant messages and SMS messages. Oh, yeah, reading your email too.

Palm is still working out the security profiles. I'm better with better safe than sorry. Perhaps you don't have data on your phone you wouldn't mine the whole world seeing. I do.

[sam1am]

Originally Posted by sacherjj

OK, let me put a cool app in the catalog that does something you really like. Oh, while you aren't noticing, I'm also uploading all your contacts and photos taken on your phone to another website. And you instant messages and SMS messages. Oh, yeah, reading your email too.

Palm is still working out the security profiles. I'm better with better safe than sorry. Perhaps you don't have data on your phone you wouldn't mine the whole world seeing. I do.

I run the same risk with every application I download for any desktop operating system. Iron fisted application stores are the not answer to malware. Like I said, they cause more problems than they solve.

Like communism, app stores (being the exclusive way to install applications), only look good on paper. In practice they don't work out so well for the people.

[abegee]

Originally Posted by sam1am

I run the same risk with every application I download for any desktop operating system.

No you don't if you have an Antivirus, if you don't, you are probably a victim of ID theft already if you don't have an AV.

I could make an app in under 5'mins that looks great and uploads all your info to me including CC info. if i have full acces to the phone data.

Abe

[ADGrant]

Originally Posted by sivan

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/C++/Objective-C or even a JVM. Though I'd concede that to me threading is a big ommission.

While I agree that many mobile app requirements could/can be met with Javascript, it doesn't mean it is the best tool for the job. There are many advantages to C & Java on a mobile device.

1) Use of resources

Smartphones are relatively low powered devices with limited memory and power resources. A fully compiled language like C allows a developer to utilize those resources in the most efficient way possible (exhibit A the snappy iPhone GUI). Java is less ideal from this point of view but it is still better than a scripting language (its also relatively portable).

2) Source code readability and secrecy

Its easy to write elegant readable code in Java and to a lesser extent C/C++. Javascript is not nearly as readable. Easy to read code is easier to maintain. OTOH, its impossible to read the source code of a compiled C application and somewhat difficult to read a decompiled Java program.

3) Debugging

With the Palm SDK, you don't discover your errors until your code is running (you hope) on the emulator. With Java and C, the compiler can detect typos and syntax errors. Decent debugging tools are available for Android and the iPhoneOS.

[abegee]

Originally Posted by sam1am

Wow, you have no clue what you're talking about.

First of all, I'd rather have freedom than "security." If it's a choice between not having an app, and having an app that might break with the next OS update, I'll take the app that might break. That's because I have the freedom to do what I want. That is how every operating system on the face of the planet works.

You obtain an app, and it may or may not work with the next OS update. If your XP apps don't work with Vista, you either don't upgrade or you don't use the apps. Giving the OS maker so much control over what you're allowed to do leads to far more problems than it purports to solve.

xp and vista are two different Os's, i would be very upset if a had a program that stopped working after a service pack or a tuesday night M$ update.

Originally Posted by sam1am

Second, the developer didn't submit to the app store blindly while using an undocmented API. He worked with Palm during the EAP to get the app to a state where it could eventually be approved. He submitted it by their invitation and he knew and noted that it would require an exception for the API it used.

he now updated us with that info on in the comments on the front page, he hadn't mentioned that before, and besides if he knew he would need an exception and he didnt get it why is he so upset.

Originally Posted by sam1am

Despite Palm's promise of working with him, he got nowhere with them and now you see the aftermath - the app has been rejected and Palm has proven that we can expect more of the same bull(*@#& we've seen from Apple.

palm didn;t promise anything he assumed it, and its his problem if he got rejected using com.palm and Undoc't API's

[PreGame]

Sooooo should I complain about Palm not letting fileCoaster into the app catalog??? It uses undocumented API's

[Kasracer]

Originally Posted by ADGrant

While I agree that many mobile app requirements could/can be met with Javascript, it doesn't mean it is the best tool for the job. There are many advantages to C & Java on a mobile device.

1) Use of resources

Smartphones are relatively low powered devices with limited memory and power resources. A fully compiled language like C allows a developer to utilize those resources in the most efficient way possible (exhibit A the snappy iPhone GUI). Java is less ideal from this point of view but it is still better than a scripting language (its also relatively portable).

2) Source code readability and secrecy

Its easy to write elegant readable code in Java and to a lesser extent C/C++. Javascript is not nearly as readable. Easy to read code is easier to maintain. OTOH, its impossible to read the source code of a compiled C application and somewhat difficult to read a decompiled Java program.

3) Debugging

With the Palm SDK, you don't discover your errors until your code is running (you hope) on the emulator. With Java and C, the compiler can detect typos and syntax errors. Decent debugging tools are available for Android and the iPhoneOS.

THANK YOU! This is my biggest gripe with webOS. I really wish we had some compiled language to work with. JavaScript is painful (I like my languages typed, please).

#3 is the worst. There isn't a good way to step through code, reliably. Half the time it's guesswork since the API documentation is lacking.

[abegee]

Originally Posted by ADGrant

3) Debugging

With the Palm SDK, you don't discover your errors until your code is running (you hope) on the emulator. With Java and C, the compiler can detect typos and syntax errors. Decent debugging tools are available for Android and the iPhoneOS.

use the aptana plugin and syntax and are detected pretty well.

[KallDrexx]

Originally Posted by sam1am

I run the same risk with every application I download for any desktop operating system. Iron fisted application stores are the not answer to malware. Like I said, they cause more problems than they solve.

That's not a valid analogy because desktop software you download software from everywhere, trusted and non-trusted sources.

A more apt analogy is downloading games from Steam's service. You assume that because the software is on steam it has been properly vetted for virii and malicious code and thus the user assumes it is safe to download. If a game is found to have malicious code in it or do things in ways that Valve does not consider safe, they will (and have) reject the application.

So no, downloading an app from the app store is no where near the same risk as downloading willy-nilly on your desktop from the thousands of untrusted websites. And most users and corporate entities don't want to deal with that risk on their mobile phone and want to be sure that they can trust Palm to distribute only software that is secure.

It's really not that hard of a concept.

[sam1am]

Originally Posted by abegee

No you don't if you have an Antivirus, if you don't, you are probably a victim of ID theft already if you don't have an AV.

I could make an app in under 5'mins that looks great and uploads all your info to me including CC info. if i have full acces to the phone data.

Abe

I don't use a virus scanner because I don't use Windows. Regardless, you could write that same app for any platform and it wouldn't show up with a virus scanner.

So I'll revise my previous statement. Neither iron fisted app stores or ridiculous virus scanners are the answer for malware.

[sam1am]

Originally Posted by abegee

xp and vista are two different Os's, i would be very upset if a had a program that stopped working after a service pack or a tuesday night M$ update.


he now updated us with that info on in the comments on the front page, he hadn't mentioned that before, and besides if he knew he would need an exception and he didnt get it why is he so upset.

palm didn;t promise anything he assumed it, and its his problem if he got rejected using com.palm and Undoc't API's

You're ignoring the bigger issue here - which is that Palm shouldn't be exercising such tight control over app approval.

[Kasracer]

Originally Posted by abegee

use the aptana plugin and syntax and are detected pretty well.

Errors != syntax errors. Syntax errors are easy to figure out and avoid. Exceptions being throw are kind of difficult to track down, especially if they are swallowed before they can bubble up to you.

[PRedwood]

This sounds like a case where you need to contact Palm and determine how you can work together to get the necessary APIs finalized and available to the the public. There are a lot of APIs that obviously need to be released to us developers and I'm sure Palm just needs time to make sure the API meets developers' needs and is secure against major abuse.

Trying to work with them will surely be more fruitful than flaming against them.

And I don't buy the argument that Palm wants to protect their own music player. An underdog like Palm would be insane to reject good apps from the catalog just because it overlaps existing functionality. Users can make the choice whether to use a built-in application or a third party application.

[sam1am]

Originally Posted by KallDrexx

That's not a valid analogy because desktop software you download software from everywhere, trusted and non-trusted sources.

A more apt analogy is downloading games from Steam's service. You assume that because the software is on steam it has been properly vetted for virii and malicious code and thus the user assumes it is safe to download. If a game is found to have malicious code in it or do things in ways that Valve does not consider safe, they will (and have) reject the application.

So no, downloading an app from the app store is no where near the same risk as downloading willy-nilly on your desktop from the thousands of untrusted websites. And most users and corporate entities don't want to deal with that risk on their mobile phone and want to be sure that they can trust Palm to distribute only software that is secure.

It's really not that hard of a concept.

You bring up a good point. I'm not anti app-store, and I'm not anti Palm's or even Apple's ridiculous app store policies. What I am against is an app store being the only reasonably accessible way to install applications. Have whatever rules you want for your app store, but if you're not going to give people alternate means to distribute their applications than we're going to have a problem.

The current sideload method for Palm is good, but it's not good enough. I want to be able to browse to a website and install an application from my phone. Outside of Palm's control.

IANAL, but I think if someone challenged app store exclusivity in court, it wouldn't hold up. It is anti-competitive and ultimately damaging to consumers. Especially in the case of Apple where they reject applications for "duplicate functionality. Anyone remember the Internet Explorer debacle?

[abegee]

Originally Posted by PRedwood

This sounds like a case where you need to contact Palm and determine how you can work together to get the necessary APIs finalized and available to the the public. There are a lot of APIs that obviously need to be released to us developers and I'm sure Palm just needs time to make sure the API meets developers' needs and is secure against major abuse.

Trying to work with them will surely be more fruitful than flaming against them.

And I don't buy the argument that Palm wants to protect their own music player. An underdog like Palm would be insane to reject good apps from the catalog just because it overlaps existing functionality. Users can make the choice whether to use a built-in application or a third party application.

+1,

I'm happy to see youv'e signed up here

[chuq]

We have gotten a lot of feedback about NaNPlayer which is great. We love that people are excited about the application, and that developers are able to be creative on the webOS platform.

We reached out to JC (the developer) and discussed our reasons for not accepting the application at this time, but we also wanted to be open with you about this.

NaNPlayer is using APIs that are currently private because they will change significantly in a future release. Although we aren't able to support the functionality that JC needs right now, we are listening to the community to help prioritize which APIs and features we put into webOS.

Chuq Von Rospach
Palm Developer Community Manager



While we can’t accept NaNPlayer into the App Catalog right now, we are not rejecting it, and we are happy for it to continue life as a homebrew application until we get to the point where we can release public, supportable APIs for the functionality that it requires.

Thanks for your passion, and we can't wait to enable even more fantastic creative applications via an expanded set of public APIs.