With Apple making changes to section 3.3.1 on the iPhone dev agreement can one stillness libraries like boost in their apps?
I want to use Boost in my iPad app...
Boost C++ Libraries, are just that.. Libraries written in C++. Nothing in 3.3.1 prohibits their use. The one exception would be if you want to use the Boost Python Library. But that would not be strictly a violation of that section. But using Python might be. It's still an open question as to the ability of Apple to enforce the rule changes. And more to the point.. If they will retroactively enforce it since there are many iPhone applications written in Python.
Related
I'd like to learn how to use the OpenCL API, however I am a bit confused about how to "install" OpenCL for development. The various articles on Google are conflicting and I suspect some are obsolete.
My understanding is that Khronos group provides the specification and then various companies provide an SDK that complies with that specification.
As I understand it you need:
The OpenCL headers, which can be downloaded from the Khronos site
The OpenCL library, which comes with the various SDKs
Is there a difference between the different SDKs? From what I can tell the options are Intel, AMD or Nvidia. I've read conflicting information about whether it matters what SDK you use - some sources say that the SDK is just for the developer and the binaries that are produced will work on any hardware that supports OpenCL while other sources say that using a particular SDK locks your application into one vendors hardware. Which is it? Does it matter which SDK I choose to use and is there a non-vendor specific OpenCL library that I can link to?
OpenCL SDKs are different. They provide tools to ease the developing, additional functions, samples, and documentation.
Every manufacturer will include what it suits best their hardware, but they all should be compatible when the app is compiled.
The ".lib" ".a" OpenCL library that gets linked into the app (the one that comes in the SDK) is the same in all the cases (except if they have different versions, 1.1, 1.2, 2.0).
This is because the library is not really a library, but only a stub to the real functions in the real driver. This also explains why the headers are all the same, they all link against the same library.
All the apps, no matter what SDK should be the same after compiling.
In the case of nVIDIA, additionally to their OpenCL.lib, they provide some functions to ease the platform acquisition (oclGetPlatformID() in oclUtils.h) and so on, that are not available on other drivers, and it is recomended NOT to use them unless you want to end up having to pack another nVIDIA propietary library to your app.
But if you really want to be generic, then you should go for dynamic library loading (dload(), LoadLibrary()). Which will make your app work even in situations where the system does not even have OpenCL installed.
You are correct, all SDKs use (or should use) the Khronos headers. You could also just use the Khronos headers yourself.
On Windows, you'd link to OpenCL.lib, which is just a static wrapper around OpenCL.dll (installed by your graphics driver in \Windows\System32). Everyone's wrapper should be similar for the same version of OpenCL. It is also supplied by Khronos (the ICD is open source) but it is easier to use one from an SDK.
OpenCL.dll uses the ICD mechanism to load the runtime(s) installed by each driver. If you have multiple runtimes installed, they each show up as a cl_platform.
If you are targeting OpenCL 1.1 (due to NVIDIA) I suggest using the version 1.1 header to ensure you don't accidentally use newer API.
While the OpenCL aims to abstract code from hardware, there are several different types of GPU architectures. These differences force writing specific code for specific hardware. Hence it is not easy to write a portable code. IMHO, you are better off selecting one hardware and utilize developer friendly SDK for that platform.
What is the use case you are trying to solve?
The binaries can be compiled at runtime (at least in Java). Therefore a OpenCL-C-runtime (?) is needed, but the compiled kernel are mostly hardware-dependent.
As you can probably guess, my knowledge of coding is very limited. Nonetheless, I do know a little Java. I have Eclipse and was wondering if I could use it to code for iOS iPhone/iPad applications. I know that I would almost certainly have to use a language other than Java, but I'm clueless as to what packages or plugins I would need to install in Eclipse to use it to code for iOS. If you guys could answer this question in extreme detail or link me to a very good sequence of video tutorials, I would be extremely grateful.
Yes you can!
If you can live with coding ActionScript, which should be easy to learn with a Java background, you can use Eclipse & AIR to code for iOS (and Android at the same time)
Some resources:
http://flex.apache.org/
http://labs.adobe.com/technologies/flashruntimes/
http://blogs.adobe.com/flashplayer/
http://flashdaily.net/
Be aware that many apps in the store have been build on this platform, and the community is pretty alive and supportive.
The short answer is, "not natively."
Apple pretty much restricts "native" iOS development to XCode which, as #Bob said in his answer, is only available for OS X. So that means no Eclipse or Java-based development. However, there are several cross-platform development frameworks and tools that work to varying degrees of quality. Here are a few, in no particular order:
PhoneGap
Appcelerator
Corona
Adobe AIR (see answer by #dogsgod)
There are others, but those are ones that I've at least heard of and might have tried a little bit. Some, like Appcelerator, have IDEs built on Eclipse, so at least the dev environment would be familiar.
IOS apps are written in Objective-C or Swift using XCode. (This also means you'll need a Mac to do so. XCode is only available for OSX.)
So unfortunately this means the answer to your question is no. You cannot use Eclipse to write an iOS app.
I am thinking of learning Haxe, after extensive as3 experience and some javascript/nodejs but several people have stated that haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
I am interested in knowing about ipad/iphone specifically. Does this somehow compile into a format compatible with such apple devices? I mean does it translate to x-code then compiles it or what?
I have various clients that want cross platform versions of the same application and Haxe looks like a simple, elegant solution but since my clients are from US, Apple products are a concern to me.
My scope of projects revolves around simple apps with server services and maybe some webcam/microphone action, if this helps for an answer. Cheers.
haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
This is a big misconception. Though as with any cross-platform tech, it's a somewhat nuanced answer.
First, know that Haxe is simply a programming language that compiles to many other language (& bitcode) targets, e.g. JavaScript, C++, PHP, python, SWF, hl, neko and others.
Compiling to C++ is the typical path when building native Android and iOS apps (and Windows and Mac apps, for that matter). Also, Haxe is just the language. Usually a framework is used for building apps, and there are many choices -- OpenFL, or its predecessor Haxe NME, or heaps.io, or HaxeFlixel, or luxe, or Kha.
Each framework is unique in paradigms and workflows, but for example, last time I used OpenFL, it exports an XCode project with C++ code when building for iOS. You are then expected to open and compile the project in XCode and onto your device (or for the app store), just like any other iOS app.
While using a framework is a common way to build apps with Haxe, you can roll your own, if you like, for example:
Compile Haxe to JavaScript, using externs to leverage existing JS libs (e.g. here's a set of Pixi.js externs, or the built-in jQuery externs), and develop mobile web apps with Haxe. Note: many of the above frameworks support a Haxe -> JS workflow.
Compile Haxe to SWF, and then use the Adobe AIR SDK to package your app as a native iOS / Android app. This avoids XCode and is possible from Linux and Windows (where compiling an XCode project is not). Perhaps this flow is what those other people were talking about.
Following the instructions on the PlayN wiki I was able to get the "hello" PlayN sample running on the iOS simulator. However, when using MonoStudio, I was told that I need to upgrade to an Indie license or higher to compile the code. (Apparently I was using 33+ features which required it.) When I activated a trial edition, the sample compiled and ran fine on the simulator.
The PlayN wiki seems to indicate the you'd only need a license if you plan on testing on a real device. Is it wrong or am I missing something?
Also, I thought the idea behind PlayN was to build a free, open source game engine on top of free, open-source technology. Mono is both, but MonoTouch is neither. Is there another option or am I stuck with shelling out $1000/year to use iOS (which so far seems far from fully implemented on the PlayN side of things)?
Right now, there isn't. Sorry its disappointing, but its the nature of iOS. Its a very non-free platform.
Perhaps you can try your hands at writing a cross compiler, and release it under an opensource license? You can try basing it on http://gcc.gnu.org/java/.
As perhaps you know already, most probably the next version of Delphi will be cross-platform. Also, here are some polls on the matter.
While writing a cross-compiler isn't a thing which interests us very much now, porting a library which was/is Windows-tied to multiple platforms, certainly does.
You can think, for example at VCL (Delphi's standard library). While it was designed for Windows only, it has value in it, and, of course, there are huge codebases which depend on it.
The question is:
Which would be the best approach to made an application / library cross-platform aware ensuring a smooth conversion / upgrade path (as much as possible of course)?
I stress it again, we are not interested which is the best way to do cross-platform development only (there were questions on this theme). We are interested also in yet another requirement: The old code base / installations management.
PS: Experiences and/or methodologies from similar situations with other languages (eg. C/C++) which are regarded as standard practices are welcomed.
Thanks in advance.
Visual component developer's perspective:
Add levels of functionality to your code, so as to be able to add another platform without changing the "Core" of the component.
The compiler hopefully will have a platform switch. (Preferable more than one, working in conjunction with each other. ex. Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).
The Layout structure might look something like this.
ComponentJ.pas
Linux\ComponentJ.pas
Linux\Gnome\ComponentJ.pas
Linux\KDE\ComponentJ.pas
OSX\ComponentJ.pas
386\ComponentJ.pas
ARM\ComponentJ.pas
As an Application Developer:
I'll start by moving all WIN API calls in my code into a group of libraries in a Windows directory as to be able to IFDEF it at library level and translate it into another platform I'd like to support as soon as the compiler becomes available, but only as I come across them.)
This will also add the possibility to add adapters easier for the new platforms.
It in any case is good practice to remove possible dependencies into a central place.
IMHO you can't build a xplatform Delphi and ensure a smooth transition for current VCL applications. It won't work. VCL was (luckily, because it allowed for great applications) designed with Windows in mind, and trying to design a compatible library working on a different platform would just mean longer development cycles and lots of compromises. The outcome will be a library noone would wish to use. Look at what happened to VCL.NET: it was the wrong choice. And it was working on the same OS!
We know that targeting non-Windows platform with native applications needs a native GUI library. We don't care about creating a GUI from scratch, for our application it's the way to go, we don't need Windows GUIs with all their standards under a different OS using different standards - we need to be able to code a fully native GUI for the target OS.
Other applications may survive a GUI porting, but in the long run you don't get a real xplatform tool - you get a tool that may compile for other platforms but brings one platform paradigms to others - and it will also be not welcome by "native" developers on other platforms. If you're a Linux or Mac developer, why should you learn how to work with a library that carries its Windows inheritance to your platform? You'd find it a pain in the ass. If Embarcadero wants to sell XDelphi outside actual developers base, it has to offer much more than a new CLX.
I will pull from some ancient experience in making a code base cross compilable between windows and dos (Delphi 1/Turbo Pascal 7). The rule of thumb was to separate code into multiple units. Try to code WITHOUT using windows, messages or any visual components. If you find you need to make a call to one of these, then place that call in another unit and write a proxy (abstract class that you descend from works well) to dispatch the calls through. When a cross compatible version is released, all that you should have to do is code the other side of the proxy for the new target.
If you're designing a form based system, then try to stick with as many of the standard components as possible. NEVER implement any "business" rules directly in an event, instead place them in another unit and call into the other unit to perform the logic.
Now, there will definitely be changes required to get your final project cross compatible, but by following these simple patterns you should be able to greatly reduce the amount of work it will take.
Experience so far has shown that the best way to get a Delphi app compatible with future versions is to stick to pure Delphi components, and use nothing third party. Such an app will probably suck, but that's how it seems to me. I use lots of third party components, and the apps are great and successful. But the chances of them moving to this future too are not certain, and that may cause problems with such changes, but I'd rather have a great app now and have the problem than have a poor app now and not need to worry about it.
Compromises should not be done too much to make VCL compatible with Linux and Mac. Windows is VCL's root. I'll prefer a new and very clean GUI framework, even though without any backward compatibility. Make VCL fatter and fatter isn't a good idea!
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
Well, look at freepascal and lazarus
I don't get it. All .NET looks the same to me providing we don't use any third party.
Delphi using standard control is already fully functional but your app would look
like thousands of others.
I think Embar should go for PDA, IPhone, Andriod as Windows desktop already eat about
98% of the market.
Mac is expensive and Linux is no cost at all. No use to go for Mac and Linux. Not worth
the investment.
Well, aside the things said - thanks all - I do think that there we need some additional things:
we need tooling to do the necessary conversions
we need tooling to help us in programming against a (some form of) MVC pattern
Simply pick the latest 4.6 QT and add good integration betwen the Pascal and the QT library.
They have done it before (in the Kylix times). The QT is such powerfull these days.
I believe that QT is even better then VCL and at least 10 times more frequently updated and fixed.
So the plan is simple:
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
and you will have a first-class natively looking applications on all platforms.
My opinion:
Make cross platform compiler (OS x/Linux/ embedded solutions?/ symbian?). Maybe add ability to compile/convert pascal code into portable c/c++ code to build then on embedded platforms.
RTL have to be separated into cross-platform layer and native layer (as for JCL).
Add new core components for cross-platform compatibility and native components for each supported platform (QT for ex)
Add translation utilities to create/convert between platform's components, for ex: to convert pure windows form into mac os x cocoa's form.
All windows hierarchy of components have to be only upgraded to support x64 with maximum backward compatibility. All cross-platform component have to be in parallel hierarchy.
Next version of cross platform solution can be refactored and can include migration/convertion utility. Due to minimum codebase of cross-platform solutions, hierarchy and classes for cross platform can be heavily changed from version to version to achieve best architecture.
sorry for my English - not a native language (Russian is)!
Make C/C++/Delphi compilers that targets OSX/Linux
Make C/C++ compiler that can be Boosted
Write new VCL-Presentation Foundation (VGScene/WPF alike)
it should not be backward compatibile! Delphi IDE should be
written with such VCL-PF
Component Library should stay as it is (but with improved Data-Binding)
Only provide VCL 64-bit for Win64
Is this a problem?