È stata interpretata come un netto cambio di rotta rispetto alle politiche commerciali di Apple, a parere di molti spesso al limite del bacchettonismo , la vicenda che qualcuno ha addirittura definito come lo sbarco della pornografia su App Store. Il protagonista è Hottest Girls applicazione il cui nome parla chiaro: mette a disposizione migliaia di foto di giovani più o meno discinte, ha fatto registrare il sold out. E si è fatta espellere.
Chi ha già testato l’applicazione, venduta al prezzo di due dollari, sembra disposto a giurare che le immagini proposte non sarebbero molto più scandalose di quanto è possibile vedere in TV: qualche capezzolo e molto softcore, nudo – per così dire – artistico. Una volta installata sul dispositivo, l’applicazione propone un set di quattro immagini, ognuna delle quali può essere ingrandita e, se particolarmente apprezzata, salvata nella propria galleria di immagini.
Dopo le prime 4 immagini si passa a quelle successive, che verranno scaricate dal server e visualizzate sul display del dispositivo. Il sistema, oltre a fornire alcune sezioni tra cui quelle dedicate alle bellezze bionde, brune, asiatiche e in costume, offre anche un servizio di rating delle immagini, utile a carpire meglio i gusti dei numerosi utenti che hanno acquistato il servizio e ad indirizzare il corso degli update che verranno distribuiti gratuitamente in futuro.
Comunque, nonostante l’applicazione sia normalmente comparsa sull’App Store, la sua repentina rimozione ha dato vita ad un piccolo giallo: vi sarebbe stato un ripensamento da parte dell’azienda californiana. A dissipare ogni possibile dubbio è stato l’ideatore dell’applicazione, secondo il quale le vendite sarebbero state sospese per l’eccesso di domanda da parte degli utenti. Ciò avrebbe sovraccaricato letteralmente i server legati all’applicazione, rendendo necessario lo stop onde evitare ulteriori disagi.
Nonostante ciò, dell’applicazione non sembra essere rimasta alcuna traccia: secondo i più maligni nella rimozione ci sarebbe lo zampino di Apple, ipotesi che sarebbe confermata da una nota inviata dalla Mela per chiarire quanto successo. A quanto pare, dopo aver ottenuto l’inserimento dell’applicazione, stando al parere di Apple, gli sviluppatori avrebbero pilotato dal loro server contenuti non ammessi dal regolamento imposto dall’azienda.
Difficile ipotizzare quale sarà il destino dell’applicazione, dal momento che non è dato sapere con precisione quali possano essere i contenuti non graditi ad Apple. In molti potrebbero pensare ad immagini più pruriginose di una bella donna ammiccante, ma dall’introduzione del sistema di parental control sul firmware 3.0 appena rilasciato, problematiche del genere dovrebbero essere superate.
Vincenzo Gentile
-
E' la possibilità che conta
Come da titolo, l'importante è che si possa fare, sta allo sviluppatore poi decidere COSA fare...Il bello dell'open è proprio questo: non ci sono catene :-)AndreabontRe: E' la possibilità che conta
> Come da titolo, l'importante è che si possa fare,> sta allo sviluppatore poi decidere COSA> fare...> > Il bello dell'open è proprio questo: non ci sono> catene> :-)...E liberarsi dai pesi morti come giava :DpippoRe: E' la possibilità che conta
quoto in pieno; alla fine trovo giusto che si sia aperta questa strada. Per come la vedo io in buona parte del codice le prestazioni non sono un grosso problema, soprattutto nella parte che si occupa dell' interazione con l' utente che un' operazione impieghi 1ms o 100ms ad eseguire spesso non è percettibile per l' utente e dunque non fa differenza (andate a vedere lo storico della quota idle del vostro proXXXXXre/i in una tipica sessione desktop se non ci credete).Esistono tuttavia piccole porzioni di codice in cui effettivamente ogni microsecondo è importante, ed è lì che l' NDK casca a fagiolo, permettendo di realizzare soluzioni perfettamente ottimizzate al caso specifico, senza overhead che in quel contesto sarebbero dannosi.E poi fintanto che parliamo di C/C++ siamo a posto, c'è l' unico inconveniente di dovere compilare per architetture diverse, ma non mi pare che questo sia mai stato un problema su linux/unix/bsd...pentolinoRe: E' la possibilità che conta
Bhe, se guardiamo proprio il millisecondo è un problema :-)Linux e co se la cavano sempre compilando tutto in assembly "universale".... che ha il difetto di non sfruttare mai al 100% la potenza di ogni singola macchina (ognuna differente)Per questo il C si è imposto nel mondo open :-) Hai il sorgente e puoi compilartelo da solo in assembly specifico per la tua macchina, ottenendo la massima ottimizzazione :-)AndreabontRe: E' la possibilità che conta
> Bhe, se guardiamo proprio il millisecondo è un> problema> :-)> > Linux e co se la cavano sempre compilando tutto> in assembly "universale".... che ha il difetto di> non sfruttare mai al 100% la potenza di ogni> singola macchina (ognuna> differente)Che beep stai farneticando?Quale parte di./configuremakemake installnon ti è chiara?> Per questo il C si è imposto nel mondo open :-)> Hai il sorgente e puoi compilartelo da solo in> assembly specifico per la tua macchina, ottenendo> la massima ottimizzazione> :-)Questa è buona la prima ;)pippoRe: E' la possibilità che conta
assembly universale? intendi il C?se è per questo windows fa uso massiccio del c++ che è molto molto più lento del canzi linux è il sistema operativo che meglio sfrutta tutte la potenza dei proXXXXXri su cui girapabloskiRe: E' la possibilità che conta
L'importante che non ci siano standard, che ognuno faccia quello che gli paree che non esistono compatbilità...Boh si vede che la lezione non l'avete ancora imparataMuccaRe: E' la possibilità che conta
> L'importante che non ci siano standard, che> ognuno faccia quello che gli paree che non> esistono> compatbilità...Quale standard?Il giava di compile once and debug everywhere? :DpippoRe: E' la possibilità che conta
Non che la scrittura in codice nativo sia totalmente immune a questi problemi.Ricordo l'unico (credo) programma che rilasciai anni fa, come freeware in Internet. Usava, per una determinata funzione, delle standard API Win32. Da Win2000 a WinXP, quella parte ha smesso di funzionare. Magari, con una Virtual Machine, il problema non ci sarebbe stato: con Java, finora, non mi è mai capitata nemmeno una volta di differenze di funzionamento tra una piattaforma e l'altra.JosafatRe: E' la possibilità che conta
- Scritto da: pippo> > L'importante che non ci siano standard, che> > ognuno faccia quello che gli paree che non> > esistono> > compatbilità...> > Quale standard?> Il giava di compile once and debug everywhere? :DIn effetti Java è uno standard. Chiunque può implementare una JVM compatibile (ce ne sono diverse). Esiste anche una suite di test com MIGLIAIA di test che servono agli implementatori per capire se e dove sbagliano nell'aderenza agli standard.Ovvio che nelle implementazioni ci possono essere poi bachi, come in tutti i software. La lotta fra chi "vende" le JVM sta appunto nel dare l'implementazione + veloce e con - bachi (come kinder! :D)In ogni caso io il java lo compilo su di una macchia (windows-amd)e lo eseguo su di un'altra (linux-intel) e non ho MAI avuto problemi di compatibilità.Se poi tu ti riferisci a problemi di compatibilità nei giochetti java da cellulare, allora il problema la non è di java ma di chi sviluppa i giochi usando delle librerie NON STANDARD implementate solo su quello specifico cellulare.WhishperRe: E' la possibilità che conta
in pratica aprire la possibilità allo sviluppo di codice nativo vuol dire non avere standard?quindi windows e tutti i suoi applicativi sono una completamente fuori standardpabloskiRe: E' la possibilità che conta
Credo che per standard si intendesse la possibilità di far girare lo stesso programma su varie architetture.In effetti sul mio telefono Nokia Windows non ci va...Le midlet Java che scrivo e faccio girare sul mio computer invece sì.AntelucanoMi sa che c'è confusione...
Non vorrei sbagliarmi ma mi era sembrato di capire che le applicazioni Dalvik possano accedere a librerie di codice C/C++ compilato, tramite JNI. E' un pò diverso da come è raccontato nell'articolo..Dal sito...http://developer.android.com/sdk/ndk/1.5_r1/index.html#overviewPlease note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.reefRe: Mi sa che c'è confusione...
sono piuttosto i componenti nativi a non avere una libreria per l'acXXXXX all'api di sistema mentre tramite jni dalvik riesce a comunicare con i componenti nativia ben guardare però mi sembra sensato, google vuole mantenere il software per android il più portabile possibilepabloskiRe: Mi sa che c'è confusione...
- Scritto da: pabloski> sono piuttosto i componenti nativi a non avere> una libreria per l'acXXXXX all'api di sistema> mentre tramite jni dalvik riesce a comunicare con> i componenti nativi> > a ben guardare però mi sembra sensato, google> vuole mantenere il software per android il più> portabile possibileSì ma solo tra un device Android e l'altro.Non vogliono invece la portabilità tra Android e i sistemi Unix o Java suoi cugini, ragion per cui1) non hanno usato una JVM come tutte le altre e non supportano i vari JSR e2) benché il kernel sia Linux la libc di Android non è compatibile con quella Linux.La ragione ufficiale sono le performance ed il voler confinare la GPL nel kernel e nei driver ed usare altre licenze per le applicazioni. La sensazione però è che Google abbia paura che la gente si possa compilare su Android tutte le applicazioni Java o Linux che ci sono in giro.Che faccia male allo store? ;-)Antelucanoe i virus?
campo libero ai virus su Android quindi, ottimo.MicheleRe: e i virus?
ps. strano che Google non ci abbia pensato, Chrome è davvero ben fatto dal punto di vista sicurezza.. sono io ad essere poco informato? :-|MicheleRe: e i virus?
Linux normale lavora sugli eseguibili da sempre... eppure non soffre di virus come soffre windows (penso che i virus per linux si possano contare sulle dita di una mano, e probabilmente sono già stati resi tutti inoffensivi)Dato che android ha sotto un sistema linux, rimane quella sicurezza intrinseca (sempre che non abbiano fatto stupidate) di un sistema Linux per PC....Quandi che venga eseguito codice compilato invece che codice per macchina virtuale cambia veramente poco in termini di sicurezza...(ps: esistono i virus scritti in java.....)AndreabontGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoGrazie per esserti iscritto alla nostra newsletterOops, la registrazione alla newsletter non è andata a buon fine. Riprova.Leggi gli altri commentiPubblicato il 29 giu 2009Ti potrebbe interessare