I talking about Native Client thing for google chrome...
Developers claim it can run native code compiled from c / c++ in browser's sandbox.
They describe a lot of things, but never point at what I need... So, if I create window in my application with CreateWindow, would this window appear when my Native Client application loaded into browser?
In short, no. Two key things to know about apps that use Native Client in Chrome:
They are platform independent (platform-specific calls are
disallowed).
They are still web apps with the restrictions and possibilities that come with that.
If Native Client allowed operating system-specific calls like CreateWindow, it would no longer be platform independent (and it would also present a security risk).
Instead Native Client provides a set of platform-independent APIs called Pepper or PPAPI that work the same for all supported operating systems (currently that's Mac OS, Windows, Linux, and Chrome OS). As mentioned, apps that use Native Client are still web apps, so Pepper gives the same possibilities and restrictions that you'd expect from JavaScript. E.g., you can fetch URLs or ask the user for fullscreen permission, but you cannot access any random file from the local file system (app-specific isolated local storage is possible; as is having the user upload a file for the app to use).
Moving an existing C or C++ codebase to Native Client is very much like porting to a different operating system. Instead of using, say, Windows API calls, your app should use Pepper API calls.
For additional background it may be worth noting that Chrome Packaged Apps can request access to a much wider set of APIs in the chrome.* namespace. These APIs include USB, sockets, opening new windows, and more. A Chrome Packaged App will still not be allowed to make OS-specific calls, but they have access to quite a few more APIs, all of which are platform-independent.
In short, if your app can be made to work with the Pepper API plus the chrome.* APIs, you could write it in Native Client and JavaScript, and you'd have an app that worked the same way across the four operating systems mentioned above. If your app cannot be made to work with those APIs, Native Client in Chrome is not the right choice.
Seems not.
This is a bit related: http://ssj-gz.blogspot.com/2013/01/emscripten-qt-progress-faster-better.html. It's translated to javascript, though, and only for QT. And slow.
Related
First of all am new to PPAPI plugin development. Earlier i have been using NPAPI plugin to perform certain functionality which in turn uses windows APIs.Now since NPAPI is obsolete, i am trying PPAPI. My question is can i link windows APIs to PPAPI? Is it possible ?
As Bennet mentioned, it is not possible to make calls to the Windows API. If this is necessary for your application, try making a Chrome Extension and using Native Messaging instead.
From the link:
Extensions can exchange messages with native applications. Native
applications that support this feature must register a native
messaging host that knows how to communicate with the extension.
Chrome starts the host in a separate process and communicates with it
using standard input and standard output streams.
It is not possible to call Windows functions. If it were, then it would be trivial to escape the NaCl security sandbox.
I am writing an application which requires access to the microphone of a device to determine instantaneous volume levels. The app will have a web version, iOS version, and Android version, and must be compatible with as many devices as possible, since the particular user base our application targets may not be able to switch browsers easily.
At first, I looked into using HTML5 for my application. However, it does not seem to be viable for my purposes, because I can't find any cross-platform way to get instantaneous microphone input and many users may be using an out-of-date version of their browser, which would not support HTML5. Is there any tool which alleviates these challenges and would allow me to use HTML5?
As a replacement, I began looking into Apache Flex. It seems to have all of the features I seek: It is cross-platform, allows me to access microphone volume levels, and will work even on very old devices, as long as they have Flash installed. However, many people predict the imminent death of Flex and strongly argue against using it, opting rather for HTML5. For my purposes, is Flex an appropriate tool, or would it still not be recommended?
You can achieve it by using PhoneGap or similar backend app which can host a webview and allow you to access native api through JavaScript or JSObject.
For front end, you can use HTML and keep your UI standard across all devices/platforms.
PhoneGap is little bulky but on Android and iOS, you can create a minimal app by hosting WebView and customize it to create JavaScript bridge and write your own native api.
what does the relation between a Web frontend and a smartphone App with identical feature sets look like regarding the development effort? Are there any specific differences regarding the development effort between Apps of different smartphone platforms (iOS, symbian OS, Android, etc.) ignoring training time? A general estimation would completely satisfy me. ;)
Thanks in advance,
Flinsch.
I hesitate to call this an estimate, or even an informed guess, but perhaps by putting down some ideas I might help your thinking.
Ignoring any particular platform specifics I see the fundamental difference of Web v Native is that in the Web case you have some extra work to do:
a). You have presentation separated from the backend, with probably HTTP in between. So there are services to write and issues concerned with notifications and/or polling to deal with.
b). You're likely using a browser to do the presentation so you will be using some JavaScript kind of library, and these are still hard to drive.
So, if you are targeting a single device my guess is that writing native code is likely to be 50% quicker than web-based code - assuming that you really are targetting identical function.
What seems to happend is that we compromise Web Apps, reducing functionality somewhat and hence the overhead is reduced.
Also there's another factor, the UI portions of the Web App are in principle portable, hence in fact the Web App development may be a reasonable investment even if it does take more effort.
I suspect that portability may well end up being a dominant consideration.
specific differences? There are plenty, but each with their own tradeoff:
UI: Web applications have CSS, (HTML, XHTML, HTML5) specifications that is supported by major browsers (although have have their issues). For Smartphone apps, each UI has to be designed and implemented according to the language the apps can be built on. You can effectively create apps like Winamp (having skins). For web applications, this is relatively a quick effort compared to writing UI's for each different smartphone OS models out there.
Language of use/Portability: In Web applications, an application sits in a server, so every request is sent to the server and response is returned from it. This allows that 1) Web applications can be written in any language of choice, as the end user never sees the server nor needs to configure it, 2) It allows the developer to write in a language that he/she is comfortable in. In smartphone apps, for the developer to run his apps to all the smartphone OS'es, he/she has to learn the programming language for the OS, and learn to port their code to work there (if porting is possible). That never exists in Web applications.
Hardware limitations: For smartapps, the developer must be aware of the cellphone capabilities and limitations. Facebook (e.g.) can essentially grow their memory, and add new servers and cluster their environment as the demand grows. You can't do that with smartphone apps. You will have to limit your implementation to run in a capability that your desired smartphone can accommodate.
There are more (feel free to add) but all these are part of the development effort that a software developer has to look at if they want to go a a field of choice.
I have a progam this is a converter for .NET that can be used in other .NET projects.
I have two kinds of license:
Developer license for DESKTOP software
Developer license for WEB server deployed software.
How I can protect my program if client buy (1) license he CAN NOT use it on the SERVER.
Disclaimer: I don't know anything about .Net, other than how to spell it, and I'm not completely sure about that.
It seems like one difference between a person using your file converter on their desktop and using it on a web server is that only a single instance will be running at a time on the desktop; a web page will probably have multiple instances, once per concurrent request. This seems like something you could enforce in software, and also something you could easily write into a license agreement.
Does IIS run with a graphical console on Windows? If it doesn't, and your desktop version does, maybe you could detect that?
Ultimately, though, if someone wants to get around your server/desktop distinction enough, they're going to; they could, for example, have the web server send the document to a desktop machine, and have the desktop send it back to the server. So, at some point, you'll have to give in and either ignore it or to say that's a problem for legal to handle.
If it is desktop software (I'm not sure by the question with the tag), you could use the Environment object to check what OS the code is running on and stop it running on Server Technology. This won't help if they run a server using XP or the like though, but it's a start.
I am developing an application in flex 3 using action script 3.........
I have some range of ip address in LAN(wired or wireless both).....i want to check which all the systems available...and also want to see their shared folders.....can anyone give some code or reference in action script....
Thanks to everyone...
Actually, I don't think it's possible at all with Flex due to sandbox violation of the Flash Player and/or not supporting it.
I don't know if Air supports network access in this way. Check this out for more information on Adobe Air.
MysticEarth is right, Flex cannot access the operating system directly because of security issues that might arise.
However, you can solve it in two ways:
Adobe AIR 2.0 Command-Line Integration:
Server-side script
Adobe AIR 2.0 can now run native processes! So you could have it access your operating system, check the systems available, shared folders, etc. Here's an example on how to execute native processes with AIR 2.0
The current standard is to just use Flex and HTTP to a server side script. To do something like what you're describing, I would create a ruby/php/python script or whatever, send a restful GET HTTP request to that script (say GET /shared_folders), and have that search the OS for what it needs, and return it as XML. Then you can use Flex. If you don't want to do that, AIR 2.0 is the only option.