So I am writing a cross-platform (so far plans for Windows and Ubuntu) application for both the web and desktop.
This application
is expected to at times be moderately graphically intensive and perform a substantial amount of file IO. I am writing it in Dart. Which may seem like a
"funny" choice given the circumstances, however I did not want
to deal with any heavy API's or have two code bases (NaCl and GCC with two different libs).
In short I am using Dart to interact with an HTML web page, and noticed the Dart VM does
not interact with a webpage unless you are in Dartium. But I want a "desktop application" as well as a web application which eliminates Dartium as a choice, so alternately I plan to use a Qt Webview to make it look like a desktop app, but what I am wondering is would it be worth it to go through the trouble of embedding the Dart VM into my app? In doing so would it easily enough to get the Dart VM (running a dart script) to interact with the page in the Qt Webview (I am a bit new to Dart)? Thanks for reading!
Dartium will eventually be merged with Chromium, allowing your DART applications to run inside chrome directly as a web technology.
Once that merges, you can take advantage of the new Chrome Apps which allow you to have a desktop version of your web technologies. As such, you won't need to use Qt Webview, or embed dartVM into your native application; just use Chrome Apps.
~Main
Related
Have you already developed a Xamarin app whose views are generated from a Json recovered when launching the application?
I met a client with this kind of need:
they are developing a web app to prototype the screens by adding and positioning some controls (TextBox, Label, ...)
this generates a Json that must be interpreted by the Xamarin app: this will build the different views dynamically
in a first version, the user's data would be stored locally (through a file or SQLite) and synchronized "manually" when the device is connected to a computer
the app will work on Android only in a first time, and then on WPF
The client has not yet decided between Xamarin.Forms or Xamarin native, but it's probably more interesting to do it through Xamarin.Forms, even if iOS is not required: this should make porting on WPF easier.
Have worked on similar cases? Have you some recommendations? Are there plugins or patterns that could be used to simplify this development?
I've found this one, but it doesn't seem to be the same use.
There is also this article on iOS, but there is not the same thing on Android.
This would in theory be possible using a massive code behind builder for a page but should NOT be done for a production app. Mobile apps have very specific requirements that need to be thought of before attempting.
Xamarin is great for simplifying code reuse, and if you use Xamarin Forms you can reuse the UI components for Enterprise apps.(the less fancy and pixel perfect the layouts need to be the better. )
Your client would be better served by making it a mobile compatible web page instead from the details you have shared.
When looking up Electron and Offline HTML5, I have found it difficult to make a decision between which one to use for a project.
Assuming that a user will have to go to a certain website to download the Electron application, and would have to go to the same website to get the Offline HTML5 loaded, what are the pros and cons between using one over the other?
Some that I could think of:
Offline HTML5 can be updated without the user consciously updating their application by just making the user go to the online page again.
Electron would eliminate the need to code around multiple browser/browser version dependencies and quirks
It really depends on your exact requirements. The following is a list of everything that I came up with:
electron supports module system (i.e. require) both in main and renderer processes.
electron provides you access to OS APIs (e.g. fs). Without such many node modules will not work in the JS runtime of the browser (e.g. ip).
updating your app with electron is as easy as sending an http request. (or even better as described here)
an HTML 5 offline app requires a browser and the user might just give it IE6.
electron integrates with native desktop environment (see dialog, power-save-blocker, shell or even app for some examples)
electron enhances some of HTML5 APIs such as file API
electron lets you modify the default behavior of underlying chromium. For example you could intercept all URLs with file scheme and modify them on the fly*.
In short if you want your app to have a good native integration and act deterministic (i.e. no browser quirks) I suggest choosing electron.
*electron-jade for example takes use of protocol API to compile all files ending with .jade on the fly without the need to prior compilation.
DISCLAIMER: I am the developer of electron-jade.
(I have a problem with Google Chrome improvements that will drop support for my current solutions.)
I work on project where I move desktop system to an Intranet web application.
The crucial requirements are:
to move desktop system to a web application
to reproduce every single functionality from the desktop system in the webapp
While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:
connecting with libraries
launching desktop apps
file manipulation in background
The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).
Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).
My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).
So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.
(Both above solutions work on Firefox and IE.)
The question:
What other technology can I use to interact with a client machine from my web app?
Other remarks:
I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)
There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:
connecting with libraries like *.dll, *.so etc.
file manipulations
launching applications
And doing that across browsers and operating systems!
Solutions?
Tell your users that certain browsers can't be used (like Chrome and
Opera Next)
Write individual plugins for each browser (which probably is beyond your budget ;-)
Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)
There are lots of discussions on SO to this topic so take a read:
alternative technologies to replace applets
applet alternative launch from browser
alternatives to java applet to launch microsoft office applications
alternative-java-applet-network-drive-access
what are the alternatives for java applet to launch client programs using chrome
alternative of npapi plugins for flash java applet
python alternative to java applet
npapi alternative for live file editing
... and many, many more!
I am contemplating buying an iPad and am wondering what options I will have for developing an app for personal use ... specifically whether I will be able to do it as an offline browser app. The app currently exists as an Android Java app; it interacts with a large local database (about 3MB) and displays images and text drawn from a very large pool of resources stored locally (about 2GB).
My immediate questions are:
How would I get the files (html/javascript, database, images and text) transferred into the iPad's storage from a Windows PC? With Android this is a simple matter of hooking up via USB and using Windows Explorer. Googling suggests that for an iPad I might have to use an app on Windows called DiskAid, but this costs $25 which seems a bit steep for my simple purpose. Are there free alternatives?
Once the files are installed on the iPad how would I run the html app? On Android this appears to be a matter of keying "file:///sdcard/MyBrowserAppFolder/mybrowserapp.htm" into the browser's address box. Does th iPad browser work in a similar way.
There are two basic kinds of applications that run on iOS.
Mobile designed web applications that are hosted on a server and accessed through Safari or another browser.
Native applications built using Xcode and usually objective-c.
For the latter, you could use the phonegap framework to build an app using existing html and javascript.
My personal advice is to invest the time to learning how to code this up using objective-c. Depending on what format your db is in, importing the structure and data might be trivial. It will take an investment of time, but doing things using the native tools is the best choice for iOS development in my opinion. I was in the same situation (PHP, VB.NET and Javascript developer) and just decided to take the time and learn to do it right. This was a great decision and the development time of a simple to moderate application takes very little time now.
Safari on iOS does not support the URL's of type file:// natively. So you either write your own app, purchase an app or use something like a local web server after jailbreaking.
Alternatively, and if you can verify that the app you have mentioned does what you want to do, then maybe $25 is not so much of a price. Depends on what your time is worth :)
However there are cheaper apps around that allow to transfer and read html via wifi and usb. (Not sure I can name them here)
The USB transfer aka iTunes Filesharing is a standard function that a developer can enable in the info.plist of their app. Many apps use this to transfer data between Computer and iDevice.
Is it possible to create a complete client side application using HTML 5 (it will embed chat clients, stock ticker) + JavaScript, and then bundle is with underlining Firefox 3.5 engine, so that user can install it as a desktop app on Linux, and then it runs in its own window using firefox 3.5 engine. The app will store everything in local storage - like url, usernames etc, and will not interact with any local server.
It would pure HTML5 + JavaScript based client web app which would be packaged, and can be installed or launched from startup scripts.
Or instead of using firefox 3.5 engine, we can use Mozilla Prism to convert it to web app, and then bundle it.
Well, you should take a look at xulrunner (https://developer.mozilla.org/En/XULRunner). This is an engine to build portable applications... like firefox. You are getting full Gecko engine + full access to the environment, like a plain application. (XUL is something similar to HTML -- it is still XML-based UI description -- but it is better suited to develop desktop applications -- using native/almost native UI).
It sounds like what you're trying to do can be done with Adobe AIR (though there is no HTML5 support yet). Adobe AIR apps can be written with just HTML and JavaScript, though AIR uses the WebKit engine, not FireFox's.
The app part is surely doable (and will work just about everywhere, not just Linux), the bundling appears to be the more problematic part -- not every distro of Linux will like the specific way you built the bundled Firefox, not to mention that you're cutting yourself off from just about any non-Linux box on the planet (and every linux box with a non-x86 compatible processor, etc, etc)... all for the sake of that bundling. Can't you stop at the prism aka webrunner part, without bundling?
I'm almost sure I've seen something like this done with Qt Webkit. It was only a few lines of C++ to create the window with the web browser control and load a local page. The page created the UI of the application. I can't find the link though.
I second what liori said about using XULRunner. You can deploy your HTML application easily, and, more importantly, when you run into limitations of HTML 5 or its level of support in Gecko, you can work around it by using XUL APIs.
(AFAIK, Firefox 3.5 doesn't support any socket APIs in HTML content, and it doesn't support offline storage in web apps, only the localStorage part).