I'm interested in the following features:
Writing an app for Android Market that is written completely in C++ (a port of existing product actually).
Use fast screen-buffer pixel pushing (or rather using OpenGL ES for this).
Grab user input and direct it to C++ code.
Is it legal to write such an app for Market? Is Market policy somehow strict to such things?
As of NDK r5 with Android 2.3 (Gingerbread) this is possible, although I assume only devices to support natives apps must have Gingerbread on them.
From the native-activity sample:
The Android SDK provides a helper class, NativeActivity, that allows you to write a completely
native activity. With a native activity, it is possible to write a completely native application.
NativeActivity handles the communication between the Android framework and your
native code, so you do not have to subclass it or call its methods. All you need to do is declare
your application to be native in your AndroidManifest.xml file and begin creating your native
application.
It is really not my cup of tea but there is something called Android NDK (Native Development Kit) to use if you want to write your program in C. Not sure how the C++ compiler support is though.
As far as I know your app can be almost 100% native code but keep in mind that by walking that way you will probably have a hard time supporting the different CPUs out there in Android hardware. If you need to bootstrap the native code so that it is started from java it is probably not a very big problem for you.
I found a few different tutorials when googling for "Android NDK". This one is a very minimalistic Hello World. Obviously you want something much more than a library that returns a string to java but it is a good first start and you will probably have to do all of the things described. Do a search using NDK and Android as keywords and you get a good selection. I see no reason to list them here as such lists tends to be outdated and broken within a year or so.
I guess the official Android Developer site from Google will stay put and be updated on new releases of the platform, it has a link to the current NDK.
With Gingerbread (Android 2.3) it looks like you can build your entire app in C++.
cf:
http://phandroid.com/2011/01/11/android-developers-blog-awesome-ndk-leads-to-awesome-apps/
"
With the latest version of the NDK, r5, many big improvements have been made to coincide with the release of Gingerbread. The most major is the ability to code a native application for Android 2.3 entirely in C++. This means even programmers and developers with no Java knowledge won’t have to implement a single line of that code..."
Can't vouch for the veracity of this blogger, however, from what I have read, it appears you can do this
There is no 100% native solution but what I think you are looking for is the Android NDK (Native Development Kit)
From their site "Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine."
I believe it lets you make calls to your own native code from an Android application
I have personally never used it for my games, but I am sure it would help on a lot of things (like being able to manage my own memory and not have "lag" do to the garbage collector)
conversations in this thread can help you.
http://groups.google.com/group/android-ndk/browse_thread/thread/50362904ae0574cf
essence is,
It is possible to make Native only apps and Android Market doesn't restrict you either.
But with limited support for native development, there is high chance of using some of the non standard functionality which might break in future releases.
http://developer.android.com/guide/basics/what-is-android.html
"The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language."
http://arstechnica.com/open-source/news/2009/06/android-goes-beyond-java-gains-native-cc-dev-kit.ars
In general, you don't. There is some limited C++ support through JNI, but it is mostly intended to supplement Java code, not replace it. There's no framework/API support (AFAIK) for C++, so doing this isn't really an option.
Related
We are trying to create an Application for all mobile platforms (Android, iPhone, Windows phone). We will build the User Interface using the native development languanges for each platform (Java, Objective C, C#). For the intermediate layers (DataAccess Layer and Business Logic Layer) we plan to use C++ for all platforms.
We are going to use libraries like Curl, sqlite3, libzib. So I think a good solution would be to create two seperate C++ projects (DataAccess and Business Logic) and make references to those libraries we need. First we are going to start with Android, so I will include those two projects as prebuilt static libraries using Android NDK and in the jni folder I will add some methods that they will communicate between UI and Business Logic. Later we will do the same for the other two platforms. Since I am very new to C++ I would like to make the following questions:
Do you think that this theoretically will work?
What problems are we going to face (e.g debugging, using Curl in different operating systems)?
Are there any open source mobile projects using the same approach?
Do you think that this theoretically will work?
Yes, I've written and app for Android and iOS that uses a data access layer written in C++ on both platforms. I wrote the Android edition and a colleague wrote the iOS edition. It is not open source, so I can't show you the code.
What problems are we going to face (e.g debugging, using Curl in different operating systems)?
Debugging the shared C++ code can be a pain in the ass on Android. I've never gotten the debugger for work on Windows. I normally resort to careful reading of my code and printing messages to LogCat if it is not something I can reproduce and debug on iOS. Normally this only affects the JNI layer that links the C++ business logic and the native UI code.
You'll probably have to build 3rd party libraries separately for platform. Curl has instructions for building it for each platform so that shouldn't be much trouble.
Apart from learning JNI, the biggest problem I had was that the app had to look the same (or very similar) on each platform. I'd recommend looking into Qt Mobile Edition as
πάντα ῥεῖ suggested, however it doesn't currently support Windows phone. Still, you would be able to write one UI for two of your three platforms at least - and your shared business code would still be reusable. We are in the process of starting a second app and Qt is definitely looking like the best option for us. I don't think we'd want to repeat the experience of trying to provide the same functionality on two platforms using very different APIs.
Are there any open source mobile projects using the same approach?
I'm not aware of any off-hand, but I'm sure you can Google it.
I am contemplating designing a framework to allow for one C++ code base to become a desktop application and a web app for most major platforms (Mac OS, Windows, Linux, and possibly Android). I have decided Qt would be best for desktop builds, however I am conflicted between Google Native Client and Wt for the Web App part.
Wt code may be more easily compatible with the Qt code, however I heard Wt is actually AJAX output so I do not know how much this will impact performance (I plan to develop a game engine with this so I need performance).
On the other hand NaCl, is more, well... native. But it seems to be a mess, especially with the JS integration, I just want to write in C++ and be done with it. Additionally I don't know how compatible it would be with Qt.
I have been researching this for weeks and I do not know much about either. So it really boils down to:
A: Could I literally (or pretty much) replace all the W's in the front of the names of all Wt objects with Q's and have it be Qt compatible code?
B: Is Wt native at all, and how fast does it execute at run time (I cant seem to find an answer to this)?
It would be possible to run Wt as a NaCL application as well, in fact, that would combine the best of both worlds. Wt itself (and its dependencies) build fine with the NaCL toolchain, it's only a connector library that is missing currently. There was an opening for a GSOC project to implement last year, but it didn't happen.
First off, greetings everyone and thank you for your interest in my question.
I'm currently working at a mobile startup. Our product is a communication app for Android, iOS and BlackBerry devices and we're looking to expand onto some Nokia platforms.
I don't know a lot about Symbian details as I've never actually programmed in the platform before but this is all of the information I was able to gather.
The platforms to support are Symbian S60, Symbian^3 / Symbian "Anna", Maemo + Meego.
In order to accomplish this, there's several tools at our disposal but we're not sure which ones to use.
Nokia Qt appears to be unsupported on Symbian S40 devices (we seem to be stuck with J2ME) and Symbian S60 devices pre-3rd Edition Feature Pack 1
On Symbian's C++ we can't rely on C++'s STL. This means that we can either create two versions of the same software or create our own STL that's compatible with Symbian (I'd like to avoid that).
Approach
Among the team the consensus seems to be to split this into two logical chunks:
Core business logic + libraries in C++
Device specific UI branches using Qt or native UI tools
With all this information in mind, I ask:
What is the general approach for this problem? Is there any considerable flaws with the one mentioned, namely incompatibility or inconsistencies with Qt on older platforms?
What pitfalls should we avoid to ensure compatibility and performance of the app across all Nokia devices listed?
Is there a way to get around Symbian's C++ limitation of the STL? Can we bundle the Qt sources somehow?
Suggestions and other approaches are welcome. Thank you for all your feedback.
You should consider that Symbian is a dying platform, so I would not invest huge development effort into a Symbian application. And even more so I would not use Symbian C++. Qt is a promising platform but Nokia/Microsoft announced that there will be no Qt port for Windows phone (which might be interesting for you).
Maybe you should support Nokia devices only by Java ME because Symbian has big market share but the most devices are not smartphones where you can run a Qt app.
Your approach sounds very idealized, but I am not sure if you can use the C++ libraries you mentioned for the business logic from Java ME. Is that possible?
There are STL implementations that are possible to use on Symbian.
I was once part of a team hat used a C++ core (with STL) on Symbian devices ranging from S60v1 to S60v5 as well as UIQ, S80 and S90. The same core was also used on windows mobile.
We used STLPort for the STL implementation, but I have been unable to find that specific version again. I do believe there are other Symbian STL implementations out there.
On the other hand S60 device have a very competent J2ME runtime, so if you have to develop a J2ME app for S40 devices you might as well use it on S60 as well.
I am not more experiences as you but according to me Qt is good for Application development.Write code once to target multiple platforms
Qt allows you to write advanced applications and UIs once, and deploy them across desktop and embedded operating systems without rewriting the source code saving time and development cost.
Thanks
2 questions:
Can someone tell me if unmanaged c++ code will
be supported in future versions of Phone 7 OS for all developers?
What are MS reasons for not
supporting unmanaged c++ code?
This answer is purely speculative, but I feel that most others who have answered this question miss the point by a long shot. Let's for a moment assume that this is not a vindictive decision by Microsoft, but instead actually a very well thought out engineering decision that has absolutely nothing to do with content restrictions or otherwise. Those issues are just a bonus for MS
Microsoft is entering into the mobile market, this time for real it seems. Pretty soon there will be tens of millions of Nokia phone being shipped using Windows Phone and whatever they get on top of that will just be gravy. Windows Phone though still hasn't really found its home.
In the next year or two, phones, tablets and laptops will finally start converging into a single device. People will carry their phone in their pockets, but that phone will also be the CPU unit of their PC. That means that by simply sitting near a wireless HDMI monitor and connecting a keyboard and mouse via wireless USB (or bluetooth if we're all unlucky), the user will have their entire PC with them at all times. Tablets will become just a battery powered touch screen which interfaces to the PC in your pocket.
So, all software written for Windows Phone should be able to run unmodified on a PC, a tablet and/or a phone. This is because there's a huge chance that the PC you're running will be either x86 or ARM based running Windows 8. When the PC is in your pocket, the user interface you'll see will be the Windows Phone GUI. When you're hooked up to a monitor, you'll see the ribbon interface. But the underlying OS will most likely be Windows 8, not the Windows CE that is currently used.
Based on all this, the only way Microsoft can insure that developers who invest in producing apps for the Windows Mobile market will not be screwed and that users of Windows Mobile devices won't be shorted when the newer platform comes around is to ensure there is a standard system for running apps on all these processors.
Even now, writing for Honeycomb is a nightmare since if you develop native code, you have to support both ARM and x86 and there's no real support mechanism for it. The only solution is to develop, package and ship two versions. Writing apps for iDevices are a little easier since there's no overlap. x86 on desktop, ARM on device. If you have to use native code on device, ARM is all you need. Even then, there is fat binary support on both device and desktop, so this won't be a problem except when optimizing.
In the end, the decision by Microsoft to stick strictly to .NET is probably a good one. Once they have a gazillion Nokia phones on the market and things have settled a bit, native code could be a real possibility.
These answers are for the application development perspective. OEMs can write native code today, as that's how they create drivers, but that's not open or available to most developers and therefore of no use to most.
For #1 Microsoft has made no announcements, so only Microsoft knows the answer and they're not saying.
For #2 it's all about code security and overall platfrom stability It's very tough to sandbox native code and they don't want your app being able to affect other apps or the platform itself. The general idea is that you should be using Silverlight or XNA for application development, so that's what they expose.
Windows phones will go nowhere with native support. Games and other more intensive apps are driving sales. Android was forced to blow the lid off of its NDK to support the games industry. As far as supporting multiple processors, etc., those of us doing this kind of work have been doing it for a long time, so its no problem. Already handling Intel and ARM without a problems with our systems.
EDIT, finally: for WP7 unmanaged code won't ever be supported, but in Windows Phone 8 - yes it will! They've just announced it. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. Looks like VS2010 is not getting the requisite WinRT SDK.
The nongame UI, however, will still be XAML-based. Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it.
SDK will be available later this summer.
For the sake of posterity, here's the pre-06/20/2012 answer:
Microsoft probably can.
To ensure platform closeness, as a means for attaining stability and UI consistency. To enforce app isolation. Also, to make jailbreaking/rooting harder.
EDIT: if you want a native SDK on WP7, like I do, please go sign this petition and/or that petition. Thank you!
EDIT: see this.
EDIT: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.
I believe MS will support native development like C/C++. Really. Seriously.
Because, for end users, one of the killer app is game. And Most of game codes are based on C/C++. JS or C# based codes are exist, but meaningless from industrial perspective. Consider big players in game field like Unreal or EA. They made huge investment on C/C++ codebase. They won't give it up. In other words, MS has no power to force them to spend money for .NET. Even Xbox360 development offers C/C++ development. Because of that.
And leading platforms like iOS/Android all supports native development. WP can't bear up the situation without any game from big players. MS really wants 3rd path games, and offering native code is the only way to get them.
Of course, this can be applied to other apps which are not game, but games are biggest one. When C#/XNA just came out, there's no library. People had to make everything themselves. Now there're a little more, but still meaningless for professional games.
If MS won't offer native environment, just don't go there. MS wants to make developers to use managed .NET code, but .NET has too many limitations can be solved with only unmanaged code.
The only question is just when will MS support native development.
Just in general terms, for a noobie. I apparently need an 'SDK' to install something; what is this?
An SDK is a set of libraries which hold reusable code that you in turn use to develop applications. Whether those applications will run in Windows, on an XBOX, and iPhone, in a Flash application, etc. determine what SDK you should be using.
Take the iPhone for example. To write an iPhone application, you write code in a language called Objective-C (which looks and feels just like C, but with Smalltalk's object-model). Anyway, every time you write an app, you don't need to rewrite the code that draws text on the actual screen or registers the actual screen-touches. Instead, Apple provides the code that all application developers will need to do simple things.
Likewise, if you're writing for Windows, there are libraries to do things like draw an actual window, or connect to the network stack.
All of these common libraries, along with some other tools, make up an SDK.
For C++, you will probably see a lot of mention of Boost. This is not an SDK, but rather a set of libraries that contain code that a lot of other developers find useful.
What platform are you trying to write for? Are you just getting into C++ in Windows and looking to get started? Are you trying to write a game for some console?
"Software Development Kit" - a set of tools and libraries that let you develop software.
An example would be the iPhone SDK, which lets you develop software for the iPhone.
An SDK for a given product in general includes what you need to create an interface or an application based on that product. That's why "software development kit", a set of things needed to build software. It is strange though that an SDK is necessary for an install, could you provide more details?
An SDK is a tool kit that helps you develop software for a certain platform.
Help us out with some context! We might just be able to get you the correct SDK.
The OP indicates that the SDK is needed to install software. If this is the case, then maybe the OP is really asking is "Why is an SDK needed to install software, given that I am not developing (compiling) software?"
The OP tagged the question with SDK, which provides a definition and if the OP took the time write the question, the OP would in all likeliness Google SDK.
I suspect this is a case where moderators could have helped the OP to refine the question.