I was tweaking SSML in Actions on Google, thought I did it right, but the test app didn't change the rate and pitch in prosody(audio part was working fine):
conv.close(`<speak>${conv.data.userName}.<prosody rate="x-fast" pitch="+5st">Can you hear me now?</prosody>, your lucky number is ` +
`${luckyNumber}.<audio speed="200%" repeatCount="10" src="${audioSound}"></audio></speak>`);
Appreciate the help.
Your SSML looks perfect. My experience with the simulator has been that (maybe because of caching?) the simulator doesn't always immediately respond with updates when you update your webhook fulfillment.
Related
I've inherited a codebase that implements a half-baked implementation of custom intents and shortcuts. One issue that I can't figure out is the one described by the title.
On paper, everything seems to work. When the confirm() method's completion handler is called, the response code passed is '.ready'; the UI extension boots up correctly, everything. In the UI extension, cancellation works great. However, when "confirm" is pressed in the UI extension, it just runs through the same confirmation flow again.
So why is the handle() method in my intent handler not being called? Is there something I'm missing? Anyone see any holes in what I'm describing? Unfortunately I can't put large swathes of code into this post, but if anyone would like to see anything specific just let me know and I'll start adding small snippets.
Ran it on a real device and it worked. Not an ideal solution (especially if you're doing watch stuff, with those ridiculous build times) but it works.
SoupChef had the same issue for me & a coworker of mine, so we went ahead and filed a bug report with Apple as well.
I'm trying to send a second source of audio (streamed from a bluetooth connected device as Int16 data flow) to a room using twilio-video on iOS.
I already looked at TVIAudioController but found nothing about audioInput.
Checked-out also TVIAudioSink but I don't know if it can do the job.
Anyone can help ?
Twilio developer evangelist here.
I'm not an expert in this at all, but since no-one else has helped yet, I can try to point you in the right direction. It sounds like you're trying to hack around the limitation of using one microphone on an iOS device at a time. Good luck!
In order to send another audio track, you need to create a TVILocalAudioTrack. Normally this is initialised using the track method, which picks the audio input itself. It's not recommended to use the regular initializer, but that is probably worth exploring.
Once you have your TVILocalAudioTrack you need to add it to your room Participant using addAudioTrack.
Let me know if that helps at all.
I'm using the VerificationController provided by Raywenderlich in several of my apps, and it's been fantastic. Totally reliable, easy to implement, and effective. It's been live in three of my apps for several months each.
However, two days ago, all three apps suddenly stopped working properly. Every purchase is now being flagged as invalid without exception, both for my live users and for my own test accounts. I've made no changes to the apps or their backends, in fact I've been moving apartments so I literally haven't touched them in a week or more. The change was instantaneous across all three apps, and I've understandably started getting complaints.
The problem seems to be in the checkReceiptSecurity() function (it's always returning NO when it needs to return YES for valid transactions), but the code inside that function is beyond my ability to comprehend. I'm hoping someone has encountered something like this, or perhaps is even experiencing it now, and knows a solution?
As far as I can tell, it seems to be happening on the second of these lines (VerificationController.m line 158).
require(signature_length > offsetof(struct signature_blob, certificate), outLabel);
require(signature_blob_ptr->version == 2, outLabel);
certificate_len = ntohl(signature_blob_ptr->cert_len);
Which are helpfully commented as "Make sure the signature blob is long enough to safely extract the version and cert_len fields, then perform a sanity check on the fields." When it hits the signature_blob_ptr line, it suddenly jumps to the end of the function, which I assume means that it failed a check having to do with the version number of some response from Apple?
Can anyone shed any light on what is happening? This is obviously devastating to my app portfolio, and I need to fix it immediately. I'll disable the verification temporarily and release an update if I have to, but I'd like to find a fix for whatever has changed...
Search for "receipt validation" at https://forums.developer.apple.com
Apparently, a certificate update just made VerificationController to stop working.
The obvious, but not quick at all, fix is to use the more recent receipt validation processing. See: https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573-CH105-SW1
As for the code above, signature_blob_ptr->version == 3 now. But putting 3 instead of 2 in the code is not a fix as the signature is not 128 bytes long anymore.
this is my first time posting so if I make a mistake correct me please!
I am currently brain-storming an app, and as I have been researching part of it on here, and other places I have come to a bit of a snag. I want the app to be able to access the call timer on a iPhone (as in, it will be able to track how long you are in a call) and then store this information. As of 2011 it seems that this was either not possible, or you had to use something called CoreTelephony. I however could not find any recent material on this, so I was wondering if anything has changed in recent years.
Thanks in advance for any help!
If your trying to count/show how long someone has spent on the phone from the iphone usage data you cannont, If you are trying to show how long someone has been on the phone in your app using your phone/voip or what ever you use then you can use NSTimer
I read some of the similar posts on this site that deal with what seems to be the same issue and the responses didn't really seem to clarify things for me.
My application works fine in the simulator. I believe I'm on Bold 9000 with OS 4.6. The app is signed.
My app makes an HTTP call via 3G to fetch an XML result. type is application/xhtml+xml.
In the device, it gives no error. it makes no visual sign of error. I tell the try catch to print the results to the screen and I get nothing.
HttpConnection was taken right out of the demos and works fine in sim.
Since it gives no error, I begin to reflect back on things I recall reading back when the project began. deviceside=true? Something like that?
My request is simply HttpConnection connection = (HttpConnection)Connector.open(url);
where url is just a standard url, no get vars.
Based on the amount of time I see the connection arrows in the corner of the screen, I assume the app is launching the initial communication to my server, then either getting a bad result, or it gets results and the persistent store is not functioning as expected.
I have no idea where to begin with this. Posting code would be ridiculous since it would be basically my whole app.
I guess my question is if anyone knows of any major differences with device versus simulator that could cause something like http connection or persistent store to fail?
A build setting? An OS restriction? Any standard procedure I may have just not known about that everyone should do before beginning device testing?
Thanks
Just providing the URL will not work. You will have to append some info after the URL to determine the transport method your HTTP connection will use. For instance http://example.com;deviceside=true will use DirectTCP (you might also have to supply APN information but that's saved on the device for my phone). http://example.com;interface=wifi will use wi-fi. On OS 5 there's a ConnectionFactory class that makes this a lot easier. Here's a link that goes into more detail.
This was a tough one for me!
As Jonathan said you have to put some parameters in the url to make it work on the device. You shouldn't do it by hand but use the ConnectionFactory instead.
As you may thing this would just make it work but it doesn't!
The real problem is that not the url has been altered because it has ;interface=wifi;deviceside=true in it (in my case). Depending on the webserver accepting your request this could broke the code.
A solution I tried and that works is try to happend a fake parameter like
&foo=true -> &foo=true;deviceside=true
This will result as a standard parameter for the webserver but your device would use it to driver your connection.
On the simulator this work without this extra code because behind it there is a BIS server for you. On the device (as in my case) there isn't because I'm using a development device unregistered and without SIM (just wifi).
Another point is that the HttpConnection class doesn't handle HTTP 302 Redirect and if you get one you have to handle it manually.
It's probably an issue with the APN not being specified. See my answer for this question for details:
video streaming over http in blackberry
I would make this a comment, but I think I don't have enough rep yet for that... So I'll just answer and hope this doesn't get hosed for just pasting in some links.
I've been working on this exact sort of networking issue on our app this past week, and it is indeed tricky as some others have pointed out. Here are two links which really helped us out using HTTP on different devices, especially older devices which do not provide ConnectionFactory.
http://supportforums.blackberry.com/t5/Java-Development/Connecting-your-BlackBerry-http-and-socket-connections-to-the/td-p/206242
The first one has some code examples, including demonstration of querying the system's ServiceBook and CoverageInfo classes to make a decision about what kind of connection will work.