I need to provide support for various scanners and printers to an Intranet web application. Basically the user needs to be able to take pictures using his webcam or camera, scan using his scanner and print through his printer. Because this is an Intranet application, compatibility is not an issue. I can ensure the user has all drivers installed. But the client insists that the application should be embedded inside the browser and not run in a native window. All client machines are Windows PC, but the client is flexible with browser choice.
I am thinking about writing an ActiveX control. But then I am not sure if I am using some 90s technology when better technologies might be available. Therefore, is there anything else I can look at? If I have to write ActiveX, can you point me to a good sample app to start with? I am very comfortable with C.
You could use .htc extensions on Html files. This puts the website in a different sandbox which allows for more access on client side functions (eg. execute commandline software which connects to a printer or scanner...)
Related
I’d like to develop Windows 8 applications and have them hosted on Azure as if they were any other website, i.e. accessible to Macs, PCs, etc. I don’t want to be limited to people downloading Windows 8 applications to a Windows 8 PC or device. Can you explain how Azure achieves this?
I’d like to develop Windows 8 applications for desktops, but not be limited to running them on Windows 8 PCs and devices.
Thanks
Azure doesn't achieve this at all, other than providing a public endpoint for access to 'code'. What you have up in the cloud will depend on what you want to achieve and who you want to reach.
You mention web site and application, but those connote two very different architectures.
A web site will give you the most reach since you'll (presumably) be using standards like HTML5/JavaScript and CSS that are available on a multitude of platforms. As you can see by using applications like outlook.com, the user experience can be quite immersive. With a web site there's little to no client-side requirements other than a browser.
An application typically implies native installation on the target machine and provides the richest possible experience because you use techniques, frameworks, and APIs that are specific to a platform or a device. Applications also (arguably better than web sites) enable reach and monetization via marketplaces like Apple's App Store, Google Play, and the Window Store.
Technologies like Silverlight and Flash were part of the RIA wave (Rich Internet Application) that was a hybrid of both: use the web for reach, and a plug-in for richness. Those are still valid models, but the tide is shifting to HTML5 which is now much closer to reality and narrows the user experience gap that Silverlight and Flash filled. While Silverlight is definitely supported (in an out-of-browser mode as well), the choice of using a plug-in technology will limit your audience because of platforms supported and the need for an additional installation. That may or may not be acceptable given your target application.
What we are seeing now is a trend toward mobile application development paradigms - native still, of course, but also hybrid applications such as afforded by PhoneGap, AppMobi, Sencha, and other HTML5 frameworks and cross-platform options like Xamarin. Each of these allows you to develop in the language and constructs you know well for a given platform, but create applications which are partially or wholly 'native' and can run on multiple devices and platforms. Typically, you will reuse much of your 'back-end' and data integration layers across you targeted platforms, but rework the user interface to be in-line with the expectation for the device.
Windows Azure figures prominently in the development of such apps by providing infrastructure for data storage, services, identity management, push notifications, and other facilities that rely on centralization and scale.
And I suppose there's one other option in all this, virtualization, but that's a larger hurdle for end users and wouldn't recommend that as a general approach.
You can create Silverlight apps, it runs in browser. So it can be open Windows PC as well as in Mac. Do visit Microsoft Silverlight website. Here's few links regarding Azure with Silverlight.
Silverlight in the Azure cloud
Microsoft Silverlight 5 and Windows Azure Enterprise Integration
Windows Azure with Silverlight End To End Demo
More you google, more you will get results.
I have a mobile web app running as client-side JavaScript using Opera Mobile 10 on Windows Mobile 6.5 Professional (on a Motorola MC9500). (I've tried IE Mobile 6, but it doesn't support the canvas element nor enough JavaScript to be useful for my purposes.) I need this app to exchange messages with a native app on the same device. Because JavaScript is sand-boxed and I don't have access to ActiveX, it seems that one way to do this is to send/receive messages via AJAX through an intermediate server on the same device. Does anyone have a recommendation for an HTTP server that will run on Windows Mobile 6.5 Professional? This server should be able to cache the messages with persistent storage, e.g., SQLite.
I'm currently looking at PocketHPH, a PHP server. I have also found Padarn, an ASP.NET web server. I welcome any suggestions on small web servers that are better suited to this task.
Thanks.
Here's some clarification of my original question. The original web app is running on iPhone using Safari. It's a pretty complicated JavaScript app which I didn't write. So I'm trying to move it to Windows Mobile without having to rewrite the thing as a native app. The reason I'm moving it is because we're partnering with another company that has an existing native app that must run on an MC9500 which runs Windows Mobile 6.5 Pro. So I don't have any control or access to the code of the native app. However, our web app must exchange messages with the other company's app. Hence, many of the constraints, e.g., I can't use IWebBrowser2 from the native app. The other company's developer could try, but it doesn't look like he's going to go for that because there are much smaller things that he won't do. My understanding is that I can only use ActiveX from IE Mobile, not from Opera Mobile. However, there are several JavaScript features that IE Mobile 6 doesn't support. So I might be able rewrite the entire JavaScript app to make IE happy (I had already done quite a bit of rewriting before switching to Opera Mobile which has a much better JavaScript engine), but it would probably be easier to just rewrite it as a native app. It might be possible to engineer out the canvas element, but again if I'm going to do that, I might as well bite the bullet and rewrite the whole thing as a native app. So much for trying the "easy" route of porting to another web browser.
I think PocketHPH is giving me what I need. It is a compact PHP server that runs on Windows CE devices. It includes SQLite3. It is working on my Windows Mobile 6.5 Professional device: a Motorola MC9500.
You can download it here: http://mobileleap.net/hph/
However, it looks like it hasn't been updated since 2007. So it might be a risky thing to rely on.
I have been able to send/receive AJAX requests/responses from a web-based Javascript app running in Opera Mobile using Cross-Domain Messaging. I wrote PHP for the server that stores/retrieves the messages to/from the SQLite3 database.
One problem I'm having though: the AJAX cannot connect to the server when the device is offline, even though it is entirely a local connection. For more info: https://stackoverflow.com/questions/9307745/cannot-connect-to-127-0-0-1-when-offline-using-windows-mobile-6-5-professional-e
I need to create an application that is primarily going to be about numbers and graphs, as well as UI controls to select information and input choices, filter lists, etc.
The application needs to be available as:
a) A web application so that a user can use the application via their browser
b) Downloadable, so that the user can use it without internet or browser - windows being the most important platform, followed by Mac OSX if possible.
Are there any recommendations for this? Either Microsoft or open source solutions I am interested in considering.
I believe that the Unity 3d engine is capable of this, but I think that its focus on game development would get in the way too much for an application that is interested primarily in standard GUI controls.
Thanks!
Silverlight supports out of browser applications on Windows and on the Mac so it can run in a browser and out of a browser in Windows or on the Mac.
There are graph controls available freely from Microsoft and there are other third party controls.
I'm in the design phase for a desktop-based application. Because of the nature of this particular application, I believe it would benefit greatly from a web-based approach (i.e., allowing a user to interface with the application through a browser running in kiosk mode) in order to leverage the simplicity of HTML/CSS/JS and the availability of many great JS interface plugins. Does taking this approach (rather than coding in a native or cross-platform graphics library) come with any gotchas?
Well, your access to the OS and other domains are going to be limited.
What about using something like Adobe AIR that lets you use HTML/CSS/JS and compile it into a proper desktop app?
Please look at http://www.terrainformatica.com/htmlayout/ - the library which was designed to create desktop GUI using html and css.
The main "gotcha" to doing a web GUI is that you are going to need to set up a web server of some kind. A gui app can be just a single executable. You allso (probably) will need some GCI coding to get information back from the user to your program. In general, it is liable to be a whole lot more work.
Balancing against that is the fact that any user networked to your webserver anywhere in the world using the OS and browser of their choice should be able to operate your program.
How can I use the browser as a UI for a desktop app? The ways I have come up with so far are...
Use all HTML/Javascript. Problem: Can't access filesystem or just about anything else.
Run a local webserver while the application is in use. Problem: How do I kill it when the user is done? My users are not technical enough to Ctrl+C.
Embed a browser component in a regular GUI. Problem: Embedded browser components tend to be glitchy at best. The support for Javascript/CSS is never as good as it is in a real browser.
...?
The ideal solution would work with any technology. I know there are options like writing Firefox extensions, but I want to have complete freedom in the backend technology and browser independence.
Please note that if you choose to run a local webserver, you're creating a security risk.
Any webpage running on the same machine that knows about your app can send requests to your server using Javascript, and you have no simple and reliable way of knowing what the request came from. (Don't trust the referer header)
Google Desktop, which uses a similar approach, has had several real-world vulnerabilities that allow any webpage to read any file on disk.
There are several ways to protect against this; I would recommend requiring each request to have a auth key which is randomly generated per-machine (and expires at some point), which you could put in the source for the actual pages. XHR protection would prevent malicious websites from reading the auth key, rendering them powerless.
If you are looking for a python Web Server with a Kill link, you could always check CherryPy.
import webbrowser
import cherrypy
import threading
class MyApp:
""" Sample request handler class. """
#cherrypy.expose
def index(self):
return """<html><head><title>An example application</title></head>
<body>
<h1>This is my sample application</h1>
Put the content here...
<hr>
Quit
</body></html>"""
#cherrypy.expose
def exit(self):
raise SystemExit(0)
class MyBGThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self.start()
def run(self):
cherrypy.tree.mount(MyApp())
cherrypy.quickstart()
myThread = MyBGThread()
webbrowser.open("http://127.0.0.1:8080")
This code is based on the sample from the SingleClickAndRun on the cherrypy website:
http://tools.cherrypy.org/wiki/SingleClickAndRun
Note than in a normal WebApp you would probably use a templating engine and load templates from methods like main.
Something that would be nice would be to embbed a browser control in a gui window and close the server when the app exits.
For the security, you could possibly add an authentication scheme. There are a few that are supported by cherrypy, but you possibly could implement your own too, using tool modules.
I am looking to do the exact same thing (desktop app that uses an up to date HTML5 / CSS3 browser as the desktop app's GUI), only with Ruby (various reasons why I decided to work with Ruby). Its amazing the number of cross platform libraries people have come up with. But yet, few to no one, has done any work on trying to get a web browser to be a desktop app UI. Cross platform issue... well I won't say solved, but I will say several steps in the right direction taken.
To me this would be perfect with the new HTML5 / CSS3 standards coming out. I know it can be done with a web server running locally.
Another way might be like how the guys from “280 North” are doing what they do. They developed Objective-J (an extension of regular JavaScript that mimics how Objective-C extends regular C) and Cappuccino (the Objective-J equivalent of Objective-C’s Cocoa frame work on the MAC). They also developed “Atlas” which is 280 North’s version of Apple’s “Interface Builder” from Xcode, for their Objective-J and Cappuccino frameworks to build Internet Applications. Atlas is actually a Cappuccino web app running on your desktop as a desktop app. In this case they use the Narwhal… a cross platform, general purpose, JavaScript platform for developing JS apps outside of the browser (basically a specialized web server).
If any one can come up with an idea to make “Browser, direct connect to Desktop App” work without the need of a web server co-existing and still get to manipulate the local FS, I to would be very interested… Hmmm... Now that I think about it, I wonder if the new Google Chrome project “Native Client” can be used to do that. NaCL is much like Active X except you are not limited to a windows platform (but will be limited to the Google Chrome browser, at least for now). Only there is added security via Sandboxing, but you can manipulate the local FS… The more I think about it, the more I am beginning to suspect that it can be done.
Any thoughts?
In Windows, you could embed the IE ActiveX control, which uses the same rendering engine as IE. (That's a plus and a minus) You can set the ScriptObject property in your host code and access it in Javascript as window.external to do things that Javascript cannot do.
If you run a local webserver, you could have an exit link in the app that kills the websever.
You did not mention the OS you will need to target. But you might be able to create a program statared web server, then launced the default browser. Wait until the browser is terminated by the user and then shut down the web server.
So for example on windows you can use CreateProcess() to spawn the process
then MsgWaitForMultipleObjects() to wait until it is finished executing.
HTML Applications (HTA, for short) have been around for a while. You can read all about them here. They are basically HTML and Javascript with some extra options to create a window and with access to the local file system. They seem to be exactly what you want. It is Microsoft technology, so this will only work with IE on Windows systems. I've successfully used this as a front-end for a CD-ROM which was used to distribute software to first year students
Another option would be to use Adobe Air. I'm not all that familiar with the technology, but it seems to provide a framework to deploy web pages as desktop applications. I can't post a second link as a guest, but just google it and you'll find it soon enough.
Today, in 2023, you can simply use any installed web browser as GUI using the WebUI library.