I have very old Siemens CX70 in working state and just don't want to throw it out. My idea is to use its math power and peripherals (GSM module, USB, Camera and screen) to build some simple applications for home use (multichannel termometer, timer and cheap security system - for examples).
I know I should use Java ME and IDE (I love Netbeans, for example). Can you tell me what I need more to start developing? I know Java well, I just need to make an environment to developing, debug and deploy. Mobile library documentation will be very helpful too.
Thanks.
There are so many online tutorials about this topic that the only right thing to do is to refer you to google.com
Search after "getting started with j2me".
However, there's something else you should know upfront before getting too excited.
The security model in JavaME will prevent you from doing much useful stuff, in relation to some of the things you mention.
Every time you try to access certain things in the phone, like e.g. the camera, or send SMS, or read/write a file on SD card, etc etc - the phone will show a popup "This app is trying to access camera. Allow this?". And the app will only continue after a manual click on Yes.
As you can imagine, this of course renders a lot of ideas useless.
In order to prevent these popups, you can sign your app with a certificate you buy from Thawte or Verisign. But as that'll cost you $300 a year, it's not the way most sparetime hobby developers chooses.
Personally, I found another way, but it requires you to use a phone from Sony Ericsson.
Because the old Sony Ericsson phones can be patched in order to remove the Java security. After doing this on one of my old phones, I've been having fun making apps like the ones you mention. For example, an app that keeps an eye on my home when we're out, by taking a picture every second. If it detects a difference in the picture, it sends me an MMS with the picture. :-)
I have searched a long time for patching options for other brands, but I just can't find anything useful. Nokia should supposedly also be patchable, but I just can't find anything useful about it.
So in short: If you'd like to make some sparetime hobby apps on a phone like that, you should either find a Sony Ericsson phone and patch it - or go dig up an old used Android device.
Good luck.
I'm writing an application that needs access to a serial port (it's a credit card reader). I'd like to be able to read and write to the port. The following seems like it would let me do exactly that: http://www.activexperts.com/serial-port-component/howto/html/. However, this deals with ActiveX/COM which means I'm tied to Windows.
Any better solutions for me? Would be nice if the solution would work on multiple platforms, not just Windows.
I'm using PHP.
Does the device emulate a keyboard? You'd be much better off getting the user to position the cursor inside a textbox (or putting the cursor there programmatically) and swiping the card if that's the case.
I spent a lot of time writing a userspace driver in C for a Magtek Mini-Mag card reader only to realize years later that it was academic more than anything. I mean we used the code, only if we'd have gone with the keyboard solution there would have been tons of time to focus on other things.
For the Mini-Mag the USB/HID support in the kernel would recognize the device, hopefully there's something similar for the device you're getting.
Also, Windows has it's own variant of USB/HID so the 'treat it as a keyboard' solution works pretty much out of the box for devices that act that way.
Processing has Android support and it seems to be pretty awesome from my 10 minutes of playing with it. But I would like to make a regular (nongraphics) application like a twitter feed reader or something. So is there something like Processing that can do regular apps? Besides Titanium...
Basically I am looking for anything that will make coding for android easier, processing was so easy to get working that I was very happy with it, but it is for graphics only. Titanium didn't give me the same wow factor and it isn't open so that kind of takes away from it. What other tools are out there?
I'm going to give you the answer you are looking for and some advice.
Processing can do ANY of the things you are thinking about doing. If you want textboxes etc, you can use the Control P5 library. It's great. If you are an expert at Processing and just want to port over your Processing code to android, Processing for android is great.
But that's not what you want to do. You want to write an application. And you want to write it on Android. There are frameworks designed to give you a leg up in writing cross-platform mobile apps, but nothing is going to make writing an android application easier than learning Java and learning how the android stack works. It's actually really well designed and easy to follow once you start grokking "intents" and "bundles".
At the end of the day, you might even want to scale back a little further. Are you trying to write an application that needs to be used without internet access or that uses super special phone APIs? If you aren't, maybe you should try just writing your app as an html5 css3 website.
You can do plenty of input based stuff with processing. The original mouse events work as specified, except pass touches, but you can also access things like pressure and multiple fingers down. The hardware keys are also supported.
When considering a platform for a game, I've decided on multi-platform (Win/Lin/Mac) but can't make up my mind as far as browser vs. desktop. As I'm not all too far in development, and now having second thoughts, I'd like your opinion!
Browser-based games using Java applets:
market penetration is reasonably high (for version 6, it's somewhere around 60% I believe?)
using JOGL, 3D performance/quality is decent; certainly good enough to render the crappy 3D graphics that I make
there's the (small?) possibility of porting something to Android
great for an audience of gamers who switch computers often; can sit down at any computer, load a webpage and play it
also great for casual gamers or less knowledgeable gamers who are quite happy with playing games in a browser but don't want to install more things to their computer
written in a high-level language which I am more familiar with than C++ - but at the same time, I would like to improve my skills with C++ as it is probably where I am headed in the game industry once I get out of school...
easier update process: reload the page.
Desktop games using good ol' C++ and OpenGL
100% market penetration, assuming complete cross-platform; however, that number reduces when you consider how many people will go through downloading and installing an executable compared to just browsing to a webpage and hitting "yes" to a security warning.
more trouble to maintain the cross-platform; but again, for learning purposes I would embrace the challenge and the knowledge I would gain
better performance all around
true full screen, whereas browser games often struggle with smooth full screen graphics (especially on Linux, in my experience)
can take advantage of distribution platforms such as Steam
more likely to be considered a "real" game, whereas browser and Java games are often dismissed as not being real games and therefore not played by "hardcore gamers"
installer can be large; don't have to worry so much about download times
Is there a way to have the best of both worlds? I love Java applets, but I also really like the reasons to write a desktop game. I don't want to constantly port everything between a Java applet project and a C++ project; that would be twice the work!
Unity chose to write their own web player plugin. I don't like this, because I am one of the people that will not install their web player for anything, and I don't see myself being able to convince my audience to install a browser plugin.
What are my options? Are there other examples out there besides Unity, of games that have browser and desktop versions? Did I leave out anything in the pro/con lists above?
I'd suggest writing a game first.
It's easy to get caught up in how to make the best game ever,which can run on anything from an abacus to SkyNet, but the reality is that you're going to have plenty of challenges ahead of you just finishing a game that runs on your own PC.
Write a game first, for one platform (whether that platform is "Windows native with DirectX", or "Java applet" or even "pure AJAX in a browser"). If you can do that, then you can start thinking about how to port it to other platforms. But trying to do everything is a sure way to end up achieving nothing.
Or to put it another way:
I've decided on multi-platform (Win/Lin/Mac)
so you've actually decided nothing. Decide on a platform to develop on. Then make the game. Then make it work on other platforms.
Don't worry so much about what your "audience" will find acceptable. If your game is fun, then yes, people will happily install Unity. Just like they'll install your game if it's not browser-based. But the important point is not "what do I have to install to play it", but rather "is it worth it". Your focus should be on making a game that is worth the installation.
And unless you're planning to sell 20 million copies of the game and live off it, your "audience" doesn't really matter that much, does it? What matters is putting the game out there so those who are interested can try it.
But a single-platform game is a lot better than an unfinished cross-platform nothing.
A game that requires me to install Unity is a lot better than something that takes you an additional 3 years to develop because you insisted on reinventing the wheel.
Yes you can have the best of both worlds.
It's perfectly possible to write a Java application that will run in both an applet (for your online users) while also running as a standalone application in downloaded form.
The key technologies are:
JNLP
JOGL for the graphics, which also has some good demos
I'm not so familiar with it but I think jMonkeyEngine looks very promising if you want more of a full-featured game engine
If it's any use, an old game I wrote called Tyrant supported running both as an applet and as a standalone downloaded .jar file, all the source is open if you want to look at it. This used simple AWT rather than 3D graphics.
And finally here's another example of converting an applet into an application with a pretty minimal amount of code.
If you really want that kind of penetration then I suggest HTML 5 + javascript depending on the performance you need.
First of all you start with the wrong question. Your decision for a technology should be driven by the concept behind the game. It seems that you are sure about the idea to write a game - so ask your self what the requirements for the game are. This will lead you to your technologie. If it doesn't get an idea of "what" you want to do.
To your Pro's and Con's:
Don't focus on things you will never need or be able to use. Thinking about the steam platform isn't interesting for a hobby developer. Also android isn't interesting if you are not really want to ship your application for android. This Pro's will actually never be a pro in reality.
To sum it up: Let this decision be driven by your idea, not the technology itself. If you have a clear idea of what you want to do you will get your answer.
(And btw.:
Think about what browsergames imply. Behind a Browsergame there is a huge service-area, only for keeping the game running. Companys working in such areas are basically service-providers.)
You might want to look into Google's Native Client, which allows you to write your application in C or C++ (or anything else that compiles to native code, really). A new feature coming to the SDK is LLVM support, which will (hopefully) allow NaCl software to target any platform that Google's Chrome browser runs on (or any browser that the NaCl plugin works with - currently x86 and ARM are supported, IIRC).
You mentioned Android in your question - have you thought about developing the game purely for Android?
In effect you get the best of both worlds, easy to maintain, easy to release new versions, easy to monetize and get some small income and you don't have write your own installer or update mechanisms either.
Yes. You can make something that will work in both. Basically, make your program work inside a JPanel. The applet can display the JPanel, and the desktop version is just a window with your JPanel in it.
You could also have a full Swing (or whatever) GUI, which the applet launches in a new window when they click the little "start" button you'd have on your applet.
There are a few other differences you'll have to take into account, like possibly loading resources, but I've done it before for simple games I've made.
I don't think you can really compare the two:
In my opinion:
Applet, flash and other browser based games are typically small "toy" games either written for free or supplemented with advertising. For examples, check out the Addicting Games website.
C++ games are more likely to be heavyweight studio-written games relying on dedicated physics engines, graphics engines, etc (particularly true of games distributed on Steam I would have thought). The learning curve is likely to be much steeper, as C++ is inherently a more difficult language than Java / Flash.
If you're unfamiliar with C++ my advice would be to steer towards Java with JOGL. That way you can scale the Open GL learning curve before having to tackle C++.
EDIT
To address the other section of your question regarding implementing a game in both browser and desktop form, you could consider implementing the game in Java and deploying an applet and standalone version, whereby the standalone version can take advantage of Java's full-screen exclusive mode API. You could base both applications on the same codebase. You could also consider shrinking the applet's footprint size by retaining data files (e.g. game levels) on the server-side and retrieving them dynamically when required.
While WebSense won't let me browse directly to the site, for obvious reasons, the first thing that came to mind when reading this question is a game like Wurm Online. It's written in Java with JOGL, implements content streaming and local caches, and seems to have touched on a lot of the points you're interested in. It's a desktop Java application rather than being truly "in-browser" but I think you could still learn quite a bit from its implementation.
The in-browser game is always in peril of having its window closed or refreshed, causing it to abruptly lose state unless everything is being kept server-side. This means you either have very simple games that can maintain synchronization using a call/answer model (such as the myriad of Facebook "Mob Wars" text-based games) or risk an inadvertent bump of F5 catapulting someone back to their last "saved game."
I'm not sure that refusing to use a plugin because you personally don't like it is a sensible choice. This option lets you write you app installable as a desktop app, or a browser plugin (with not much extra work) and you still get to write it in C++/GL. You said you don't think your users will install plugins... why not? If they will install an application then why not a plugin which basically boils down to the same thing?
You could look at Flash too, which is gathering some 3D functionality and can run in-browser or as an AIR dektop app. But then users would need a Flash plugin, which you presumably don't have either.
is it possible to create java application that will
work as background process on symbian smartphones?
You can approximate it but J2ME (the version of java on mobile phones) may not be the right technology to do this.
starting a MIDlet (a Java application for mobile phones) when the phone is switched on is tricky at best without coding a small Symbian OS C++ module that will start it for you. If you want to try anyway, look at the PushRegistry class in the MIDP specs
(http://java.sun.com/javame/reference/apis/jsr118/). The Content Handling API might provide some way to do it too (http://java.sun.com/javame/reference/apis/jsr211). When you are ready to give up, do it in C++.
Backgrounding a MIDlet isn't hard. The phone's "menu" key will do it for you. Programatically, Canvas.setCurrent(null) has a good chance of working. Trying to trick the phone by providing a fully transparent GUI and not handling any keypad activity will absolutely not work. Creating and starting a separate Thread in the MIDlet should allow you to keep something running even after your overload of MIDlet.pauseApp() has been called by the application management system.
The real issue is that the MIDlet will not have any Inter Process Communication system unless you make one. The usual way of doing that is a loopback socket connection over which you transfer data. Not a nice or efficient way of simulating IPC. Sharing a RMS record can only be done from within the same MIDlet suite (you can package several MIDlets into the same .jar file), I think. The code to create a provider/consumer data flow over a file connection is even uglier and will raise security issues.
Without any more information about what you want to use it for, my answer is : maybe but you should probably not try.
You will have in-built MIDP support for background MIDlets in MIDP 3.0 (http://jcp.org/en/jsr/detail?id=271). Don't hold your breath for devices to appear, however - might be some time.
(Note that a few Symbian OS devices have more than just MIDP - the S-E p990 for instance, https://developer.sonyericsson.com/site/global/products/phonegallery/p990/p_p990.jsp).
As already pointed out, it might be helpful to have more information on what product functionality you are trying to implement - often more than one way to skin a cat.