Related
I am very new to react-native. I am having good experience on Cordova/ionic framework for Hybrid app development. I am just exploring react/react-native. One concept which I like is "virtualDOM" There are a couple of questions here. (some might be layman questions. But, just want clear my thinking.)
Because of VirtualDOM, do you think the memory footprint will increase?
I am trying to develop a small app which plays/pauses/stops a video. and starts/stops the recording of the video. Do you have any plugins available for accessing media devices?
Does react-native support all device native features?( like Address Book, file system, geolocation, vibration, battery status, device native calendar, capture, contacts, device, device motion, SMS). If so, can you point me to some links where I can access the device specific features?
Of course a React Native app is slower and uses more memory than a full native app. However, React Native still seems to be pretty performant in many ways.
There is a library called react-native-video which supports all you're asking for. There might however be some issues on older versions of android. https://www.npmjs.com/package/react-native-video
A lot of these features are supported by React Native: https://facebook.github.io/react-native/docs/actionsheetios.html#content (Check APIs in the sidebar). If something is not implemented by React Native itself, probably somebody else already did and there is a npm package you can install (and link with rnpm for linking android/ios code).
If you want something custom, you can still build your own Java/Swift/objectiveC component and wrap it to a React Native component. (https://facebook.github.io/react-native/docs/native-components-android.html and https://facebook.github.io/react-native/docs/native-components-ios.html)
I've been playing for a while with phonegap,
did some tests on my Android...
It's pretty nice.
My questions are:
What is the best (your favorite) framework to develop native mobile applications with web client side (HTML / JavaScript / CSS)?
How easy is to build and maintain those applications in multiplatforms (iOS / Android / BlackBerry) parallel?
Does it has many exceptions between different platforms (iOS / Android / BlackBerry)?
What are the requirements to develop my app for iOS?
Should I need a special IDE with special SDK? Must I have a Mac?
We're currently building a native iOS application using React Native. It would be a shame if it wasn't included here.
Pros:
React treats the DOM as an implementation detail. This made the transition over to native UI very natural. It also removes the need for HTML/CSS when writing a native app. All you need is native components, written in JavaScript.
Native components! The fundamental native components have already been bridged over to JavaScript, and there is a community busy at work bringing everything else over. The thing is, if you know or are willing to learn some Objective C or Java, there is an easy process to add any native module (or third-party module) to React Native.
Quick iteration. There have been over 2600 commits to the master branch since it was open-sourced in March.
You get all of the benefits of normal React: a virtual view layer, diffing, declarative UI creation, fantastic developer experience, and a stellar community.
You can build for multiple platforms from the same repository, reusing much of the same codebase (application logic, mostly).
Cons:
It's still young. There are a few features that require jimmy-rigging, a third-party library, or custom Objective-C/Java to get working.
Some great third-party libraries that are tied to the DOM or Browser API still don't work on React Native, including React Router.
The biggest pains have had to do with XCode and Apple's developer program, but there's no way to get around that.
How easy is to build and maintain those applications in multi-platforms?
React Native for Android was open-sourced on September 14th, 2015. I haven't used it yet, but here's what I've been able to learn so far. Update 10/21/16: React Native for the Windows Universal Platform was announced earlier this year. That means you can now use React Native to build apps for Windows desktop, Windows phones, and even Xbox!
React Native is not intended to be a write once, run anywhere mentality. They adopt a learn once, write anywhere paradigm instead. iOS is a very different platform than Android, so sincere effort needs to be put into the design for either platform. The native APIs will also be different.
So, you will end up re-writing code for native components and APIs. However, much of your application logic can be re-used. In fact, React-Native is organized so that you can keep both your Android and iOS applications in the same repository, so that you can re-use the same code when possible. I think it's brilliant, but only time will tell. According to them, it works well so far.
By the way, a team at Facebook built an iOS app using React Native, then turned around and built the Android version in three months using 87% of the same code base.
What are the requirements to develop my app for iOS?
Currently, you need a Mac and XCode in order to deploy. Currently there are very few ways around this. According to this issue and from conversations on Slack, once deployed, you can actually develop from a Windows or Linux machine. Facebook is also working on open-sourcing all of their Nuclide packages, which, according to their presentation at F8, will include tools to package and build without XCode.
Overall, React Native has been a stellar experience. It is, in my opinion, head and shoulders above anything else currently out there. The feeling within the community is also very positive. I can only assume it will get better with time.
If your app is going to be very simple (for example a port of existing web app) and you need it only on one platform and it does not need integration with phone-specific features you may want to simply use a WebView on the selected platform. If your selected platform is iOS and you don't have any programming skills, you can follow these steps:
Download xCode on your Mac,
Download this simple web view app project: https://github.com/nomtek/iOSWebViewApp
Open the simple web view app within xCode
Add your HTMLs to the project
Run it :)
Advantages of this approach:
Simple setup
No extra libraries to load - the application starts much faster
This is one arena that keeps changing, and it only gets better. Googling at the moment of your interest would be the best bet. At the time of this writing, I am watching the following right now, in no particular order:
Enyo JS
Sencha
NativeScript
Meteor
PhoneGap
Appcelerator
these are the options
Phonegap : http://phonegap.com/
PhoneGap is a free and open source framework that allows you to create
mobile apps using standardized web APIs for the platforms you care
about.
.Download the Phonegap.
Coronalabs : http://coronalabs.com/
Corona SDK builds rich mobile apps for iOS, Android, Kindle and Nook.
Build high quality >mobile apps in a fraction of the time.
Appcelerator : http://www.appcelerator.com/
Appcelerator is the only mobile first platform that enables enterprise
to create, deliver >and analyze their mobile applications.
Phone Gap does look like your best option, if you are trying to use javascript to build a mobile app
Yes, you will need a mac, because you will need to install XCODE (https://developer.apple.com/xcode/) - appleĀ“s own IDE.
If you invest a bit in learning a new script language, Coronalabs would be your new weapon of choice. With it you can build native (cross-platform) apps and you can use a webview to add your HTML/CSS/Javascript stuff if you need it.
At the moment React Native is the best option for creating mobile apps in JavaScript.
Here are my top 3 reasons:
Very active development and updates - After all it originated at FB
Negligible learning curve
Great online resources
I was able to write a small but functional app without previous React Native experience and even deploy it to the Google Play Store all within 2 days.
Also one great benefit that i see with React Native is that you can "eject" your app at any point in time and continue to work on it in Android Studio or XCode. This could be a big relief in projects that start simple but could get complex over a period of time.
Here is short tutorial I put together while building my first react native app for Android:
http://geekycentral.com/creating-a-native-android-app-using-javascript-hello-react-native/
I need some expert information about ActiveX and some valuable experience reports from those that already used it.
The situation is the following: ~90% of all of our applications are created as web apps with ASP.net WebForms. We're now in the process of switching to a more modern approach, creating rich client JavaScript apps. However, In one of the recent projects, a strong requirement from the customer is the ability to directly print to a (previously configured) printer attached to the user's workstation. Yes, no printer dialogs, print previews etc.. It has to be fast.
Obviously this is a scenario where you would rather use a desktop app than a web based one. Still, we would like to benefit from our existing web dev knowledge and are therefore considering to write that very specific, isolated printing functionality as an ActiveX control (IE dependency is not an issue).
Now, since the word "ActiveX" alone causes disgust for some people, I'd like to hear what might be the potential problems at using such a (old) technology or do u directly consider me to make it as a desktop app and completely forget about it?? Or are there alternatives??
The primary challenge you'll face is the learning curve; beyond that the biggest problems are the potential for you messing up and opening a security hole (for example, what happens if a malicious third party loads your activex control on their phishing site? can they use it to print things?), etc.
For the learning curve, I highly recommend looking at FireBreath, which can be used to create browser plugins that work on IE (as an ActiveX control) as well as Firefox, chrome, safari, etc (as a NPAPI plugin). Though ActiveX is an "old" technology, it's still used extensively in the modern day; for example, Flash, Silverlight, Quicktime, and other "plugins" like that are all activex controls in IE.
Take a look at http://www.chromeexperiments.com/
I think JavaScript is very close to have everything that RIAs can offer.
What's missing from or for JavaScript to make it a viable RIA development alternative?
At the moment the only thing you really can't do in javascript/html is sound and video. This is changing with the HTML5 standards which includes sound and video as first class html elements.
The other thing Flash has going for it is a (slightly) more level ground between browsers. All browsers implement things slightly differently but a flash page renders pretty much the same across all.
Eventually (even now maybe) you will be able to do everything flash can in the browsers, the only question will be if and when all browsers support what you need.
While chromeexperiments.com has many neat technology demos, and I especially like some of the games there, it's still very much far off compared to what's being done with Adobe Flash/Air and Microsoft Silverlight.
I'm a long time web developer and I experienced the pain with browser in the early days, where none of the browsers cared much about standards. Today, it's very different. Not only do we have a lot more browsers, there are small incompatabilities in all of them which in some cases can be problematic. Normally applies when you're doing a pixel-perfect design, which you shouldn't do anyway ;-)
One of Silverlight (and WPFs) promisses are separation of concerns when it comes to delegating work between the developers and designers. While the tooling is not yet optimal, it's improving in every release of Visual Studio and Expression Blend. Being able to actually see what you're doing in a designer is helpful for a designer.
I have traditionally been a pro-web, it's more compatible, works everywhere, standards based and just the decent way to do things. It's only when you have benefits towards alternatives you should pick them, but normally they should be additions to an existing implementation built on web, this applies particulary to information systems, line of business, etc.
You don't want to get tied down to a specific version of a runtime or viewer, that will get us back to the problems we have today with far too many web-systems only compatible with Internet Explorer 6.0. It's a nightmare in many organizations today, their IT-systems doesn't work with anything other than IE6 so they are stuck, without any means of upgrading expect when they can afford replacing the existing systems.
If you develop a solution today, will your users be able to use it 3 years from now? What about 5 years? 10 years? Will they require a special-purpose-PC-setup that sits in the corner, running an old version of the OS and RIA/Viewer runtime? Sort of like how the IT-systems of the police runs all around the globe.
One project I'm currently working on (hobby-project) I initially started out with a desktop application, using Windows Forms and SQL Server Compact Edition for local storage. Then I figured I wanted to be more available to users, so I changed my plans to be an ASP.NET MVC project. Later on, I realized that it was about time to get more experience with Silverlight, so I ended up doing the whole thing with Silverlight 4 and Windows Azure. I'm amazed how productive you can be with Silverlight, though there is a pretty steep learning curve for someone who's traditionally built Windows Forms and Web Forms solutions.
What is missing from the HTML+JS technologies? Tools & Frameworks! One of the most important things for any developers is familiarities between projects. There shouldn't be a difference in the tools and frameworks you use if you want to develop a 3D game, Line-Of-Business Application or an interactive web banner. Reduced development time is another critical point, today's AJAX frameworks is way better than what we had to write ourselves back when XmlHttp first arrived with IE, so we're slowly getting to some place where we can do really cool RIA-solutions with nothing but web-technologies. I think HTML 5 is the beginning of something good, though it's still pretty far off compared to what we have today with Flash and Silverlight.
There is an adage that "anything that can be done in javascript, will eventually be done in javascript". Certainly, lack of a good designer for this sort of interactive app is one problem. It's important to note that javascript is just a scripting language, where silverlight and flash are frameworks that each include their own programming language. In fact, Silverlight 1.0 used javascript as it's language. So the real question is whether HTML+javascript will get to a point that Silverlight and Flash are not needed. I could see that happening in the post-HTML-5 timeframe, but that will be a while.
I don't think we are close to knowing the answer to this yet.
Personally I could argue either side pretty equally.
Javascript:
Pro - Almost universal. Newer phones even support it.
Con - Can be hard to manage. Still varies from browser to browser to some extent.
RIA:
Pro - Typically richer tools/better management.
Con - Not as close to universal. Flash is very widely deployed and Silverlight is gaining ground. More control for developer (I'm thinking of games, etc.)
Bottom line: either approach can be made to work. Each has strengths. Each has weaknesses. I don't expect a clear winner for a long time, since both sides will have proponents who won't want to switch camps.
Yes, of course.
jQuery+HTML5 makes it easy. jQ has animations, AJAX, keyboard and other stuff. HTML5 has canvas, audio and video. What else you need?
I think that there needs to be greater uniformity of the performance of JS engines across browsers. The cool things on chrome experiments are made possible by the super-fast performance of V8, the JS engine in Chrome. These things are not so exciting in many other browsers.
The advantage that is held by Flash/Silverlight is that they are browser extensions that do their work closer to the actual computer and are thus less constrained by the characteristics of the browser.
JS applications will be limited until all browsers have performance approximately the same as Chrome's.
I'm currently writing my first real application in Flash (Flex, actually) but it's only because i needed to have complex imagery from PDF, and PDF2SWF works much better than PDF2SVG.
so, in this particular case, it wasn't about the platform capabilities (neither of them could handle PDF), but about an accessory tool (transforming PDF to a usable vector format)
The benefit of Silverlight is that, with Silverlight 4, the same code base can be used to create a web hosted application and a full trust desktop application*. This is of great benefit to designers of Enterprise applications where the user must be constrained (to a certain extent) in what they can do and how they interact with the application.
So what you might see is that consumer websites go down the Javascript route, while Enterprise applications stick with Silverlight and Flash.
* I don't know about Flash and Adobe Air, but I would suspect that Adobe are working on this too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 months ago.
Improve this question
As a win32 developer moving into web deveopment the last few years, I found the
web desktops based on extjs very interesting.
Coolite Desktop (broken)
Extjs Desktop
Puppy Web Desktop
Wikipedia list
Lifehack list
Windows 3.1 desktop (broken)
Do you know about others?
Without any experience of developing applications as web desktops (and I am not promoting extjs, only impressed...),
I have to say I like the concept.
What do you think, is it useful?
Edit Dec 30 More about the subject here:
are-webos-practical-yet
I find it an interesting experiment, but I don't really find much added value in it.
The desktop concept works for an operating system. Most people use one operating system. They are familiar with how it works and what to expect in terms of navigation. That being said, having a desktop at an application (or site) level adds another navigation model that the user must learn. If they are expecting it to be the same at their OS (which it won't likely be), then it can lead to confusion because it doesn't work exactly like what they're used to - although it looks like it should.
NO.
Also, Uncanny valley of UI.
I think they serve as purely tech demos, I don't see the web desktop getting any traction unless Google jumps on this and offers all their major apps (Google Office, Gmail, etc) as apps within a web desktop.
Of course the whole desktop methodology doesn't exactly fit the browser mentality very well.
Really it doesn't look like a huge step forward. I don't care if the desktop runs in my browser vs my actual PC. Desktop environments continue to suffer from a lot of problems.
First, I really need some way to declutter and organize open apps around my personal real-world "logical" tasks. Desktop environments all display a single, poorly organized static list of apps. I feel like I have lost my mind half the time during a busy work day. I often get a feeling synonymous with the "why did I come into this room!?!" feeling when I can't keep track of where I am in the desktop environment, or why a given app is even open.
Attempts have been made to address this by grouping items by application. For example, in Windows, grouping all the Microsoft Word content in one group on the taskbar. The thing is, I need things on the task to actually correspond to my real world tasks. Granted, I don't expect the UI to read my mind, but if there was some really slick way to group multiple instances of different apps together and identify them with one task, that would be awesome.
Another problem with desktop environments is their performance. They continue to attempt to push the limits of what hardware can do. Often, they go to far. As Jeff points out, for a developer, I want my tools to work fast. I can't stand waiting for some GUI widget to load so I can code, or for that matter browse the web or write an email. This, in my opinion, is why straight up command line development continues to thrive and why many of us don't want to give up Windows XP for Vista.
If Vista can't get this right, performance is not going to be improved by having a "web desktop".
Like others have said, this has been around for a while. I think if it was gonna take off, it would have already. I don't think it's a matter of technology catching up, I think it's a matter of developers not wanting to put time into a tried-and-didn't-take-off technology.
Is the desktop a good way to organize your apps? Most people I know don't use their desktop very often, it's rarely actually visible. The Start menu in Windows sees much more use and it's analagous to a list of browser bookmarks.
Also, my opinion is that Silverlight will allow better browser-based user experiences with less development time.
In my opinion but people will never use them as a desktop replacement, there are too many quirks and potential pitfalls to be an actual replacement or even useful.
They do make an cool demo of ajax-y technologies and serve as a guide on how to develop apps with that desktop feel (which I'm not sure it's worth it), but not much more.
The demonstration of capabilities is amazing. To create a desktop environment in a web browser is a beautiful indication of what browsers and javascript are capable of.
With that said, I believe it will (and hope it does) die as a viable development platform. Currently browsers don't provide the processing power that a desktop does and ease of development is much greater for desktop than browser "simulated" desktops.
the desktop metaphor in a web browser is neat, but
the first link was still downloading images after 1 minute so i closed the browser
the second link came up instantly and looked really good
for intranet applications this might make sense
for task-based site with multiple tasks this might make sense
this isn't that new of a concept - BBS software had this 20+ years ago, and extended it to the web 8-10 years ago; the metaphor was not very popular because that's not how people use the web...yet!
No, because the web is the OS, the platform is the browser.
I use several web based application including Google Docs, Gmail and so on. Not all of them are from the same provider. I access them all using my browser.
Forcing me into using a "web desktop" is like the portal thinking of the ISP's ten years back - forcing users into your own "world" to make them use only the application you provide. Instead of just acting as a gateway to reach all the possible choices out there.
IMHO, this is why web desktops will fail. The OS of a PC is there to tap into all the possible resources of your desktop, in the same way the browser is for the internet. Web desktops is to me equal to install yet another OS on your current one and limit yourself to use only that.