I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
Related
I am considering making a small app for desktop pc's. I would mainly like to have support for mac and for ubuntu (linux) and I wouldn't mind support for windows as well. An easy way seems to develop an app using Unity, but it is more known to be an engine for games.
To my simple logic, there should be no reason why an app cannot be built with Unity. A platform that features the ability to create massive laser marine gunbattles should be capable of rending pretty buttons and a user interface. The plus side is that with unity you can port to all platforms that I would like this app to run on as well.
Am I making a bad assumption? Are there any people that have done such things? The app I would like to make might be open source, does the Unity platform limit me in any way here?
You are correct in your reasoning that it is possible to make a normal app with Unity, but this of course is not what Unity was intended for. It is geared towards rendering and updating scenes (including physics, game logic, etc.). If you do not need the notion of scenes in your app, then you will add additional complexity to your development and run-time overhead that you would not normally need.
Another drawback is that you will need to abide by Unity's licensing with your app which may or may not be an issue for you (https://store.unity3d.com - See links at the very bottom for other special licenses, such as for gambling).
Since you mentioned Unity specifically, it uses Mono for some of its run-time support across platforms. Perhaps you want to consider using just Mono and associated tools instead (http://www.mono-project.com).
This one is a quick question regarding the possibility of having the same LnF (same look) on Android and iOS, is there an API that can provide something like this? SImilar to MAUI in MoSync or IwUI in marmaladeSDK?
Basically what I would like to do is to create my UI once for both iOS and Android using monodeveloper.
Note: Before anyone downvotes anymore, please take into account that this is a real requirement for a real project. The question is not without reason, since after looking at the documentation, I can see that Xamarin does not provide such solution, but other multi-platform SDKs do provide such solution, and since the mono ecosystem is vast, perhaps there is a third party library that can provide such functionality.
Unfortunately most of your code portability will be on the backend (non UI) when leveraging Monotouch. There are far too many inconsistencies with how an Android UI vs iOS UI are implemented respectively to their OS's.
Have you checked out http://ifactr.com/overview ? It is a paid product so I haven't tried it, but it might be at least work looking into. Other than this, no there is no cross-platform UI if you go the Mono route.
Taken directly from their page:
"But we learned that even with as much code sharing that MonoCross provides, for applications with significant UI layers, the burden of creating platform-specific UIs can be overbearing. So we created the iFactr UI abstraction layer, which allows developers to code to an abstract UI interface, and then reference our iFactr concrete implementations of that interface for all the mobile platforms, both as native UI implementations and HTML5 UI implementations.
While not a silver bullet for all mobile development, it is designed and optimized for rapidly creating data-driven UIs that enterprise users tend to demand. And because it’s integrated with MonoCross, you can mix-and-match your iFactr UI screens that are shared across platforms with screens that you can code to target specific platforms using the entire set of native APIs available on each mobile OS."
The problem is Android and iOS have different UI / UX metaphors.
Take this for example: http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-6-and-android-4/
The differences are fairly significant. If you use a development wrapper then you'll have to 100% rely on their tools. We've had experience with Titanium in the past and it wasn't good at all.
What is the difference between Metro apps written in web-development technologies and ones written in XAML/C#, etc.? Does Microsoft Metro API provide hooks for Javascript, where it's all native for C#? Should they work hand in hand, or is it the developers choice which route to go?
Is there certain functionality that cannot be implemented if using JS (other than OpenGL hardware capabilities)?
The reason I'm wondering is to know which technologies are necessary for building extensive Metro apps, so that when I get to a certain point I'm not stopped by a brick wall, letting me know that I used the wrong technology.
Microsoft has put in a lot of work to make Javascript a first-order language on par with C# for WinRT development. Both Javascript and C# have direct access to the WinRT API via language projections. That is, there is a unique binding specific to the language to the underlying API. So neither language is any more "native" than the other.
You should be able to write an equivalent Metro app in either language. At a high-level, it really does come down to which language/environment you are more comfortable with.
However, there are a couple of differences that should factor into the decision. First, WinRT components can only be written in C# or C++. Javascript can only consume thse components. If there is an intent to create reusable/shareable components, should keep this in mind.
Second, although the Windows Phone 8 SDK has not been released yet, there are indications that Windows Phone 8 apps can only be written in C#. If there is an intent to create similar apps for both the tablet as well as the phone, this is probably a serious consideration.
There haven't been a lot of performance-based studies comparing the two in a Metro app, so it's hard to say whether that will become a factor or not.
Then, there is also 3rd-party support to consider. C#/XAML is well established and has a lot of 3rd-party support. But similarly, Javascript has a lot of 3rd-party libraries available (e.g. jQuery) that for the most part can be brought in and used in a Metro app as well. I would give a slight edge to C#/XAML, but it seems like support is good for both.
I've been looking over Sproutcore, Ember and Blossom and other competitive framework efforts (e.g. Sencha) to select for a HTML5 client side application project. The state, information, and documentation from these projects is a bit fragmented and in need of clarity, so I am presenting this to the community.
My project is to be a native-like HTML5 application with desktop level complexity in need of a complete application framework, that will work well on desktops and run with good speed on mobile devices with touch awareness. The widgets should be native-like (not web-like), but customizable so to be unique to the application.
Questions/framework Requirement:
Native vs. Web style Applications. Framework should make it easy to
build native-like user experiences with the ability to make a custom
native feel (not just wholly imitating mac/win/iOS). Some of the text
surrounding Ember indicates it is really meant for web-style apps - which given no
UI layer maybe goes without saying. Frameworks like Sencha, can it easily accommodate custom widgets?
Mobile Appropreatness. Framework should be appropreate for mobile devices and have facilities for touch input and
gestures.Several notes I've seen in my research indicate that Sproutcore and
Blossom aren't very appropreate for mobile, and that Ember is better
geared towards mobile (size?). It isn't clear whether the
touch/mobile libraries are very developed in Sproutcore/Blossom and if they will be supported it the
current state going forward. (and blossom compile to native is not acceptable). On the otherhand, Frameworks like Sencha, do they have the facility to work well on desktop as well as mobile?
Framework Completeness. The framework should be a fairly complete application framework, with desktop-like OO expectations and management for automatically and efficiently syncing, managing, and serializing the data model with the server. Not sure if there is much difference between Ember and Sproutcore, how do other efforts like Sencha stack up?
Your question covers a lot of ground. I will pick some quotes and answer them directly.
My project is to be a native-like HTML5 application with desktop level
complexity in need of a complete application framework
Ember.js specifically bills itself as a "web-style" framework, not a an RIA framework. That said, you can build anything you want, but you would be trailblazing.
Sproutcore bills itself as an RIA framework. You have complete control over the DOM, so if you can do it in the browser, you can do it in Sproutcore.
Ext-Js is also a good application framework for desktops (Sencha Touch is for Mobile). If you like the way its examples look, then its a good choice. You can of course customize the dom and write your own widgets.
Blossom is basically Sproutcore with a canvas based view layer. It just went into beta, so you would definitely be trailblazing if you went with it.
So, you can basically use any of the frameworks you mentioned for the RIA part of your enterprise. I would eliminate Ember.js simply because the framework itself purposes itself for web-style (e.g. twitter) as opposed to RIA (e.g. iCloud) apps, which is not what you want.
The widgets should be native-like (not web-like), but customizable so
to be unique to the application.
All three of your remaining options can do this. If you like Senchas widgets, its a good choice. I don't know if they are native enough for you. That said, with any of the remaining frameworks you can customize the DOM to your heart's content.
Mobile Appropreatness. Framework should be appropreate for mobile devices
This is a tough one. Sencha Touch (which is separate but similar to Ext-Js) is very popular and gets the job done. It is performant too; a non-trivial app ran fine on my original Droid (which surprised me).
Sproutcore is very heavy weight. It has mobile support (i.e. for touch events) but you need to very careful about the dom you create, so as not to overwhelm the browser. I wouldn't choose Sproutcore for mobile, although you could if you are very careful.
and blossom compile to native is not acceptable
That does not seem reasonable to me. To be clear, NONE of these frameworks run natively on mobile devices; they ALL run in the browser. Blossom comes closes as the canvas API is mapped directly to the native API, giving you a truly native app. The only way you could get closer would be to use objective-c/java for iOs and Android.
So basically, at this point your left with Sencha(Ext-Js) and Blossom. Blossom is still in Beta, you would be trailblazing if you tried it. Sencha is established, has great support (Blossom support is good on irc), and a large developer base.
So Sencha is the choice, unless you really want to be cutting edge, and take a little risk.
Troy. Indeed, ember can run with another view layer framework such as jQuery Mobile which can provide a "app-like" look and feel.There is a github project: https://github.com/LuisSala/emberjs-jqm. In my view, if you need very cool animation you can use blossom.If you want to build a app, SC or ember should be OK. I'll choose ember because it 's loosely coupled.
I've been thinking to give GUI development a try lately and am torn with the choice of between wxPython and Mono.
Judging from what I've seen out there, wxPython people seem to use the WebKit trick to produce nice (doesn't have to be beautiful) UI.
How hard is it to do the following in each of the platform:
1) Custom Control
2) Use HTML rendering
I don't quite understand how far the HTML rendering works via WebKit in wxPython (i.e.: does it support separate CSS/JS files? how's the JS support? do we need to write extra wxPython code to run the JS? how hard it is to integrate between JS events and wxPython widgets? what are the usual strategy of integrating WebKit with wxPython?)
Mind to share your thought on this subject? I specifically pick either wxPython or Mono, not Java Swing for no reason.
PS: I'm aware of certain limitation of cross-platform UI (as in: it won't be 100% native) and I could care less of such things.
wxPython has wxWebkit available via the new WebView widget, but WebKit is only available on Mac and Linux right now. WebView uses a different rendering engine on Windows called Trident from IE (see http://wxpython.org/CHANGES.html). So you'll want to keep that in mind.
Either way, we're talking about browser engines that display HTML, CSS, etc. They should, theoretically, display whatever those engines support. You'll have to look up their specifications to be sure and also make sure to check if the port supports everything. As I understand it, they should definitely support the usual HTML and CSS and I would assume normal javascript. If I were you, I'd just create a simple window in wxPython and then load the web page you've created and see how it works.
I don't know how the javascript communicates with wxPython or if it even does. You'll want to ask on their mailing list for that kind of information.