Develop Reference

How is nrfConnect able to send more than 20 bytes from android app to raspberrypi?

I am trying to write a 120 byte data through ble to raspberrypi from my android app(I increased the MTU to the required limit). But all I am able to transfer is first 20 bytes. When I tried to search on the internet, I see that android limits the size to 20 byte for ble transfers and I will have to send multiple 20 byte packets.
But why I tried to end the same data from nrfConnect android app, I see that the data is being transferred without any issue. Can you help me understand how nrfConnect is able to do it with you writing it as packets?
Through the data is getting truncated, i am getting GATT_SUCCESS response from raspberrypi
Just as info, I am able to send 52 bytes to our custom board with nrf52 chip from the same app

Looks like android takes care of writing more than 20 bytes of data.
Below are the two cases that I had:
Case 1:
Android app trying to write data to custom program running in nrf52 chip.
Size of data : 50 bytes.
After increase the BLE MTU on the chip side, the write was successful without any changes from app side.(gatt.writeCharacteristic(characteristic))
Case 2:
Android app trying to write data to ble program running in raspberrypi 3
Size of data 120 bytes.
Issue:Even after increasing the BLE MTU in raspberry pi, when trying to write the data only 20 bytes are received, with successful write response.
Solution: After using gatt.requestMtu(120) and calling the write character in onMtuChanged() callback, was able to send the entire data.

Data used in WhatsApp

If I am sending a text message of 100 letters/digits over WhatsApp then how can I measure the size of the text message in mb and what is its connection with the MB required for sending that message.
Similarly if I am sending an image of size x mb then how much of data will be used for it?

you can use 3G watchdog Here . To monitoring data usages, after send message just back to 3G watchdog app and see how many data are used

how much size of data can be send in tidtcpclient in delphi xe7

I'm using Delphi XE7 for developing mobile application. And I'm using TIdtcpClient component to interact with the Server application. And I need to know for Android mobile & iOs mobile app, what is maximum size of data which I can send at a time to server. Or it depends on the speed of the internet. Please help me in this

TCP sockets are data streams, the length of the transmitted data is unlimited. For data with fixed length, client and server have to know when the stream ends, either by sending length information first before sending the actual data, or by using a end-of-data symbol / terminator sequence. You can also send an 'endless' stream, for example live audio / video data, which continues until one side disconnects.

There is no theoretical size limit to data that you can sent. Limitations are because of system resources/processing power, bandwidth availability and of course time that it takes to send.
System resources in the case of mobile devices will be memory, cpu power and data availability (cost per data) as it will most probably be for other platforms as well. Another resource that influences performance is the developer; the worst he writes the app the worst it will perform.
Bandwidth availability will determine how fast that chunk of data can be sent which directly influences the time it takes. Who wants to wait forever, right?
One more thing that is important, is the recipient. How patient the recipient is and how much resources he has also influences how much data you can send him.
So if you have plenty of time and resources then you will be able to send large amounts of data.
The Indy suite which TidTCPClient is part of, uses TidBytes as a memory data container into which an array of bytes is stored (the bytes that make up your data). Those TidBytes arrays are used to hold the data that you send or the data that you receive. They are handed to TidTCPClient when sending or receiving. The size of TidBytes arrays are once again limited by resources of the sender/receiver. If that causes an issue then you can break the data into smaller chunks then send them one-after-the-other. As long as you indicate to the recipient how big each chunk is, as mentioned by mjm and in the case of segmented sends you must also indicate which segment goes where in the complete data stream. A way of indicating to the recipient is to prefix the size of the data as either a byte, word or integer to the start of the entire package that you will send and as long as the server knows to either read the first byte, word or integer he will know how much data will follow that indicator and thus know how much data to expect as actual usable data.
Seeing that you might not know how much resources the recipient has it is wise to always break large amounts of data up into smaller chunks. This unfortunately is something that you will have to test to figure out how large. Also keep in mind the technology that will be used to send it across. For example Ethernet has certain packet sizes and if data is broken up into too small sizes it might cause too much overhead. The trick is to try and find the balance. Do not worry about that too much but do read up on it.

What is the Maximum packet size to send data over bluetooth in Android?

I'm working on an Android Bluetooth project to send and receive data from a custom made hardware. I used Bluetooth Chat Sample in SDK as basis.
I am sending data from one device to another (LG Nexus 4). All is ok until I reach a length of 1004 bytes (it is the audio data). At that point it splits it into 2 messages of 990 and 14 bytes in most of cases. but is strange sometimes its sending 1004 without splitting (approx. 4 times in 100).
I am sending this packet of 1004 bytes, in which there is 4 bytes is my header and rest of 1000 bytes is actual data which I want to use as per command in header, now if packets are splitting as per above mentioned way than I cannot handle the flow.
So, please let me know why packets are splitting in such way and how can I stop this splitting or, if I cannot do this, than please suggest me any alternative way to do this.
Thanks.

Data sent via Bluetooth socket is abstracted as a stream. Here the transport layer is broken into packets, where packet has a maximum size of almost 1KB(1000 bytes). So you can devise a mechanism in which you can send the message length info in the header, then on receiving side you will have to make subsequent read() calls; each returning data for one packet.

Sending long sms messages

I've got an app that lets users send sms messages. Works great when the message < 160 characters. After that, things work less-perfectly. Seems like there are a few options here:
Manually break the message up into multiple SMSs, send each part as a separate SMS.
Use the multi-part send SMS function (sendMultipartTextMessage()).
Send the message as an MMS message (sendDataMessage()?).
Here's my novice take on it:
1)
most well supported across carriers. Users may get mad that you just cost them N separate messages though, instead of converting to MMS or something.
2)
not sure if this is supported by different carriers, and read that once the message is greater than 3 * 160 chars in length, gets converted to MMS anyway by different SMS apps - maybe stay away from this altogether.
3)
not sure how to do this, and older phones might not support MMS. To send an MMS using the android SDK, do we just use the SmsManager.sendDataMessage() method?
Thanks

This is quite an old post but it's high up on Google when searching for Android multipart sms, so maybe it helps someone.
Regarding part 1 and 2, it's pretty much the same thing. To use sendMultipartTextMessage, you need to break up the long message into an ArrayList of Strings. It then sends as many SMS as needed. In short:
SmsManager sms = SmsManager.getDefault();
ArrayList<String> parts = sms.divideMessage(longMessage);
sms.sendMultipartTextMessage(phoneNumber, null, parts, null, null);
Part 3: MMS is not an option, as it has been pointed out. The charges and all.

seems to me that the first option is what most mobile phones do by default. sms messages by design can only send a certain amount of characters (160 probbaly), just inform the user that the message is too big and if he still wants to send it anyway (informing also how many sms would the total be).
as for MMS and multipart as you said not every carrier supports it, so they dont seem to be the best option.
EDIT: as for how does MMS work on android-sdk check this thread out: Android SDK MMS

I would suggest the usage of option 2 when you are working on Androids GSM based handsets.
GSM based Mobile device takes care of segmentation in which breaking the messages to multiparts for sending in performed and also assembling of the multipart messages in to one message on receipt.
If you have a method which takes care of sending text messages, than by default use the options of manager.divideMessage as it will work even if the message segments required are only 1 in number.
I dont think you should have any problem sending messages using option 2 and it will also ensure that the receiver receives the message as a single message.
Else we need to write your our own protocol stack where in you write reference number and number of messages for the receipient to understand and recreate the complete message; which is not very tough. We can use byte arrays with headers and the messages can be sent as base64 encoded.
Also I dont know much about the limits the carriers enforce on the number of segments in multipart message; based on my test I was able to send and receive 160*8 segments properly. Based on the GSM standards the segments can be upto 255 but that count might depend on the service provider implementation.