Closed Bug 792823 Opened 7 years ago Closed 7 years ago

[b2g-bluetooth] BluetoothOppManager prototype

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: echou, Assigned: echou)

References

Details

(Whiteboard: [LOE:S])

Attachments

(2 files, 5 obsolete files)

We need a basic implementation of BluetoothOppManager, including registering OPP service.
Assignee: nobody → echou
Blocks: 792683
blocking-basecamp: --- → ?
Whiteboard: [LOE:S]
Attachment #663000 - Flags: review?(kyle)
Attachment #663000 - Flags: review?(kyle) → review+
Assuming this is the end of our service additions for v1, we might want to remove the unused constants for the time being, just to clean up the warnings.
Attachment #663000 - Attachment is obsolete: true
Please note that SendFile, StopSendingFile and ReceiveSocketData will be implemented in another issue because they are all related to OBEX protocol.
Attachment #663370 - Flags: review?(kyle)
blocking-basecamp: ? → +
Comment on attachment 663370 [details] [diff] [review]
patch 2: v1: BluetoothOppManager interface and prototype

Review of attachment 663370 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bluetooth/BluetoothOppManager.cpp
@@ +11,5 @@
> +#include "BluetoothServiceUuid.h"
> +
> +USING_BLUETOOTH_NAMESPACE
> +
> +static BluetoothOppManager* sInstance = nullptr;

Make this a RefPtr. Since it's inheriting UnixSocketConsumer it'll get RefCounted from there, and bad, afternoon eating things will happen if we don't do this. (Also: Change HfpManager to refcounted)

@@ +74,5 @@
> +  }
> +
> +  nsRefPtr<BluetoothReplyRunnable> runnable = aRunnable;
> +
> +  nsresult rv = bs->CloseSocket(this, runnable);

Using the new socket stuff, we can just call close on ourselves. No need to pull a service.

::: dom/bluetooth/BluetoothOppManager.h
@@ +35,5 @@
> +   * process. At the end, the application will get a system message
> +   * indicating that te process is complete, then it can either call
> +   * Disconnect() to close RFCOMM connection or start another file-sending
> +   * thread via calling SendFile() again.
> +   */

Since we're explaining things there, might want to add something about sending progress as a system message too?
Attachment #663370 - Flags: review?(kyle)
Depends on: 794469
Blocks: 794469
No longer depends on: 794469
* Added more comments 
* Passed a BlobParent* variable in SendFile()
* Disconnect => void Disconnect()
Attachment #663370 - Attachment is obsolete: true
Attachment #665453 - Flags: review?(kyle)
Comment on attachment 665453 [details] [diff] [review]
patch 2: v2: BluetoothOppManager interface and prototype

Review of attachment 665453 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bluetooth/BluetoothOppManager.cpp
@@ +15,5 @@
> +
> +USING_BLUETOOTH_NAMESPACE
> +using namespace mozilla::ipc;
> +
> +static nsRefPtr<BluetoothOppManager> sInstance = nullptr;

Just a RefPtr, actually, not an nsRefPtr. We aren't an XPCOM object... yet. :)
Attachment #665453 - Flags: review?(kyle) → review+
Nit fixed. Used nsAutoPtr instead of nsRefPtr to hold sInstance.
Attachment #665453 - Attachment is obsolete: true
Replace nsRefPtr with RefPtr
Attachment #665798 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/9946c7e4dd92
https://hg.mozilla.org/mozilla-central/rev/5ce162e8bb47
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.