I have an Eclipse RCP application which I am planning to write in RAP so that I can allow my users to access it on web. I have just started with RAP and have gone through what RAP can provide and what it can't. Also I have seen the demo workbench application. Seems like a good fit for my use case but I still have some questions around the feasibility and workarounds possible in RAP.
Can RAP allow ports for existing views from eclipse like Package Explorer or Navigator. Also since the workspace would be shared can there be a way around to show different projects to different users.
The short answer is NO!
The Package Explorer or Navigator views itself wouldn't be hard to port to RAP. The Workspace/Resource API is the limiting factor here, as you already guessed. For RAP, a multi-user aware resource API would be desireable that provides a workspace for each seesion.
But until now, nobody put in the effort to implement this feature.
Related
I need to integrate an API created with .NET with SAP FI/CO.
Researching online I found out there used to be something called IDES that would provide access to an SAP server free of charge, just for testing purposes, but that's no longer available.
The Consolut solution seems to have been a viable solution while it was active:
https://www.outsystems.com/forums/discussion/6598/sap-server-test-account/
Anyway, my question is: Is there any way for an independent developer to test an SAP integration without spending money to access that server? Are there any options out there that would allow me to access an SAP instance for testing purposes?
Here you can find the official list of developer trials that you might access without having any kind of relationship with SAP:
https://www.sap.com/developer/trials-downloads.html.
If you have an SAP S-user, you might have access to more stuff from the SAP Marketplace. From my knowledge, IDES was / is only accessible through the SAP Marketplace (or external sources which use the marketplace themselves).
FI/CO runs on Netweaver AS ABAP (or an older alternative, e.g. R/3), so you could download it here: https://tools.eu1.hana.ondemand.com/#abap. But it will not have FI/CO in it. Based on the discussion here https://archive.sap.com/discussions/thread/2039981 I would say that it is not really possible to get FI/CO up and running on your local Netweaver.
This is a general strategy of SAP. They provide the possibility of trying out their technological platforms (HCP, HANA, NW, etc) but they don't really offer access to their business solutions for free.
If you don't find any other way of getting access to a FI/CO system (e.g. from a third party or customer) then maybe the best thing would be to use the local Netweaver and mock the FI/CO specific RFCs that you are using (assuming that you use NCo for the integration). At least this way, you would know that the integration works at a pure technical level (at some point though, you will need a real system).
The UWP infrastructure seems to have everything what's needed for a portable model.
Clear separation between os and application
Clear separation between different applications
Less dependencies
Support portable class libraries
As far I know portable scenario's are not supported right now. Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
How hard would it be to create some kind of host executable that can run any local UWP app. At the moment I'm looking for portability between different Windows 10 PC's. Not so much cross device or cross OS.
I'm aware you can side load UWP apps, but that's not what I'm looking for.
Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
I don't see any major technical limitations that would prevent this scenario. UWP apps can register to some global mechanisms (which is something portable apps shouldn't do), like push notifications or background tasks, but the whole application model has been designed so that users can limit access to those features on a per-application basis. So every developer publishing an app is supposed to have considered beforehand that those code-paths may fail.
But "technically possible" doesn't mean that Microsoft will do it. In fact, I seriously doubt they ever will. The reason is simple: they're pushing the store with all their might, even seeking to put Win32 apps on it. Clearly, they're moving towards putting more apps on the store, not the other way around.
As to know whether it'd be possible to make a third-party standalone runner, I think so. When running unit tests for an UWP app, Visual Studio is launching a sort of "shell" hosting the app (it has become very apparent recently because after an update of Windows 10, the API that allowed to hide the splashscreen wasn't working anymore). I don't know what API is used to create this shell, but I'd definitely dig that way if I wanted to make a portable UWP host.
Although I haven't done this myself (will update answer if and when), reading this article makes it look like there is an easy way to create an installer that calls that command.
In short, an appx package can be installed locally using the command:
C:\Program Files (x86)\Windows Kits\10\bin\x86\WinAppDeployCmd.exe
Which can probably be wrapped in a UI or CMD installer.
Here's nice example of it (not mine).
(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'm currently working on a no-touch deployment and auto-update mechanism for a Windows application. I've tried Microsoft ClickOnce strategy but it did not work for me as the strategy only suits small-sized apps, and my application hauls at ~500MB.
I'm interested in how the stub based installation and update strategies work for Mozilla Firefox and Google Chrome and also Microsoft's packages including its .NET framework and VS installers. I've come across Google Omaha which hosts the Google product update deployment mechanism, but it is not very conclusive for me.
Can anybody please help me out how the stub-based deployment design works?
P.S. Any open source code for the same would be of a great help. ;-)
I'm not quite exactly sure of what you mean by "stub-based". There's a handful of technologies and tools involved in what I understand you want to accomplish. For the setup packages creation there are: NSIS, Inno Setup and the WiX Toolset, for example. A core technology is MSI. On the other hand, for application updates and the such, there's BITS and also some web stuff involved in updates publishing, like using an ATOM feed, for instance (your referenced Google Omaha might fit into this category).
It's only a bunch of pointers, but I hope it helps.
The Mozilla installer is opensource (as is the NSIS system it uses) so I'd suggest adapting the code found here: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/installer/windows/nsis/
It's a bit complex so you could start with a simpler script and incorporate the bits you want (like finding/downloading updates and UAC evelation).
We are looking at building a GUI application having the following attributes -
* approx 100 screens
* approx 200 users
* interfaces with 8 different legacy applications (protocols tbd but we are assuming web services will be exposed)
* has a separate data store for storing authentication and authorisation info along with few other information.
We are trying to avoid spending any money on procurement of physical servers, application servers etc.So we thought instead of building a web application , we could develop a standalone GUI based application that could be deployed on users' desktops considering that the users are less and the access to this application is confined to our organisation.
We were thinking of Java Swing as one of the options to consider. Is it a good choice? Please advice on the other options that we need to think about. We thought MS products would involving licensing costs to buy the product hence we are looking at developing the application using some free software tools.
Thanks a lot!
Regards,
V
I really like Swing and have written many applications with it, but I'm not sure the argument that you will get a cheaper solution because you have to procure less physical servers is a good reason for it.
There are other ways to use computational capacity on the client side. For example you could use SmartGWT. With a browser based solution you get easy deployment and have no problems with client-server communications (i.e. no proxy hell). It's possible to get all of this solved with a standalone GUI, but it requires experience and time (== money).
I think a standalone GUI is a good idea if you need a "rich" user experience and tight integration with the native environment. Web apps are generally less snappy and not so well integrated. If it's just about editing data on a server, the standalone GUI does not really have any advantages.
I won't rehash what we talked about in the comments. It seems you are focused on java gui solutions. With that said there are alternatives for developing gui applications with free tools. Just to name a couple, you could develop your client with Adobe Flex or Adobe Air, use python, php or ruby and GTK, or develop a windows GUI app using c# if your target os is windows. Similar to Air, Microsoft Silverlight is an option. Java is not the only solution.
Many Java gui apps are written using swing. The major competitor to Swing has long been SWT which is used for eclipse and by IBM. Javafx is a newer/alternative platform Sun/Oracle is behind, you should also look at. To be complete, you should also take a look at qt jambi that lets you develop in java against the Qt framework.