As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to develop a mobile application that is able to access all the features of the mobile device it runs on (camera, files, phone and network connectivity). I intend to build a series of applications that each have a specific function to perform, rather than a single application with a large feature set. My programming background is C, C# and web applications.
What would be the best tool set to use to do this? I have looked at using the NetBeansIDE to create a Java ME applications using LWUIT - this looks promising, but what are the caveat's?
I want to target the largest universe of mobile devices possible.
J2ME is the way to go to reach the masses, in the consumer or the business market. From a consumer standpoint, most of the world's mobile phones support J2ME. From a business standpoint, most of the world's smart phones support J2ME.
Nokia owns a 40% share of the smart phone market (and the whole market) worldwide. Next in line is Blackberry with a 13% share. Both have standard implementations of J2ME on their devices (though Blackberry also has a proprietary version of Java as well). On top of this, most devices that run Windows Mobile come with a JVM as well (I developed a game recently that initially targetted the Sony Ericsson W810i and it ran flawlessly on my HTC Tilt's JVM). Add in the fact that Android has a Java SDK and the only segment you are really missing out on are the BREW only phones and the iPhone.
I'm not a huge backer of J2ME. I just know that every other mobile platform has disappeared from my life over the last 3 years as it just makes financial sense for companies to only target the J2ME segment of the industry.
You are facing the usual main issue of mobile development : targetting as many handsets as possible with only one programming language means using J2ME, which doesn't quite give you access to all the features of the handset.
Most open handsets will support J2ME but different phone manufacturers implement it in different ways and fragmentation is enourmous accross the board. Unfortunately, the majority of open handsets (the ones where you can install third-party applications) only allow you to develop in J2ME
The only good news is that your intent to only write small applications will provide large relief from fragmentation issues.
J2ME also has huge limitations in terms of file system access, complete lack of a telephony API, very poor interaction with the system applications management...
In order to get full features, you always need to use the native technology of the open platform you are targetting, be it Android, iPhone, the several variants of Symbian OS, Brew, Windows Mobile or Palm OS handsets. Each of these has its own native technology.
Writing your application many times in many different languages in the costly price of wanting both a large number of targetted handsets and access to the full features of each of them.
I'm a Symbian/J2ME veteran myself and, given your stated background and goals, I suspect that you are trying to learn about mobile technologies. I'll therefore shamelessly plug my book, which is meant as an introduction into the Symbian development ecosystem :
http://www.amazon.com/Quick-Recipes-Symbian-Smartphone-Development/dp/0470997834/
Good luck
If your primary goal is to reach the consumer market, Java 2 Micro Edition (J2ME) is probably your best bet. All popular mobile phones (from Nokia, Sony Ericsson, Samsung) come with a Java Virtual Machine installed. If you look at Google, for example, they are developing all of their mobile applications (like Gmail and Google Maps) in Java.
If you instead are targeting business customers, the Microsoft .NET Compact Framework is the way to go in my opinion. The Windows Mobile operating system holds a strong position in the business market, mainly because of Outlook Mobile and its integration with Exchange.
I respectfully disagree with Fostah.
If you want to reach the masses, the Web is your best bet. It's far easier to write a simple Web application that will work on millions of devices.
And the best bit is that you can easily update your application and improve the user experience everyday with the Web.
Related
Where do they differ?
What are the advantages of choosing libfreenect or OpenNI+SensorKinect, for example, over the Official SDK, and vice-versa?
What are the disadvantages?
Please note that the below answer is per date and some facts may very well be outdated in the near future. Current state of the Official Kinect SDK is beta 1.00.12.
The first obvious difference is that the official SDK is maintained by the Microsoft Research team while OpenKinect is an open source SDK maintained by the open source community. Both has its cons and pros.
The Official SDK is developed by Microsoft which also develops the hardware and therefore should know internal information about the device that the open source society must reverse engineer. Obviously this is to Microsoft's advantage.
Microsoft is pouring a lot of money into this device and I am sure that they will do what they feel is necessary to keep their SDK up to par. Having economy behind it gives many advantages.
On the other hand, never underestimate the force of the open source society: "The OpenKinect community consists of over 2000 members contributing their time and code to the Project. Our members have joined this Project with the mission of creating the best possible suite of applications for the Kinect. OpenKinect is a true "open source" community!" - http://openkinect.org/wiki/Main_Page.
OpenKinect was released long before the official SDK as the kinect device was hacked on the first or second day of its release. Kudos to OpenKinect!
Programming languages supported:
Official SDK: C++, C#, or Visual Basic by using Microsoft Visual Studio 2010.
OpenKinect: Python, C, C++, C#, Java, Lisp and more! Obviously not requiring Visual Studio.
Operating systems support:
Official SDK: only installs on Windows 7.
OpenKinect: runs on Linux, OS X and Windows
Clearly advantage OpenKinect.
License:
The Official SDK is in its current beta state only for testing. The SDK has been developed specifically to encourage wide exploration and experimentation by academic, research and enthusiast communities. commercial applications are not permitted. Note however that this will probably change in future releases of the SDK. Visit the FAQ for more information
OpenKinect appers to be open for commercial usage, but online sources state that it may not be that simple. I would take a good look at the terms before releasing any commercial apps with it. Read Kinect – Licensing implications of open hardware projects for more info.
Documentation and support:
Official SDK: well documented and provides a support forum
OpenKinect: appears to have a mailing list, twitter and irc. but no official forum/QA? Documentation on website is not as rich as I would like it to be.
Device calibration:
Different Kinect devices may differ slightly depending on the batch that they were produced in. Thus device calibration is sometimes required. But:
the Official SDK does not provide any calibration settings but I have so far not had to calibrate the device I am working on. According to something I read online (link lost) at production time the calibration parameters are written to the kinect device, so with the Official SDK calibration is not needed.
OpenKinect features device calibration: http://openkinect.org/wiki/Calibration. Thus I believe that you should calibrate your device if you go with OpenKinect.
If its true that calibration is only needed for OpenKinect that is a big advantage for the official SDK as it is easier to distribute and install applications without such need.
Personally, after a failed try with the OpenKinect SDK I went with the official SDK, which
came with drivers that installed out of the box
came with examples and code for easy getting into business
All-in-all: I could start my own development within 15 minutes or so.
Now, after working with the Kinect for a few months, I have to say that I am quite satisfied with the API provided. I cannot however compare it to the OpenKinect SDK as I in fact never got it working (but perhaps it didn't give it a fair try).
UPDATE: As of February 1st 2012 there is a commercial license for the official SDK:
"The commercial license for this release authorizes development and distribution of commercial applications. The prior SDK was a beta, and as a result was appropriate only for research, testing and experimentation, and was not suitable for use with a final, commercial product. The new license will enable developers to create and sell their Kinect for Windows applications to end user customers using Kinect for Windows hardware on Windows platforms."
Developer Frequently Asked Questions
As explained by Avada Kedavra in his/her answer, these are some interesting differences:
supported operating systems: you can only use Microsoft SDK on Windows, while open source solutions are usually able to work on other operating systems;
programming languages: you have a wider choice with open source solutions, while Microsoft only supports C++ and C# (Visual Basic is no more supported with SDK 2.0);
documentation and support: Microsoft offer a good forum and a well done documentation (with a lot of samples); but there are several open source solution well documented;
license: Microsoft is less or more proprietary, open source is less or more free. Consider also that open source ideas have sometimes been bought by big companies, and transformed in something that is no more open. Probably yours will not be the case, but keep in mind this additional eventuality.
In my personal opinion, the most significant difference between open source solutions and Microsoft SDKs is strictly related to the skeletal tracking algorithm.
While depth and RGB data can be effectively provided by both open/free APIs and Microsoft SDKs, implementing skeletal tracking capabilities is not only a matter of reverse engineering.
To implement such an algorithm, developers must have strong competences in pattern recognition and machine learning areas, and I am quite sure that such kind of knowledge is available among the open source community. But the implementation of skeletal tracking is based on a "trained" algorithm, that requires a lot of experiments to collect very large amount of data. These data are then used to "train" the algorithm, that can recognize the skeletal joints.
Getting enough data, but also adjusting and properly using them, requires a lot of time and money. Microsoft researchers and developers are in the best conditions to work on this kind of stuff, simply because it is their job.
In my previous experiences, I noticed that open source solutions provide good skeletal tracking capabilities, but they are not at the same level of what Microsoft offers with its SDK.
Remember also that Microsoft SDK provide a lot of additional capabilities, like facial recognition or joint orientation, and several widgets very useful if you want to fastly build a gestural GUI.
So what I suggest is: if you are working on a project in which you simply need depth and/or RGB data, or if you have the necessity to use a programming language that is not supported by Microsoft SDK, then you should opt for open source solution. Otherwise, Microsoft SDK would be my best choice.
I would strongly recommend the Cinder framework. (libcinder.org)
It supports both OpenNI and Kinect develoment, if you're using C++. It now supports Kinect SDK 1.7 and OpenNI 2, via these Cinderblocks:
MS Kinect SDK 1.7 (stable)
https://github.com/BanTheRewind/Cinder-MsKinect
OpenNI 2 / NITE 2.2 (alpha)
https://github.com/wieden-kennedy/Cinder-OpenNI
Both can do skeletal tracking out of the boz, OpenNI being capable of tracking up to six skeletons simultaneously. OpenNI 2 is gaining rapidly on the Kinect, although the new Kinect will probably change that when it comes out next month. However the basic underlying principles are unlikely to change.
The main drawback with the initial release of OpenNI was that it required a full body activation pose to recognise a user, which was a deal breaker for a lot of applications - however this seems to have been solved in the newer versions and OpenNI 2 also supports robust hand tracking at close range, although it still requires a focus gesture initially. If you work on Mac or Linux, it's pretty much your only choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am studying about programming, so I want to make some programs.
Actuall, nowadays I'm studying embedded with embedded development board.
so, I want to make embedded program....
but...... I have no ideas...... what program I can make.
so could you guys recommend for me????
The program you write will depend upon what hardware you have or what skills and equipment you have to build your hardware.
If you have no hardware (or electronics skills), then buy an off-the-shelf development board, and then the program will depend on the features available on the board. The simplest will have no more than a serial or USB port and some I/O pins direct to the microcontroller's GPIO and peripheral device IO; you will need to attach additional hardware to this. More expensive boards may include fast 32bit processors, displays, Ethernet, memory card interfaces, large external RAM/Flash memories, WiFi, buttons, switches, LED's etc.
At the very minimum if you have never brought an embedded system up before, you should do exactly what you might do on a desktop system when learning to program it; that is write "hello world". In this case teh text should be emitted from the serial port, and displayed in a terminal emulator (such as TeraTerm or if you must, HyperTerminal). This will confirm that you have the development tool-chain and work-flow working and can build an load the binary to the board. It will also verify that you have basic serial host communications working which will be beneficial for debugging, especially if you do not have dedicated debug hardware such as a JTAG emulator or ICE.
You may find that your development tool suite, or the microcontroller or board vendor's website includes demonstration examples for your hardware which will include basic driver code. No doubt there will be a simple serial I/O demonstration that will suit the "hello, world" test. It may perform direct serial output, or it may be more sophisticated and provide library retargetting code such that standard I/O library calls such as printf() and getchar() will work over the serial port.
Once you have got the basics sorted, you are then perhaps ready to decide what to build. If your board has a dot-matrix graphical display (even a very small one), and a few switches or a potentiometer, then a simple arcade game such as breakout, defender, invaders, or even pong would be possible and give instant gratification!
One of the most rewarding things you can do with an embedded system is make stuff move. Motor control and robotics applications are most rewarding and have important real-time requirements that will develop skills that are not generally utilised on a desktop application. For such applications you will need additional hardware to interface to high current devices such as motors, such as a simple H-Bridge controller. You can purchase such hardware from a number of robotics kit suppliers, or you can build your own if you have the skills and equipment necessary. I suggest starting with a simple "big-trak" style mobile vehicle (Meccano or Lego-Technic can be used if you have limited mechanical skills), and then perhaps add sensors such as bump-switches, light-detection, line follower, ultra-sonic, odometry etc.
When your applications ger more complex, you will benefit from learning about an deploying a simple RTOS or real-time scheduling kernel.
Clock program. With a timezone converter.
You could look at programming an Arduino ( http://www.arduino.cc ) or perhaps a MAKE controller of some sort ( http://www.makethings.com ). It really depends on what you want to do! Enjoy!
I think this s3c6410 board may fit what you need www.developmentboard.net called tenbyten6410.I just bought it few days ago, now its working perfect in our project. I hope it will work in your project, as good as, in mine .
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm looking for reasons developers ought to consider before developing and testing applications and games on a jailbreak device. My conviction is that if you want to publish your App to the App Store, you better make sure you always test on a non-jailbreak device. Eg. if you are a serious developer, what do you have to consider before jailbreaking your only development device respectively buying a second untampered device just for development.
The legal implications are fairly well known but it doesn't hurt to reiterate them. What I'm more interested in are all the technical reasons why development on a jailbroken iPhone will make your life harder (or sometimes easier if that exists, too).
For example, I've read that jailbreak devices can cause adverse behavior, bugs and crashes which will not appear on a non-jailbreak device. But what those issues are remains in the dark. I'm looking for concrete evidence of bugs and misbehavior that is relatively common (eg occured to you, or someone who blogged about it) when you do test on a jailbreak device.
You always want to test on the device and configuration you will be releasing for. If your going to release for jailbroke devices, test on jailbroke. If you intend to release through the app store, test on an unbroken devices.
I haven't work on a jailbroke device but I think the biggest issue would be that jailbroke devices do not enforce the same security restrictions as non-jailbroke devices. It would be easy to have a segment of code that relies on access that disappears on a non-jailbroke device.
You always want to develop and/or test on device as close to your projected average user as possible. One big mistake that developers have made for decades is building and test new software on their high-horse power developer stations. They see that the softwares runs fine on there above average systesm but when they release the software to average users running on average systems, the software is to slow in real-world use. That wouldn't be such an issue on mobile devices but the principle is the same.
there is one big problem that I've took more than a week to figure out:
inAppPurchase development doesn't work on JB devices (it gives InvalidProductIDs for all inApps)
(some reports say it's for JB with AppSync installed)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When we develop web pages we can broadly work out which browsers to support based on market share.
When we develop in .NET we can broadly work out which .NET version to develop for based on which Windows versions have it installed.
But when developing OpenGL or Direct3D applications, how do we know which video cards people (I mean "people" as opposed to "hard core gamers" or "companies using CAD" :P) are using? Are there statistics on such things? Is there some common logic that people use to work out what version to support? Just as most companies have supported (perhaps until just recently) a minimum of IE6 in web pages, is there a general consensus to support a minimum of, say, OpenGL 1.5, or DirectX 8 or something?
I note that we can find out which specific video cards support which versions of these APIs, but how do we know which video cards people are actually using, is there any kind of research on this?
N.B. I'm more interested in OpenGL because that's what I'm using, but I mention Direct3D because I assume the same problem applies.
Market fragmentation for 3d hardware has always been a huge problem. There is no simple answer.
You need to define who your uses are. Is this a casual-oriented game that you intend to sell to people who haven't updated their computer in years? Is this a business application that is aimed at workstation-grade hardware? Are you just looking for an average middle-of-the-road game-buyer? Is this something simpler than a game like a screensaver that you plan to sell to people who don't buy games at all? Do you need to support laptops? Netbooks?
The market fragmentation is considerably worse with OpenGL than it is with DirectX. The official standard requirements from the Khronos Group are all well and good. But the hardware vendors tend to be very slow to update their drivers to match the standard. Many features are required by the GL spec, but are only implemented in a fallback software path that is absolutely unusable in commercial software. The new OpenGL 3.1 spec tries to improve this situation by removing support for most older, poorly supported features. But if you need to support hardware more than a couple years old (or most modern Intel integrated GPUs) then GL 3.1 would be aiming too high.
A good place to start for general hardware usage stas among game purchasers is the Steam Hardware Survey ( http://store.steampowered.com/hwsurvey ). Steam is the most popular digital game distribution service that covers a variety of games from casual to core. They reset the numbers periodically to keep it current. Last year they reported that they had 25 million active users, so the sample population is pretty good.
So you probably need to narrow your target customer group down more. I would recommend picking some recent competing applications that you consider to have a similar customer base to yours and basing your target hardware around what they require.
OpenGL 2.1 is a good bet. The newer OpenGL 3 doesn't offer that much more functionality. You have to check for the availability of all of the OpenGL extension anyway,so you don't loose much by sticking with 2.1.
For DirectX: Use DirectX 9c. That is the latest version that still runs on WindowsXP. Drivers are stable and very mature. DirectX 10 offers more functionality but you will lock out the user-base that still runs WindowsXP.
About compatibility for non-gamers: Graphic cards that don't support these APIs (at least to a usable degree) have died out more than five years ago. Given the typical life-cycle of a PC you can be almost sure noone will have problems.
If any user complains that the software doesn't run on his 10 year old matrox-parhelia card he should just buy the cheapest graphic card he can get. It will run much faster and will cost a fraction of the software.
It depends on the timeframe of the project on the DirectX side.
If the project is to be ready in months, then follow the advice from Nils.
IF the time is over a year, I would reconsider limiting to DirectX9 as the XP machines are getting lesser and lesser with the time. DirectX11 would be a good idea, especially with retrocompatibility till feature level 9.0.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is there any cheap and very extensible robot kit, which can work with Microsoft Robotics?
I want to have a great choice of cool parts for a robot to buy. :)
If where is no such robot kit which can work with MS Robotics, is there any chance to buy a very extensible robot which just can be programmed, maybe even in assembler?
Microsoft Robotics Studio is a PC robotics platform. So if you want to use that, you need a robot with a PC on board. Unfortunately, this type of robot is more expensive and there are far fewer of them on the market. A select few that I know of that work with RDS:
Robotics Connection Stinger robot with an ICOP eBox Windows CE PC
IRobot Roomba with an ICOP eBox Windows CE PC
CoroWare CoroBot (Full disclosure: I work for CoroWare.)
As Paul said, the Arduino is a popular microcontroller for robotics. Microcontroller robots can be used with RDS, but they operate in a "tethered" fashion, always connected to a PC either with a physical cable or wireless. Some popular robots like this that work with RDS:
Lego NXT
Parallax BOE Bot
Of course a custom made microcontroller robot can work with RDS, however, you will have to architect the microcontroller-to-PC interface specifically for your robot and communication medium. This is typically not a task for novices.
Any good robot kit is, by definition, going to require you to be fairly handy with ALL the aspects related to robotics. That is, you're going to have to learn a bit of mechanical engineering to make sure your locomotion device works properly, a bit of electronics to attach sensors, and so on. If you're looking for a snap together pre-built kit where all the accessories fit into proprietary docking connectors, you're not looking for robotics.
If you're feeling gung-ho about learning to program ICs, you could do worse than the Arduino system. With that in tow, you could look here for more inspiration as far as parts go:
http://www.sparkfun.com/commerce/categories.php?c=31
The Arduino is one of the more popular open-source robotics base boards, and it's easy to program and get started with. You can do a lot before you run into the hardware limits on that, but you will have to build your robot from bits and pieces, rather than a nicely packaged kit with printed instructions. That's half the fun though.
I personally would recommend the roomba. It is supported by iRobot, which is a major manufacturer of robotic devices (military and civilian). Additionally they have created a device called the roomba "create" that is a roomba, but without the vacuum cleaner. The control of the roomba can be taken over via a serial connection, and once you get the basics down (its easy), controlling the device is pretty simple!
Since its serial, you can control it with almost any device - be it a computer, micro-controller, or whatnot!
I've done a lot of work playing around with the device myself, so if you have any questions, feel free to post back!