I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "
Related
Chromecast v2 devices announce their presence using mDNS, and they are discoverable when performing mDNS queries for _googlecast._tcp.
DNS-SD / Bonjour also support the concept of "wide-area discovery", which makes use of standard unicast DNS queries to find devices. This can be useful for more complex networking scenarios - i.e your Chromecast devices may be in one VLAN but your sender devices are in another.
However, when trawling Chromium source I found this code in mdns_api.cc which seems to indicate that the Chrome extension will only search for _googlecast._tcp.local - completely preventing wide-area DNS discovery of other Chromecast devices. Based on anecdotal testing, it seems the Chromecast iOS app and SDK also have this behaviour.
Why does the official discovery mechanism for the Chromecast Chrome extension explicitly only discover link-local Chromecast devices?
They probably didn't do "wide-area discovery" because there are a lot of gotchas in implementing it and there isn't much gain to be had.
Let's suppose that they did implement it (from looking at the spec, it doesn't seem to be technically difficult; seems like it is mostly an edge-case problem).
You'd need:
A domain under your control. Could be a local-only domain.
Not many people do this.
Multiple VLANs that you want to use.
Most homes only have a single VLAN.
A DNS-SD server that supports Wide-Area Discovery.
This is probably the easiest thing to have. Even then, most people wouldn't do it.
A UX flow to input the various WAD servers that you want to ping for devices.
This is the hard part for Google since it needs to be consistent across all SDKs and using a WAD-discovered Chromecast would cause all local-media-server Apps to not work (e.g. Plex).
(1) - (3) are why Google wouldn't make this a priority. Chromecast is, after all, a consumer device and consumers tend to have simple networking situations. (4) is why it isn't low-hanging fruit.
You'd also need to solve a few problems:
What happens when you are connected to a Chromecast on a separate VLAN and then remove it's WAD server?
What if the WAD server goes offline?
What happens when you have multiple Chromecasts with the same name?
What if they also have the same IP address (possible since VLANs can have overlapping IP spaces)?
What happens when a Chromecast is discoverable using WAD but not reachable?
Should they attempt a connection to every single Chromecast you discover to test that it is reachable?
How would you scale this out to work with 100s of Chromecasts in VLANs that could be "far" away?
It is these problems that I think would prevent Google from implementing WAD even if they wanted to.
I have a RaspberryPi connected to my home network via WiFi with a dynamic ip address. I then have my iPhone connected to the same network also via WiFi. The Pi has a lightweight c++ HTTP server running on it that can execute commands. I now want to write an Objective-C app that can find the Pi on the network, regardless of it's ip address, and send it commands. So, Universal Plug and Play seems like the logical solution - but everything I find on Google is dealing with Media players and streaming audio/video content.
I just want the Pi to somehow simply broadcast on my network - "Hey, I'm RasberryPi and my IP Address is 192.168.0.5!".
Can somebody please suggest a package or solution to this problem? Thanks!
For the RPi side I would suggest GUPnP as long as you can fulfill the dependency requirements. It's a very modular framework so you don't need to load or use any of the multimedia related things if you don't need them. It's based on glib and libsoup and allows you to fairly easily define and implement your own UPnP services. Take a look at the BinaryLight example: It implements a BinaryLight Device that contains a SwitchPower service with several methods and two state variables (properties). You should be able to hit the ground running if you start with that. There's documentation on how to write a server.
The components you are going to need/want:
libgssdp, handles discovery, used by gupnp
libgupnp, the actual upnp implementation, used by your app
the dependencies (glib, gio, gmodule, libsoup, libxml)
Also possibly for testing (this on a desktop linux machine since it requires gtk):
gupnp-tools, contains gupnp-universal-cp
EDIT: If you really don't want to implement any UPnP functionality, it's possible you could just use GSSDP for the IP discovery. This could be very simple: see test-publish example.
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?
I need to connect to a Bluetooth device through virtual COM port created in Windows. It's easy when the port has been already created during manual pairing procedure. But I would like my application to relieve an user from the manual pairing of a device. I would like to present all devices in the range, allow user to chose one, and then create virtual COM port connected with the selected device. I'm not trying to avoid the pairing procedure itself, but rather I would like to invoke it by my application.
I started getting familiar with Microsoft Bluetooth API. And then some doubts arose. I've been wondering what happen if some user would use different (than Microsoft's) Bluetooth stack? Is the Microsoft's API the real Bluetooth API, which have to be implemented by any other Bluetooth stack provider? Or rather each provider has its own API, and the Microsoft's is only one of many other?
Thanks everyone for valuable input. I'd like to summarize what I've found so far. The Microsoft Bluetooth API is not operating system API. Application written against it will not cooperate correctly with any other Bluetooth stack. It seems that applications which are intended to cooperate with multiple stacks need to provide some stack abstraction layer, and stack specific code for all of them.The other solution is to allow user for manual pairing of the Bluetooth device, which eventually create some virtual device in the operating system (e.g., COM port). Then the application can use standard interface of such a device.
I can't speak for the Microsoft Bluetooth API, but there are multiple Bluetooth stacks available for the PC platform (even more for mobile devices).
The underlying API is defined by the Bluetooth Core Spec and so all stacks should be able to interact, in fact it is mandatory that they interop or they cannot use the Bluetooth name and logo.
As to pairing, your going to have a hard time getting devices to pair if they have default security, which requires a pin code.
Things might be simpler in the (near) future, as the Bluetooth standard has introduced a new security model, secure simple pairing, which has a 'just works' mode that requires no Pin code. This is still stronger then the current security, except against Man in the middle attacks. However, it could be a while before you see the chips with this feature in PCs.
If you can change to using .NET :-/ I can recommend our library 32feet.NET.
For explicit pairing there's BluetoothSecurity.PairDevice. We can also create the virtual port for you, for example:
BluetoothClient cli = new BluetoothClient();
BluetoothDeviceInfo[] list = cli.DiscoverDevices();
BluetoothDeviceInfo selected = GetUserToSelectOne(list);
BluetoothSecurity.PairDevice(selected, pin);
// Ask Win32 to create a virtual serial port
selected.SetServiceState(BluetoothService.SerialPort);
However I really don't like virtual serial ports so I always suggest that people use a normal sockets connection using our BluetoothClient class, it will automatically handle a pairing request if required.
On Win32 we support the stacks from Microsoft, Widcomm/Broadcom, and BlueSoleil. On Widcomm there's no support for SetServiceState there yet, and their API has no support for responding to pairing requests. BlueSoleil should support both.
A brief user's guide is at 32feet.NET — User’s Guide, and all the class documentation is available at the main site http://32feet.net, the Widcomm documentation is only in our code repository at the moment.
Midlet using HttpConnection to connect a webservice application.
A mobile can use a wireless broadband to connect to internet or can use internet facility provided by the network provider i.e. Vodafone or Virgin which is I think known as GPRS. Correct me if my understanding is wrong.
Now my question is when the midlet will run which connectivity it will use? Secondly do I need to code differently for midlet to use GPRS or it doesn't matter?
I deployed my application on Nokia E65 and it asked me which connection to use. The mobile had both wireless lan and provider GPRS active.
On IPhone the preference is for wireless lan. (Not related to J2me)
There is no standard Access Point Selection APi in J2ME.
That means the MIDlet itself can't decide whether to use Wi-Fi or GPRS.
Some phones will allow the user to change application settings in order to force a MIDlet to use a specific network when it is available (and maybe prompt the user for an alternative when the preferred network is not available).
This is mostly because there is no standard way to describe a wireless network that contains enough information : QoS, cost per byte downloaded and uploaded, average bitrate, ping time...
In most cases, the logic to automatically choose a network without those information would be too complicated and not reliable enough.
Manual Access Point selection is the only way to put the user in charge of the cost of data transfer, so far.
It depends on the client mobile phone. On some models, there is only one GPRS configuration that is used by all applications including midlets, On some others the configuration used for browsing can be different than the one used by midlets.