I was always wonder what would it be my first question on StackOverflow since everything I'm looking for is already asked. (Find only one similar here Bluetooth data transfer between two countries )
BACKGROUND STORY:
From when it comes I’m a fan of Nokia N-GAGE. It’s a Nokia’s phone from 2003 with dedicated games. In its heyday 2003-2007, it has single-player, multi-player via Bluetooth and using a dedicated internet service N-GAGE ARENA for compete with people all over world.
N-GAGE ARENA servers were disabled about 2008 and as far i understand It isn't even worth trying to resurrect such a infrastructure. Mainly because it requires modifying the code of each game and that's illegal.
Multiplayer mode using Bluetooth work fine, but requires opponent 5m away max.
Nokia sold 1mln copy of this phone, and still are people all over world collecting n-gage games. I have a dream, I want to reactivate the possibility of playing multiplayer with people from all over the world.
PROBLEM DESCRIPTION:
I want to use the Bluetooth multiplayer mode by extending the usual N-GAGE to N-GAGE Bluetooth connection with an additional 3 elements. Two N-GAGEs, instead of connecting directly to each other as host-join, connect via a PC / smartphone applications that communicates with the server that transmits full data sent from the game of one user to game of the opponent.
I admit that I do not have full knowledge of technical limitations. In my opinion, as a software engineer, it is theoretically possible, but I want to consult you, people more familiar with the subject. Maybe someone is working on a similar project and can comment.
WHAT DO I KNOW:
The application would have to transmit all data from the Bluetooth connection so as not to disturb the illusion of a direct connection between N-GAGEs.
The application must enable the selection of an opponent on the basis of the game. The choice itself could be made on the basis of some kind of chat in which users first define what they are playing, who’s the host, and then the connection is made.
WHAT DO I WANT TO KNOW:
Does what I describe is even possible?
Is such capturing Bluetooth connection and forwarding is even possible?
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
I WOULD BE GREATFUL FOR:
Any technical tips, literature that can help me to understand my limitations.
Any constructive criticism. Of course before I start doing such a project I have to confirm that isn't a utopia. For me It’s a side project, I’m able to spend years on it, but don’t want to get to dead end after all effort.
Does what I describe is even possible?
Yes, yes it does. Your hardest part will be setting up a tranceiver to interpret the I/O. Your failure point would be super-encrypted messages and making transmission difficult...
If it's clear I/O you can signal this through any server and output it back to the tranciever to output. Confusing but possible just not sure of the design or how bluetooth sends its data.
Is such capturing Bluetooth connection and forwarding is even possible?
If a connection is possible then forwarding it is too. Considering this piping the transports.
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
Bluetooth real-time no... with added network latency, you're looking at anything from 1-200ms~. you may be able to improve it?
Overall I think if you can:
Connect the device to PC, and have PC talk back to device through blue-tooth
Read the data that goes in and out
Encryption proves little or none at all to be able to signal the data properly, tricky to explain you'll know though if there's a wall.
All should be possible it doesn't overly go against the grains but do more homework this is very valid.
I want to make a simple multiplayer game with Game Maker Studio 2 for mobile platforms, but it should work locally (via wi-fi or bluetooth).
For e.g. this is a list of existing games and my game will be classified as (Bluetooth | WIFI Direct | Online).
I have some experience in programming and GML should not be a problem for me.
But I want to know for sure whether it is possible to implement Wi-Fi Direct and bluetooth communication?
Required answer those who have already done it. Any plug-ins required for this?
I do not want to reinvent the wheel and modify some libraries or broken code. I just need a 100% working solution.
Why Game Maker Studio 2? Because I want to make a game with my friend who doesn't have any programming skills. So, we need some game editor like Game Maker Studio 2 despite the fact that I have programming experience. And now my task - is to solve the problem with local multiplayer before we start to make a game. Maybe there are other editors that fit these requirements?
Gamemaker has some built-in functions to make a local multiplayer (I assume it is what you mean by "WiFi"). if you are familiar with UDP/TCP, it's a plus. They can be found here :
https://docs.yoyogames.com/source/dadiospice/002_reference/networking/index.html
I personally used them for a local multiplayer and it worked fine.
For the bluetooth, the devs are working on some functions, but I believe they didn't release them yet.
If you want to make a global multiplayer, you have to face a few tehnical issues (port forwarding, global matchmaking, etc.) I recommand GMnet, that comes in two flavors :
GMnet Punch if you simply want to communicate through a NAT with your own synchronisation strategy.
GMnet Engine if you don't want to worry about the details and let them do all the work for you.
The official website : https://gmnet-engine.org/engine/
Keep im mind that for a global matchmaking, you will probably need some kind of relay server, so that players can find the games hosted by other players. It is not that hard and GMnet comes with a java server program for this purpose, but it needs to be hosted on a server with direct internet access (no NAT).
Hope it was helpful !
I'm currently thinking of developing chess code with multi-player facility connected and played via bluetooth. For that I need to chalk out the phases, i mean systematic modules, that I should follow to develop the game. If anyone can state it or have any link that can help it out, it would be great.
Another thing I am developing this in J2ME, so can anyone give me an idea about the way to connect the game in two mobile devices through bluetooth in J2ME. I mean to say the class or file that is used to connect the gaming devices.
For the second part of your question: you need to make an SPP (serial) connection between the two devices, with one acting as a client and the other as a server; see this tutorial for more information.
Then you need to create your own protocol to allow the two devices to communicate everything they need to.
This will only work on handsets with JSR 82.
I am writing a windows application (written entirely in C++) which reads files from a storage card on a mobile phone running Windows Mobile. The tough part is, I don't know how to make my application detect the event that a user has connected the mobile phone to the USB of laptop. I did some reading on MSDN and have written a small code using RegisterDeviceNotification, which detects whenever a USB disk is attached/removed from the laptop. However, I am unable to tweak this to make it work for phone type devices. Please help me out through any links/tutroials which explains this(preferrably C++, as I don't know .NET or C#).
Thanks
Alok
According to this article you can use RegisterDeviceNotification to get notifications when activesync detects a device has been plugged/unplugged. (See option 3 at the end of the article)
It may just be a matter of setting up the correct notification filter.
Windows Mobile devices use RNDIS, a network interface protocol behind the scenes. Hence, the RegisterDeviceNotification method still works, but you're looking for a DEV_BROADCAST_DEVICEINTERFACE, not DEV_BROADCAST_VOLUME. (i.e. dbch_devicetype==DBT_DEVTYP_DEVICEINTERFACE)
You can use RAPI or RAPI2 to detect when a Windows Mobile device connects to a PC via Active Sync or Windows Mobile Device Center. RAPI can also be used to read the files on the storage card and much more.
RAPI is simpler to program because it is a C based API. RAPI2 has more functionality than RAPI, but is an object oriented COM API. If your needs are simple and you only care about one device/connection at a time then RAPI is good enough. There are two RAPI functions used to detect connections: CeRapiInit (blocking), and CeRapiInitEx (signals an event upon connection).
Recently I started developing a J2ME app prototype. I noticed how difficult it is to develop a good looking UI. Consider developing an app in J2ME for booking flights interacting with webservice.
A website to book flights will be easy to develop with nice ui and can be accessed by browser on a handset. I understand not all handsets have browser but all the new and upcoming ones have browser and have big screen as well.
Is it a good idea to develop such a application in j2me which need to talk to webservice for it to work? Or j2me is only suitable for standalone apps?
Advantages of J2ME:
Can access phone resources, like file system, phone book and GPS. The last is very important in map applications.
You can build richer User Interfaces. It may be difficult as you say, but there are many GUI libraries that could assist you. On the contrary the UI for a mobile browser (you can't rely on CSS and javascript working) would be very poor.
Greater flexibility on the communication logic. You can encrypt/decrypt data, compress them, use SOAP web services. With the browser, your best bet would be to develop REST services.
Disadvantages of J2ME:
Midlets need to be signed. This has some cost and there are situations that even a signed app won't run properly in specific phones.
Developing a midlet to run in all types of phones is a nightmare. On the contrary, a well designed mobile web application would be displayed properly in all recent phones.
You need to have a channel for distributing your application. People would need to download it and get charged for the required bandwidth. You would need to care for angry customers having problems with the application. Things are easier with a web site.
J2ME apps are inevitably compared with native applications (iPhone, Windows Mobile, Symbian). Compared to these, they are very poor and many would find that paying for them or even using them isn't justified.
My conclusion: Nowadays real smart phones are becoming more popular and win an ever growing market share. Under these circumstances, the advantages of J2ME can't really overcome its restrictions. The only exception I could think of, is if to have to develop a GPS application. For all other cases, a mobile web site is a better idea.
There are a lot of misunderstanding and plain wrong statements in the previous answers.
I advice you to just do your research yourself. Nowadays you CAN develop really good looking apps with J2ME without writing your own GUI framework. Take a look at LWUIT really. For example they have a virtual keyboard as one of their touch screen functionalities and this you have on devices like the N97 which itself does not have a Virtual keyboard. BTW using LWUIT you have a Blackberry and Android port included if anyone cares.
Also Apps nowadays become the center stage on many platforms not just the iPhone. Look at the recent developments in this area like OVI, RIM, Samsung, SE, Orange World they all start with app shops.
"Getting people to use a website on their mobile phone is easier than getting them to download an application." this is just a claim without proof. you cannot say that like this. It depends on a lot of other factors. - Why should users type in your mobile url into the rather small screen again?
Anyway, this answer is probably too late so I'm not gonna write much more. The mobile industry is changing fast right now but there is not yet a alternative to J2ME for crossplatform development. Maybe in the future with better browsers and widget technolgies.
Just a short note, applications like google maps or gmail mobile probably don't use WebServices to talk to their server part. A WebService has a lot of overhead, especially when considering that mobile users are usually rated by the amount of data they transmit. The best way to perform communication between your client app and its server part is to use binary data over a socket connection.
I personally think it's really hard to make a consistent and reliable J2ME application that will run across a large set of mobile phones. Based on my experience, I would only develop a J2ME application (instead of a Web application) if it's a strict requirement - for example, to be able to view your bookings without being connected to the network. There are other costs associated with J2ME applications - the applications must be downloaded, the user will be asked if the application is allowed to connect to the network when it attempts to (there are exceptions for this case but I believe the application has to be signed by 3rd party company - more $$$ involved), you will have to maintain different versions of the application running on a variety of mobile phones (more complexity to the application), and so on...
Think about it this way - if you were developing a similar thing for a computer, would you build a desktop application or a web application? With the cellphones of today (many of which can access full-html sites with javascript - which means ajax), the proposition of the question is valid.
I thing a good rule of thumb should be: If what you're trying to achieve can be done with a mobile website - go for the website.
IMHO, apps should only be used to if they cant take advantage of the mobile hardware - like location, sound, video, 3d, pictures etc...
Even if the dev costs for the app were insignificant (they usually aren't), you'd have to offer some really amazing capabilities to make the users go through the trouble of downloading it.
(All of this is essentially true for J2ME/BREW. The iPhone is a little different as apps take the center stage)
One thing worth highlighting: the only standard way of deploying a MIDlet is via OTA download so you wouldn't expect a J2ME-capable phone to not have a web browser.
Mobile web browser like Webkit and Opera are getting better faster than J2ME (at least until MIDP3.0 starts shipping, if ever).
No matter which platform you choose, you will need to test your service on many devices. I don't think switching from J2ME to webapp makes a huge difference in that regard, because phone manufacturers keep changing the binaries that go into the phones firmwares.
Getting people to use a website on their mobile phone is easier than getting them to download an application. unless that application is already installed when they buy the phone, that is.
You might want to look at LWUIT for better and easier J2ME GUI.
One thing that J2ME will accomplish for a flight booking service is save battery life by not requiring constant network data transfer, thanks to the local storage mechanisms.
there are many great j2me apps that (need to) talk to webservices. just think of the google apps, like gmail mobile and maps for mobile. they are faster and easier to use than using the services via cell phone browser. so if you can design a good app, it's definitely worth it.
EDIT: also, a j2me app makes possible features that can't be provided by a web application: integration with phone features (address book, calendar), "call this number", location api, etc.
I think for business apps, or more text/data oriented things, a mobile web/wap site might be easier to maintain, since you won't have to deal with pushing client updates out to handsets.
For UI-intensive apps (maps, games, etc.), client apps are probably the way to go, so you can handle the more of the processing and rendering on the client side.
Both options are difficult though, since there are so many compatibility issues with phones. You might be best served by narrowing down what types of phones you want to support for your app. If you think most of your customers will be iPhone or Android phones, you can target those platforms (with either client apps or web apps) and avoid old-school j2me completely.
I hate WebApps on phones. They are slow and they don't work in a semi-connected environment.
J2ME apps can do local backups, bluetooth backups, bluetooth data sharing between 2 phones and better responsive UI. However that requires money,skill,time etc.
My main gripes with MIDP though is pushing software updates and wav real time mixing. Technically those are possible within the scope of MIDP but the goons at wheel are not very creative.