First I would like to thank you (Stuart in special) for this amazing framework MvvmCross.
I have an application case that involves socket connectivity, and I would like to go with PCL for Android, WP7 and iOs.
Unfortunately, the PCL subset doesn't support sockets usage as is (I think NCL is supported only for Microsoft different frameworks).
I thought may be MvvmCross Plugin is the way to go, but still needs plugin implementation for each platform (I mean ...plugin.Droid, ..plugin.WP7 etc..) while it should be the same code at the end.
What do yo suggest?
Thanks
I thought may be MvvmCross Plugin is the way to go
Yes, this is exactly the sort of situation that Plugins were designed for.
I'd certainly implement this as a socket plugin:
The PCL part of the plugin would provided a socket interface, although it might also perhaps include some shared base class 'buffer copy' type functionality in the shared code too.
The platform specific socket implementations which handle raw socket connection and IO.
It's likely that these platform plugin additions would use quite a lot of file linking between several of the platform implementations - I'd expect there to be a lot of code that would have to be shared this way.
I think a sockets plugin will be quite a common requirement - so if you were to tackle this via open source, then you might find some willing contributors ... or, if you were to go closed source, then you might find some customers.
While no-one has open-sourced an IP network socket implementation at this stage, the Sphero project did include a Bluetooth socket example - albeit one that wasn't entirely network efficient in the way it communicated.
This Bluetooth socket code is open sourced within Ms-PL at https://github.com/slodge/BallControl/tree/master/Cirrious.Sphero.WorkBench/Plugins/Sphero
This Sphero plugin doesn't expose a PCL Sphero-Socket level API - instead at the plugin level it chooses to expose a Sphero-Robot level API.
With the benefit of hindsight (a wonderful thing), if I implemented this again then I'd implement:
a bluetooth serial port plugin exposing bluetooth scanning, connecting and socket streaming
an additional PCL library which consumed the plugin to drive the robot - this perhaps might be called a plugin but would not have any non-PCL code within it.
Related
We want to write a custom Gatt Server Application for Bluez where we want to give some useful features. For example:
Start Gatt Server
Register/Unregister custom Service
Add/Remove custom Characteristics/Descriptor
Set/Get Value of Characteristics/Descriptor
Disconnect Client / Close Gatt Server etc.
Bluez don't have these features in command line tool but they have several APIs (functions) to do that, we need to call those internal functions.
In according to that we wrote an application in "bluez5.28/attrib/" directory from where we called several internal functions from files of
"bluez5.28/attrib/", "bluez5.28/profiles/" and "bluez5.28/src/" directories and tried to build it with bluez Makefile.
Since bluez have automated generated make file from automake it is quiet hard to make any change in that Makefile. But when we tried it showed lots of errors
regarding dependencies and libraries e.g. undefined references, no such files of directories, etc.
Is their any easier way to use bluez functions to make a GattServer Application ?
Thanks in advance for your valuable answers.....
bluez gatt dbus apis are now complete as of version 5.29. You may consider using those if going via the dbus rather than directly through library calls is acceptable for you.
correlate pg:1950 in bluetooth spec4.0 APPENDIX: EXAMPLE ATTRIBUTE SERVER
ATTRIBUTES with gatt-example.c in plugins in bluez5.28
I wanted to write a B/S project that client side uses ActiveX or Gecko to Communication with server via network socket. And any browser(ie/firefox/chrome/opera/safari) can use it.
If you want to support every major browser than you need to write both the ActiveX part (for IE) and the NPAPI part (for all other browsers). You can use support both technologies with one DLL though.
An easier way than implementing both yourself would be to use FireBreath, which does that for you and provides an abstraction layer over those APIs.
As you write native code with both technologies, sockets etc. can be used with both. The biggest limitations are with the UI side and permissions due to running code in a host application.
Note that XPCOM as a plugin technology is obsolete.
Is there an equivalent to Linux DBus on OSX? I mean, is there a "message bus" available by default on OSX?
Disclaimer: OSX newbie here.
If you need to use DBus you can install it via Homebrew.
Homebrew is a package manager for OS X providing a lot of libraries which where mostly written with Linux as their primary target.
The DBus package can be found here
However, this is not installed by default and if you intend to write Cocoa applications the way to go would be to use the (distributed) notification center as mipadi explained in his post (which you also accepted).
If you need a robust middleware for communication you can also have a look at IceTouch from ZeroC which is a Cocoa library for using the services and functionality offered by their Ice framework.
The package contains IceStorm for example which is a publish/subscribe server or the IceGrid service which can be used to build large scale distributed systems
Probably the closest analog would be distributed notifications (or notifications for same-process communication). It's not a perfect analog, but it fits into roughly the same niche. You can read more about it in Apple's Notification Programming Topics, particularly the part about the distributed notification center.
There's Mach's ports, which will probably do what you need: http://en.wikipedia.org/wiki/Mach_(kernel) .
You could check DarwinPorts. It should include the dBus libraries.
Is it possible to write a mobile application with J2ME and whenever we want to implement a functionality not offered by J2ME call native mobile API ? (kind of like what is done with .NET, whenever you need something not provided, you just call the Win32 API from the .NET platform).
While JNI is not officially supported in J2ME, the Symbian implementation of J2ME obviously uses something very similar.
Since most J2ME APIs have a corresponding Symbian OS C++ API, what Symbian did (a lot) is develop adaptation layers between the 2.
Between that and the new modular architecture of the IBM J9 virtual machine (from Series60 3rd edition feature pack 2 onward), it is technically possible to add a new API to the virtual machine without actually needing to recompile most of a handset firmware.
However, third party developers simply are not allowed to do it without a lot of help from the handset manufacturer.
A loopback socket connection is the solution that people have tipically implemented to transfer data accross the language barrier. Large-scale deployment is not the easiest task, though, as you technically need to install 2 applications on the device. Once you understand the threading model of the Symbian J2ME implementation, you also realize how ugly and inefficient a hack it is.
When you reach that kind of issue, it's time to learn Symbian OS C++ and do it right.
No. That's not possible with Java ME.
Only sort of. Actually it is possible but not directly. You can write a native server that listens on a local socket and send requests to it from your Java MIDlet. Someone even released a framework to do this called MIDP-JNI (as opposed to real JNI). Obviously the form of the solution imposes some limitations on what you can do with it but it isn't actually impossible.
Be aware that using this approach can make your application much more complex to debug.
If you are specifically looking out for Nokia/Symbian, then APIBridge http://wiki.forum.nokia.com/index.php/J2ME_API_Bridge_Interface could be a solution. Typically it is the 'official' version of 'native server on local socket' kind of thing. The APIBridge is 'extensible' & you can write your own 'plugins' for your suitable 'low-level' task.
I am planning to use SCTP for a embedded Linux project. Anybody has some comments on SCTP usage, mostly in one-to-many mode? Did it beat using a home-made UDP-based equivalent solution?
I control the network environement and all devices involved, so compatibility is not an issue.
I have made extensive use of lksctp and have found it to be robust and interoperable with many other implementations of sctp. The standard for the sockets API for SCTP is still evolving but is quite mature and I would expect any further changes to be backwards compatible.
I would use it with confidence.
The ACE library has a performance test for SCTP, so I would assume that it works.
Currently these programs provide the only example code on
how to use ACE's wrapper-facades for SCTP. In the future additional
code will be placed in the ACE_wrappers/examples/IPC_SAP/SOCK_SAP
directory.
Using a framework like ACE is a good idea anyway, as it alloes you to program on a higher level and shields you from the error prone low level details of socket programming. As an additional bonus your code will be portable to all platforms that ACE supports.
Best answer is the comment:
Also, SCTP support in Glibc is less than ideal (in other words, non-present) -- you must use the libraries from lksctp, and it's not entirely well-integrated into the normal sockets API. Just one more reason to use a nice library that encapsulates the low-level functionality :) – ephemient