I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
Related
Apple introduced Xcode source editor extensions with Xcode 8.
Will Xcode 8 still support plugins served via Alcatraz?
Xcode 8 prohibits code injection (the way plugins used to load) for security reasons. You can circumvent this by removing the code signing on Xcode. Both of these tools are capable of simplifying that:
https://github.com/inket/update_xcode_plugins
https://github.com/fpg1503/MakeXcodeGr8Again
To work on Xcode 8+ without removing the code signing, plugins will have to be rewritten as Xcode Source Editor Extensions. Unfortunately, the APIs for these extensions only allow for text replacement at the moment, so they are not an adequate replacement.
I've filed a report on rdar, do not hesitate to express your mind as well:
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party
plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being
narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic
source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First
shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
https://github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day
without:
AxeMode – Xcode issues patching Backlight – active line highlighting
ClangFormat – code formatter DerivedData Exterminator – daily need
getting rid or bad stuff FuzzyAutocomplete – name says it all, still
more powerful than Xcode completion HighlightSelectedString MCLog –
console log filtering, including regexes OMColorSense Polychromatic –
variables colouring, cute stuff RSImageOptimPlugin – processing PNG
files before committing SCXcodeMinimap – love this SublimeText-thingy!
XCFixin_FindFix – fixing Find features XcodeRefactoringPlus – patching
Refactor functionality, still buggy, but less than Xcode without
plugin XToDo – TODOs collection ZLGotoSandbox – 'cause dealing with
your folders would be a hell without it
Most of them are not source code-related, thus deserve having a way to
be loaded and working like a charm again.
You can certainly load all your plugins by recode signing Xcode 8.0. All credits to the XVim team. They seemed to solve this problem.
https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md
The Most Important Step From The Solution
There is no support and we can't expect any. Apple decides to shut down the ecosystem around the Alcatraz package manager before they have an api ready (extensions) that is able to do what the plugins were doing before. The extensions are currently limited to the text frame which does not allow to do much.
The main reason announced by apple is security and we can now disable code signing with effort to get back the most important features that were missing in Xcode.
Bad day for the community, bad decision from apple.
I also recommend the discussion on Alcatraz here: https://github.com/alcatraz/Alcatraz/issues/475
Most importantly if you want to support Alcatraz file a bug at http://bugreport.apple.com to make them aware that many people are suffering with this change
I did the same (openradar.appspot.com/28423208):
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day without:
AutoHighlightSymbol - Add highlights to the currently selected token
ClangFormat – code formatter
DerivedData Exterminator – daily need getting rid or bad stuff
FuzzyAutocomplete – name says it all, still more powerful than Xcode completion
KZLinkedConsole - be able to click on a link in the console to open the relevant file and be faster to debug
PreciseCoverage - nicer gui than xcode provides to view the coverage
XcodeColors - shows colors in the console depending on log level (how else should a console be used?)
Most of them are not source code-related, thus deserve having a way to be loaded and working like a charm again.
If you do not make a fast step to support your community i'm sure we
will find another platform to work with.
Seems like this should work. Found some answers here:
https://github.com/alcatraz/Alcatraz/issues/475
The key seems to be to removing code signing in order to get existing plugins to work.
Apparently not :'(
https://github.com/alcatraz/Alcatraz/issues/475
We have to wait until someone convert the plugins into the new Xcode Extensions
I'm a developer in ActionScript and while I'm watching Haxe as a language to be used by me, since besides the resemblance ActionScript, still be possible to make applications with output to flash yet.
However I have a question about building AIR packages. When I search about building AIR applications with Haxe, the search does not bring satisfactory results.
I ask, after the codification and development of the code (in Haxe), how is it possible to transform what was built into an AIR package?
Thank you!
It isn't a very popular topic it seems. Anyhow, as far as I remember my experience building it some years ago, what you need would be:
If you need some air-specific APIs then you should write externs for them. There is this existing project, but it would need a bit of update as it was written for flash9, however, I believe it is doable in like 1 hour of work.
Compile to flash.
Write all the manifests you need for Air. (Sorry, don't remember what exactly it needs.)
Use this guides to package(also test and sign) your apps.
Note: If you want to go the same way you did before, you could compile haxe to as3 and be happy. However, I wouldn't recommend this method due to loosing speed and probable implications which may arrive.
I have a few questions that I hope clarity and facts can be fed all of us about this. First, the last release of ironpython had the feature of running on the mobile platform highlighting that on mono/android it runs best and not so much on the other platforms which are IOS and Windows phone. So does this mean one doesn't have to use the SL4A? Can i argue that monodroid hooks into the core of what android is capable of and so might give a more robust access/implementation/rendition of apps on android?
Next, I just want to be sure of this: As with python you can create full fledged desktop applications with ironpython right? Cos everywhere (almost) I see ironpython they refer to it as a scripting tool and how you can script aspects of excel etc which has prompted me ask such a question. some say that the speed of applications written using ironpython is not that great and I was arguing asking for why that opinion is held by those who were speaking and no one could say anything worthwhile.
Lastly, with the movement at novell and xamarin, I have not understood where mono stands in their release schemes. I have a mac and I installed a recent version of mono and when I typed ipy I saw something like mono 1.1.0 or something like that. Does anyone have a clue of what is going on with it.
I fell in love with python from learning ironpython and I think the ironpython concept is just sheer brilliance its a pity microsoft esteemed F# other it.
First off, for future reference, multiple questions should really be, well, multiple questions. :)
On IronPython for Android: it works slightly better than on other platforms (where it doesn't work at all right now) but it's still very, very early code. There are some limitations with what you'll be able to do (mainly, you cannot inherit from Java classes from dynamic code). It's very experimental.
On desktop apps: You can absolutely write full apps in IronPython. There are some samples that show how it can be done. In particular, PyWpfSample and PyGtkSample. Startup times are not great, but the actual runtime should be just fine for most GUI apps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have questions on true cross platform development and if it is possible to use ONE platform to develop software.
I have a few applications that I write that work on OS X, Windows and Linux. They all use native platform toolkits with some shared source across platforms. I have to boot to each platform, checkout, compile, etc.
I have in the past tried GUI toolkits like QT (I bought a commercial license for Win, mac, Linus, but very expensive and paying it year after year became hard). I have tried WxWidgets, development moves slow.
So what I am thinking about is there a way to run a single platform and cross compile for other platforms so I can build my products from a single platform.
I favor OS X, is there a way to write apps for OS X, Windows, Linux from OS X where I just need to test on each platform respectively. I have found information on cross compilers, stub compiling, etc, etc.
Does anyone have any thoughts? Is this even possible? Would someone make a killing creating such a beast?
In my company, we use the Mozilla Framework to develop cross platform dictionary products. These applications are based on the Gecko/Necko Browser and most of the development is done via Javascript, HTML, CSS, XSL, XUL,... Of course, our homebrew Search engine had to be cross compiled to the three platforms (with some other code which was first done in JS and then ported to moz' C++ for speed reasons).
In the end, we have a reasonnably cross-platform solution: Our developers mostly work like power web-developers (think client and server side at the same time). Because the Gecko is the same on the three platform, we know it will predictably look and behave the same way (except when there are bugs, but the platform is now quite mature on this point of view).
Our R&D knows how to port slow javascript code to rather quick portable C++ code (you do Mozilla code using the NSPR library, a cross-platform lib). Testing has always to be done on the three platform however, although with time and experience, you get to know what will break where (Font support, Audio support, Flash Support)...
Today, you should probably have a look at XULRunner which is really the Mozilla without any real browser interface (in 2002, we had to dismantle the Mozilla Browser to repaint it in our first product colour). Of course, it works well for simple applications but if you wish to make OpenGL, 3D Audio and other nifty things, XULRunner will appear too limited.
I believe Blizzard has some cross-platform framework for that kind of thing... :)
Good luck!
Pierre.
Trying to develop applications on a single platform that will be used on many platforms isn't a good approach. At best you'll make applications which feel alien to users of the platforms that you didn't develop for.
More likely, you'll run into subtle compatibility problems in areas which you never forsaw. Java is probably the best way to go if you want to go down this route. Cross compiling will lead to autogenerated code that will be a nightmare to debug and maintain.
Certainly, you may be able to use tools for porting in some cases, but I don't think that this is a problem that you can just provide an automated solution for in general.
Well, to be honest, the only guaranteed way to build an app to be cross platform in one go is to use Java, but it requires a rather large runtime to be installed first.
However, if that's not an option, I would recommend keeping an eye on recent developments in Qt - it is now available (or should be soon) under the LGPL, which presumably means you don't need to pay for it anymore. Using GCC with Qt, I've found, works perfectly when cross-compiling on different platforms, as long as you only use Qt's classes/code/objects and make sure that any non-Qt code you create or use is capable of being compiled cross-platform.
You don't mention any specific programming language (but I'm guessing C or C++ because of the GUI toolkits), so it's kinda hard to give a good answer to what you are actually asking.
If you want "true" cross platform, I would first consider if it is possible to solve your problem using a language that is less platform bound. Python, Java and plenty of others allow you to write on one platform, and run on many.
If you still want to use C/C++, GCC gives you the option of cross-compiling, and if you combine that with QT (which will soon be available under the LGPL) you should be able to get something working.
Java has tried to do the write once, run anywhere. It works well in some situations, but there are too many "unique" things in an OS. GCC provided the ability to cross-compile applications, but you run into the same sort of problems. The code will just have better performance. The RIA approach seems to work, but it doesn't feel like a native application.
Even using a cross platform GUI toolkit will not remove all your cross platform problems. There's more to an app than GUI, after all. Cross compiling will never be able to catch all the issues that a native build will catch, either. If you're going to support multiple platforms, you're going to have to at least test on each platform. But hopefully you can perform native builds with all warnings turned on, in addition to testing.
In the past few months, I found a few great videos exploring this topic of cross platform development. I hope you find them useful as well.
QTCreator
http://www.youtube.com/watch?v=aYiPvM7ZRHA&feature=channel
FlexBuilder
http://www.youtube.com/watch?v=_O_xDXRsh3Y&feature=channel
Mono / MonoDevelop
http://www.youtube.com/watch?v=U6VG_Z0aRek
I've personally had success using Silverlight / MacOS X
http://screencast.com/t/if8xenkt
RealBasic
http://www.youtube.com/watch?v=GWipoBeKSRk
For Cross Platform Development you can use Phone Gap, Appcelerator (Titanium), Corona... This all provides a framework based on JavaScript and finally able to run on different platforms. What I am using is Titanium for Mobile Development which allows us to develop applications with Native Codes.... (which is very good advantage). Phone Gap is giving a web app which is not native in general... This softwares are used for development of cross platform supports... with support on Windows, Linux and Mac OS.
Based upon my personal experience, I believe you should adopt Java: you will avoid many headaches.
You develop in whatever platform you like and you deploy in all other platforms with no need of compiling for each target platform, as you mentioned.
For example, I develop under linux, I hit "compile" only once and the resulting file is ready to be run anywhere (windows, mac, solaris, z/OS, you name it). A double click will run it on any platform (Java runtime must me installed, but most users have it installed already and if not, it's a matter of downloading, installing, "Next>", "Next>", "OK").
If you choose the "Java Web Start" deployment method, it gets even easier: the user just clicks the launch button on a webpage and the application runs (if the proper JVM is installed according to what specified in the JNLP descriptor) or the user gets redirected to the Java download page (if no suitable JVM is found).
GUI development (with Swing toolkit) is easy and powerful, especially if you use the right tool (i.e. Netbeans IDE).
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.