Waveboard 2.0 is afgewezen door Apple omdat er gebruik was gemaakt van Three20 libraries. Die kunnen private API's aanroepen waardoor Apple de applicatie niet goedkeurt.
Taalfout gezien of andere suggestie hoe we dit artikel kunnen verbeteren? Laat het ons weten!
Artikelcorrectie, spelfout of -aanvulling doorgeven?
Reacties: 16 reacties
yoenoesz
Offtopic, melden dat je de eerste bent voegt niets toe aan discussie.
Niels
Wat een onzin zeg..
Kijk, ik snap dat Apple de touwtjes in eigen handen wil houden. Hierdoor zijn ze natuurlijk ook succesvol 🙂
Maar hierin draven ze een beeetje door. Inbox en Push zou worden toegevoegd aan de app, leuke verbetering zou je zeggen. Maar waarom moet apple dit in godsnaam afkeuren? Omdat er gebruik wordt gemaakt van een onderdeeltje dat eigenlijk niet gebruikt mag worden. Maar waarom niet??? Apple wordt toch niet slechter van deze 2 nieuwe functies? Hun merk wordt toch niet aangetast? Hun uitstraling niet? Hun exclusiviteit niet? Nee, ze krijgen juist een slechtere naam door steeds zulke rare afwijzingen te doen.
De iPhone leeft op de community, maar in plaats van de community goed en respectvol te behandelen ontstaan er volgens mij alleen maar meer irritaties. Ik kan hier zelf niet over meepraten omdat ik niets te maken heb met het ontwikkelen van apps, maar als ik de verhalen zo lees dan wordt ik wel moe van apple.
Jammer, want push updates voor Google Wave zou ik wel een goede plus vinden! 😛
Peabz21
Regels zijn regels! Er moet ergens een grens zijn.
Nmz
@:
betekent niet dat de regels goed zijn voor het merk Apple en de iPhone community
Nmz
Aan de andere kant vind ik het niet erg dat dit waveboard overkomt. Als wave verder wordt uitgerold komt google zelf met een gratis app, dan kun je waveboard wegmieteren. Daarnaast ziet het er exact zo uit als de webversie. Zonder deze upadte voegt het dus helemaal niets toe.
Aus
Hoewel ik steeds minder enthousiast over Apple en hun beleid wordt hebben ze hier gelijk. Een programmeur weet dat je private api’s niet moet gebruiken doe je dat toch dan is dat jouw eigen probleem.
Uiteindelijk is iedereen daar bij gebaat want anders valt bij een nieuwe firmware alles om
Sanjeev
Gonny, een iphoneclub nieuws applicatie voor de iPhone. Dat zou echt geniaal zijn 🙂
Jens Kortmeijer
Waarom zouden die libraries private moeten blijven. Dat heb je bij OSX toch ook niet ?
Pieter
@Niels:
Ik denk dat je niet begrijpt hoe een software platform werkt. Apple levert een OS met bepaalde functionaliteit, die aangesproken kan worden via een gedefinieerde interface (de API). Deze interface is vastgelegd en gedocumenteerd en de OS leverancier zal deze dus moeten blijven ondersteunen. Om het OS te kunnen maken en de afgesproken API’s te maken zal de OS bouwer gebruik maken van code, die wellicht interne interfaces aanroept om code te hergebruiken (Beter 1 keer iets in een bibliotheek zetten en aanroepen dan op 20 plaatsen (net iets anders) implementeren).
Deze interne code is, zoals de naam al zegt, intern.
Deze zal dus niet gedocumenteerd hoeven te zijn richting de normale ontwikkelaars en kan, als de OS bouwer dat nodig vindt, met iedere software versie veranderen.
Een voorbeeld: Een resultaten lijst is in v1 een normale lijst, in v2 een hash table.
Voor de bovenliggende API, die gewoon de gevonden gegevens wil hebben en dat ook aangeleverd krijgt via de API, geen probleem. Als echter code van de ontwikkelaar direct in deze resultaten lijst probeert te kijken, zal het niet meer werken. De hash table kan echter bijvoorbeeld 10 x sneller zijn en dat is voor iedereen leuk…
Daar het interne code is, hoeft de OS bouwer geen zeggenschap af te leggen richting de 3rd party ontwikkelaars, zolang ze de afgesproken API’s maar intact laten.
Het probleem is dus dat er gebruik gemaakt wordt van deze prive bibliotheken, terwijl die niet officieel geleverd zijn. Als ontwikkelaars ecter gebruik maken van functies, zorgt dat er opeens voor dat deze niet aangepast kunnen worden (of verwijderd), zonder dat dat impact heeft op de applicatie die er gebruik van maakt. Dit is voor de door de OS bouwer geleverde programma’s geen probleem, daarvan is bekend welke App gebruik maakt van een interne functie en deze zullen zijn aangepast. Echter, voor de Apps in de buitenwereld is dit niet het geval… Oftewel: App gaat stuk, OS bouwer krijgt de schuld. Als ze dit niet willen, moeten ze de API in stand houden, maar dat levert een probleem op voor innovatie en onderhoud. Als alle oude (Interne!) code moet blijven werken, inclusief de bugs waar mensen workarounds voor hebben gemaakt, krijg je een systeem wat steeds logger en groter wordt.
Om dit te voorkomen zal de OS bouwer dus niet willen dat ontwikkelaars gebruik maken van dit soort interne interfaces…
@Nmz:
Deze regel is dus juist zeer goed voor de community: Apple kan de interne structuur dus wijzigen en bijvoorbeeld opeens multithreading of GPU code toevoegen voor de interne implementatie van de code, waardoor deze beter/sneller/kleiner zal zijn, waar iedereen profijt van zal hebben. Kijk naar OS X: Iedere versie is sneller (en kleiner) geworden, omdat ze interne zaken anders oplossen. Dat had niet gekund als ontwikkelaars de interne code aanroepen….
Pieter
@Jens Kortmeijer:
Zeker weten van wel.
Kijk maar in /System/Library/PrivateFrameworks/
Sterker nog, bij mij (10.5.8), staan er 128 PrivateFrameworks en slechts 82 publieke in /System/Library/Frameworks/ …
Wat is er toch gebeurd met de slogan ‘think different’. Alles wordt ingeperkt en tegengehouden. De vrijheid van de gebruiker neemt hierdoor ernstig af. Erg jammer.
Maar waarom niet??? Apple wordt toch niet slechter van deze 2 nieuwe functies? Hun merk wordt toch niet aangetast? Hun uitstraling niet?
Vergeet niet dat ontwikkelaar Storm8 door (mis)(ge)bruik van deze private API’s onder vuur ligt i.v.m. het naar de server sturen van het Iphone telefoon nummer.
avdvee
Wat is er toch gebeurd met de slogan ‘think different’
Alhoewel ik ook baal van dat restrictieve beleid, vage criteria en slechte communicatie klopt die stelling in deze nog wel. Want alleen Apple handelt op deze manier; de rest van de markt niet. Dat kun je met recht different noemen.
Pieter
@avdvee:
Vergeet het maar.
Ook andere OSen en programma’s die een plug-in architectuur hebben (Denk aan Photoshop) zullen dit statement hebben, anders kun je nooit de code van het OS/de applicatie wijzigen.
Heb je de illusie dat de nieuwe Windows Mobile Marketplace dit toelaat? Of een game die gaat draaien op een PS3/Wii/Xbox360?
Apple is hier niet de enige in.
Maar wat ik dan niet begrijp, als Apple volledig in haar recht staat om applicaties zo af te wijzen, waarom er dan zo vaak aandacht aan wordt besteed als er een app wordt afgekeurd. Dit moet dan toch niet echt veel nieuwswaarde hebben?
En de reden waarom de ontwikkelaar van de Facebook app stopt is dan ook vaag, omdat Apple hier dan niets fout zou doen en hij weet wat hij wel en niet kan gebruiken toch?
Offtopic, melden dat je de eerste bent voegt niets toe aan discussie.
Wat een onzin zeg..
Kijk, ik snap dat Apple de touwtjes in eigen handen wil houden. Hierdoor zijn ze natuurlijk ook succesvol 🙂
Maar hierin draven ze een beeetje door. Inbox en Push zou worden toegevoegd aan de app, leuke verbetering zou je zeggen. Maar waarom moet apple dit in godsnaam afkeuren? Omdat er gebruik wordt gemaakt van een onderdeeltje dat eigenlijk niet gebruikt mag worden. Maar waarom niet??? Apple wordt toch niet slechter van deze 2 nieuwe functies? Hun merk wordt toch niet aangetast? Hun uitstraling niet? Hun exclusiviteit niet? Nee, ze krijgen juist een slechtere naam door steeds zulke rare afwijzingen te doen.
De iPhone leeft op de community, maar in plaats van de community goed en respectvol te behandelen ontstaan er volgens mij alleen maar meer irritaties. Ik kan hier zelf niet over meepraten omdat ik niets te maken heb met het ontwikkelen van apps, maar als ik de verhalen zo lees dan wordt ik wel moe van apple.
Jammer, want push updates voor Google Wave zou ik wel een goede plus vinden! 😛
Regels zijn regels! Er moet ergens een grens zijn.
@:
betekent niet dat de regels goed zijn voor het merk Apple en de iPhone community
Aan de andere kant vind ik het niet erg dat dit waveboard overkomt. Als wave verder wordt uitgerold komt google zelf met een gratis app, dan kun je waveboard wegmieteren. Daarnaast ziet het er exact zo uit als de webversie. Zonder deze upadte voegt het dus helemaal niets toe.
Hoewel ik steeds minder enthousiast over Apple en hun beleid wordt hebben ze hier gelijk. Een programmeur weet dat je private api’s niet moet gebruiken doe je dat toch dan is dat jouw eigen probleem.
Uiteindelijk is iedereen daar bij gebaat want anders valt bij een nieuwe firmware alles om
Gonny, een iphoneclub nieuws applicatie voor de iPhone. Dat zou echt geniaal zijn 🙂
Waarom zouden die libraries private moeten blijven. Dat heb je bij OSX toch ook niet ?
@Niels:
Ik denk dat je niet begrijpt hoe een software platform werkt. Apple levert een OS met bepaalde functionaliteit, die aangesproken kan worden via een gedefinieerde interface (de API). Deze interface is vastgelegd en gedocumenteerd en de OS leverancier zal deze dus moeten blijven ondersteunen. Om het OS te kunnen maken en de afgesproken API’s te maken zal de OS bouwer gebruik maken van code, die wellicht interne interfaces aanroept om code te hergebruiken (Beter 1 keer iets in een bibliotheek zetten en aanroepen dan op 20 plaatsen (net iets anders) implementeren).
Deze interne code is, zoals de naam al zegt, intern.
Deze zal dus niet gedocumenteerd hoeven te zijn richting de normale ontwikkelaars en kan, als de OS bouwer dat nodig vindt, met iedere software versie veranderen.
Een voorbeeld: Een resultaten lijst is in v1 een normale lijst, in v2 een hash table.
Voor de bovenliggende API, die gewoon de gevonden gegevens wil hebben en dat ook aangeleverd krijgt via de API, geen probleem. Als echter code van de ontwikkelaar direct in deze resultaten lijst probeert te kijken, zal het niet meer werken. De hash table kan echter bijvoorbeeld 10 x sneller zijn en dat is voor iedereen leuk…
Daar het interne code is, hoeft de OS bouwer geen zeggenschap af te leggen richting de 3rd party ontwikkelaars, zolang ze de afgesproken API’s maar intact laten.
Het probleem is dus dat er gebruik gemaakt wordt van deze prive bibliotheken, terwijl die niet officieel geleverd zijn. Als ontwikkelaars ecter gebruik maken van functies, zorgt dat er opeens voor dat deze niet aangepast kunnen worden (of verwijderd), zonder dat dat impact heeft op de applicatie die er gebruik van maakt. Dit is voor de door de OS bouwer geleverde programma’s geen probleem, daarvan is bekend welke App gebruik maakt van een interne functie en deze zullen zijn aangepast. Echter, voor de Apps in de buitenwereld is dit niet het geval… Oftewel: App gaat stuk, OS bouwer krijgt de schuld. Als ze dit niet willen, moeten ze de API in stand houden, maar dat levert een probleem op voor innovatie en onderhoud. Als alle oude (Interne!) code moet blijven werken, inclusief de bugs waar mensen workarounds voor hebben gemaakt, krijg je een systeem wat steeds logger en groter wordt.
Om dit te voorkomen zal de OS bouwer dus niet willen dat ontwikkelaars gebruik maken van dit soort interne interfaces…
@Nmz:
Deze regel is dus juist zeer goed voor de community: Apple kan de interne structuur dus wijzigen en bijvoorbeeld opeens multithreading of GPU code toevoegen voor de interne implementatie van de code, waardoor deze beter/sneller/kleiner zal zijn, waar iedereen profijt van zal hebben. Kijk naar OS X: Iedere versie is sneller (en kleiner) geworden, omdat ze interne zaken anders oplossen. Dat had niet gekund als ontwikkelaars de interne code aanroepen….
@Jens Kortmeijer:
Zeker weten van wel.
Kijk maar in /System/Library/PrivateFrameworks/
Sterker nog, bij mij (10.5.8), staan er 128 PrivateFrameworks en slechts 82 publieke in /System/Library/Frameworks/ …
@yoenoesz: Beetje teveel FML’s gelezen?
Wat is er toch gebeurd met de slogan ‘think different’. Alles wordt ingeperkt en tegengehouden. De vrijheid van de gebruiker neemt hierdoor ernstig af. Erg jammer.
@Niels:
Vergeet niet dat ontwikkelaar Storm8 door (mis)(ge)bruik van deze private API’s onder vuur ligt i.v.m. het naar de server sturen van het Iphone telefoon nummer.
Alhoewel ik ook baal van dat restrictieve beleid, vage criteria en slechte communicatie klopt die stelling in deze nog wel. Want alleen Apple handelt op deze manier; de rest van de markt niet. Dat kun je met recht different noemen.
@avdvee:
Vergeet het maar.
Ook andere OSen en programma’s die een plug-in architectuur hebben (Denk aan Photoshop) zullen dit statement hebben, anders kun je nooit de code van het OS/de applicatie wijzigen.
Heb je de illusie dat de nieuwe Windows Mobile Marketplace dit toelaat? Of een game die gaat draaien op een PS3/Wii/Xbox360?
Apple is hier niet de enige in.
@Pieter: heldere uitleg 🙂
Maar wat ik dan niet begrijp, als Apple volledig in haar recht staat om applicaties zo af te wijzen, waarom er dan zo vaak aandacht aan wordt besteed als er een app wordt afgekeurd. Dit moet dan toch niet echt veel nieuwswaarde hebben?
En de reden waarom de ontwikkelaar van de Facebook app stopt is dan ook vaag, omdat Apple hier dan niets fout zou doen en hij weet wat hij wel en niet kan gebruiken toch?