I Want To Ask basic question of dojo toolkit usage
Can i use it for desktop application development these applications run on windows platform may or may not have internet connectivity
If So Than How
Kindly Answer In Detail
Thanks!
Well, Dojo is javascript framework/component collection. So your question could be answered here:
Can you do Desktop Development using JavaScript?
Adobe Air won the race in this question.
In Wikipedia article;
Dojo Toolkit is an open source modular JavaScript library (or more
specifically JavaScript toolkit) designed to ease the rapid
development of cross-platform, JavaScript/Ajax-based applications and
web sites.
That means there is no way to use desktop app development but again in Wikipedia;
Dojo can be used in JavaScript-based Adobe AIR applications. It has
been modified to meet AIR's security requirements.
Sitepen, a Dojo consulting company, has made an Adobe AIR application
called "Dojo Toolbox" using Dojo. It includes an API viewer, and a GUI
to Dojo's build system. Normally, the build system is run from within
Rhino, but in this AIR application the build system can be run from
AIR, without use of java.
So when we look Adebe Air Wikipedia page;
Adobe Integrated Runtime, also known as Adobe AIR, is a cross-platform
runtime environment developed by Adobe Systems for building Rich
Internet Applications (RIA) using Adobe Flash, Adobe Flex, HTML, and
Ajax, that can be run as desktop applications or on mobile devices.
So, YES.
This depends somewhat on what you mean by "desktop application".
If the app can be implemented as a self-hosting web app, e.g., local DB for storage, run an embedded server, etc. then sure–it's just a web app, coincidentally hosted on the same machine.
You could run it in an Air app, but why not just use Air then?
Related
With the tremendous progress going on with web technologies, does it make sense to bring these to desktop and client-server applications.
We typically build our applications using winforms and wpf and the code base is like 100k+ lines of code.
Is it worth exploring the option of HTML5 UI and Node.js backend and use a framework like the chromium embedded framework or node-webkit.
The reason I am asking this is that the support from Microsoft for the desktop technologies is questionable (wpf, metro apps ...).
At least with the technologies I listed, it is easy to port to make the application work across all platforms and companies like microsoft and google are pushing for html5 and javascript.
A number of companies are using CEF and similar web-based technologies for desktop applications.
Steam from Valve is CEF based (https://developer.valvesoftware.com/wiki/Chromium_Embedded_Framework), as is
Spotify https://community.spotify.com/t5/Help-Desktop-Linux-Mac-Windows/Chromium-Embedded-Framework/td-p/912377 and
Adobe Creative Cloud (I believe using Adobe Brackets Shell over CEF and incorporating Node.js) https://github.com/adobe/brackets-shell
Advantages for them are that server side content can be delivered to the application, as can UI updates, and the client machine is fully accessible.
We are using it for product authorization and delivery, the advantages of CEF for us are dynamic update from the server of both UI and business logic in Javascript, and because CEF allows calls from Javascript to C++, we can access files on disk and Registry entries that pure Web code cannot.
So I would recommend looking into this.
For ordinary Line Of Business applications, I would suggest no, don't go half-way.
I used to do advanced UI development in WPF, and it was amazing for its time (a decade ago), but nowadays it is really amazing what can be done all within a modern web browser. And yes, Microsoft's support of full-powered desktop technologies is like a ghost town (I suspect they just want to get their 30% commission on apps in their store, so they've shifted focus to UWP).
Why do you need to create a hybrid desktop/web application? Unless you have a specific (and important) need to break out of the browser's sandbox, why not go all the way and create a web application? Modern browsers have a lot more capabilities now, and they keep getting better.
There are also many technologies and frameworks that really help to make large-scale web application development a lot easier than it used to be.
Recently, I started learning about mobile app development frameworks called Mobile Angular UI, IONIC, Sencha, KendoUI. They help to develop mobile app using html, javascript and css.
That's when it got me thinking if the above frameworks are hybrid or not.
A Hybrid framework is one which helps to create mobile app using html, css and javascript. But so do mobile apps. So actually what is the difference between Mobile web app and Hybrid mobile apps.And are the above frameworks Hybrid or not??
Originally posted here: Cedcommerce
First of all, let me guide you what actually is a native app and what we mean by Native vs Hybrid mobile apps. A Native app is an application which is built specially for a particular operating system, different application for a different operating system using native language of that particular device.
If you’re still confused about Native app development, it means creating an Android or iOS mobile application using the respective company’s (in this case Google and Apple) SDK(Software Development Kit) and tools.
Two most widely used operating systems are Android and iOS where Android dominates the market with a whopping 86%, while iOS comes at a distant second at 12%.
Native vs Hybrid Mobile App
Worldwide Smartphone OS Market share
Image Credit: IDC
If you are developing for Android, that means writing your apps in Java (or Kotlin) and for iOS, writing your apps in Objective-C or Swift. The main tool Xcode is the integrated development environment in which your developer will create your native app.
Another type of less known Mobile app is called Hybrid app. Hybrid app development means using a 3rd party hybrid platform (examples include React Native, PhoneGap, Ionic, Cordova, or Xamarin) and using web technologies (HTML, CSS, and Javascript) to write a hybrid app that runs on both iOS and Android.
When it comes to Native vs Hybrid mobile apps the hybrid apps can run on any platform – (Android and iOS) – with the same code. This may sound like an advantage over the native apps because writing one app is cheaper than two but don’t get excited so quickly as I will highlight why not to choose the hybrid apps as we go down.
While 79 percent of consumers would retry a mobile app only once or twice if it failed to work the first time, only 16 percent would give it more than two attempts. The poor mobile app experience is likely to discourage users from using an app again. Source
Users experience tops all the other features when it comes to mobile apps, a bad UX will surely help you get your app deleted and there is hardly any chance the user will ever return to your app again.
See How Native Apps provide Faster and User-Friendly Checkout
Talking about mobile apps, the number of downloads surely represents how good and popular an app is but the key factor is the user retention. And It’s a known secret in the mobile development community that mobile app retention is pretty low. According to TechCrunch, one in four mobile users only use an app once.
Retention Curves for Android Apps
Source: Quettra
Native apps are far more superior when it comes to Speed, Responsiveness and therefore scores more in the user retention segment. Native applications have the best performance, highest security, and best user experience.
Talking about native apps a simple yet top-performing solution for your online store is MageNative App
Native vs Hybrid Mobile Apps:
Built-In Features: A native app has better and faster access to device’s native features and inbuilt utilities such as camera, GPS, calendar whereas hybrid app struggles a bit.
Speed: Hybrid applications are web applications (or web pages) in the native browser, such as UIWebView in iOS and WebView in Android (not Safari or Chrome) but native app runs as a standalone application (no web browser needed). Due to this dependency on a native browser, hybrid lags behind a native app.
Responsiveness: Native apps are more responsive compared to hybrid apps since they follow the design pattern for unique platforms but hybrid apps are same for all the platforms.
Offline usage: Since Hybrid apps are dependent on a native browser they are unusable without internet connection in contrast native apps like media players, games, navigation works well offline.
Security: Native apps are stored in an application store and the approval process stops buggy or harmful from being published whereas no such store exists for hybrid apps.
Importance of Security Testing
Source: QArea
App Stores also provides good accessibility if a user wants to search any particular app. Besides, before publishing the app you have the possibility to encrypt everything with standard tools, hide the implementation and so on.
Better UX standards: As I mentioned earlier the problem with a hybrid app is that even the most brilliant user experience architect cannot truly build an app that caters to the two dominant user types: iPhone users and Android users whereas Native app follows the specific UX/UI standards for creating Android or iOS apps, which allow users to easily understand the interface and navigation of the apps. An example of a native app:
Native vs Hybrid Mobile App
Bottom-Line: Native vs Hybrid Mobile Apps
It’s time to finish the Native vs Hybrid mobile app battle with the conclusion that ultimately the user and his needs decide which framework will work best, for me Native apps are better than hybrid apps in almost all the major aspects.
The choice depends on you, if you are looking for a simple app with some basic functions and can handle daily simple tasks go for hybrid app but if you want a more complex app which can make full use of the device’s inbuilt features and handle complex tasks then the native app will be the best choice and you won’t regret.
Anything that wraps HTML/JS code into a native app is a hybrid. The difference is that the hybrid app relies on the UIView (think of it as a minimalistic web browser) to show all the content, while the native apps usually use the UIView only for browsing and have everything else coded in the native language. Basically, the hybrid app is always laid on the UIView and everything happens inside it. Similar to opening a dedicated web page in fullscreen and having access to all (or most) of the native phone features (vibration, sensors, notifications, etc...).
Think of a simple button made using HTML vs. a simple button made using Java/Objective C/C#... That's what hybrid frameworks are trying to make work and look as similar as possible. Hybrid apps require none (or almost none) native language coding.
"So actually what is the difference between Mobile web app and Hybrid mobile apps?"
None of the frameworks above say that. More specifically: none of them mentions mobile web apps with a contrast to hybrid apps because those are the same thing, just different semantics. What the frameworks offer is:
web version of the app (web app)
mobile version of the app (mobile app)
Bottom line:
Anything that is written in HTML/JS/CSS and functions as a native mobile app is a hybrid app.
This article shows the difference between the native app, hybrid app, and a "mobile web app": http://blogs.telerik.com/appbuilder/posts/12-06-14/what-is-a-hybrid-mobile-app-
Be careful, the last one is nothing but a website optimized for phones that can't be installed on a phone as an app, and it should definitely not be mixed with phone apps (native or hybrid). Excerpt from the URL above:
Native apps are built for a specific platform with the platform SDK, tools and languages, typically provided by the platform vendor (e.g. xCode/Objective-C for iOS, Eclipse/Java for Android, Visual Studio/C# for Windows Phone).
Hybrid apps, like native apps, run on the device, and are written with web technologies (HTML5, CSS and JavaScript). Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage.
Mobile Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor.
Having all that in mind, all four frameworks you listed above can create mobile web pages (or mobile apps, as they call them), but seems like only Ionic is able to build hybrid apps that you can actually install on the phone (couldn't find relevant info on Sencha, but now you know what to look for).
Agree with all the above said.
Will just add/sum up the pros and cons of Hybrid Mobile Apps (Apache Cordova and React Native).
Apache Cordova
Pros
High development speed
Coded in web development technologies (HTML, CSS, Javascript) that yield cross-compatible iOS, Android, and web software (just one web developer needed)
Frameworks are availalbe that emulate native app UI elements (i.e. buttons, menus, etc.)
UX is very close to a native experience using UI elements that mimic native app behavior
Access to the smartphone’s hardware API, facilitating device functionality (e.g. camera, push notifications, geolocation, and others)
Cons
UX is not as good as it is on native apps (300ms click delays, phantom clicks while scrolling, etc.)
The more complex the application, the slower it works due to the various wrappers and libraries employed
Doesn't work offline
Animations are difficult to implement in the UI
React Native
Pros
High development speed for the React-based apps
Web application built with React.js can be easily converted to a React Native mobile app, and some source code can be reused
Native user experience
Application looks and feels exactly like a native mobile app for a specific platform
Reduces development costs
Experts in React Native can usually build both Android and iOS apps
Cons
Relatively new technology (limited open-source solutions)
Limited with regard to visual design
Not ideal for complex projects like mobile games or apps that require a high load (significant computations)
If you are interested in comparison of Hybrid vs Progressive vs Native app development this article is worth reading.
What's the best way to turn an HTML/Javascript web app into a self-contained app that can be run from Windows (and maybe Mac/Linux) PC's? Preferably without any installation, ie a network share.
I have looked into Chrome and Firefox Portable, but these require write access to the folder, so are unsuitable for running off a read-only network share.
(some background, I have a big javascript app but many of my clients are using IE6 or 7. Their IT teams won't allow Chrome Frame, or other modern browsers).
node-webkit sounds most promising.
From the README on the github repository:
node-webkit is an app runtime based on Chromium and node.js. You can
write native apps in HTML and Javascript with node-webkit. It also
lets you to call Node.js modules directly from DOM and enables a new
way of writing native applications with all Web technologies.
If LightTable can be built with it, certainly a web application can be ported and run natively using it.
I know this is a bit late, but what about Sencha Desktop Packager?
http://www.sencha.com/products/desktop-packager
It was primarily developed for ExtJS apps, but it should work on any JavaScript app.
We had a similar requirement and ended up building a dedicated web browser using QT. However if we'd known about the Sencha Desktop Packager before we may have gone for that.
Like most .NET developers I was watching the keynote for the Build Event in Anaheim, Cali and had a questions about the new support for building applications for Windows 8 using JavaScript, HTML5 and CSS3.
They showed quite a few examples and even said the new Windows 8 marketplace was written using these technologies. The only thing that kind of has me guessing is when they put JavaScript in the same category of C#, in the sense that you could program your windows apps (have access to .NET directly) using JavaScript.
Obviously being a web developer this was pretty awesome news considering some of the applications I've built using JavaScript, HTML5 and CSS3.
The question I have is whether or not the applications we build for Windows 8 are truly web compliant? Can we build apps for Windows 8 and turn around and launch them on the web? Can web applications that are currently online access some of the features they demoed?
Like I said this would be an awesome advancement. Not to put down Silverlight, which I have written quite a few applications for, and the way it works in blend rocks. And the thought of replacing JavaScript with some of my apps that are written in C# is not even an option.
Is this just to get "web" based developers to develop for Windows or is this a cross platform solution for building applications?
Slight clarification, the Javascript/HTML5/CSS3 windows programs run on a new layer called WinRT (Windows Runtime), not .Net. All of the new Windows Metro style apps will be built on top of this layer rather than the older .Net. If your app utilizes the WinRT features, obviously you would need Windows to run the app. It is your choice if you want to integrate those features. (Obviously it depends on what you are trying to do with your app) I believe you can build an all standards compliant app and have it run on the system just fine - you just won't be using any MS specific features. In that sense, it would be like a webpage that you launch as an app.
Other notes:
MSIE currently uses some -ms specific prefixes until those features are accepted by W3C and given official cross browser names. Not unlike -webkit-border-radius,-moz-border-radius and border-radius.
The HTML5 uses some features such as grids that are not yet implemented in most browsers.
Microsoft includes a lot of Javascript libraries to make it easy to build apps. Many of these are jQuery based. Some are Windows specific. Not sure what the licensing is to use them elsewhere. I assume the jQuery is allowed to be portable whereas the Windows ones, wouldn't make sense to use outside of WinRT.
#Matt
To clarify the "converse", standard web app written in HTML5 running as a Metro application:
Assuming your application isn't doing "Bad Things" then yes. The Metro app environment is restricted by default. In order to access non-local resources (e.g. a website) from within the application in HTML5/JS, you must create what is known as a "Web Context".
The Web Context allows an application access to the internet and unsafe resources while preventing that same context from accessing privileged resources, like the Windows Runtime APIs.
This ultimately means that if you need to host a Bing Maps widget and want to get GPS information from the system, you would need the following:
an iframe inside the page (which is Local Context by default) hosting a Web Context that contains your Bing Maps widget
use window.postMessage to send data between the Local Context and the Web Context (contained in the iframe)
Call the Windows Runtime API for accessing the GPS location of the device from the Local Context mentioned above
This application model affords you the security that no website opened inside the JS application will have rogue JS executing Windows Runtime APIs to scrape your data. This is probably the biggest area that you will have to re-architect in an existing web application to get it running as you must push data between contexts if it comes from an unsafe resource.
Short answer is no -- apps built using the WinRT stack won't be able to run in a "normal" browser. I'm not sure about the converse though -- if a standard web application written with HTML5 can be run as a Metro app.
I am looking for Titanium Appcelerator alternatives for Desktop application development with HTML and JavaScript. I want to convert a web app to a desktop application. Hence, there will be a lot of server interaction. Appcelerator was a good choice, but it looks like the company is no longer interested in the Desktop SDK. Also, ajax request from Appcelerator does not retain cookies.
I read that Adobe Air can be used for desktop app development, but I don't want to use flash.
How good is XULRunner? Will it allow features like Growl notificaiton and creating tray icons?
Will I be able to develop applications using mostly Javascript and HTML in Qt?
I started looking into Titanium for desktop dev. I liked the concept but not the implementation. I then stumbled upon chromiumembedded and have been mostly very happy with it. It's basically a web browser control based on chromium.
http://code.google.com/p/chromiumembedded/
It's written in C++ so you can do all the low level OS stuff you want(Growl, tray icons, local file access, com ports, etc) in your container app, and then all the application logic and gui in html/javascript. It allows you to intercept any http request to either serve local resources or perform some custom action. For example, a request to http://localapp.com/SetTrayIconState?state=active could be intercepted by the container and then call the C++ function to update the tray icon.
It also allows you to create functions that can be called directly from javascript.
My biggest challenge has been debuging. It's very difficult to debug javascript directly in CEF. There's no support for anything like Firebug that I am aware of.
Appjs (appjs.org) looks very promising.
You could also check Bowline which is another alternative: http://bowlineapp.com/.
Although it's not officially intended for general-purpose use, a number of people have had success using brackets-shell for HTML/JS desktop apps. It embeds Chromium (CEF) and adds APIs for menu bar management and file IO. It also embeds an instance of Node.js so you get access to all its APIs for launching processes, etc. It's MIT-licensed and available for Mac & Win, with a Linux version currently making rapid progress.
As I mentioned, it's not officially a general-purpose app shell, but someone wrote a detailed blog post about how to customize brackets-shell for your own uses.
I notice that the other answer about Titanum says CEF is hard to debug. I'm not sure if that's true in Titanium, but in brackets-shell it's easy to debug JS – you just open http://localhost:9234/ to load a full instance of the Chrome Developer Tools (including breakpoints, profiling, etc.).
TideSDK is a continuation of the old Titanium desktop http://www.tidesdk.org/