We are implementing blue prism and have an issue to proceed.
We use the object spying for our web application which works fine. However before the application opens, we have smart card authentication. So there is a pop up for entering the smart card pin.
I am not able to detect that. Can you provide me an idea how to detect the same?
Awaiting your response.
I have tried all the Spy modes but none of it seems to work.
enter image description here
Are you using Blue Prism version 5 or 6? There was a similar question in the past, you can look it up here.
To sum up the options:
Firefox or Chrome plugins (you'll need to change object type to browser based for Firefox and Chrome) and HTML spying mode.
UI spying mode.
Use Surface Automation techniques - Region mode.
Web services that will use website's API (if applicable).
Options 1 & 2 are exclusive for version 6.
As for this particular problem, I would also try to create separate object for Smart Card application/pop up and treat it as separate entity (you would need to test different spying modes as well).
Hope this helps
Related
I'm researching reliable ways to programmatically control instances of Chrome/Chromium to leverage its capabilities of rendering web pages in Node.js/C#/Java application. In short, things I want to do are as follows:
Open/close a browser window.
Minimize, maximize browser window.
Navigate to a certain URL.
Set cookies.
To make it more clear: I need a headful browser to display web pages to the end users. It can be either embedded to my app or can be a standalone browser (separately shipped instance of Chromium for example).
I was not able to find information about any public APIs in Chrome/Chromium that I can use from the Node.js/C#/Java environment. The ones available for Chrome Extensions are not applicable to my project, as I want to control the browser from the outside, like Selenium WebDriver does for example. So far I found the following ways to control the browser the way I need:
To use Puppeteer/WebDriver APIs.
Use chrome-remote-interface NodeJS library.
Rely on Chrome Embedded Framework capabilities.
Rely on Electron.js capabilities.
Build my own library that somehow includes the Chromium modules as dependencies (similar to what Electron team implemented for example).
First two options are similar from the perspective of all the mentioned libraries eventually leveraging Chrome Devtools Protocol. The risk of CDP being retired/deprecated is quite substantial for our project. The other concern is that the intention of CDP is debugging and test automation and not application development. Moreover, having an open debugging port in Chrome open on user's machine seems vulnerable.
CEF and Electron paths concern me due to dependency on the embedded Chromium updates cadence. Although Electron team is targeting to update with every other release of Chromium it still can be a security concern due to inability to update the Chromium version right after a new version released with a security patch, for example. Moreover, in case when I need the real browser experience (and that's the case) I won't have it out of the box and I'll have to implement browser features like buttons, tabs address bar etc. myself.
Option #5 seems to be extremely complex in implementation as it seems to require team's competency on Chromium internals, C++ development and C++ build tooling.
Anything I missed in the options list? Anything I missed in my assumptions? Any tips, thoughts, suggestions will be greatly appreciated!
Some of your options are about controlling a browser (#1, #2) while others are about embedding a browser (#3, #4). These are two different use cases and what you need depends on what your goal is.
Controlling a browser
If you want to control a browser to execute tasks, maybe even in the background without the end user noticing, you should go for option 1 (puppeteer) or 2 (chrome-remote-interface).
I recommend to use puppeteer as this is the library developed by the Google Chrome developers and it comes with many functions for your use case (opening browser windows, navigating, setting cookies).
I do not see any reason to worry about the Chrome DevTools Protocol being abandoned anytime soon. The Chrome DevTools fully rely on this protocol. In addition, Firefox (Mozilla bug tracker: #1316741,#1523097) and Edge are already partly supporting the protocol making it even more unlikely to be abandoned in the future. (more information)
Embedding a browser
If you need to embed a browser, meaning you are trying to show a browser inside your application, you should focus on the options 3 (Chrome Embedded Framework) or 4 (Electron).
The Chrome Embedded Framework is a more low-level approach putting a separate browser into your application. But I cannot go into detail here, as I have never used this one myself.
Electron on the other hand is a browser, meaning the whole application is developed as web application. You can embed another browser window (webview) into your browser, which you can essentially control (similar to what puppeteer can do).
Directly using the Chromium code (option 5)
Although the Chromium project is split into multiple components, it sounds like you need a full browser. I once compiled the Chromium source code myself and it takes literally hours. Keep in mind, that he code consists of roughly 35 million lines of code (source). Even if you figure out what parts of the code to use, it is more realistic that some low-level parts of the code change and break your implementation than the DevTools Protocol being abandoned. So, I definitely recommend to not follow this idea.
Alternatives
Depending on your use case, you could also take a look at DOM simulation libraries like jsdom or cheerio. These libraries are very limited in terms of their functionality and you might have to implement parts of the browser yourself, e.g. downloading the document, reading and setting headers to deal with cookies, etc.
All in all, I recommend to go for puppeteer if you want to control a browser to execute tasks primarily in the background. If you need a browser window as part of your application go for Electron.
I want to write a web app that can process a users presentation which when submitted, gets sent to their local system printers - one part of the order will go to B&W laser printer and another part goes to another printer for another process.
Ideally, this will be able to run on any of the major systems - Linux, OSX or Windows.
It could be a packaged Chrome or Firefox app or extension, but I can't tell if there is sufficient access to the system printers. (I can see all the printers available to my current chrome installation - but are they available to an extension?). I can't see the code in any demos or libraries.
I've seen reference to NPAPI, but I can't tell if that's what I need either - if so would I need to write an app for each of the major platforms or each kind of printer?
In Firefox it is possible to print from an extension. Using only javascript, that is (you're free to mess about with C++ if you like).
Extensions are essentially the browser: Everything the browser can do, an extension can, too.
There is however not much documentation about using the printer. To be precise, there is none that I'm aware of. However, the browser is open source, and the UI is mostly Javascript, so you can just read the code.
printUtils.js would be a good starting point to check out how this might work. Also there is a component implementing nsIPrinterEnumerator. See the firefox-addon info section for a collection of "Getting started" and documentation resources about add-on development in general.
I don't think the Chrome extension API provides ways to control printing the way you'd need.
The NPAPI plugin API does not provide enough control over printing. You just basically get a buffer to draw into, but no way to control printing setting or initiate printing yourself. You could cheat of course, and have your plugin directly print something via OS bypassing the browser, like e.g. those PDF readers do. However, it should be noted that NPAPI plugins are the past... Don't develop new ones, if possible.
I need to write a text box control for Metro Style app. And I need that this text box can invokes a touch keyboard, when my app runs on tablet PC.
Microsoft advices me:
If you are writing a custom text control (whether in Xaml or not) you will need to make sure it supports the UI Automation TextPattern and ValuePatterns and focus changed events
and
You will need to provide an AutomationPeer which supports the ITextProvider and IValueProvider.
But I can't to figure out what actually I need to do. I will appreciate any help.
You need to implement a UI Automation Provider; in particular, you need to implement a server-side provider. Start with the UI Automation Provider Programmer's Guide, and pay particular attention to the Document Content Provider Sample, as it demonstrates how to implement TextPattern. There are more samples as part of the Windows 8 SDK, in the samples/ui/uiautomation directory. Also, there's a very quick introduction to server-side introductions here, written by one of the architects of UI Automation.
Just got a car with the Microsoft sync system in it. Did a quick search online and was curious if anyone is aware of any SDK that may exist, sample open source add-on applications, etc.
Thanks in advance.
UPDATE:
Looks like Ford has finally released their SDK:
https://developer.ford.com/
Ford has a website SYNC Mobile Application Developer Network but the SYNC SDK does not look to be available yet (their site mentions possibly later this year). It appears they are stilling working on the API before releasing it. All they are offering now is a way to register to be notified of new info as it becomes available.
From their About page:
Ford is hard at work developing an API
to allow developers to integrate their
Smartphone applications with SYNC. The
Developer Program website will educate
developers about the Ford SYNC
platform and how to interact with it
via the API. There will be a full set
of documentation, example
applications, reference libraries, and
even a developer forum so you can
reach out to the community for quick
help.
With the available SYNC API's, mobile
application developers will be able to
do some of the following:
Create a voice UI for your application using the in-vehicle
speech recognition system.
Write information to the radio head display or in-vehicle touchscreen
Speak text using text-to-speech engine.
Use the in-vehicle menu system to provide commands or options for
your mobile application
Get button presses from the radio and steering wheel controls.
Receive vehicle data (speed, GPS location, fuel economy, etc.)
The official API and full website
launch is set to be targeted for later
this year.
It looks like the SDK is coming very soon. The story was just posted on Engadget:
http://www.engadget.com/2009/12/18/ford-to-give-sync-some-app-store-flavor-opening-api-to-devs-in/
Now just imagine what you could do with access to your automobile functionality!
I don't think there is any. Its a closed ecosystem.
http://www.autoblog.com/2009/01/09/ces-2009-sync-could-one-day-add-app-development-like-iphone/
From what I understand it is based on the CE 6.0 platform using windows automotive 4.1, but I could be wrong. We really need a forum to get this going. Hurry up Ford! Release the SDK!
Given the way Windows automotive is there is only two ways of putting a ROM on Sync. Using JTAG to put your own custom bootloader (forget it), or though the USB. Which you will need to know how to sign the file so sync will think it is an OEM ROM. So at this point even if you were able to come up with your own custom rom by using Microsoft eMbedded Visual C++ you would still have no way to get it on there.
BTW, the SDK they are talking about releasing will only be to develop apps for applink. (not modifying the OS). However, to upload the apps we might be able to find out how to sign the .bin file for sync to accept a ROM through the USB.
Then again this is just from my understanding... I am no great developer or anything.
Ford launched sdk in ces, check it out: http://techcrunch.com/2013/01/08/ford-launches-its-openxc-sdk-and-hardware-specs-to-let-developers-access-its-cars-sensors-and-metrics/
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Stackoverflow User Luke wrote in this answer:
The boundaries between desktop and web
applications have really blurred.
Whilst once upon a time the nature of
developing for the web was totally
different to developing for the
desktop, nowadays you find the same
concepts [...] cropping up in both.
Since I am continually looking to improve my existing web applications, I'd like to know which common features of "classic" desktop applications do most web application miss?
For example, most desktop apps prompt the user to save unsaved data leaving a page or closing a window - a feature that many web applications miss. It could be that some feature aren't even necessary or are compensated in some other way. Maybe there are features which can't be implemented in (a classic) web application?
The thing you'll never be able to imitate in a web application is the low latency and instant feedback of a well written desktop app.
Even with the ajax techniques to load only parts of the pages, there usually is a noticeable delay in the response (or maybe it's just me and my narrowband). You're (for at least a few more years) just bound to the orders of magnitude of speed difference between network access and no network access.
The Undo button.
Right-click application-specific pop-up menus is the thing I've noticed most.
Usually right-clicking on a browser application will bring up the browser pop-up menu rather than an application-specific menu.
Keyboard support on most web applications is weak to non-existent. This is getting better than it used to be but you will still find plenty of mainstream sites that can't even get the tab order to work correctly. Most sites don't handle focus correctly and force users to use the mouse to activate even the simplest of data entry forms. You can usually forget about accelerator key support.
You can't pull the plug when the application hangs. (Yes, I'm serious)
For fairness is to mention, that desktop-applications miss a common feature of webapps: XSS (Cross-Site-Scripting). ;-)
Support for Big Files.
Integration with the client OS.
Support for special Input/Ouput Devices.
3D or anything else computationally intensive (specific to each users).
Advanced graphics: I've written a C program that draws a surface joining Bézier patches in a simple window and I had to tweak it in unimaginable ways to get it to draw in a decent time. I can't imagine that being ported to the web.
I mean, doing advanced graphics is not what every application needs, but if displaying nontrivial pictures is slow, then we shouldn't even talk about animations.
One Proper Macintosh menu bar support.
If you're a long-term Mac user, even with two large monitors, you have muscles that swoop to the top of the screen for actions, comfortable in the knowledge that the infinite depth effect will kick in and you can slide along that edge, picking from the menus.
No in-browser app can deliver that experience.
Two Command-keys, which is a side-effect of the menu bar not belonging to the app but goes a bit beyond that - good desktop apps have command-key shortcuts (accelerators to you Windows guys, I'm not just talking the Mnemonics which work with alt-key support). Great desktop apps show little reminders next to the buttons that have accelerators, when you hold down the appropriate modifier keys and wait a fraction of a second.
Three Smarter tables. There are a lot of apps where some kind of spreadsheet view works as a paradigm, including editing, sorting, resizing columns. I think I've seen some odd examples of partial support but a good table in a web app is still a bit of a dancing bear.
Four Used to be right-clicking but I'm finding more and more apps that do this properly, like Kerio's excellent webmail engine. It is still missing in enough web apps to be worth emphasizing.
Displaying application request/process status or messages on Taskbar or Status bar.
For the web, Javascript can be used to update text on status bar, but its not a common usage.
The usability benefits of standard GUI elements that look and behave uniformly across applications.
(Although this will surely change as web app developers adopt certain GUI elements and patterns that are considered best-practice, notably by eventually using the same libraries, e.g. for drag-and-drop.)
A common feature of "classic" desktop applications is the ability to work without an internet connection. I miss that in Web applications.
For example, MS word works without an internet connection, but you need to be connected if you want to use Google docs.
Of course, it does not matter if the application requires an internet connection anyway. For example, if its a feed reader, I have to connect to the internet, whether I use a desktop reader or an online reader.
Drag and drop from Finder/Explorer into the web app. And vice-versa.
The ComboBox is the most notable widget omission.
On the web, lack of desktop features such as popup dialogues is actually a boon, making for a simpler interaction experience. Think also of the autosave draft feature of Gmail vs. the desktop convention of prompting the user to save.
So consider carefully before trying to reconstruct that desktop feature in your web app.
Decent help. Seems to always be an afterthought, if it's even implemented...
Desktop integration (may change if we get online desktops)
Offline use (does exist but it is early days)
(Reliable) Responsiveness
Reliability generally (somewhat debatable as there are pros and cons - e.g. your data is probably better backed up online, however security generally is less in your control with an online app, and if the network connection fails an online app tends to freeze or fail horribly.)
Blue Screen of Death
A task-specific UI with no extra controls. A web app, in addition to all the controls of the web app, also has back, next, bookmarks, etc buttons. You end up with an extra inch-high set of buttons that don't directly support the task at hand.
This isn't necessarily a programming feature, but the audience of an application will be different. For a web application you are cutting out a complete segment of your audience (those with slow or no internet access). While this is a relatively low number, it is a difference between a desktop application and a web application.