<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>A better way to handle the completion of a long write?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/4550/a-better-way-to-handle-the-completion-of-a-long-write</link><description>I have a 384 byte, writable, variable length, vloc user characteristic and I want to trigger an event when the write completes so my application can operate on the data. 
 Right now I get the BLE_GATTS_EVT_WRITE event, check for op == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 24 Nov 2014 11:43:27 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/4550/a-better-way-to-handle-the-completion-of-a-long-write" /><item><title>RE: A better way to handle the completion of a long write?</title><link>https://devzone.nordicsemi.com/thread/16143?ContentTypeID=1</link><pubDate>Mon, 24 Nov 2014 11:43:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4f86e8fd-daa8-4f95-be54-b742ff0183e4</guid><dc:creator>Matt Sieren</dc:creator><description>&lt;p&gt;I agree. I just ran into a similar problem trying to develop a device for iOS/OSX MIDI protocol and cannot proceed as they rely on fragmentation / reassembly and larger MTUs for larger data packets.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: A better way to handle the completion of a long write?</title><link>https://devzone.nordicsemi.com/thread/16142?ContentTypeID=1</link><pubDate>Mon, 24 Nov 2014 09:35:25 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d97039f2-d942-47e9-bf27-2fe3d199adf2</guid><dc:creator>Clem Taylor</dc:creator><description>&lt;p&gt;I&amp;#39;m looking forward to support for larger MTUs and fragmentation/assembly, should make life easier for the user and improve the performance of things like long writes.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: A better way to handle the completion of a long write?</title><link>https://devzone.nordicsemi.com/thread/16141?ContentTypeID=1</link><pubDate>Mon, 24 Nov 2014 09:15:38 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ac587bdf-d71e-4f80-8306-2887617467e4</guid><dc:creator>Carles</dc:creator><description>&lt;p&gt;Hi there,&lt;/p&gt;
&lt;p&gt;First of all thanks for your feedback, it&amp;#39;s great to get suggestions for improvement from SoftDevice users.&lt;/p&gt;
&lt;p&gt;The problem is that the SoftDevice doesn&amp;#39;t have a special mechanism to deal with Write Long Values (Prepare Write + Execute Write on a single handle) when compared to Reliable Writes (Prepare Write + Execute Write on multiple handles). This is because we chose to approach the user awareness of changes based on incoming over the air packets, and not based on changes on particular characteristic values. There were several reasons for this: one is to allow some apps to restrict particular operations, and another to be able to implement a reliable and safe deferral model via authorisation.
But for some applications this raises the question on whether it is actually useful to know which operation was used to modify the value, when all the user wants is to be informed that it has changed. A subscriber model could make sense, where the application simply gets a &amp;quot;value changed&amp;quot; event at the end.&lt;/p&gt;
&lt;p&gt;We will take for feedback into account for future versions, but for now the only solution is the one you already describe in your post.&lt;/p&gt;
&lt;p&gt;Also in the future long MTUs will make it possible to avoid the complicated Write Long procedures by simply sending larger packets in one go with all the data in them.&lt;/p&gt;
&lt;p&gt;Thank you again, keep this feedback coming!&lt;/p&gt;
&lt;p&gt;Carles&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>