写入/读取特性的好方法

将数据分离成特征完全是一个应用基础问题，它是如何结构化的，而不需要数据存储/传输的紧凑性。
（注意：如果你想要两个功能的组合，你可以实现另一个特性，它可以从一个特性的读/写中独立地更新多个特性。例如炭。A，Char。B，写信给Char。C将更新两个Char。A和B）
为了确保可靠的数据传递和确认，请尝试可靠的写、写和指示用于向外围设备（“主设备”）发送数据的功能。（也有签名的写，但这是安全特性，不一定是握手特性）
通过使用可靠的写，您可以确认数据在握手之前可靠地传递，然后更新您所称的“句柄”。这将丢弃任何未通过握手应答确认的更改。
让我知道如果你需要更多的澄清或有更多的问题。



     以下为原文
  The separation of data into characteristics is entirely an application-base question on how structured you need it versus how compact you want the data stored/transmitted.
(Note: You can implement another characteristic that updates multiple characteristics separately from a single characteristic read/write if you want a combination of both functionalities. E.G. Char. A, Char. B, Writing to Char. C will update both Char. A and B)
 
For ensuring reliable data delivery and confirmation, try looking at the Reliable Write, Write, and Indicate functions for delivering data to and from the peripheral device ("main device"). (There is also a signed write, but that is a security feature, and not necessarily a handshake feature)
With using the reliable write, you can confirm the data was delivered reliably with a handshake response before updating the "handle" as you called it. This would discard any changes not confirmed with a handshake reply.
 
Let me know if you need more clarification or have more questions.

坦克为你解答！
这一点更清楚了，但我还是困惑。
对于数据的分离，我想知道什么是更有效的方法来定制特性（在定制服务中）。
因为我不明白为什么我应该使用20个特性（每个特征的1个参数集），如果我只能使用一个唯一的特性，并用页面字节切换数据集。
例如，1个独特的特性：0xP1 0xP2 0xSS0xSS0xSS00xSS。使用0xp1和0xp2页面选择器，剩下的参数/数据集
因此，使用该组织/结构，GATT表的大小可以减少到最小（但这真的重要吗？）
在未来，如果需要更多的特性，我可以使用一个新的服务UUID的第二个服务，并在里面添加新的东西，并且通过识别新的服务UUID来识别旧的外围设备和新的外围设备（新服务允许的新功能）。
在我所看到的所有例子中，大部分时间只有一小部分的值来传输。但对于我的应用来说，这有点不同，而且我必须确保从智能手机到终端设备的正确交付。
大多数时候，智能手机（中央）命令外围设备（非常小的数据和延迟必须是最小的）。
但是智能手机也用于配置，所以有时也会编写和读取大量信息（32或64位参数的大集合）。
为了保证数据传输，
有了可靠的写，我们可以知道数据被正确地传送到BLE，但是如果我必须重新检查“句柄”之后的UART传输（UART传输）是否仍然是必需的？但如果用这个解决方案的应用程序必须管理重试，如果错误的传输，然后我们不使用所有已经存在的东西。



     以下为原文
  Tanks for your answer !
 
It's a litte more clear, but i'm still confused
 
For the separation of  data, i wonder what is the more "efficient" way to procced in a custom characteristic (in a custom service).
Because i don't see why i should use like 20 characteritics ( 1 set of parameters per characteristics), if i can just use one unique characteristic and switch the set of data with a page byte.
So for example 1 unique characteristic like : 0xP1 0xP2 0xSS 0xSS 0xSS 0xSS. With 0xP1, and 0xP2 the page selector, and the rest the set of parameters/data
So with that  organization/structure the gatt table size could be reduce to the minimum (but does it really matter ?)
And in the futur if there is a need of more characterisics i could just use a second service with a new service UUID and add the new things inside, and recognize old peripheral and new peripheral ( with the new functionnilties allowed by the new service) by recognize the new service UUID.
 
In all the exemple i see, most of time there is just a little set of value to transmit. But for my application it is a bit different plus i have to be sure of the correct delivery from smartphone to the end device.
Most of the time the smartphone  (central) command the peripheral ( very small data and latency have to be minimum)
But the smartphone is used for configuration too,so sometimes write and read lots of information too (larges set of  32 or 64 bits parameters).
 
 
For ensuring the data delivery,
With reliable write we can know that data was transmitted correctly to the ble, but if i have to recheck the "handle" after the handcheck (of uart transmission) is it still necessary ? But the problem if with this solution app have to manage the retries if errors in ble transmissions and then we don't use all the already existent stuff..

别担心：
GATDB数据库自动存储和更新与远程设备通过BLE通信的数据；因此，如果您有一个值存储在数据库中，那么运行在外围设备上的应用程序不需要将数据库上的每个读取请求的值作为数据库。它存储和自动化回复。因此，如果您具有多个特性，则它简化了外围应用程序，以使请求的数据被自动发送/回复到中央设备。您所描述的分页方法将用于发送和接收数据，但对于需要处理接收到的数据并在外围固件代码中显式地响应（GATT数据库内置到BLE堆栈中，因此是一层），将略微有更多的等待时间。较少的延迟响应。
另外，如果在新版本上添加新服务，则可以直接为每个新的服务添加新的新服务；例如：版本1具有名称、编号和位置特性。然后，版本2添加了第二个数、第二个位置、位置和位置，两个位置。版本3然后添加LaSyNeNd、MIDILYNEX、EMAIL地址
等等，在每个方法实现的方式上没有很大的差别，因为它们都是相似的复杂性IO。然而，我认为这些特性被很好地定义了，所以它使得文档更容易在那里发生，以及正在发生的事情。
因为所有的特性都会被分解成不同的数据包，所以当你发送它们时，每一个数据都是一个低延迟的少量数据；对于设置交换来说，只有更多/更长的通信。（改变你与特征的交互方式不会改变这一点，我敢肯定）
如果您打算在编写该特性之后阅读该特性，那么您可能只需做一个没有验证的写响应，知道您将在阅读之后立即验证它。
或者，如果您只读取它来验证它，那么使用可靠的写允许您丢弃写入值失败的更改值，或者不为其中之一获得响应。（它将所有的写更改保持为临时的，直到您在最后确认它们，在那里完成所有值的更改）。您仍然需要处理在应用程序级别上写入数据的重试，唯一的区别是您是否在每次写入之后添加一个额外的读取，以及在中央设备上的应用程序代码中，您在哪里处理重试；我会看到写、读、重试是类似的。R写，确认/重试，以较少的开销可靠写（S）方法。



     以下为原文
  No worries:
 
The GATTDB database automatically stores and updates data that it communicates with the remote device over BLE; Thus, if you have a value that you store in the database, then the application running on the peripheral doesn't need to tell the database the value on every read request, as the database has it stores and automates the reply. Thus, if you have multiple characteristics, it simplifies the peripheral application to having data requested being automatically sent/replied to the central device. The paging method you describe would work for sending and receiving data, but would have slightly more latency for you needing to handle the data received and respond with the response explicitly in your peripheral firmware code (the GATT Database is built into the BLE stack, and thus is one layer less of latency from responses).
Plus, if you are adding new services on a new version, you can just directly add the new services with new names for each new one; For example: Version 1 has Name, Number, and Location characteristics. Version 2 then adds a Second_Number, Second_Location, Location_one_Times, Location_two_Times. Version 3 then adds Last_Name, Middle_Name, Email_Address
Etc. There isn't a large difference in how easy each method is to implement, as they are both similar complexity imo. I think the characteristics are nicely defined however, so it makes it easier for documentation on what is there, and what is going on.
 
Since all of the characteristics would be broken into different packets of data, then when you send them each one would be a small amount of data with low latency; There would just be more/longer communication for the setup exchanges. (Changing how you interact with the characteristics won't change this I'm pretty sure)
 
If you are planning on reading the characteristic after writing to it, then you might be able to just do a write response with no verification, knowing that you will verify it immediately afterwards when you read it.
Alternatively, if you are only reading it to verify it, then using the reliable write allows you to discard changed values if the writes fail to work, or don't get a response for one of them. (It holds all of the write changes as temporary until you confirm them at the end, where it finishes changing all the values). You are still going to need to handle the retry of writing the data at the application level, the only difference would be whether you add an extra read after each write, and where in the application code on the central device that you handle the retries; I would see write, read, retry being similar to write,confirm/retry with some less overhead on the reliable write(s) method.