I want to implement cloneable interface but I am unable to. I am using J2me, it gives me error
create interface Cloneable in your package. As far as I know J2me allows to implement Cloneable interface as it is a part of jdk1 1.0. Kindly help me
I don't see Cloneable here or here. Which JavaME API are you using?
Related
I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.
Can anyone give a list of Instructions on how to implement Bonding/Pairing in BLENO? I have created a list of ble profiles but don't know what to code or do in order to implement pairing.
Bleno doesn't really support proper bonding. Use BlueZ instead.
I want to use a bluetoothmodul like this Waveshare Core51822 to send data to a raspberry. I want to use the SPI on the bluetooth modul but i dont have a plan how to configure that.
What do i need?
Thanks
The SPI and BLE are all documented extensively at http://infocenter.nordicsemi.com/, including examples, specifications, and an API.
In the future, you should give much more information about your situation. For instance, what platform/IDE are you using to develop? If your module is compatible, you would probably be best off using ARM's mbed compiler (https://os.mbed.com).
I have a couple questions:
In general, what is the general difference between the OpenNETCF.Net namespace and the OpenNETCF.Net.NetworkInformation namespace in the Smart Device Framework? There seems to be a lot of functionality overlap between the two. Is the OpenNETCF.Net namespace now deprecated in favor of the NetworkInformation namespace?
More specifically, I have a device with a wireless adapter. My goal is to be able to query nearby access points and then connect to them through my own user interface.
OpenNETCF.Net.Networking.GetAdapters()[1] gives me my adapter object representing the wireless adapter. Even though this is a wireless adapter, IsWireless and IsWirelessZeroConfigCompatible both return false. However, NearbyAccessPoints DOES return a list of nearby access points as you would expect a wireless adapter to do.
I need a way to add one of the discovered access points to the PreferredAccessPoints collection. I have not found a method to accomplish this within the OpenNETCF.Net namespace. The only way I've found to add an AccessPoint is through the AddPreferredNetwork() method of the OpenNETCF.Net.NetworkInformation.WirelessZeroConfigNetworkInterface class. The problem I'm having is that I've been unable to find a way to obtain a WirelessZeroConfigNetworkInterface object. The object returned by the NetworkInterface.GetAllNetworkInterfaces() method is just a plain old NetWorkInterface object, not a WirelessZeroConfigNetworkInterface object as I hoped. I'm sure this is probably related to the issue with IsWireless returning false in the NetworkAdapter object.
Is there a way to construct the WirelessZeroConfigNetworkInterface object even though the framework seems to think it is not wireless? It looks like the functionality is there as demostrated by the Wireless related methods of the NetworkAdapter object.
The history is a bit confusing, yes. Basically SDF 2.2 (or earlier, I don't recall any more) had everything in the OpenNETCF.Net namespace. When I was adding features in 2.3, I added a boatload of stuff in the OpenNETCF.Net.NetworkInformation namespace that paralleled the full framework. Some of that had functional overlap with things we had done in the wireless stuff, so I made the decision to move everything over to the OpenNETCF.Net.NetworkInformation namespace. I left the originals and marked them as deprecated to try to be friendly to existing deployments. The items you should use are the ones in the OpenNETCF.Net.NetworkInformation namespace.
Now on to how the stuff functions. First we query NDIS for all network interfaces. This gives us wired, RNDIS, wireless, etc - basically everything that the network stack knows about. NDIS, however, doesn't know much about "wireless" stuff - it does know some though.
Once we have our list of known adapters, we then ask NDIS if it's a wireless device - it can at least tell us that becasue the driver tells NDIS at registration.
Once we have a list of wireless adapters, we then walk them and ask the WZC subsystem if it knows about the adapter. WZC is an interface that knows everything about the wireless devices, allowing us to intereact with it through a common, published interface. If WZC does know about it (meaning the driver reported itself at initialization to WZC) then we create a WirelessZeroConfigNetworkInterface for it. If it isn't known by WZC, then we know it's wireless (NDIS told us it was), but we only have the NDIS methods for interacting with it.
NDIS doesn't give us a way to associate. It does give us a way to ask for nearby SSIDs. The Adapter interface you have, then, exposes the capabilities we know of.
In some cases the driver has a proprietary API to manipulate the WiFi settings (e.g. old Cisco cards).
What version of the OS is this you're running on? What WiFi chipset/adapter are you using?
Is there any reliable way to support back-light in J2ME on multitude of models, other then pre-processing?
Is there any library available that may handle the back-light for various phones out there?
Regards.
This is not a direct control as in Nokia UI API, but there is a method in MIDP that controls backlight, it is Display.flashBacklight(int duration). Unfortunately, phones are not obliged to obey this method. But this method is at least part of MIDP, not some proprietary API.
Native backlight management on phones ranges from the completely natural to the obviously insane.
It's also nowhere in the MIDP specifications.
The Nokia UI API allows to work around some issues and is actually present on non-Nokia phones.