Is there way on Android to obtain cost of SMS after sending it programmaticaly?
It would be really nice to know.
Thing is that for example my carrier always sends notification back with remaining credit, but I cannot rely on that every carrier does the same, and parsing it wouldn't be good idea anyway, as there are many different languages in world and text might be formatted differently depending on carrier.
Unfortunately there's no way to determine that as it's all handled on the network side.
There is impossible to determine pricing on subscriber site using standard android SDK API, price known only on operator's side inside its billing system. But, maybe your mobile operator provides an API for receiving bills and only then you it will be possible to define price you charged.
Also, if it is possible to check your balance using USSD or SMS, you may try requesting balance before sending SMS and after.
Related
I'm currently developing an android app for a weight scale I received that transmits data through bluetooth low energy.
I was looking at documentation and if I got the information correctly, there are specific UUIDs for data. I received a BLE scale with a Chinese protocol document found here: http://www.anj.fyi/protocol.pdf
I found and was able to get a functioning scanner working that lists the device name and the UUIDs it broadcasts.
Lets say I want just the weight data to show up in the UI, nothing else and nothing more.
I don't know what UUID they used for the weight data, and there are a lot of UUIDs. Probably 20+. I checked a UUID compilation and the usual weight data UUID does not show up.
How do I get the data from those UUIDs?
I'm thinking it might be the ones that are notifications, indications or read properties.
Looking at the UUID for example, f000ffc2.
How would I get data from that characteristic? Would anyone have an example code to grab the data from those UUIDs, or tutorials because I'm terribly lost right now.
I really appreciate it.
There are no weight information on the document you list http://www.anj.fyi/protocol.pdf, it is only shows the BLE module hardware interface spec, i.e. it does not specify the detailed service and characteristic.(I an a native Chinese speaker).
Regarding to the UUID you want to know which is the one to represent the weight, yes you are right it should be the read/notification feature without write permission. Can you use the apps e.g. lightblue on iOS to receive the notification(meanwhile change the value on your device) to test it? this will help you to understand which characteristic is the one you want.
I have a program that is charging a user's credit card. The card is charged via a 3rd party API. When I get a response from the 3rd party API, I update the internal representation of the user's balance. Once the user's balance is updated a receipt is sent to the user via email.
There is a small chance that some server error (e.g. unexpected power outage) could occur between charging a user's card and updating the internal representation of their balance. To protect against this, I've made the entire payment process idempotent so it can be retried without double charging the user but will definitely update the user's internal balance. The only issue is with sending the receipt. There is no way (that I can think of) to make this operation idempotent. Currently, I'm sending an email only of the balance update actually changes anything, but of course the server could fail between the balance update and sending the receipt, leading to a situation where the receipt will never be sent. How do people typically address this problem?
I've marked this question as language-agnostic because it seems to be a general problem with sending messages, but I'm using Java and AWS's Simple Email Service for this so it would be great to get answers using those technologies.
When we have done this before, We used a flag in the object that was set when the notification was sent so that the loop wouldnt send the email if the flag had been set for that transaction/id
I am creating a java application to receive messages on pc using jsms API. Whenever a user sends a particular message to a no, it receives it and adds to the database, the phone number and the area/ region where it belongs.
The region can either be the area where the phone number is registered, or it can also be the current location of the device. Either of these information will help me.
I would be really glad if any one could any one guide me on how to proceed with finding out the region using java code.
Note: I'm not looking for the country. I'm looking for the state/ region. Preferable Indian states.
You could try out libphonenumber. It basically defines the region based on the number.
There is a JavaScript try page here you could perform some tests.
I will construct a fictional app in order to construct my question.
I write a kind of treasure hunt app where the user gets a prize if they visit several locations around town. In effect the app would get their current lat/lon and check its proximity to the list of "treasure locations", if they are within 10 meters of any treasure location they get a notification.
The app will then do a http post to a remote script which basically inserts into a database. The post parameters will be uuid of device and the location they visited.
An attacker could easily watch wireshark and get the name of the script along with the parameters. They could go further, decompile the apk and get other things such as any hashing/obfuscation. They could then just use curl to post willynilly as they pleased and the game would be ruined for non-cheaters. This is a problem have never had to really address since in all the apps I have written there is always data which isnt sensitive and I dont mind it being exposed to the public.
What do I do?
The best think you could do is to send the data in a secure manner. Using HTTPS would be a much better choice, regardless of method. This effectively prevents eavesdroppers, it is the fundamental technology behind any secure communication on the internet.
Aside from the protocol to communicate with the server, there are still insecurities. Essentially, there are three methods that could work to overcome these.
The location of the player could be sent to the server at some periodic interval. The server responds back if they are close enough to one of the areas. Perhaps the server could include enough smarts to know that it takes time to get from point A to point B.
A single location could be sent at a time to the app. The track of the user could also be uploaded, to verify that the location is correct.
The locations could be sent through a one way function to the program. The real answer could be then sent to the server. The problem with this is that the exact location would need to be discovered in order for the same hash to result back. However, as GPS coordinates tend to only be accurate to a few meters, and don't tend to give insignificant digits, then multiple values could be tested near the current location. The one-way function would have to require some time to calculate in an effective manner, as otherwise it would be trivial for a bad guy to simply test every square meter in the city to figure out what would work.
The best method from a security standpoint would be the first, as at no time does the application know where it is supposed to go, until it reaches that location. Of course, this pings the server a large number of times needlessly.
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.