We Keep Coding

Exposing Native Device APIs to Web Apps

There are a lot of ways to develop an app nowadays. You can create a full native app, hybrid app, pwa or website. There are probably some formats of apps I didn't mention however that's besides the point. The last two decades have proven that smartphones are the way most of the people(users) are interacting with apps and that's clearly also how they want to interact all the time literally all the time! Developers(wizards) have been working to meet those demands by creating solutions like .Net blazor, Xamarin, Vue, Angular, ect to meet the demand for apps and their development. Currently app stores from Google and Apple are the way apps are distributed only for use to pay them a cut of our app revenue so we look to the web. When we want to create a highly secure app (server-side) we look to the web. When we want to support most operating systems we look to the web. I assume you get the point. only there is one thing that stands in the way and that is excess to the users native device APIs. There are alot of native APIs that are already available in HTML5 only we know that those aren't the specific ones we need for the app we develop. So what are the ways we can expos native device APIs to web apps?

Look at Cordova Plugins: https://cordova.apache.org. If you want to expose API into web, you just should write some player application (web browser) witch will translates JS commands into native API callbacks. To achieve it, you can use WKScriptMessageHandler.
Here you can find an example.
It is not very complicated, but if you want to cover all API, it will very complicated code.
Also, you forget about one coin of a web application: long time of a response, especially with low internet connection. I do not think that is a good idea.

Is it possible to build a home automation system with web technology?

I can build all sorts of web applications with common web technologies on both the client and server (JavaScript, PHP, CFML, etc.).
I would like to build some home automation tools and I have no idea how to get from the strictly digital world to the physical world.
Let's say I want a super simple web app to display a bunch of switches in the user interface for some different things in my house. Let's say I'm using X10 hardware (http://www.x10.com/x10-basics.html) that is "listening" for some radio signal.
Is there a way to use web technology to "instruct" my devices (smartphone, tablet, laptop, whatever) to "broadcast signals" to these X10 (or any) physical device in order to make my home more Jetsons-like?
It seems like JavaScript couldn't do any of this because of security stuff, but perhaps a server app running on my local device on my home network could tie into some underlying OS library and do this?
wirelessService = new system.os.superCoolWirelessBroadcasterService();
wirelessService.broadcastSignal("6520 mghz", true); // toaster frequency

All my mobile stuff is an HTML5 front end with an self-hosting asp.net web API backend. I use a https proxy application for security. But I run my stuff on an intranet. It's very easy in my opinion and very rewarding.
Here are a couple of videos:
https://www.youtube.com/watch?v=_2_JSbEytnM
https://www.youtube.com/watch?v=zOhOEWoED4M
Now I did integrate Google Glass which is an app:
https://www.youtube.com/watch?v=vLmPJ9xvfs0
Here you can find a complete listing:
https://www.youtube.com/results?search_query=nick+tullos+home+automation
Here is some of the source code:
https://github.com/NickTullos/CrestJson
Good luck!

You absolutely can. I created several automated processes with Coldfusion. Look at the scheduled tasks section of the Coldfusion administrator.
Many things that are one of specialized tools like barcodes generation or scanner software (just as examples) have third party dlls on Windows with Coldfusion (nothing is perfect mind you) some even required us to extend Internet Explorer via activeX controls. Some of these things included warehousing housekeeping tools, three dimensional boxing interfacing, shipped product checks and payment authorization switches, refund switches, warehousing scale interfaces and U.S. Mail/Endicia/UPS manifest generation.
Nowadays, I do many automated import processes with third party source data. Just formatted CSV or Excel files sent via FTP where I scan and pick of the file for processing.
We also parse raw data from a power inverter and create graphs for review and other statistically useful things for a client. This was not an easy task because there are things in that technology that I am not equipped for and had to learn (power inverter speak). Also the shorthand their technologists used to name data-points made some sense to them, but was immensely obscure and not very easy to translate.
I will tell you that one of the hardest interfaces I worked with was a 1996 serial port based warehouse scale that we got after the DHL bankruptcy. I thought I would lose my mind. There were baud settings like older modems and if there was a failure it didn't do anything (no error nothing).
I would assume you would have to consider that obscure real world interfacing with things that are digital may or may not be feasible.
Coldfusion is very good at automating because it is a dynamic language with an easy to use administrative backend that can access deeper things via Java objects and native .NET support (so anything is possible)!

the thin line between web apps and desktop apps

I've been working a lot lately with web apps, mostly with javascript and json-rich web UIs.
I have to say I get impressed all the time with what I can achieve through these technologies.
More and more, I ask myself whether I would have preferred to go with a classic GUI to start with (whether it was C#/VB.Net + WinForms, or C/C++ + GTK/QT or Java or anything). I, however, have been able to accomplish everything I wanted in terms of a user interface with web-related technology.
And although I feel I have everything I need, more and more things keep coming in (and will keep coming in forever), like HTML5, new javascript capabilities, and probably even more things.
So, as web apps become even more and more able, I ask you:
How thin is the line between web apps and desktop apps as of now?
What is the future of this line? How capable will web apps be in the distant future? In this sense, is there a definition of what web apps should be, or are they just going to improve it more and more forever?
I would like to know what W3 has to say about it, though I haven't looked into it yet.

In reality we have simply come full circle in the computing world. The web browser of today is simply the green screen terminal of 30 and 40 years ago.
It used to be that you would buy time on a University's computer to run your program and then pay for time it took for your program to process and run. This was inefficient from an end user stand point since it was done in a batch and queue process so your results would have to wait till the next day. From the University's point of view though they had more computing power than they knew what to do with, so farming it out made sense and gave a nice revenue stream.
Flash forward a few years and desktops began to be as powerful if not more powerful than the University's computers and the days of batch and queue processing died off. But desktop centric applications suffer from a single fundamental flaw, multi-user needs. If more than one user needs to use the application at the same time, a server is needed in the mix to handle the multi session data needs.
The client application is useful for doing things such as data validation, but the thicker the client, the larger the risk you run with different versions of the client populating data at the server wrong.
The solution, the "web" client. Using the term web though is actually wrong in my personal opinion. The html/browser based client removes the issues found with multiple versions of a desktop client since all users are using the same version all the time. Gone are the days of deploying an upgrade across thousands of desktops. The browser based client simply needs updating on the server side and all users are instantly getting the new features.

To answer this question about the future, let's look more than a year into the past:
http://www.codinghorror.com/blog/2009/08/all-programming-is-web-programming.html
And in fact, it references an even earlier post from 3 years earlier. The future is Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html

Apart from some UI issues, web apps are real apps.
What is the future? Wish I had a crystal ball...
However, I would hazard to guess that the trend will go on and web will subsume most if not all of desktop applications.

Both have still their meaning. Webapps will get cover global connected applications, applications that exists because there is the web. They get really more important from day to day or the builder make us thinking they are important.
GUI still will be there because for a lot of people with not so much computer skills it is still easier to operate and understand. And there are really very very complex GUI application that maybe will get never into the web (CAD for example). Their complexity will be always in front of the progress of web development. You cannot catch them.
So I believe this line is notable and will be there for long time. Not all will get into the web.

Having just made the choice of using a "web" API or Desktop API here are the most significant differentiators that I see right now:
Support of native features
For example on the iPhone: Direct access to low level APIs
With the current browser development speed we should be there soon
Offline workflows
First steps done here with offline mode in HTML5
API support for "desktop UIs" (flexible, configurable, fast)
Libraries such as ExtJS are not there yet, but close
With WebGL, Canvas, and more and more powerful CSS features it has become a lot easier to create powerful UIs
All in all there is still quite a bit of work to be done but I think a few years from now there will be no difference between web and desktop applications, some of them will work offline, some won't.
Microsoft had that vision with .hta a long time ago, at that time it just wasn't powerful enough. Google is continuing now with Chrome.

Web apps will get closer to Desktop apps as the time goes. The reason behind this is the requirements. More and more people are hooking into internet and giving time or wasting time on net. So, requirement for browser is increasing. Second, as business are going global (globalization !) It is already global but in future the requirement is much more. Even small shop need to use internet for tax etc. Developing countries are using net in governance so checking for tax is easy. For all these even if a owner has 4 small shops then he need to have a aggregate data for his selling. So, all 4 shops better need interconnection and calculate everything financial every day.
People in a single team are working from remote. So, they need to share documents on regular basis. So, Google docs etc. Google docs has capability for online editing from various user at a same time. and still docs keeps synchronized.
Competition are increasing day by day. So, all business data need to be on one place for analytic. Who will collect all data from desktop application each day and synchronize each day. So, even if company will use Desktop app for speed and reliability then also he need some kind of net connection and synchronization software for those desktop applications. In this way you see that desktop app are getting closer to web app!
So, if you visualize all these scenarios then you will find it very difficult to avoid web applications.
Web app has future. For efficiency and speed, Web app will have a sort of software that will act as a desktop app and get downloaded when you use that.

Adobe Air Questions/Resources

I recently became quite interested in developing an adobe air application, and just had a few questions that maybe some more experienced air developers could answer.
Firstly, what is the average time-frame required for an air project. Mainly I'm planning a somewhat ambitious project of porting a specific forum framework over to an air app. How long would you estimate this would take me to do personally? I want something more than just the standard browser inside an app, more along the lines of built in controls/features for all the standard functionality.
Secondly, can apps be done completely with javascript/html/xml? I'm quite proficient with these 3 technologies, but have no real experience with flex/flash. This includes making the chrome as well. Do specific features require specific languages to be involved?
Finally, any good books/articles you would recommend? Preferably more advanced books/resources that lay the groundwork for making professional quality applications.
Any additional tips or insights on what you think may be useful are very much welcomed.

Start reading Adobe AIR for AJAX Developers, particularly the Getting Started section

Without knowing your skill level how would we know how long it will take you personally?
I have built and released apps in one week in my spare time, doesn't mean your project or your skillset for this project will be comparable.
Adobe Air development is fast and easy in general.
Don't reinvent the wheel making button and menu classes, leverage what's already out there.
Take a look at MadComponents: http://code.google.com/p/mad-components/ for UI
Other than that there are several robust tweening and graphics libraries out there.
There's also stage3d and frameworks to support 2d and 3d development for almost near native performance.

You can find a python script that will do it here:
http://code.google.com/p/flashcommand/
More info here:
http://www.mikechambers.com/blog/2008/05/02/flashcommand-for-os-x-updated-to-work-with-flash-cs3/
Basically, this just uses the JSFL API in Flash Pro to automate the compilation from the command line. However, it requires that Flash Pro be installed (and the script will launch it).
There is no a way to compile FLAs without using Flash Pro.
mike chambers

Why should I use Flex?

In a recent conversation, I mentioned that I was using JavaScript for a web application. That comment prompted a response: "You should use Flex instead. It will cut your development time down and JavaScript is too hard to debug and maintain. You need to use the right tool for the right job." Now, I don't know too much about Flex, but I personally don't feel like JavaScript is too hard to debug or maintain, especially if you use a framework. JavaScript is also one of the most used languages right now, so it would seem a better choice in that regard too. However, his reply piqued my interest. Would Flex be a good choice for a distributable web app for which 3rd party developers could build add-ons? What are the advantages of using it vs. a JavaScript framework? What are some of the disadvantages?

I have recently started to develop Flex applications, and I personally find it a refreshing framework for the web.
You get a state-ful application that runs completely client side. You get no worries about cross-browser portability that you do with JavaScript, and you get some really neat things such as effects, graphing, and rich user interface components.
Flex also makes it easy to communicate to webservices and the XML parsing via ECMA is insanely powerful and simple.
I'm glad I have made the switch. As far as how popular it is...I'm not really sure, but I am fairly certain that the developer base is expanding rapidly.
The only real disadvantage I can think of is a flash player requirement, but I would say it is pretty safe to assume that most browser support flash player; even konquerer in Linux is supported; much more so then a silverlight runtime (which I NEVER plan on installing)

Here is my experience: you really need to consider 2 things separately - development and the end-user experience. Flex shines in the first area:
ActionScript is a nice mixture of Java and JavaScript so you get a familiar language with strong support for OOP
debugging is far easier than what you can achieve in JavaScript
Flex framework is component-oriented and event-driven which helps in creating rich user interfaces (HTML was not really created to support application UI scenarios)
On the other hand, the end-user experience is worse when running a Flex app compared to an AJAX app. First, you need to have Flash Player installed but this is probably not an issue for most computers today. Bigger problems are with usability - Flash Player handles all UI interactions (instead of a browser) so the password manager doesn't work, text fields don't remember previous entries, Ctrl+T and middle-clicking doesn't work, text search doesn't work etc. etc.
My advice would be - if you are developing an application (rich UI, relatively separated from the rest of the web), go for Flex as it will save you time, money and will make your users happier by providing richer functionality and shorter periods between new versions. On the other hand, if your application needs to be tightly integrated with the web and you want your users to be able to use features of their browsers, go with AJAX.
Nice example is Google Docs vs Buzzword. Buzzword is much more feature rich (for instance, text can flow around an image from both sides which is something you could never ever achieve in DHTML) but Google still decided to go for an AJAX version because they are the "web company". There is no right or wrong in doing it the one or the other way, it's just different and it's important to consider who your end users are.

I would push you towards standard web development technologies in most cases. Javascript is no longer a great challenge to debug or maintain with good libs like jQuery/Prototype to iron out some of the browser inconsistencies and tools like Firebug and the MS script debugger to help with debugging.
There are cases when Flash is a better option, but only in cases where you are doing complex animations. And, if you are willing to invest the effort, most animations can be achieved without resorting to flash. A couple of examples...
Flash content is not as accessible as other content.
This will not only affect people with out flash, but also search engine spiders. There may be some hacks to help get around this now, but I think that most flash content will never be indexed by google.
Flash breaks the web UI.
For example:
If I click my mouse wheel on a link,
that link is opened in a background
tab. In a flash app there is no way
to simulate this behavior.
If I select text in my browser and
right-click I get options provided
by the browser that include things
like "Search Google for this text".
In a flash app those options are no
longer there.
If I right click on a link or an
image I get a different set of
options that are not available in a
flash app. This can be very
frustrating to a user who is not
"flash savvy".

GWT lets you do the same stuff as Flex for the most part, and handles all the browser compatibility issues, AND lets you code/debug in Java with your favorite IDE.
All without having to learn a new language (or pay Adobe $$$ for the flex IDE you'll need to do anything real).
Flex has some prettier UI widgets than GWT has out of the box, but there's a ton of 3rd party widgets (such as GWT-EXT-JS) you can use - or, you can use your existing favorite JS widgets with GWT.
Check it out if you haven't: http://code.google.com/webtoolkit/

I can't be sure if it was myself, or someone else who made that statement but I would definitely be one to say 'use the right tool for the job'.
Flex has a large community behind it, and is well hyped by Adobe's platform evangelism team. Now, as far as replacing JavaScript, that sounds like a very broad spectrum discussion point. Flex is not a replacement for JavaScript. What it does, it does well, however. That is, 3D, drawing, and data rendering whether in chart or table form. Flex also has the power of ActionScript 3 behind it which allows you to do much of what Flash does in cooperation with the MXML frontend components without ever touching the timeline or keyframes.
In a way, Flex is the .NET of Flash and Rich Internet Application development. It uses the same datasource concepts, and component focused design structures which make it easy, and fast to develop in.
The real question is, what are you trying to achieve? What is the end goal?
As to the debugging point, Flex has a true debugger and profiler within the Flex Builder IDE. JavaScript, unfortunately, has different syntax and execution between browsers due to the nature of JavaScript engines in modern browsers. Flex, because it is essentially Flash, uses the same rendering engine in all browsers due to the use of the Flash plugin.
Hope that clears a few things up. :)

Flex has a lot of extra overhead:
New language
Clients must have flash installed (might need to install, might not be able to)
Clients must download flex framework (few hundred kilobytes)
Flex content is not indexed by search engines (contrary to what Google might claim)
Flex has one main advantage:
- Better at building rich interfaces (see Picnik.com, etc)
For example, in Flex, it is easy to create a custom styled dialog box, complete with drop shadows, inner glows, animated open, whatever you might want.
In summary, use Flex if you need the extra richness.

Aside from what's already been mentioned here, another major difference is that JavaScript is dynamically typed and ActionScript is statically typed. Whether that's good or bad will depend on your point of view :).

If you want your web application to look like it's not a web application, Flex is pretty good. You also get to sidestep all the messiness of making HTML+JS look like a real app. For something which is essentially a website, Flex might not be the best choice, but if you really want to write an application which happens to be accessed through the browser, it's quick to develop with and gives great looking results.

You should try Google Gears instead. Create your application, add some Gears to it, and you can greatly increase the speed (and reliability) of your application.
http://gears.google.com/
Essentially Google gears gives you access to two useful things for any application: offline data storage, and native threading control (allowing updates/computations to run in the background and not slow down the users computer).
The really nice thing is, you can use whatever Framework you like for your application, as long as data storage/retrieval and server side communication is handled with JavaScript.
It also allows you to cache whatever files client side you want, which is especially useful when you want to avoid that 'flickering' look in the browser while some needed image is being downloaded by the browser.

A few reasons to consider Flex:
The control library is much richer in Flex than anything you can do with JS/DHTML. The charting controls are killer for business apps and things like the DataGrid / AdvancedDataGrid are pretty well ahead of anything you can do with HTML.
The Flex framework was designed for building applications. It abstracts away the "frame-based" concepts in the Flash Player to really make it easy to build apps. It has a well-designed component hierarchy that makes it easy to extend any of the standard controls. It also has a pretty intuitive event model for handles user inputs and makes it easy to have any of your controls dispatch custom events that can bubble up to parent components or get routed through a central event dispatcher. While it may be possible to do this with JS/DHTML, I don't think it's nearly as easy and it certainly wasn't designed for it.
You can take a Flex application and quickly deploy it to the desktop with the AIR runtime. AIR also offers additional APIs for things like local system access, embedded SQLite DB, etc. Gears offers something similar but it does require a browser. Granted, AIR requires the AIR runtime but at least it's purposed towards building desktop apps.
You can build a very rich, very sexy UI that will knock your users socks' off. As programmers we might not care about UX but our users do. Part of the reason why Apple is having a lot of success lately is because they really value UX and users/consumers are taking note of this.
The biggest con I think is that if you are really used to Java or C#, the ActionScript language will seem a bit limiting. If you're comparing it JavaScript, it's at par or maybe slightly better.
A lot of people will rail on Flash Player (or AIR) because it's not "standard-based." If we were only willing to use sites that were 100% standards compliant and free of plugins, we wouldn't have YouTube today. Or pretty much any other site that does interesting data visualization you can't do with HTML/JS (or at least, not with a sane level of effort). Adobe has been pretty progressive in opening up the Flex framework, Blaze DS (for backend Java development), publishing the AMF spec and starting the Open Screen Alliance to push Flash Player to mobile devices. Flash Player, Flex, Flex Builder and Blaze DS all have public JIRA bug trackers. I'd say there is a good chance that Flash Player itself will be open source within the next 2-3 years. I think Adobe is continuing to move towards being very open and that the criticisms of the platform being "closed" and "proprietary" are becoming less relevant. I think if developers approach Flex/FP with an open mind that they would really be impressed with how it all fits together.

This comparison table was good enough to make me decide what to use . I prefered javascript:)
http://askmeflash.com/article_m.php?p=article&id=11