We have our first report of an app rejected from Palm's app catalog, but at least there's a clear and understandable (if somewhat maddening) reason.
Remember that impressive music player app we posted previews of a while ago? Yes, NaNplayer. Well, its developer, know to PreCentral forums as Blubble, today informs us that Palm has denied NaNplayer entry into the App Catalog:
I have some bad news folks. Palm has told me that they will not allow my music player NaNplayer into the App Catalog at the current time. [...]
Palm stated that they don't support music file indexing and consequently won't admit the app into the App Catalog. It doesn't seem to matter that the app is works just fine on the Pre and that it is substantially better than their pathetic stock music player in terms of features and performance. [...]
I won't spite the user community just because of Palm's decision. I will release NaNplayer to the Homebrew gallery once it is done. However, this will still leave most Pre users to get by with a music player that doesn't even let them create a playlist. However, I will slow the pace of development considerably. I can't continue to dedicate so much time to developing an app that may never be released to the majority of webOS users. In all likelihood, I will not develop any more webOS apps in the future.
Essentially, it appears the issue is that NaNplayer uses an undocumented API -- the same one the default music player uses -- to query music files on the device and their metadata (artist, album, genre, etc.). It's an incredible shame such a fine app is being denied, seemingly based off a useful API that probably should have been included with the official SDK.
While I do sympathize with Blubble, it's best to look at both sides of the issue. An undocumented API is undocumented for a reason. Palm may alter it in the future and I'm pretty sure its usage violates the SDK EULA.
One thing this rejection does clearly show is the potential breadth of homebrew apps like those you find on PreCentral vs. the App Catalog, but there's a catch. Given that our homebrew section is an unofficial testing environment for apps, developers are free to experiment with undocumented API and do things not normally possible with the standard app. But that experimentation comes with the risk that using such APIs could have unintended consequences or Palm could change them and break the app.
This is just an unfortunate situation all around. Hey, at least there's our homebrew app gallery. Not only that, Palm can learn from this situation by looking at what's being done in the homebrew scene and improving their API based on what the average developer wants. Hint: the average developer wants to use the music files on the Pre.
UPDATE: Chuq has responded in the forums regarding the issue:
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.
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.
Chuq Von Rospach
Palm Developer Community Manager
Comments
Palm is not allowing any app to use undocumented API's at this time that require the com.palm namespace. I don't really think that anyone could expect them to allow privileged apps in the official catalog.
I would guess that over the course of API releases that they include more and more of this undocumented functionality in the official SDK. They are really trying to be open, but they can only add official support so fast.
Unfortunately palm is playing catchup. To attract top quality app creators they will have to suck up to them a bit more. Otherwise, why is it worth the stress to them?
Seriously? I would hope the people reading this report, and the people who have used the music player would let Palm know just exactly how disappointing this rejection is, considering the sad music app they included as standard on the phone. Do they even WANT to compete with the iPhone? Silly. Silly and infuriating all at the same time!
NO FRACKING WAY!!!!!!
Why the heck why Palm would reject probably the most important feature of a music app??? This doesnt make sense to say they dont support it since the app feature is thrid party and they dont support 3rd-part apps...
Undoccumented API? So the paperwork wasnt filed completely?
It's not just that it's "undocumented", the problem is that it's internal to Palm and either not secure or likely to change. If they change it, the app breaks (and you potentially lose the money you spent for that app).
Also think about what undocumented means. For example once they put an app in the catalog that uses the API then they're essentially promising to keep the API, in it's current form, for a long time - and the more apps that use it the harder it is to change later.
I feel for the author - it's obvious that he's put in lots of work - but that was the gamble he made when using something that wasn't in the official API.
A lot of non-programming folks are getting into programming the Pre and that's a great thing - but they're going to run into the rules of real software development pretty hard. One of those rules is that using any undocumented feature has a price and they have no moral right to expect Palm to bear the cost of that.
I know that sounds hard - but that's the way it is.
As a developer and a user, I'm pretty disappointed with Palm's decision on this one! It's an app with features that users want and an application that would benefit the webOS community. Not to mention it took a large investment in time for the developer to come up with it only for Palm to pull an Apple and reject it. If Palm didn't want the API to be used, then perhaps they should have taken a page out of their own propaganda and obscured the code instead of "publishing" it on the phone for all to see. This case shows not only shows how Palm, in a scary way, is becoming more like Apple but it also fails to promote confidence in the safety of one's IP when developing for the Palm much less show much promise of a return for a programmers investment.
How is this case showing "how Palm, in a scary way, is becoming more like Apple"? Though I feel for the developer, and all of the work he has put in, he attempted to use an undocumented API. You can blame Palm for not documenting that particular API and releasing it in the initial SDK, but you can't blame them for rejecting the app. What about all of the other developers out there who simply followed the rules and based their work on the framework that was currently provided? If Palm were to allow this app into the app catalog many other developers might also feel spited because they followed the rules, and are being basically punished for it. Blubble made a GREAT application, but he did it with a calculated gamble that didn't quite pay off this time. Maybe if Palm does document the API he can be first to market with an app that uses that functionality, but for right now, he's kind of stuck where he is.
I hope Palm is not starting copying Apple's behaviour...
And I hope that after opening of App Catalog Palm let us install any apps outside App Catalog (like in the old palm os and win mobile) without jailbreak/rooting/hacking or whatever!
If not I will never buy a Pre/Pixi!
Be careful Palm! Don't screw it up or face the consequences !!! :(
We are not like Apple fanboys who like everything made by their company!
If good developers are going to give up that easily instead of working with Palm to remedy the issue, the app catalog is doomed to fail. There seems to be a lot more good stuff about this app than what may not be allowed that I would certainly pay for. Correct me if I'm wrong.
Very true, but you have to remember that the webOS community is new and needs to attract developers - not push them away. There are far more profitable platforms to work on just now (iPhone, Android, and WinMobile to name a few!). Palm can't afford to loose good developers or everyone involved - Palm, Sprint, Devs, users - will all loose.
I agree. I'm looking very hard at the HTC Hero and how Palm rolls out its app catalog and supports developers will be the deciding factor.
It's lose, not loose. I see this same mistake in hundreds of posts -- it drives me nuts.
You 'lose' something when it is lost (just remember both lose and lost have 4 letters).
The other one is the opposite of tight, as in loose change, loose shoelaces, etc.
What can I say - Grammar has never been my strong point! :-D
What a looser!
I'm glad that it maks you nuts, looseing your head about it and postin. Their are times when you just have to accept that this is the interwebs...
Although I hope you are simply attempting to be humorous, even if this is the "interwebs", ignorance and stupidity do NOT have to be tolerated, nor should they be rewarded.
Well obviously I'm not trying to be serious...
But then again, I'm not entirely sure how proper diction or the use of an extra 'O' constitutes ignorance and stupidity... or the need to go through EVERY post and correct the use of the word 'lose'... then again, I guess we DO have to put up with snobbery and general douchebaggery out here on the 'webs!
It all comes back to the point of this whole thread... I believe the second "o" is undocumented and therefore should not be used in a public forum. I'm sure the folks at Palm would agree with me. :)
Everything you’ve said is correct! I’m developing an App for the webOS and
this development doesn’t bode very well for my confidence in Palm’s openness
with their platform. They “badly” need all the developers they can get, so
instead of just rejecting an app, offer the developer a clear path of on how
they can rectify the problem, so they can feel confident to resubmit their app.
If for some reason, Palm is rejecting this app because it puts their own efforts
to shame, then that are a very serious and very disappointing precedent – one
that the developer community will look at very negatively. I for one, love the
webOS, but Palm sometimes, seem to be mirroring Apple so much that they seem to
starting all of Apple’s mistakes as well (hell, they even got Apple’s soul in
them by way of their CEO and several of Apple’s developers. I for one, am also
looking at the Maemo Platform and the Nokia N900
as well, just in case Palm turns into an Apple. Be careful Palm...be very
careful!!!
I think it was very clear why this app was denied. There wasn't any ambiguity or cloaks to it at all, it was denied because he used an undocumented API. Now, Palm should hopefully be working to included this particular API in future releases of the SDK and maybe they can do a better job of communicating when this will be enabled, but the developer exactly why his program was denied. And the obvious path for his app to get to the catalog would be when (if) the API is released in the SDK.
the developers need and want access to the file system, better documentation, and more apis to integrate better with the apps that come with the device. please, now!
Sure - what other features should they delay so they can go and work on finalizing the API, fixing any bugs (it may have bugs that the internal player doesn't trigger), and getting the documentation done to keep a single application developer happy?
Even Apple have finite resources - witness how long it took Apple to get power consumption under control. I don't want to wait two years for that issue to be addressed on the Pre...
As for the file system comment... well if you want apps to be able to screw up your Pre (either through accident or malicious misuse) then feel free to let them access the file system...
OTOH more application interaction APIs would be nice - but there are things I'd like to see first - like those apps being feature-complete.
Well, at least we get it on homebrew, but that is still kinda f*cked up...makes me wonder what other apps could be denied.
I dare say the developer can recover some of his investment through a donations link until/if the app gets into the official catalog. If it's as good as it's supposed to be, I think most of us would appreciate the app's value and donate accordingly. I'm going to give it a try when it's in the homebrew catalog.
I know donations will only go so far, and the app won't get the exposure it would in the official catalog, but it's a start. Frankly, Ihardly ever check the official catalog, but I'm always looking fwd to what's new in homebrew!
I totally agree. The Official App catalog blows and I never look in it. Always excited to see what is new in Homebrew though. Why is that? Well some might say because Palm needs more developers in the App community. Now they just lost one, it looked like a spectacular app. I was excited for it.
well i'm probably a slightly above average user then the general public (mostly because of this site and homebrew). and by no means know anything about programming. so to hear a developer of what seems to be a great app say he is likely not to develop for webos again is a great disapointment. i bought the pre for its potential. this to me seems to kill the potential a bit. i know we are still early adopters and all but still a very disappointing down turn. i think there is only so much of this early adopter excuse i can take and lack of good apps before i get fed up with palm. and i dont want to leave the webos but without apps and more importantly developers whats the point really???
From what I understand, using the palm namespace can be super-dangerous to the end user, (think malware) and the only fighting chance palm has of preventing this is to lock apps out of using undocumented and or protected/privileged APIs.
I understand Palm's rejection, but at the same time, they could have made a special case for the awesome looking NaNplayer.
Not that I support Palm's rejection, but I understand why they would do it.
Just port it to android or iphone and send palm a letter asking them to stick that in their pipe and reject it.
Maybe I'm a bit out in the wild, but exactly what types of applications are everyone clammoring for? Apple has a HUGE library of applications, but exactly how many of them does the average user download and use more than once? I feel like application has become some new buzz word, but practically, it doesn't have much relevance. I feel for the developer of this application, but as I said before, he made a calculated gamble, that didn't quite pay off this time. That's business. Some times you win, some times you don't. I have to agree with Palms decision to play by the rules they already set for the game. He didn't get rejected due to some out of left field response. He got rejected because of using something that was off limits. Maybe in the future Palm will all developers access to those APIs, but until they have some time to do so, let's not all torch Palm because they had the gall to actually set some rules and follow them.
I am disappointed like everyone else. But, has anyone stopped to think that Palm is just enforcing their EULA. I'd bet Palm didn't document the API because they haven't completed development of their music app. I'd bet (hope) Palm documents the API later in the future when it actually is done (not to mention when other core OS features and functionalty have been completed/polished).
Bubbles,
I hope you continue to develop future apps for WebOS because your work on NanP is incredible. I'd guess Palm will continue to document API's and release new ones regularly. If my hope/assumption are true, this community will look back on this rejection as WebOS' teething phase. I haven't been following your development very closely but make sure you create a way for us to donate to you so we can support your development, if you haven't already.
This behavior on Palm's behalf simply shows how unprepared they are, as a company of diminished stature and holdings, to compete with larger and more deeply invested corporations such as Apple, Google, Microsoft and so-on. Perhaps even HTC could be said to be more successful as a hardware manufacturer than Palm. And this brings me to a point, as the proud member of a 3-Palm-Pre touting family (hoping to adopt a Pixi for my mother upon release): those of us supporting Palm -for whatever various reasons- are doing so as a minority. Their share of the market is pitiful. What customer base and developers they have they should idolize and cherish, because it is our support at this initial stage that will keep Palm afloat long enough to see their situation change. Guess they didn't get the memo.
One more reason that unofficial applications will continue to be the driving force behind the Pre. Palm is taking the path of Apple in many ways and that path, for Palm, can only result in the marginalization of webOS.
Wow...
I'm trying extemely hard to view this from Palm's perspective, but I can't... A young (Now) company that is attempting to increase market penetration, and is in the process building a reputation as a major contender is rejecting apps due to things like this 'Un-Documented API' which for all we know was simply an oversight... but in the end, its apps like Bubbles Nanplayer that will end up making the WebOS platform more viable, and more than that, his use of an undocumented api to create something that all of us would use and find viable is something he should be commended for.
And how can you use this 'well if they let him use it, what about all the other people that haven't been able to use it??' defense? If he managed somehow to get his app up there and then open up use of these API's to the rest of the development community then who looses? Now they will have more tools to work with and can give us a better product. Thats what this all boils down to: I don't CARE that Palm doesn't want dev's to use undocumented API's... I WANT BETTER APPS, if its Palms fault for not including them then there is even MORE reason to be mad at them. Because Palm didn't have enough forsight to know that people would want full fledged, functional, innovative apps, we all, as Pre and WebOS users have to pay the price with inferior apps.
Just makes me sick... I've pushed this device so hard on friends and family because I believe in what Palm is/was doing... if this is the start of a trend then they've not only made me a liar, but a fool as well.
Business runs off of rules. Period. I don't work for Palm so I can't really say why they set the rules up like they did, but the rules are the rules. Blubbles use of an undocumented API doesn't force Palm to include it in an SDK, especially if there is a sound reason for it not to be included yet. What it does do is open up Palm for a blowback from other developers who say we followed your rules, but it looks like you're playing favorites. I understand that we are all consumers, but at what point do we really sit back and look at a situation with clear eyes? Palm can't possibly open up all aspects of the phone and give it over to the developers. It might sound good, but it's not practical. Be patient, they're working on it. And I hope that developers recognize that as well.
Unfortunetly developers don't have to recognize it... they're are more profitable platforms with much larger install bases than WebOS. Agian, this is a lack of forward thinking by Palm, not the devs.
Buisness does run off of rules: Profitability = Success .... Anything else is irrelevant, and anything that isn't profitable will be abandonded.
Valid points. But profitability is ultimately determined by being able to sell your product. A developer can go over to the app store, but good luck on trying to get your application approved if you're using undocumented API's. Also, good luck selling your application for more than $0.99 or having it show up on the featured page. Part of WebOS development is being in on the ground floor. You have the potential to get your product out to early adopters, prove you the ability to meet needs, and create a serious brand for yourself simply because you were out there first, before the clutter. It's hard to do any of that if you can't get your app onto the platform in the first place.
Fair enough... your points are sound.
Part of the problem I see with this particular issue is the hype (What hype there was, considering) based around a program like Nanplayer and then its rejection. It just makes the developers statement that he's leaving webOS development sting a bit more... part of me wants to be angry with Bubbles for abondoning the platform so easily, but part of me understands. You are correct to say that a music player such as this may not register as a blip over in the app store due to saturation... and who knows what would happen over in the Android community, always seems to be the wild west over there.
In the end I think we all just want great apps, and I don't feel like you or I are any different. I happen to be more paranoid due to buying into the hype for a previous flagship phone on the Sprint network and then having it be left behind in terms of development.
I have no doubts that this will get figured out, I just hope its before more great devs jump ship.
@BlackTemplarX, I agree with you. Reason no. 1, Palm keeps telling us that webOS is so easy to develop for and that this ease of development is what makes their OS so different, that, developers can bring their experience of javascript and create great innovative apps in a very short period. So now, with what they've done here...they've actually gone and told Bubble they were lying with all that crap. Bubble's app was the "innovation" that they say can be developed, if they are rejecting apps like these...what are they saying - that they are looking for what - thousands of fart apps?
Reason no. 2, Bubble's discovery of this undocumented API just underscores exactly the kinds of enthusiastic and brilliant minds that Palm needs to attract to their development platform - not run them away. Palm, oh Palm, please refrain from going down this path - it’s a dead end road.
Reason no 3, Palm didn't just reject a useless, baby beater, fart app or jerk-off calculator or some other useless crap, they rejected one of the most feature laden apps we've seen on their webOS platform so far and an app that most of their users, badly needs. This app could have "encouraged" other developers to join in...it could of possibly spur more sales...it "certainly" would have created significantly more good will and user satisfaction for all their existing users.
Reason no. 4...now; tell me, what are the negatives that could be potentially negate all those benefits?
"...the development community then who looses?"
loses, not looses
It seems that you don't understand what an "undocumented API" is. It means it's not supported and may change. If it changes, the app doesn't work anymore. You ask "who loses?" ... the answer is that *you* do if you've paid for the app and it doesn't get fixed.
Perhaps *YOU* don't understand what I'm saying... Undocumented API or not, something as rudimentry as file indexing is something that should have been provided before hand. If you take the time to read Blubbles post in the forums you'll find that the major issue is that Palm simply hasn't provided any info on a majority of the API's and features that the phone can do. When he was building his app he happened to stumble into that grey zone and use an API that was already functioning on the system, sure, this would seem like a problem, and, sure, his app is rejected because of not staying within the confines of the given SDK. HOWEVER, in order for apps to continue evolving Palm owes it to the developers to provide some sort of platform for them to create USEFULL and INNOVATIVE apps... its one thing to reject an app because of security, but its a whole different ball game when an app gets rejected because the company didn't have enough forward thinking to map out the API's for the system.
So on one hand, sure, I don't want my paid for app to stop working... on the other hand... I want to find some apps that I'd actually pay for. More than that, Palm could have handled this differently, perhaps giving Blubble more information, or a way to resolve the issue, or even some sembalance of a time frame for him to keep some manner of hope. This is what I take issue with, not with Blubble's app, not with Blubble himself, but with PALM, for not having the right sort of environment out there for developers to create awesome apps and then blocking apps for it and not communicating with the Dev.
We all lose (There you go Grammar Police) if Palm fails, and without devs, Palm will fail faster than we can imagine. High profile devs coming to high profile community web-sites revoking support for WebOS hurts US ALL.
Solutions and open dialog is what we need with Palm, NOT the cold shoulder.
Ahh ... no argument from me that they should provide such an API.
But that's not what you said in the original post ... you made light of "undocumented" and suggested there was no harm in allowing developers to use them, when in fact there is a real price to pay if they get changed. Just wanted to make that clear (since a lot of the other ranters don't seem to understand that).
Ideally, it would be nice to see documentation on all available API's, with a clear distinction on which would be allowed or denied.
That way, when API's are added in the future, it is safer for developers, especially considering that if something is undocumented, developers will always wonder whether it was an oversight or intentional.
Easy solution, just requires a bit more communication/documentation from Palm.
Remember guys, it's important to note that the primary reason Palm is NOT Apple here is that they are not punishing the homebrew community. We don't have to Jailbreak our phones to get custom (non-approved) applications -- don't forget that.
Not needed. Just log in to your phone and listen to the dbus communications (application for that is already on your phone) while using the internal music player. A bit tiresome maybe but not rocket science.
I think it is really silly that the Palm apps is using an other API than the one that is available to 3rd part developers. Why? Of course some calls should only be allowed to privileged applications, but then it should be a allow/deny option per application.
Apple does approve apps that use some undocumented API's such as certain types of controls and displays. The bottom line, here, is that people who think that Palm is, by nature, going to be less restrictive than Apple are in a ridiculous fantasy world where Palm is the hero and Apple is the villain. There is no reason to think that Palm is going to come to any different conclusion about their platform than Apple. So far, they have been going down the same course.
@Zach: If you want to have more Palm devices in the future and see WebOS develop into the future then its commercially viable apps that will take it to the next level, not Homebrew (I love Homebrew by the way).
All of Palm's phones in the past have had the ability to run homebrew apps, and indeed, some of those were AMAZING. This didn't stop Palm from falling so far out of the public eye that the company almost failed completely. Homebrew is the undergroud, the resistance, the innovators... but in order for a Commercial company to continue to function and provide us with both support and new devices they have to be profitable and successful. If they fail at that, then we're screwed... no matter how much we all love the Homebrew scene.
Rejecting apps because you weren't prepared and didn't have your API's documented is shooting yourself in the foot and is going to loose Palm A LOT of momentum (If this keeps up). Personally, I want WebOS 1.3 and up, so they better start approving apps people are going to buy.
"...loose Palm A LOT of momentum..."
lose, not loose
Okay, my first reaction is outrage. I tried to look at it from Palm's point of view, and all I get is, even if they have a valid reason for concern about the app, they need all the developers they can muster right about now. It's a crucial time for Palm. I'm not a programmer, I have no idea if Palm's technical rejection is valid or not, but it just looks like they don't want competition for their own music app. That's what it looks like to the non programmer.
I'm going to send an angry email to Palm suggesting that they stay the hell away from the Apple style app rejection and opt for a third way. There must be a way for clever app developers to get conditional approval, it's like one step before approval. The app isn't rejected, but it isn't approved, it's in a middle ground, so that if there are serious security or programming concerns, they can be rigorously addressed.
That's my suggestion. I still love my pre, but I am very ticked off. I was really looking forward to NaNplayer. And I am MORE than willing to pay the developer full price for whatever state the player is in right now.
three words. give. palm. time. lets be reasonable people.. if there's undocumented api in the sdk for indexing and such.. maybe palm isn't quite finished polishing things up.. be paitent.. we as user have become very picky and critical and are not thinking about the hard work palm is doing, pushing rapid updates, releasing pixi, etc.. they can't do it all at one time.. chillax and watch the future unfold.. then give your input.. don't rush it.. i loved your app blubble, so don't be a debbie downer. keep doing what you do.. i know it sux.. but i'm sure there is a very significant reason behind why they really denied the app.. it been 3 months and I truly believe the pre is a revolutionary phone.. just give em time to develop.. one last thing.. am i the only one who thinks palm knew that there were numerous features missing from this platform at launch, but because the tension and hype was building so much, the couldn't push it back further? i mean.. just look at the update rate.. obviously they were still working on it past launch.. GIVE EM TIME. patience is a virtue people.
The more we wait the more Developers are going to realize the platform isn't going to make them money and will move on to greener pastures. We need to keep them here and give them reasons to stick with the underdog...
We're more picky as consumers because we have choices, we don't HAVE to stick with any one device now-adays (Unless you are marked with rabid fanboyism of course). Palm knows this (Or should) and has apparently forgotten that they need to nurture the Developers that will end up making them successful, not letting them jump ship over something as rediculous as this.
Sitting back and waiting is NOT the answer here, finding a solution IS.
PALM, HERE'S YOUR SOLUTION: Sell any app through the catalog, but only certify some. Have a certification stamp.
This appears to be a case of Palm rejecting an application because of an oversight of Palm's. This API, or an equivalent, should clearly be there.
Don't punish developers for Palm's own shortcomings.
I originally switched from Verizon (a long time happy customer) to sprint for the pre and all the potential I saw in WebOs.Palm has it's work cut out for them. The developers, especially the little guys who are writing some pretty amazing apps are going to be key for the survival and growth of the platform. To take a developer who has been pouring all his thoughts, ideas and time into writing an application that is not only new from the ground up, but actually makes Palm's native app look pathetic in comparison. Palm needs to build better relationships with each and every developer, from the guy (or girl!) with the fart app, to the one with a beautifully written, advanced app such as this, which truely adds to the platform functionality and appeal. I agree with Palm's decision to deny the app at this time, but why piss off the developer instead of working with him to get the app released in the near future. If the playing field needs to be leveled, take the steps to release the api... work with the developer to change a couple of things in the app to better fit Palm's standards.... don't just say no, say not at this time.... but, this is what we can do to get the app submitted in the future. Throw a little hope his way and put some acknowledgment of the work that has been put into developing the app. It's all about how you do things! I understand that Palm may not have the resources to deal with each developer, but they really need to get more support for them as they are the ones who will keep people signing on to this great platform as what you can use it for grows!
Palm is doing a lot of things right... they are listening to us, they are keeping up with updating the device and are supporting the home brew scene. On the flip side, the hardware on the Pre is far from perfect (just received replacement phone #4... 1st with serious reception issues, 2nd and third for blown external speakers... not to mention the horrible slider on the current one being replaced). I was there on june 6th, purchasing this device as were many others.... Palm needs to keep that excitement we all have going and expand on it by showing more people just how great this new platform really is and where it will go in the future...
"hint" We need more apps!
.... a lot more....
....and good ones....
I will be happy to donate to the developer of this app once it is released to homebrew.
^---- This.
Solutions are the answer, not rejections.
I always enjoy using applications where the developer slightly (or a little more) 'bends the rules'. Quite sure this is because many apps I really like on PalmOS are those kind of apps.
I know and take into account the possible (but very unlikely) consequences: instability, compatibility issues, etc. No problem for me.
But if a developer, who does not play by the rules, expects to have his app approved by the creator of these rules, and, as it is not approved, cries foul, that is pathetic in my eyes.
I have no sympathy at all for this reaction.
Especially if he explicitly wants to focus the mass market. That is nonprofessional.
This should not be a surprise.
You cannot willy-nilly use services that Palm has not officially made available to third-party developers. It's not an 'undocumented' API -- it's an API that is only made available to the com.palm namespace for security reasons. When they find a way to safely allow third-party developers to use it, they will probably offer a public service. This is like writing your app against private methods and then complaining when the API "breaks you".
If you take shortcuts with your homebrew by using methods within the com.palm namespace, it's on *you*, not palm.
This is not "Apple-style" rejection. Apple is rejecting apps that use the API provided to developers because they don't like the content or functionality of the app. Palm has rejected this app because it is essentially 'hacking' the phone's features, no matter how benign the use. All the other developers making apps for the store have to follow these rules (and trust me, it makes many things MUCH harder). Why should this app be treated any differently?
If you want to agitate, agitate for Palm making more services available to developers, not about some app not playing by the rules getting rejected.
Botto, I agree with you 100%. I've been trying to say that same thing on this board all morning.
I don't get it. There are several options Palm had besides simply rejecting the app. They could have told the developer that it is on hold until the API is documented. They could have even bought the app outright and used it to replace their own music player, which uses the same API and therefore has all the same problems with it changing.
If Palm's policy is anything like Apple's, just because an app was rejected doesn't mean it can't be resubmitted at a later date. Being rejected is the same thing as being "on hold."
Also, Palm's app doesn't have the same problems with the API changing that a 3rd party app has since the player gets updated along with the API changes when updates are downloaded.
Is there any way to remove the app catalog from my pre? I waste time each day checking it because its there, but would much rather just not have it for now.
Palm chose to stick with the rules. I don't like that they rejected a very good product but they just followed rules they already made so it makes sense.
Now if Palm starts blocking Dictionary apps then you can compare them to Apple. This rejection doesn't seem to compare.
I can see Palm's perspective on this; use the APIs we've given you - don't hack our stuff. There may be a copyright/patent reason why that particular API is undocumented-- royalties/fees, contractural agreements... nothing is ever as cut and dry as it may seem. Those are the kind of things Palm *can't* discuss as the *real* rejection reason.
As an alternative, the homebrew community is a great place to put something like this. Yeah, it won't generate much money for the author-- but it's still a place where unofficially sanctioned software can been developed outside the official scope of what Palm can permit in their App Catalog without getting sued.
+1 for Hero.
Palm needs an App Beta section, where they take no responsibility for breaking any app, and those beta app will need to be free to save palm any headache of people wanting refunds.
I also think they need to reach out to developers (not just big comanies, the single person operation too) The rejection was way too cold.
Palm already has an app beta section, its called the homebrew catalog and its located right here at P|C
and what percentage of Pre owners know about/use it?
Probably about the same percentage that are OK with having apps that break and hacking their phone 8^).
palm seems very alike to apple from day one, even though they claim open source and show *friendliness* to developers... the moment they think they've amassed enough developers, they will show their true color...
Meh no biggie,
Palm has already stated that their primary concern in app approval process is system stability. Using undocumented APIs by third parties sets a precedent for undermining that stability.
At the same time, nothing stops the NanPlayer from being in the homebrew catalog and even from implementing a payment system for the software. PalmOS apps used to be sold all over by everybody without a problem.
Look, even if Palm has a valid reason, the effect is that developers will think twice. And users who love the Palm, myself included, obviously feel that the phone needs a better music player. None of us would be here complaining if Palm had rejected a flatulence app. As a matter of fact, we might be cheering.
JD is right. Palm had several options. They STILL have options.
And Bubbles, I would easily pay you $20 for a functioning, solid NaNplayer. If you release it, and its solid, and people like it, then sell it, if it's good, you WILL make money. Palm app catalogue or not.
There are guidelines for the SDK and for apps that get accepted into the main app catalog. If the app does not conform, I do not see a problem with that app being rejected. It doesn't mean the app is bad or cannot be sold it just means it does not get listed in the catalog.
It may be very meaningless, BUT... i've kept my pre with OEM software for 3 months already and no big desire to put any homebrew on [yet].
UNTIL i saw the NaNplayer review/article. This might be the best quality/functional app created yet and for a very good cause. (MUSIC, DUH!)
You can add +1 to the homebrew 'customer' stats because if palm denies this for app catalog, then they have successfully diverted me from their preferred app catalog in favor of well, the better app and that means homebrew.
way to go palm
way to go precentral
way to go blubble, this app looks amazing
PALM IS EVIL!
one more nail to their coffin!
What is shows is that Palm is going to suck just as much as Apple. They're providing themselves features that they then deny to 3rd party developers to avoid the competition.
The comment:
"I do not see a problem with that app being rejected. It doesn't mean the app is bad or cannot be sold it just means it does not get listed in the catalog"
displays ignorance of how the marketplace works. Once the app catalog is really up and running, the vast majority of Pre owners will never look anywhere else for software, nor even know there's anywhere else to go for software. This decision kills the commercial viability of NaNPlayer unless the author dumbs it down to fit Palm's selfish model.
I wonder if he could get away with providing the dumbed down version through the app catalog, with a help file that directs buyers to another site for the "good" version.
It's not ignorance it's how agreements work. I happen to have a very good grasp on how the market works. Both parties have to play by a well defined set of rules. Until the rules are amended, the developer, not abiding by the rules has no place in the official catalog.
One more example of how limited the programming capabilities of the WebOS DSK are, at least for now. Given the limitations of the SDK, and Palm's stance, I don't think we'll ever see true, enterprise class apps on the Pre. Which doesn't surprise me. It's more and more clear that Palm has abandoned the business user to go after the 'tween, teen and 20 somthing entertainment user.
WORD!
Sure there are guidelines. And I'm sure that the NaNplayer developer understood the guidelines. But my guess is that there are a handful of developers who get special access to api calls that homebrew devs don't get access to. Palm could have told Bubbles that they like what they see, they're excited to help him make the app better, and give him access to the software to make a killer app that makes the phone even better.
Obviously the stock music app is... wanting. I think if we in the community heard that there was a killer music player coming to the official app store than we all would have been patient and really excited. Instead, we're ranting on a homebrew forum. Palm should have opted for community getting excited, rather than community getting ticked off.
I wonder where this leaves Music Player (Remix) currently in Homebrew. Hoping that isn't using indexed music too.
John, I've submitted a query to Palm on what my options, if any, are with distributing the "Music Player (Remix)" app. Without seeing the actual rejection email, I can't say for sure why NaNPlayer was rejected. So before making assumptions about my app, I would need to know more info as to the reasoning of the rejection and whether it's a permanent rejection or may be revisited if the SDK is updated with these undocumented/unsupported APIs.
My app does use the built-in media service to retrieve song, artist, album, genre, and playlist lists. I developed my own module/service using Sqlite when implementing bookmarking and on-the-fly playlists.
Palm's built-in media service/API does require that your app id domain is "com.palm". When I read up on NaNPlayer, I always assumed the developer either got special permission from Palm to use these APIs or developed some other way to accomplish this. I'm surprised that he would spend so much time developing the app without first consulting with Palm if he knew he had to spoof his app id domain to start with "com.palm".
Whether or not Palm has a right to do this, it's still a crappy thing to do. Punishing a developer for making a really good application just because they do it in a way Palm didn't expect is, well, stupid.
why didn't they simply say, "we'd love to review your app, but we cannot spend resources reviewing an app that at the moment, we by policy cannot accept. please resubmit your app in the future when the APIs become documented."
Seems that is basically what they said.
+1
Undocumented API? Then they should have documented it. Seriously. Such an API is critical on a multimedia device...and Palm can ill-afford to do *anything* right now to discourage development on the platform.
Didn't have time to document the API...and/or it may chnage? Fine. Tell the developer that their app may break later...and agree to get the app in the catalog as soon as you establish that it doesn't crash the OS.
Seriously, Apple sold more iPhones in a single weekend then Palm has sold Pre's since the introduction...and the delta keeps growing daily. Apple also has tens of thousands of apps in their store and hundreds more being added each day. They can afford to be picky and defend their core apps. Palm? No freaking way...unless they want to be in a soup line this time next year. Palm, you seriously need to get your act together and embrace such innovation rather than viewing it as a threat. Sure, you may change the API...or enhance your music player...but at the moment, that app sucks...as does your email client...and many other core PIM apps...and you need to embrace developers who are trying to do something about it.
You are not Apple. Don't pretend that you are. You are dead men walking and those developers are your attorneys submitting last minute stays of execution. Wake up and get your heads out of your collective a$$es.
You are comparing apples to oranges. You can't compare sells of Apple products which was released on multiple carriers worldwide, to Palm, who was married to Sprint until recently when they added Bell in Canada.
And as a side note, who the crap cares how many applications that Apple has? People have simply bought into a marketing ploy. Can you name 100 hundred apps that are in the app store? How about 50? How many of those apps are simply different versions of the same thing? How many of those apps are used more than once? How many of those apps actually make their developers any money?
Guess what, there are thousands of apps for my PC. There are thousands of parts I can buy for my toyota camry. The number of aps is marketing, functionality is what really counts.
The number of apps *does* matter...because it implies a rich array from which you can select. It also inspires competition to create best of breed apps.
I have many family members and friends who have iPhones and iPod Touches. Speak with anyone who owns one of those devices and you will quickly see the enthusiasm for the app catalog. In fact, I would bet that they have downloaded a new app fairly recently. That selection helps motivate more development, sell more iPhones, and further entrench their dominance. When those same folks look at my Pre, the iTunes music and app store ecosystem is one of the first things that they mention...and about which they inquire.
As I noted in the forums previously, I was in a Sprint store some time ago and was showing my Pre to a woman whose boyfriend was extremely enthusiastic about the Pre. What it came down to for her was that she wants an iPhone for the apps that she sees advertised...and for the iTunes compatibility...and they eventually walked out...on their way to the AT&T store.
Apple also essentially gets free press for their platform now as retail outlets like Chipotle (and many others) tout their new "iPhone apps"...daily.
Yeah, I had a Mac before it was cool...as far back as the Lisa...and I frequently sold the bill of goods that you are trying to sell. What do I need a thousand graphics programs for? I have the best on the Mac. The reason is this - competition yields superior products and lower prices. There were many choices on the PC that were far cheaper and as good. Ditto for peripherals. Furthermore, while the Mac had fairly decent programs then, the Pre does not now. The music player is a joke...and many of the PIM apps are far less capable than what I had on my Treo. That will not stand if developers have the access that they need to create replacements...but I can suspect that there are many more "undocumented APIs" in use for those other apps as well...and *that* is why I am writing.
BTW, your car example is great...and you can use it in many other areas...like computers. Where many parts are available, you can get great replacements inexpensively. Where they are not, you pay through the nose...often without options for features and quality. Think of a SATA hard drive. Works in any PC...and you can get one for $50. You can also pay for a 10k or 15k RPM drive. In contrast, the same size custom drive for a Sun-based proprietary architecture costs $1200. Competition is good. Similar examples convey to vehicle parts...unless you think that the JC Whitney catalog is worthless.
Functionality is what counts? Then search the forums and read the complaints about the steps backward from the Treo...and the many things that the iPhone can do that WebOS cannot. Give it time? Yeah, well we'll see *if* they have time. That requires survival. Also, you "strike when the iron is hot" and many developers are interested now at the outset...and Palm ignores that enthusiasm at their own peril.
Of course, Mark twain had a saying for arguing with a fan boy...and I think that I'll take that advice.
It's not the use of undocumented features that's the problem. He put his app id in the com.palm namespace to allow his app access to things that right now only Palm apps can do. Allowing a 3rd party app to masquerade as a Palm app is not the "right thing to do", because that app would be more able to screw up your phone, and possibly snag your personal data. While I'm jazzed about the homebrew scene, I refuse to install a 3rd party app which has more priviledged access to my device. The right thing to do is be patient, wait for the features you want in the sdk to open up and then resubmit. There's no need to blow this out of proportion.
It's an interesting argument being made for developers; that is, the only way WebOS and Palm will be successful is for Palm to essentially let developers do whatever they feel like. Of course, no other businesses ever place restrictions on how their interests will be used in partner and third party relations. Please. This whole line of reasoning is absurd. Palm is absolutely right to do what they did. If a dev doesn't like the rules established, then they should either do a better job up front negotiating for a change to them or move on to another platform that tollerates it.
Palm took the financial risk in rolling out the platform and hardware. It's almost all Palm skin in the game. I suggest those devs that think the rules don't matter should consider starting their own company and develop a competing product to Palm. Perhaps if they had a real risk, they'd be a little more sympathetic. It would be interesting to see just how tollerant they'd be to outsiders violating their established rules (assuming they had any).
Palm has shareholders to answer to. They're acting like adults with real responsibilities.
This is why I think they need a third category. If Palm doesn't have the resources for an app that might need tons of testing, fine, put it in the 'will approve once OS is fully baked' pile. I am more than willing to wait for stability.
Again, they may have valid reasons, but it doesn't matter if it comes off as petty.
Most of the rants and flames at Palm have no clue what they're talking about. This has nothing to do with "competition", or "rights", or "hidden" APIs, or being "evil" or "stupid". It's about not allowing apps that might break with a new release of WebOS. I guarantee that the same people who are ragging on Palm now, would scream first and loudest if their $20 music player suddenly stopped working when they updated to WebOS 1.3 ... and the guy who developed it decided it wasn't worth his time to fix it.
YOU don't know what you're talking about. Like any application on any Operating System since the beginning of mankind, it can only be expected to work on the platform on which it was released. If your XP apps don't work in Vista, you either don't upgrade to Vista or you accept that your apps will no longer work. None of my Palm OS apps work in WebOS. Should I be angry about that?
I strongly suggest you read the first chapter (at least) of The Future of the Internet and how to stop it.
I will never choose to give up freedom for more security.
Except you have a choice to go to Vista or stay with XP. You don't have that choice as a general user on a webOS device. You must update. The vast majority of users don't hack and will likely not be able to turn off this "auto-update" feature.
How to download NanPlayer? Its not out on HomeBrew app list. Please help.
It isn't out yet.
Uh... "Allowing a 3rd party app to masquerade..."
isn't that exactly how the media sync works?
+1
Sounds like "eat your own dogfood" might have some merit here. Palm spoofs iTunes to look like an iPod, but they won't allow an app to Spoof like its Palm.
I've ran the numbers...it don't add up.
Pot, Kettle, etc...
Very bad move, Palm!
Don't be like Apple!!!!!
Keep up the great work, Palm! Shut those developing evildoers out from those private APIs!
I have a problem with Palm doing this. Yes the API is "undocumented" yet one of Palm's core apps uses it. What is th problem with this API that they don't want anyone else using it? It's obvious the API is dependable enough to use since Palm even uses it. Who is to say that Palm will never "document" this API, in essence never allowing any third party music players.
I think it's not really right for Palm to deny this tremendous app that many people have been waiting for and pretty much crushing the hopes of a developer that has tried to hard to use the WebOS within its limits for his own app. The API is not malicious, the app does not try to access anything low-level. It's not a mod of the stock app like Music Player Remix. It is completely original. Just because an API might not be "documented" doesn't give them the right to not allow anyone to use it, especially when they themselves created the API and use it themselves. Seems almost greedy of them to act this way.
Since you asked "what is the problem" ... the problem is most likely that the API could change and then the app would not work. Palm's internal apps would be updated with a new release of WebOS, but there's no guarantee (especially with a lone developer) that the 3rd party app would be fixed. You can argue that Palm should be providing/supporting this API ... I would agree, and most likely they will eventually. But it is in fact exactly "right" that Palm should protect customers of their App Catalog in this way.
It's time for Homebrew to go "Professional" --- seriously, why doesn't PreCentral just make Homebrew part of the PreCentral Store? It can come with all the same legal disclaimers. Developers can decide what they want to charge for, ask for donations for, or offer up for free?
Users, like me, will end up making decisions probably based on free trials/past experience/reviews, etc....I know there are are definite Homebrew Apps that I have supported through donation in the past, and will pay for in the future if it comes to it.
Won't that violate the TOS though? I think part of the agreement to using the SDK is that you can't distribute your apps outside of the App Catalog. I know Palm is OK with the Homebrew scene but will that remain the case of P|C starts charging and competing with the App Catalog?
From the TOS http://developer.palm.com/termsofservice.html:
4.3 Applications Can Only Be Distributed Through the Palm Application Catalog. Developer acknowledges and agrees, that absent a separate written agreement with Palm, Developer may not distribute any Application except as allowed by Palm’s formal approved distribution process and channel (the “Application Catalog”)...
I totally agree w Kyusaku. Making Homebrew (Plus or some other name) part of the PreCentral Store is the right play. Competition is good.
I feel sorry for the developer for working hard on this app, but he didn't think that palm may actually be working on their music app? He used undocumented API and he thought palm would acept this on the App Catalog? Seems like he didn't think through.
This post explains why my 5-day-old Palm Pre quit working. I copied about 400 MB of music files to my Pre and listened to them with my BT sterio headset. My music files had lots of metadata. Palm's music player did not properly organize the music by Genre, Artist and Album as it should have. Many files were put in "Other" or "Unknown" when other similiar files were put into their correct Artist, Genre or Album category.
Right after I installed the music my Palm Pre, the launcher quit working. Google Maps showed garbage near the top of the screen.
The launcher problem didn't bother me because I was already running the apps I needed. However, because of the corruption, I threw up all the apps so nothing was running. Then I discovered the launcher wouldn't launch anything -- not even the phone dialer.
I reset it several times by holding down the Power button and flipping the switch 3 times. That did not fix the problem.
When I reported this to Palm, they wanted me to send them my phone immediately by courier so their engineers could study the problem. They are sending me a new Pre.
There is no doubt that my Pre's corruption was caused by the Music metadata because during the 5 days I used my Pre, I didn't run any other apps except the phone, Google and the music program. The Music program was clearly not working properly because it did not organize the music properly using the metadata.
Probably, the metadata overflowed the memory allocated to it by Music and corrupted Launcher and Google.
Palm will probably provide metadata support in the API and SDK when it resolves the problem that caused my Pre to because unusable.
I don't think so... it may not sort your music properly because of metadata, but if it can't read it then it certainly can't 'Overflow'.
I would wager that you had some other sort of issue with your phone OTHER than the MP3 issue.
Like I said before, if Palm need time to work on the OS and the SDK so that one day the NaNplayer can get released in the app catalogue, fine. Tell him that. Tell US that. I haven't had any problems with my Pre, but I don't want something to make the phone less stable.
And I just took a look at the Nan player in action. It looks very stable, and damn sweet!!!
http://www.youtube.com/watch?v=0iplM3Vz4Bw
I don't feel sorry I mean sorry for him that he spent all the time but he should have known that trying to pass a app with the com.palm wasn't going to past with palm. I mean really how mad at palm can you be?. The way he went about it is ment for the homebrew, so just release it maybe for a small donation from people and im sure they will be more than happy to do so.. Until then stop all the non sense blaming Palm.
I want Palm to comment publicly on this
DON'T JUST GET MAD, DO SOMETHING. Don't just post here, go to the forums and create a new thread that says the webOS music player stinks. Do the same in Pixi forums. Then do the same at other sites, including official Sprint and Palm sites. They'll get the message soon enough.
/concur
This app will prolly still be in the homebrew section and hopefully then by popularity of app it will have the bowties on it and resubmitted. Most likely when the next sdk is out though.
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 '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 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.
"4. fix bugs and add API's
palm can only do so much at once give them TIME."
Unfortunately Palm does not realize that time is not on their side. From when Pre was announced until it was released apple mostly caught up with them, and android has made significant improvements. By time palm finishes ironing out webos, apple and android will be at the next cycle, cutting any technological advantage they had. Palm's we know what best, and you'll take it as we give it attitude, doesn't work when you are playing catch up.
"P.S. anyone with any problem with what Iv'e said can leave a comment I'm waiting to here stupid comments."
Fvck you
Did you see the new Blur Motorola announced today? If it wasn't on t-mobile, it would seriously give the pre a run for it's money
quote: 'Fvck you'
yeah my name is Abe.
Sometimes it's as simple as looking in the mirror. To disagree with a point of view is one thing, but to put another developer down and resort to name calling, you simply say the same about yourself as you comments refereed.
Palm has done a great job developing this new platform and has been doing most things right when it comes to development and progress... however, there are some shortcomings. The music player is one of them... it works well for playing music, but by today's standards and in comparison to Palm's competition their player is lacking in many areas NaNplayer picked up the slack on. Palm absolutely should not have accepted the app, but should probably do things a bit different when denying an app which has so much potential and would be a great addition to the platform. Deny, yes, but work with the developer to make it happen in the future... don't slam the door in his/her face.
It's like when a kid comes to your door selling peanut brittle for his school... you can politely tell him your not interested...and maybe go a little further recommending he tries Sally down the street as she loves peanut brittle.. or you could just slam the door in his face, ensuring not only will he not come back to sell you more candy, but may stop selling it all together. Palm may not need or better, may not be ready for a new music player right now, but they sure do need a lot of everything else. The next thing the developer brings to the door may be just the thing they needed.
Palm, stop slamming doors.....do it in a better, more helpful way. You will reap the benefits in the end!
Abe, being constructive gets a lot more done than being destructive.... give it a try.... you too may benefit!
referred.... stupid spell check!
quote: Abe, being constructive gets a lot more done than being destructive.... give it a try.... you too may benefit!
I'm constructive to constructive people not to proplr who get angry when they do something stupid and make others (PALM) look bad.
check up my username on the webOSdev site read my posts and see if I'm being destructive, oh and try my app findMYcar its pretty destructive.
Abe
I'm not going to go as far as calling anyone an idiot here, but I must agree with the general points of this post. We all hate rejection, but the way the nanplayer dev handled this is not the way I'd suggest. Personally I'd have returned to Palm with a simple question: Do you have any advice on how I can fix this? Also, being willing to "listen" to the response helps. :-)
Keep in mind that Palm also makes some money on your apps if/when accepted. So I don't buy when people say they rejected it because it was "better than their pathetic app". That just does not add up for me. But hey, I'm getting all this second, third and forth hand so I don't know.
I have personally contacted Palm about issues I've run into as a developer and they have been nothing but helpful. In some cases I simply asked if there was a way to do "xyz" because I couldn't find it in the documentation. Now I knew there were ways to do these things because other apps were doing them. But the point is in the approach. Usually their response was "try this..." and the problems where usually resolved.
"In all likelihood, I will not develop any more webOS apps in the future."
Throwing the baby out with the bath-water, huh?
Seriously, your going to stop developing apps that people want because of one rejection? I sure am glad that some of the greatest writers/directors/actors/software developers of our day didn't give up completely after their first rejection.
Honestly though, I can understand at least one part of Palm's reaction here. There is a good chance that many of these features are going to be added in a future update to the music player from Palm. They have been releasing updates every couple of months that have been pretty substantial (I mean did you look at the changes for 1.2?). So, you never know.
But seriously, Blubble, don't give up your time will come. Put the same gusto you put into this app into something else and submit that.
You're entitled to your opinion, but you simply don't know what you're talking about.
There were several indications that Palm would make exceptions on a case by case basis when it came to undocumented APIs. There was mention of this on the private EAP forums and in some of the PreDevCamps. Additionally, other independent developers have been given permission to use undocumented APIs.
As an Early Access Program participant, I went through the proper channels to presubmit my app as Palm had suggested. The idea is that developers could work with Palm to polish their apps and to help them conform to Palm standards. Instead of looking at the app or even offering some path to approval, their rep simply rejected it. A more reasonable response would have been to review the app and suggest a plan for moving forward to approval in the future.
As far as dumping webOS, my reasons for that are not solely related to the rejection of the app. It's not a matter of spite. In developing NaNplayer, I have become very frustrated with the extremely limited SDK and the related tools for development. Many of the most basic APIs are non-existent or incomplete. There are a lot of features I wanted to add that are simply not possible documented or undocumented APIs. I mainly just want a better SDK that will allow me to write more advanced apps.
I don't really want to develop for the iPhone or Windows Mobile, so Android is the logical choice. Hopefully, Palm will come out with a better application development model in the future and I will happily write more apps for webOS.
WebOS has been out for 3 months. Give it some time. The iPhone had a crappier SDK when it was first released than Palm does.
The problem with this argument is that Apple have now established themselves, you can't come to market and expect the same sort of leinency as Apple got years ago. People now have an expectation that needs to be met, and if it isn't, then they will look elsewhere to fill it.
I get it though, I really do, WebOS and Palm are moving faster than Apple did with the iPhone, but in order to be successful they needed to take the trials and tribulations that Apple went through and have most if not all of that worked out before releaseing a phone/sdk to the public, not doing so makes them look like they are still behind the game, no matter how much faster and better they may be doing things now.
Yes I'm entitled to my opinion, and yes I do know what i'm talking about.
You do write ' The idea is that developers could work with Palm to polish their apps and to help them conform to Palm standards. '
DID YOU WORK WITH PALM or did you submit an app without contacting PALM if you could use undoc't API's and com.palm.
NO you didn't, you felt you had a great app that needs automatic approval, but you get upset when 'A more reasonable response would have been to review the app and suggest a plan for moving forward to approval in the future.'
you don't talk to them but want them to treat you like a king.
and BTW its pretty common knowladge on the webOSdev site that using com.palm will get your app booted, and that PALM is opening up more API's soon, so calm down and wait, or 'dump webOS'
quote: I mainly just want a better SDK that will allow me to write more advanced apps.
Patince My Noble Excelency.
Feel free to continue being a dick, but you still don't know what you're talking about.
I didn't submit a finalized app. I presubmitted the app per Palm's invitation. This option was only open to approved Early Access Program participants and the whole point is to help work out any issues with an app so that it could be included in the app catalog down the road. Where you part of EAP? If so, you should know about the presubmission program.
I knew that the app would require an exception and let them know that it used the API in question. I didn't expect them to automatically accept the app nor was the plan for it to go into the app catalog immediately, since it isn't even finished yet. I attempted to "WORK WITH PALM", but got nowhere fast.
However, I just got a call from them, so we'll see what they have to say.
Yup i'll continue being a dick as long as mother nature allows.
:)
Abe
P.S. I hope they give you and all of us more API's but i hope they don't give you a privilege because you acted like a brat.
Forgive me, but if you're a developer of any experience, you would have noted off the bat that the SDK isn't fully baked. (Full disclosure, I am developer - from the PalmOS 3.0 days.) In a lot of ways, the WebOS SDK/Emulator isn't even up the standards the PalmOS toolkit circa 1998. On the other hand, it's free (in terms of cost). The 1.1 image isn't a full fledged product, yet. Clearly, the Palm people are in a hurry.
Your case represents the risks of early adoption and entry into an unproven OS space from a vendor in a hurry. In defense of Palm, their explanation is specific, at least - and you can talk about it.
My own advice, from one hand held developer to another, is to wait until the platform settles. (Or start writing your own libraries - at least we dropped that 64K barrier from the old PalmOS.)
You should reserve your right to re-enter the WebOS market once the API/SDK settles into something more stable.
And with that...
I am with Palm on this one. The application uses an undocumented API hence the reason why the application needs an appid of com.palm.*. Palm cannot risk allowing an undocumented API supported application into the app catalog. Should users have issues with the app, Palm cannot support them. Once the API is fully functional and stable I am sure Palm will open up the API to the public.
Time is valuable and Mr./Ms. Bubble gives as well as he/she gets.
We/I/you can only hope that reason prevails and that he/she/they come to a solution soon/today/someday.
I agree with Blubble. From what I've seen of the app, Palm should have at least looked at it and considered giving it special attention.
And Blubble, dude, seriously, when can I get the app on my phone. I'll pay you money. I'll wait, I'm a patient man. Just let me know you haven't given up on the app all together.
So are you saying EVERYONE that uses undocumented API's should get special attention? There is a reason why the API is not documented yet.
+1
+1
As expected, Motorola just introduced its Android strategy at the Mobilize conference, and it's based around a skin called Blur -- or MOTOBLUR if you're feeling cute. It's built around social networking, and it features live widgets that integrate Twitter, Facebook, Gmail, MySpace, Yahoo, Last.fm and more. Like Palm's Synergy, Blur aggregates all your contacts into a single address book, but it shows you recent status updates along with photos when contacts call you -- very slick. There's also remote wipe and GPS tracking like MobileMe.
Motorola just announced its first Android handset, the Cliq, which is headed to T-Mobile by the fourth quarter, or in time for the holidays. As you'd expect, it runs the new MOTOBLUR Android skin, and Moto's calling it "the first phone with social skills" to highlight the social networking integration. It'll come in two colors, Winter White and Titanium, and have 3G, WiFi, and a five megapixel camera that'll also shoots 24fps video. Internationally, the Cliq will be known as the DEXT, and it'll be on Orange, Telefonica, and America Movil.
This is probably stated already, but another good reason for why they might reject the app is they might be thinking about updating their stock music player already.
What would make a lot more sense to be honest, is if Palm just hired Blubble as a consultant to work on the music player. The contract should/could be just until the music player is to the level Palm is happy with.
That way Blubble gets paid for his work, and Palm benefits a lot, because c'mon Blubble's music player >>>>>>>>>>>> Palm's default music player. I just think Blubble's on the losing end though since it makes too much sense that Palm is gonna upgrade their stock music player a lot.
This goes to show that app stores are like communism. It sounds great on paper, but in practice it only leads to abuse and corruption.
I had such high hopes for WebOS, but it appears that we're only going to see more of the same. Palm will most likely keep a tight grip on their app store, despite their promises and reassurances to the contrary. I blame Apple for setting the stage for this sort of behavior.
It's pretty sad to see our mobile technology going this direction. We own appliances, not mobile computers. We'll never see anything on the Pre that exceeds Palm's limited vision. That makes me very, very sad.
i'm sorry but you seem very uninformed, no communism going on here, its the simple case of someone trying to get privilged care, and he didn't get it.
This is like someone applying for a job when he/she doesn't have the required degree... and hoping to get it anyway, would you act angrily at the employer for not taking on the employee.
I agree with you! People complain because the SDK isn't released yet so what does Palm do??? They release the SDK early. Then people complain because apps aren't being added to the catalog. Palm then starts taking apps and people complain that the SDK is not open enough at this point in time for them to create ANY application they want. It seems no matter WHAT Palm does people are always going to complain.
Rome was NOT built in a day nor was the Earth. You have to give things time. If Palm just opened all API's people would find problems with them and complain that the SDK is crap. Palm is protecting them selves by only opening API's that have been completed and approved.
Just because MEDIAEVENTS API is not open right now doesn't mean it will not be open in a next release.
+1
and may I add, it seems the ones who are complaining are not Dev's
Both devs and others are complaining for one side or another and it seems to be going either way.. just read the posts... not just those who take your point of view.... both sides are wrong in a way and both sides have valid points. Their are lessons to be learned by both devs and palm in building stronger relationships between the parties as it is in everyone's best interest. Just because people are not developers, they are the one who will potentially be supporting developers by purchasing apps and should be able to have opinions on the subject.
I am not a developer, but have been following the progress on this device all year. I am expert in my own field, but that does not mean that I cannot understand the points of view of those of another field... sometimes those from the outside can lend better incites than those with the in,who have their heads buried within their closed perspectives. We all tend to do it, but keeping an open mind makes up all better at what we do.
FOR ANY DEVELOPER USING MEDIAEVENTS AND WANT TO GET THEIR APP SUBMITTED TO THE APP CATALOG CONTACT ME FOR CUSTOM FUNCTIONS SIMILAR TO THOSE IN MEDIAEVENTS. BY CREATING CUSTOM FUNCTIONS YOU DO NOT NEED TO USE THE COM.PALM.* APPID. I HAVE ALREADY SUCCESSFULLY CONVERTED NET2STREAMS TO BE APPCATALOG COMPLIANT
sound great.
words cannot express how disappointed i am with this news. I know this must be a harsh situation for Blubbles, and I really wish palm would do something to help this app become a reality instead of simply shooting it down. This is the only truly GREAT app I've seen running on the pre (though some are quite impressive) and it would suck to see someone like Blubbles not develop for WebOS any longer. I'll support your homebrew app, and i'll definitely be writing palm about their oversight.
Please don't leave us!!!
nothing to be disappointed about it seems palm has called him to work things out.
Abe
I would totally pay for NaNplayer! fyi
Want to leave a comment? Register for free!
In an effort to reduce comment spam, you need to log in to comment. Registration is fast, free, and easy and gives you access to comment, discuss the Palm Pre on the largest Pre forums on the 'net, enter contests, and much more. Join now!