I want to create an application for several mobile platforms (android, BB, iOS etc) which has the capability to use nfc peer to peer functionality. (for example, to read/write to a nfc reader/writer).
I looked at mosync (because it allows us to write C/C++ code which i'm comfortable with) but their API does not specify anything about peer-to-peer nfc. It only supports read/write to/from nfc tags.
So, which is the best platform that i can use to fulfill this need? (by best i mean flexible and which supports the maximum number of platforms)
Also, can libnfc be used with "any" such framework?
If you don't plan to take advantage of the capabilities of the devices like a native app can, I suggest you to take a look at PhoneGap. When we talk about cross platform apps, it is the most common framework. Also you can use phonegap-nfc plugin to support android, bb and windows phone 8.
We have developed ~5 NFC applications for Android, iPhone and Windows Phone 8. We are starting BB10 now.
Do not count on cross-platform there - at the end you will not save either money nor effort. I have nothing against cross-platform and we heavily use it e.g. on Google TV or PS3, but not there.
It is simpler (at least for us) to quickly come with Android, iPhone (iCarte), Windows Phone 8 and possibly BB10 application done in native code. The content itself can be rendered with use of HTML/JavaScript/CSS.
BR
STeN
Related
I am wondering about the limitations of using libraries in code name one. Specifically, I would like to use a specific http client library that uses nio but I am not sure if that will even work in code name one. There is an http1 client and an http2 client here
https://github.com/deanhiller/webpieces
Can the nio stuff actually be compiled into iOs? or does it have to be synchronous socket http client implementations?
thanks,
Dean
It won't work and you can't. This article is from 2016 but it's still mostly accurate. The gist of it is that most of these APIs aren't essential and if we add all of them performance/size would balloon to huge numbers.
E.g. a Codename One application can weigh less than 3mb for iOS production builds with 32 and 64 bit support. Our closest competitors clock at 50mb for the same functionality with only 64bit support. This isn't just a matter of size, it's a matter of quality (QA), maintenance etc.
This also reduces portability as we have to test this on all ports including iOS, UWP, Web etc.
Having said that we're open to adding things and have added some features to the core since the publication of that article. But either way, you can't just use an arbitrary jar and need to use a cn1lib.
Now that webOS is opensource I am trying to find any resources on building your own mobile phone in the US. That is put webOs on some custom hardware that has 3G voice access.
I realize this question is not a programming question but I could not find another StackExchange that was applicable.
I would suggest looking at OpenMoko and their history of attempting to release phones based on open hardware specifications for open source mobile operating systems.
Per the wiki article, Openmoko phones now support Android, Debian, Gentoo, Qt Extended Improved, QtMoko, and SHR. The announcement of the webOS opensourcing means that it's possible that webOS could be ported, as well.
You're likely going to have to wait a bit before using just any hardware. While webOS is going open source, right now the only thing that's released is Enyo (the application framework, minus the UI elements). There are other components to the OS that are still unreleased, and the OS runs on a modified linux kernel. They do plan, however, to release a version by the end of this year, called open webOS 1.0, which will run on a standard linux kernel.
I need to create a web-controlled application (that lives in the browser) that can connect to and read data from devices connected via USB or the serial port.
At the moment, I'm using an ActiveX control to do this. However, I'm like to re-write this system to make it cross-browser (support Firefox) and eventually cross-platform (support Safari on Mac). ActiveX is neither cross-browser or cross-platform, so I'm looking for an alternative technology.
My first inclination would have been to use Silverlight, because Silverlight 4 grants access to COM Automation. Unfortunately, this only works with OOB (Out of browser) Silverlight applications - in-browser systems are still bound in a sandbox and do not have access.
So, what technologies exist (frameworks, browser plug-ins, etc) that will allow me to interface with a USB/Serial device from within a browser-based web application? What are the pros/cons of each?
I think your best bet is probably Java in this case. USB, though an industry standard in terms of protocol is definitely not standardised in terms of bare-metal implementation. For this reason, you will still need a different Java USB implementation for each distinct platform (windows, linux, osx, bsd) that you intend to support. Of course you will also have to pay for code-signing certificates so you can try to convince people to grant your application the kind of access it requires; something that browsers try very hard to deny access to and most people in this day and age are very unwilling to grant. That said, there's an old IBM article here on the various Java USB projects that makes a good read. Good luck.
http://www.ibm.com/developerworks/library/j-usb.html
-Oisin
It might be painful, but you could use a signed Java applet. Signed Java applets can have full access to the user's system.
Java does not have built in USB support, so you would probably need to roll your own JNI interface to native USB APIs.
Using JNI in an applet can be tricky. I've done it before. If you Google the topic, most results say "don't do it" or "you can't do it." Well, you can do it.
This is how I did: I packaged the native libraries (DLL, so, etc) inside the applet's JAR, and then read the native libraries out of the JAR using e.g. getResourceAsStream. I then wrote the libraries out to an appropriate location on disk (e.g. ${user.home}/.myapp/.) I then used System.load to load the JNI DLL.
There can be some ClassLoader issues with JNI libraries and applets. The issues are subtle and difficult to explain. They basically have to do with the fact that a JVM can only load and bind a given JNI library once per VM instance, but applets get instantiated a lot, often with their own new ClassLoader, which can be problematic. The work that Sun did on process separation in the Next Generation Browser Plugin may have relieved some of these issues, but your users will only have this if they are using Java 1.6.0_10 or later.
It is also possible to use JNA within a signed applet. I would not recommend using JNA to access USB APIs directly. But JNA can sometimes be a big time saver for accessing simple native functions. Although once you've set up your JNI infrastructure, JNA probably has less value.
Here are a few other random thoughts:
Java WebStart - Can be launched from browser, but runs outside the browser
Microsoft ClickOnce - Can be launched from browser, but runs outside the browser
Flash / AIR - Can't escape its sandbox
The best solution I've come across thus far is the cross-browser/cross-platform plug-in system called FireBreath. This is a framework built in C++ that allows you to generate plug-ins for both ActiveX and NPAPI from the same codebase.
So build it once, make it work, and it compiles to one DLL that you can deploy in either environment: ActiveX for IE, NPAPI for everyone else.
After reading this post and some derivative publications (ddotdash.com) I wonder whether it is possible to use a handheld as a main platform for development of web applications for mobile web browsers.
For web development I use a rather common set of tools: Cheap netbook, Ubuntu 9.10, Ruby on Rails, VIM, GIT. I think it is possible to use all of those on Nokia n900 due to the fact that it has Maemo OS on it which is based on Debian (all debs are possible to install and you can always compile problematic debs from source).
Nevertheless, I am concerned with 3 problems:
Display size. I have 1280x800 resolution on my netbook and it is convenient for me to have Terminator (multiple consoles), VIM, file browser, Firefox and some PDF books opened at the same time. I wonder if it would be possible to use all these apps on 800px horizontal resolution.
Computing power: Via Nano (or Atom) processor does not distinct dramatically from that on Nokia n900 (at least in MHz), however I wonder if 256+768(virtual) memory on Nokia will be enough for my work (I have 3 GB now on the netbook).
Keyboard. Frankly it is not a problem due to the fact that I have Nokia su-8w bluetooth keyboard that is comfortable enough for touch typing. However it is interesting to read some comments on this problem. [Edit]: Bluetooth keyboard is not so comfortable - a developer has to dispose a handheld on the keyboard and it is not easy to look at the small screen from such rather big distance (keyboard can be placed on a table or on the knees only).
Having solutions for the problems mentioned above, I will have an opportunity to exploit all the wonderful advantages of the mobile development platforms, such as:
work from anywhere (it is important for me);
develop for the same form-factor that is used by the developer and intended users both;
pocket-size working tool :)
It may well be possible - the question is how much energy you'll expend compensating for all the restrictions. It's like developing in Notepad: possible, but not a pleasant experience.
I develop a bit on my netbook too, and it's okay - but I wouldn't want to do it all day.
It's certainly quite cool to be able to develop on a handheld device, but I don't think it's really practical for significant amounts of code. If this is for your own personal pleasure and you think the benefits outweigh the costs, that's one thing - but I wouldn't do it for commercial apps.
I would like to ask a few questions regarding mobile game porting...
Let say if I have a simple 2D C++ game engine and have a PC game based on that engine and I want to port it to different mobile platforms BREW, J2ME, iPhone, Android, Symbian, etc..
Do I need to re-code the engine and the game for each platform? or is there an easier and more efficient way? I am sure the process is complicated since different phones have different graphic/processor/memory/etc. I am just curious about the overview of mobile game porting process. :)
Thanks!
There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible. I worked in 3rd party mobile game development for many years until recently. I watched BREW vanish and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.
At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. We never supported Symbian as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phones supported J2ME.
We would be required by publishers to provide any where from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined" based on the final product and how cost effective an iPhone version would be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.
Companies like Gameloft still brute force their way through porting. That's why Gameloft's games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.
There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can't vouch for them. The problem here is that you will be at the mercy of another companies engine. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.
Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is a huge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a 70 percent profit share through the AppStore for developers. Through carrier releases, the percentage is not even comparable.
This of course depends on in which language your "simple engine" is written. Java is supposed to be easier to move between platforms, since it in effect is a platform of its own. If your engine is written in something more low-level, like C++, it will likely depend on platform-specific libraries for graphics and input, since C++ doesn't provide you with that.
I can personally recommend edgelib as a cross platform layer for mobile games and application development.
It is widely used, offers excellent performance and supports most of the important smartphone platforms in existence today: Symbian, Win Mobile, IPhone and others.
Most important: It's cheap and offers a free complete evaluation until you decide to produce commercial content with it.
You can find it at: http://www.edgelib.com
You can see a showcase of games and other projects based on this platform at the site.
Unfortunately, BREW is not supported though. And since it isn't a real open platform, it poses quite a challenge compared to other mobile OS platforms as it's development community is mostly professional and not very "talkative" in online terms...
This will perhaps change as the competition is getting more open by the minute.
I am not affiliated with Edgelib... this is just my personal opinion. :)
There is no free lunch. The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.
About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.
So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.
Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable
What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn't support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).
Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/Linux/Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are signifficantly behind Visual Studio or GDB. Iphone, on the other side, has a lot of cool tools to debug and profile your app.
If the engine you have is not written in JAVA or FLASH I don't see a way that you can use your engine out of the box without recoding it in a language which might run on a mobile phone.
If it is coded in JAVA or FLASH, I think you're main problem (beside the performance difference between a phone and a pc) is the main memory. As I've heared, the main memory is the biggest problem in mobile phone game development.
As others have pointed out, if your engine is built on top of some 'platform independent' framework such as Java, then it's supposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/iPod touch, and it'll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn't use to implement your engine.
In general, it depends on the application/game engine you've written. Most likely you'll have to change something, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of 'platform independent'-dependence, or so I've heard. How much you'll have to change solely depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.
Unfortunately, this is the best answer I can give you.