What exactly does Haxe export for iphone/ipads? - ios

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.

Related

Video player in JUCE (C++) - building on Windows running on iOS

I'd like to know what is the simplest way to build a video playing app that runs under iOS. I'm using the JUCE Framework that allows to develop under Windows with e.g. Visual Studio and code programs for Android, iOS, etc.
I've looke around libVLC, FFMPEG and so on. But all of these are intended to be developed under Linux, I think.
Does somebody have an easy Example for JUCE to build an iOS player app working under Visual Studio?
Coding
There's nothing to step you writing the code itself; IDEs are just fancy text editors with other tools built in (in the case of Visual Studio, a full code translation toolchain).
You'll probably find that things like code completion won't work, as JUCE will #ifdef parts of the codebase out depending on what project type you're launching, but last I checked (when I worked there) there was no Visual Studio iOS project exporter available, so you'll have to just use a Windows compatible one and program through that.
Building
In order to build an iOS app, you need a Mac. If you take a look at the documentation, it states:
For iOS projects, connect to a networked Mac and start the Mac emulator from Visual Studio.
No cross-platform library that I know can circumvent this restriction; I believe it's due to a legal requirement enforced by Apple.
With that said, if you don't own a Mac you might be able to "rent" one using a service like Mac In Cloud. I'm not a lawyer, some please make sure you check the legality of using such a cloud service for building iOS apps before doing so.
Debugging
Since you need to be able to compile in order to debug a specific build of the application, the section on building applies. Of course, there's nothing stopping you from debugging it without a build by reading the source code carefully, but I'm guessing that's not what you're asking about.

Any way to use some Scala for iOS coding?

I want to be able to use Scala to code iOS programs. Any tools available for this ?
You can run JavaScript on iOS, so you could compile your Scala to JavaScript using Scala.js. This has obvious huge limitations - I wouldn't want to try to code actual native iOS UI - but might be practical for some cross-platform logic. Combining this with React Native might be interesting.
There's also Scala Native as of a couple months ago; that should probably run on iOS. It's not ready for production use, but keep an eye on it.
Well, now you can use RoboVM - a Java library for native IOS development
See also:
an SBT plugin for RoboVM https://github.com/roboscala/sbt-robovm
A blog post aboute Scala development for IOS http://ajhager.com/
Not today, but it may be close:
http://java.dzone.com/articles/oracle-gets-java-running-ios
http://www.oracle.com/technetwork/developer-tools/adf/overview/adf-mobile-096323.html
But, while Apple directly opposes the use of the JVM on iOS devices, it will make little sense to go that way (it's still early days). You will run into one obstacle after another, and won't have any guarantee that the code you write today, will run on the iOS of tomorrow.
Sit on the sideline with your Android, Ubuntu and popcorn, and let the big guys fight it out.
In the meantime.... you can write a thin front-end in PhoneGap (which works on most modern mobile devices), your services with Spray and have fun with your back-end in Scala.
I recently developed a toolchain based on IKVM and MonoTouch that allows you to develop iOS apps in Scala. I put together a demo of the toolchain here:
https://github.com/samskivert/ios-scala-demo
Currently Codename One doesn't have builtin support for Scala but it supports Kotlin reasonably well. There is a blog post here that covers the process of adapting Codename One to support other JVM languages. By doing that you can instantly get support for other platforms such as iOS, UWP, JavaScript/Web, Android & desktop mac/windows for free.
The core of Codename One which includes the VM's, API's and most of the tools is open source.

Adobe Air ios packager

There seems to be a lot of confusion regarding deploying Adobe Air apps to ios after the restrictions were lifted. Before apple lifted the restrictions you had to go through the process documented here: http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html using the Packager for iPhone. But now that the restrictions have been lifted and the Air 2.7 update we can use the same ADT tool in the flex SDK that we use with all air applications.
My understanding is that the old Packager for iPhone (PFI) some how converted actionscript code into native objective C in order to be accepted by apple.
If that is correct does the restrictions being lifted mean that the ADT tool is not converting to objective C and is only bundling the AS3 .swf and air player together when creating the .ipa app file?
What exactly changed in the Air deployment process after apple lifted its restrictions?
If anyone could point me to some documentation on how the .ipa file is being created behind the scenes I think this would really clear some confusion.
Thanks for the help
Nothing really changed; apple just lifted the ban. The ban wasn't just on flash-created apps, it was on any tool that created any kind of intermediary language or used a virtual machine, etc. What the PFI does: it actually uses the LLVM compiler to statically compile actionscript 3 BYTECODE (not AS3 source) into native ARM assembly. So essentially when you're deploying an IPA it's the same idea as publishing a SWF to an exe (as in the publish settings) in the sense that both your SWF application and the flash virtual machine are bundled together, except instead of being an exe where the code inside is x86 ASM with AS3 bytecode executed along the VM, it's ARM. The PFI and all its classes were simply merged into the ADT tool. The PFI contained a LLVM dll which is accessed through various LLVM java classes that were added to the internal adobe version of the ASC or actionscript compiler. These LLVM classes and other associated classes, however, are not open source, which adobe is allowed to do, even though the ASC is open source because it's licensed under the MPL or mozilla public license, which permits the use of the open source code in proprietary closed source applications without sharing your changes.
For proof of all that I've told you, just download the new flex SDK that includes the ADT with the PFI merged in and you'll find the LLVM dll's etc. Further, you can decompile the ADT jar and see all the LLVM classes. The LLVM classes ( I believe ) intercept the ASC bytecode through the class GlobalOptimizer, or at least it did back in the day... they've probably changed that. The only other thing that has changed is that apparently Adobe has optimized the PFI (now merged into ADT) quite a lot. More info here:
http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html
http://www.leebrimelow.com/?p=2754
Update
Here is an official Adobe article confirming the things I've told you:
http://www.adobe.com/devnet/logged_in/abansod_iphone.html. I also should clarify that I've really over-simplified the process behind the scenes and appear to me mistaken in one of my points. I guess somehow the PFI actually merges the AS3 bytecode and the VM into a single seamless executable that doesn't use JIT compilation, and thus would technically not be a virtual machine? Not sure on that point, but the above article does seem to imply this:
"When you build your application for iOS, there is no interpreted code and no runtime in your final binary. Your application is truly a native iOS app."

Running Scala code on iOS [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/

Cross-platform development - Delphi 2011: How to made a Windows-tied library cross-platform?

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?

Resources