SmsRetrieverClient.startSmsUserConsent (senderPhoneNumber /* or null */)
This senderPhoneNumber is the number I know I will be receiving OTP from. My question is if I pass null, it can extract OTP from any number as documentation says (pass null so that it will consider any number would be allowed.). How will I know that my sender is correct? What happens if I receive two OTPs?
If this is not possible can I somehow pass two sender numbers that I am sure that either would be sending my OTP?
Anyone have any knowledge regarding this, please let know.
I did my research and writing my answer with my best. Coming to your questions
What happens if I receive two OTPs?
The answer to this question is you will not receive two messages in most of the cases which contain an OTP within a span of 5 minutes.
Even though let's consider a worse situation. Suppose you receive 2 SMS containing OTP back to back in that case SMS user consent API will only show the consent for the first received SMS (Assuming you have mentioned null as sender phone number).
So basically what happens is the user consent api will stop listning for sms once it detects and show a consent.
If this is not possible can I somehow pass two sender numbers that I
am sure that either would be sending my OTP?
Answer : Yes you can. if you know the senders possible names i.e say AD-Something, BC-Something, CC-Something then you can register the listners for all 3 of them one by one like this
val task1 = SmsRetriever.getClient(applicationContext).startSmsUserConsent("AD-Something")
val task2 = SmsRetriever.getClient(applicationContext).startSmsUserConsent("CC-Something")
val task3 = SmsRetriever.getClient(applicationContext).startSmsUserConsent("BC-Something")
once you declare like this your device will listen for all of those. Make sure you also check for a callback on these to know whether they are successful or not
How do I know these?
There is no official source/documentation for this. (I looked for the documentation but I didn't find any mentions regarding this) Then I tried it for myself and found it.
Honestly, I have a feeling like this question is just another version of pre-mature optimization at this time
Thank you.
Related
I have device that accepts commands in write characteristic and returns back data in notification characteristic. Problem is when I call 2 different commands (call 2 writes) and notifications returned back to me all mixed up I need to know for which write call this notification is for.
Q: is there way to find that out? Like call to write returns some id and its included into notification?
So right now, I'm currently using the TI SensorTag and edited it such that it will send a GATT notification with some data every time I press one of the switches on the device and followed this code where moisture is the data I'm trying to send.
static void sendData(void )
{
int length=0;
while(moisture[length] != NULL)
{
length++;
}
attHandleValueNoti_t nData;
nData.len = length;
nData.handle = length;
osal_memcpy( &nData.value, &moisture, length );
// Send the Notification
GATT_Notification( 0, &nData, FALSE );
}
Now on the Java side, TI provided the SensorTag app source code so I'm editing that to receive the data and save it into a .txt file for later retrieval. I was able to get the app to create a new directory on startup if it does not exist and create the .txt file and populate it with random strings with the same button press as the one used to send the data. A quick question I had about this is should this be done or should I use separate buttons?
What I'm having a huge issue even understanding is how to read the incoming notification or data. From what I understand so far, you need to know the characteristic or something of the incoming notification to read it? I do have notifications enabled on my central device so I know that I have at least that covered. For this kind of data transfer, I don't need to use any UUID things, correct? And if I do, would I be able to piggyback on one of the existing sensor services to do so? Or perhaps use the test service?
I've read a decent amount on BLE communications but I just can't seem to get it. How do I read the incoming notification or data I sent from the SensorTag through BLE?
A quick question I had about this is should this be done or should I
use separate buttons?
It's totally your call. If I were you, I would stick on to one button since BLE devices are better if designed the most simplest way. KISS.
From what I understand so far, you need to know the characteristic or something of the incoming notification to read it?
Yes, you need the same profile running on both the peripheral and the central to enable notifications. In Bluez for example, run the bluetoothd daemon with all experimental profiles to communicate with a TI Sensor tag like this: bluetoothd -E . The same logic applies for a central running on Java. Reference: http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796
For this kind of data transfer, I don't need to use any UUID things, correct?
No, you don't have to since you aren't creating a new service but rather using the moisture sensor service already available on the device.
I've read a decent amount on BLE communications but I just can't seem to get it.
To know more about Bluetooth terminology such as profiles, services, characteristics, asymmetric architecture, etc, please read the following references to understand the theory behind what's taking place:
http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796 (use this if you are already into the technical details of the project)
http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X/ref=pd_sim_14_1?ie=UTF8&refRID=13KZ3RZ0VW93CK91RCM3 (this gives a more general picture of the BLE)
I'm playing around with OSCeleton and Processing and succesfully got to track skeletons and do stuff.
What I'm wondering is if there's any way to change the delay time a "lost_user" message is sent to Processing.
This is taking so long for what I'm trying to achive, since i need to stop tracking a user as soon as he goes away from the screen, so I can accept another user's interaction. (imagine an installation where a lot of people wants to play with).
any help/tips would be really appreciated.
Jon
As far as I can tell from the OSCeleton's source and with my minimal experience with the kinect(I never used OSCeleton), there is no way to modify that code to do that. It seems to be a thing handled even lower, by the driver or by the kinect its self(?).
Yet you need not bind yourself with that, and I would suggest a couple of ways to bypass the problem if I understand properly.
First, the latest drivers and examples should have multi-user support, meaning you can just arrange who is your main user. From what I can tell from the source you do get an osc message in Processing when a new user is detected as well as an ID number. You can put each new user that arrives, into an arrayList and figure out a way to do things without depending on the latest user.
If you are still going for the user-after-user thing though, or I was mistaken about the multi-user support(which is mentioned nowhere in the README), you can check yourself whether a user has left the area. Although you can not get a definitive answer like that you can check for example, whether a specific joint or all joints of a user have moved in the last 10-20 osc messages received. That probably means storing the position of this joint in an 10-20 item array and continuously updating while also doing a check on whether the items are different. If all items in the array are the same, your user has not moved a bit and thus probably should not be taken to account.
Last but not least you can switch to other solutions. The one I used about a year ago was "Synapse for Kinect" which also seems stale now. The latest you can use is a Processing library called SimpleOpenNI which definitively have multi-user tracking and you won't need any intermediary programs running to give you the joints.
I hope this helps
I'm trying to have more control on the number we have next to our apps for the user, How can we just send the exact number to show instead of sending notification that increment that number each time.
Basically the current behavior is :
Friend ask for something or give me a gift it increase the number
If another friend send me something its increase the number.
When I log to the game all the counter is reset.
Wanted behavior :
When I log to the game and i go see only one friend on the counter for this friend is reset.
We are currently using facebook-java-api but we will probably merge to restfb soon.
But if you know how to do it in any language it will probably help.
The old dashboard api support the set_count method that can reset to 0 or put the value you want for your apps.
See http://developers.facebook.com/docs/reference/rest/dashboard.setCount/
However the facebook-java-api don't support setCount but the newer restFB does so we need to update our apps to the new api.
EDIT: Note that you and extend the BasicClient and create a custom IFacebook Method with facebook-java-api it`s not clean but it do the trick utils we upgrade to a new facebook api.
i want to send a SMS using GPRS in MIDlet...
anyone can help me??
Thanks in advance...
Sending SMS is a HUGE beast to conquer. Now I don't know the first thing about j2me, but I do know a bit about SMS since I was at one point working on a similar project (abandoned for the reason below).
The short end of it is that you MUST use a GSM carrier to send SMS if you don't know what carrier to send to. This is because carriers know how to send the message to the appropriate cell phone.
You could send via email 5554441234#carrierdomain.com but the problem comes with the fact that you have to know which carrier the phone number points to.
Once upon a time you could tell the carrier by the second set of three digits xxxYYYxxxx (the y's), but you can no longer do this because of phone number portability.
In short, check out Kannel, but you'll still need to send via GSM (you can get PCI cards that hold SIM cards), or you can pay a subscription.