vibracion vibra solucion solo silencio poner pone funciona como boton iphone ios4 iphone-sdk-3.0 avaudioplayer avaudiosession

vibra - ¿No está funcionando la detección del interruptor Ring/Silent/Mute del iPhone utilizando AVAudioPlayer?



vibracion iphone 6 (7)

"Sin embargo, si alguien pudiera mostrarnos cómo usar esta AudioSessionProperty_AudioRouteDescription, la recompensa es legítimamente suya".

Bueno, solo NSLog () el resultado y obtienes

routes: { "RouteDetailedDescription_Inputs" = ( ); "RouteDetailedDescription_Outputs" = ( { "RouteDetailedDescription_PortType" = Speaker; } ); }

Desafortunadamente, obtengo ese resultado idéntico en un iPad2 / OS 5.0, tanto silenciado como no silenciado. Por lo tanto, parece ser funcionalmente equivalente a kAudioSessionProperty_AudioRoute, no hay alegría allí.

Al buscar en las placas de desarrollador se encuentra que este es un problema que se encuentra con frecuencia, se resume mejor con

"Informé este problema con rdar: // 9781189 en julio y el problema aún está presente en el GM".

Entonces sí ... seguro parece que eres SOL con esto en 5.0.

APÉNDICE:

"¿Pero qué hay de ese CFDictionary que estás registrando? ¿Cómo puedo acceder a la clave" RouteDetailedDescription_PortType "?"

El puente gratuito es tu amigo.

CFDictionaryRef asCFType = nil; UInt32 dataSize = sizeof(asCFType); AudioSessionGetProperty(kAudioSessionProperty_AudioRouteDescription, &dataSize, &asCFType); NSDictionary *easyPeasy = (NSDictionary *)asCFType; NSDictionary *firstOutput = (NSDictionary *)[[easyPeasy valueForKey:@"RouteDetailedDescription_Outputs"] objectAtIndex:0]; NSString *portType = (NSString *)[firstOutput valueForKey:@"RouteDetailedDescription_PortType"]; NSLog(@"first output port type is: %@!", portType);

produce

primer tipo de puerto de salida es: ¡Altavoz!

Muchos tipos de CFT comunes se conectan a tipos más convenientes.

http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html

Ahora, se necesita un poco de práctica para adivinar correctamente qué hechizos mágicos obtendrán algo útil del diccionario como el anterior. Un asistente de volcado de clases a lo largo de estas líneas te ayudará a ponerte al día con eso:

- (void)whatsInThis:(CFDictionaryRef)thingy { NSDictionary *dict = (NSDictionary *)thingy; for (NSString *key in dict.allKeys) { id value = [dict valueForKey:key]; NSLog(@"key: %@ value type %@", key, [value class]); if ([value isKindOfClass:[NSArray class]]) { NSArray *array = (NSArray *)value; for (id item in array) { NSLog(@" -- object type %@", [item class]); if ([item isKindOfClass:[NSDictionary class]]) [self whatsInThis:item]; } } } }

que para nuestro diccionario actual produce (añadiendo sangría para mayor claridad)

key: RouteDetailedDescription_Inputs value type __NSCFArray key: RouteDetailedDescription_Outputs value type __NSCFArray -- object type __NSCFDictionary key: RouteDetailedDescription_PortType value type __NSCFString

lo que le permite saber con certeza lo que podría haber deducido del registro original, sabiendo que NSLog muestra matrices dentro de () y diccionarios dentro de {} para que los moldes correctos sean eminentemente adivinables. Pero algunas estructuras CFType son más difíciles de analizar que eso.

Intenté utilizar estos métodos para intentar detectar que el interruptor de timbre / silencio está activo o no:

¿Cómo detectar mediante programación el interruptor de silenciamiento del iPhone?

La categoría AVAudioSession no funciona ya que la documentación dicta

Pero en mi iPhone 4, el valor de "estado" siempre es "Altavoz" (y el valor de longitud devuelto por CFStringGetLength (estado) siempre es 7). ¿Alguien ha usado este método exitosamente? Si es así, ¿en qué tipo de dispositivo y versión de SDK?

Lo estoy llamando así:

- (BOOL)deviceIsSilenced { CFStringRef state; UInt32 propertySize = sizeof(CFStringRef); OSStatus audioStatus = AudioSessionGetProperty(kAudioSessionProperty_AudioRoute, &propertySize, &state); if (audioStatus == kAudioSessionNoError) { NSLog(@"audio route: %@", state) // "Speaker" regardless of silent switch setting, but "Headphone" when my headphones are plugged in return (CFStringGetLength(state) <= 0); } return NO; } -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { AVAudioSession *audioSession = [AVAudioSession sharedInstance]; audioSession.delegate = self; [audioSession setCategory:AVAudioSessionCategoryAmbient error:nil]; [audioSession setActive:YES error:nil]; NSLog(@"muted? %i", [self deviceIsSilenced]); ... }

Estaba pensando que tal vez se active otro evento (más preciso) kAudioSessionProperty cuando el interruptor físico en el teléfono ... se conmuta. ¿Alguien tiene alguna idea?

Por cierto, estoy usando la categoría AVAudioSessionCategoryAmbient con mi [AVAudioSession sharedInstance].

Actualización: también he intentado usar diferentes categorías de audio y un puñado de otras propiedades de la sesión de audio, ninguna parece disparar al silenciar / anular el interruptor. :(

1 de enero de 2014 Actualización: es un poco complicado, y me encontré con un bloqueo al realizar SoundSwitch tareas en mi iPhone 5S, pero la biblioteca de SoundSwitch vinculada en la nueva respuesta aceptada es el camino a seguir si desea detectar el interruptor silencioso. Incluso funciona en iOS 7.

¡Bien, encontré la respuesta gracias a alguien de los foros de desarrolladores, y a ustedes no les va a gustar!

He recibido una respuesta de Apple sobre esto.

Han dicho que no lo hacen y nunca han proporcionado un método para detectar el cambio de silenciamiento del hardware y no tienen la intención de hacerlo.

:(

IMO definitivamente hay valor en detectar el interruptor silencioso y notificar al usuario en caso de que haya olvidado que estaba encendido ... ¡He tenido personas que se quejan de que no tienen ningún sonido y el cambio silencioso fue la razón! Oh bien.

PD: Si desea que Apple agregue esta función (¡y por supuesto que sí!), Presente un nuevo informe de error "Mejora" para "iPhone SDK" en http://bugreport.apple.com/

Actualización: aunque todavía no existe una forma oficial de verificar el estado del interruptor de silenciamiento, hay una solución / biblioteca llamada "SoundSwitch" que parece ser el truco. Consulte la nueva respuesta aceptada para el enlace.

Creo que tienes una impresión equivocada. Una ruta es hacia donde va. Desea saber el nivel de volumen. Use kAudioSessionProperty_CurrentHardwareOutputVolume

Intente insertar esta línea sobre su llamada a AudioSessionGetProperty dentro del dispositivoIsSilenced

AudioSessionInitialize (NULL, NULL, NULL, NULL);

En ese caso, comience a devolver la cadena vacía cuando el interruptor esté desactivado (aunque mostrará Auriculares y algunos otros estados si se conectan los auriculares o accesorios BT, por ejemplo).

FWIW No creo que haya nada en la API pública que se active cuando se mueva el interruptor real.

Ok, después de seguir kAudioSessionProperty_AudioRoute usando CMD + clic, encontré esto :(

/*! @enum AudioSession audio categories states @abstract Deprecated AudioSession properties @constant kAudioSessionProperty_AudioRoute Deprecated in iOS 5.0; Use kAudioSessionProperty_AudioRouteDescription */ enum { kAudioSessionProperty_AudioRoute = ''rout'', // CFStringRef (get only) };

resulta que tenemos que usar kAudioSessionProperty_AudioRouteDescription , pero este tipo devuelve CFDictionaryRef o algo así, y no tengo ni idea de cómo manejarlo ...

Hice esta una respuesta en caso de que nadie nos muestre cómo usar kAudioSessionProperty_AudioRouteDescription , donde intentaré aceptar mi respuesta ...

Sin embargo, si alguien pudiera mostrarnos cómo usar esta kAudioSessionProperty_AudioRouteDescription , la recompensa es legítimamente suya.

editar:

Claramente, este es un problema de iOS 5. No dije esto antes porque parecía demasiado obvio, pero luego pensé que podría no ser tan obvio para los motores de búsqueda ... si entiendes lo que quiero decir.

Por lo tanto, iOS 5 no funciona con el interruptor de silenciar / silenciar en el iPhone debido al valor en desuso referido.

Pasé por esta biblioteca VSSilentSwitch.
No funcionó para mí (no funciona cuando empiezas a usar audio).
Estaba pensando en cómo lo hizo, y luego me di cuenta de que la llamada de finalización de audio se invoca casi tan pronto como el sonido comienza a reproducirse cuando estamos en silencio.
Para ser un poco más específico:
Los sonidos del sistema que se están reproduciendo utilizando AudioServicesPlaySystemSound completarán la reproducción tan pronto como se inicie.
Por supuesto, esto solo funcionará en categorías de audio que respeten el interruptor silencioso (el valor predeterminado AVAudioSessionCategoryAmbient respeta).
Entonces, el truco es crear un sonido de sistema, preferiblemente de sonido silencioso, y seguir reproduciéndolo una y otra vez, mientras se verifica el tiempo que tomó desde la reproducción hasta la finalización (instale un procedimiento de finalización usando AudioServicesAddSystemSoundCompletion ).
Si se llama al proceso de finalización muy pronto (permita un cierto límite), significa que el interruptor silencioso está activado.
Este truco tiene muchas salvedades, la más grande es el hecho de que no funcionará en todas las categorías de audio.
Si su aplicación reproduce audio en segundo plano, asegúrese de detener esta prueba mientras está en segundo plano o su aplicación se ejecutará para siempre en segundo plano (y Apple la rechazará también).