Are chrome apps 'hybrid apps'? - google-chrome-app

This is my first time seeing the term 'hybrid app'. This is all I could find on the topic. I'm trying to understand if that is just a marketing term.

You can group the app types into 3 categories: Native, Hybrid and Web.
Hybrid apps is a term used for smartphone apps that are not written in the native language of the phone. Another example is PhoneGap, where you write the entire application as a web application (Using html, javascript, css, etc.) which is then wrapped as an app.
Hybrid apps generally have the advantage that they are cheaper and easier to produce, and is easily ported across operating systems, but lacks performance, and some functionality, due to the overhead, and not being run "directly" on the device.
Native apps are applications written using the native code of the device, and web apps are really just phone friendly websites that are opened through a browser.
Long story, short, no it's not just a marketing term, and to answer the title of your question, yes I would say chrome-app qualifies as a Hybrid app

Related

HTML5 web app vs Native mobile apps

Hi I have been recently exploring some of the Javascript mobile frameworks that can be used for developing mobile web apps like Sencha, JQTouch, JQuery mobile etc.
I know the adv and disadvantages of both.
I just need some recent stats which show the market's adoption or opinion.
I tried three ways to develop mobile applications.
First method is to use frameworks that will take your html/css/js files and package them into mobile applications depending on your targets (BlackBerry, iPhone, Android, ...). I used PhoneGap (known today as Cordova). I didn't like it at all because the UI's rendering is so ugly on some devices and the user experience is broken. I had to use it with jQuery Mobile because it gave me a good UI design start. I tried some Phonegap Android generated applications on my personal device and it's really horrible. Some of them got rejected by Apple because of that ...
Second method is to use Appcelerator Titanium SDK. One word to sum it up: Awesome. One language to use (javascript) to create your UI/Controller. It's so easy to learn, so powerful to develop with and it has many out-of-the-box functionnalities (like facebook API, Yahoo Query Language, ...) that will allow you to put in place solutions easily for both Android and iPhone. BlackBerry is coming soon. What I liked the most is that it converts the written Javascript into the targetted platform with the default UI. It's really great. And, above all, the UI is easily customizable (with a css like system).
Personally, I put in place apps that can: Take a photo with the device then send it to a remote server, send messages to twitter/facebook, advanced geolocation, etc.
Third method: Native! It would take time if you target both iPhone and Android but, the big advantage is that you can create anything you want without being tied to a Framework for areas such as games, augmented reality , etc.
In my opinion, if you want to create simple applications with some nice features (weather, twitter feeds, sending on a facebook wall, ...), use Appcelerator Titanium SDK.
It converts your code into NATIVE.
If you have time to spend learning native languages, do it. It's the best way ;)
Hope it helps.
Regards.
I've summed up my thoughts on the whole "native vs. web" discussion in a blog post here: http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-design.html
In a nutshell: You can't get around getting to know the platform you are targeting if you want to provide a great user experience. Plus, you shouldn't try to mimic native UI/UX in a web application, it will only disappoint your users.
here are some pros and cons of native apps vs. web apps:
Native apps:
Native apps have more security
Native apps have higher user engagement, it has higher click-through rate (CTR) among the ad-serving publishers
When it comes to aesthetics and overall user experience, it is incredibly difficult for web apps to trump native apps
you don't have to buy a server and maintain it, therefore, for small businesses it is the ideal solution, not web apps which require a server.
Web apps:
it's cross platform - that means your one app will work on both iphone and android
cheaper and faster to develop and maintain
you will find programmers easier than native apps
updates are easier
Check out this post for some more opinion - http://www.thorntech.com/2013/01/html5-vs-native-apps-which-will-win-the-mobile-app-development-battle/
In particular, the last paragraph is worth noting. If you go down the path of building an HTML5 app, it is worth having some type of background "syncing" of content so you are not always pulling it from the web in real time. The app will be much more responsive if you load HTML pages from disk.
From my experience, the success rate of a native apps are much better than html or javascript based ones. I do not have sufficient numbers to back it up, but these are some issues that may crop up when trying to build html5 apps for different platforms. e.g.
Browser OS or webkit differences can cause unexpected bugs, css issues that could take quite a while to debug.
Your app is running on top of a webkit browser engine which takes up additional resources.
Older or non-smart phone devices may not have a modern webkit engine.
Nevertheless if you have good web skills over native, then getting an app to the market the quicket and cheapest route would be html5. Some apps lend very well for html5 such as data listing, and text content driven apps. I have written a writeup on HTML5 vs Native on my blog. Hope its useful.

iPhone native application vs web application

I am pretty new to iPhone and spent some months on it but.....But i think my learning went waste when i read about web application for iPhone...These can be developed even with a nil knowledge of Objective c...
I am very shocked about that what is need of an iPhone native app....i mean iPhone developers are less required now?
please suggest........
Well it's not that simple.
You can do quite a lot on the iphone with html5 and css3. Especially effects using webkit transforms are really impressive and performant. Furthermore, you can for example access the GPS hardware using javascript.
On top of that it is also possible to write 'enhanced' webapplications using a framework like phonegap (http://www.phonegap.com/) that enables you to use things like the accelerometer or tab controls via javascript as well as makes your webapplication into a compiled app that can be destributed via the appstore (and used offline).
Combine these features with a framework like sencha touch (http://www.sencha.com/products/touch/) or the currently developed jquery mobile and you can write really usefull applications that feel like native iphone apps using mostly just web technology. Another benefit is, that these applications can also be ported to android devices rather easily.
But this all comes at the price of performance. Thomas Fuchs blogged some of his experiences in speeding up web applications for the ipad here: http://mir.aculo.us/2010/06/04/making-an-ipad-html5-app-making-it-really-fast/
Generally speaking it is extremely hard to write realtime or image heavy applications that perform smoothly on the ipad and it is close to impossible to match the performance and smoothness of native core animation effects.
Furthermore things like file access, core data (some hacks exist) or direct access to the 3d hardware require you to write cocoa code anyway.
In my current applications i usually start with a bare-bone ios app containing some webviews. Then i sketch up features using web technology and implement performance critical parts using cocoa
I have no idea what you're talking about. Yes, there are two ways to develop applications that can run on the iPhone: web applications and native applications. Yes, web applications don't require you to know Objective-C. Yes, Objective-C is more difficult than HTML/CSS. But you can't do everything in a web application that you can in a native application. So no, native apps aren't going anywhere any time soon, and neither are the programmers who write them. They are no "less required" now than before.
It's the same thing on the desktop. You can write web applications that the user runs in their web browser, or you can write a native app in Objective-C. There is a place for both, but native apps aren't going anywhere any time soon.
You can choose to take the easier route, if you choose, but you won't end up in the same place as someone who has taken the time to learn Objective-C and written a native app. Whether you need that additional latitude and functionality is up to you. As long as you're making threats like "help me or I will leave this field", I suspect that very few of us will miss you.
A huge portion of possible apps that don't require the highest performance, special device hardware features not yet supported in HTML5, nor the security of compiled code, can be done as web apps.
But if you need the highest frame rates or a lot of number crunching, a native app can run from around 20X to over 200X faster than Javascript in a web app. A native app can also do audio processing and real-time video analysis, background VOIP or GPS tracking, use other brand new iOS APIs (MIDI keyboard support, etc.), and include lots of compiled libraries and other unix code that just isn't available in HTML5.
I've summed up my thoughts on the whole "native vs. web" discussion in a blog post here: http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-design.html
In a nutshell: You can't get around getting to know the platform you are targeting if you want to provide a great user experience. Plus, you shouldn't try to mimic native UI/UX in a web application, it will only disappoint your users.

Will a Safari-based app for iPhone be accepted to the iTunes store?

I'm about to begin development of an iPhone app. The app itself is fairly basic, and I want a speedy turnaround time.
I'm a web developer myself, specialising in traditional web technologies such as PHP/MySQL; I have no experience in Objective-C.
My plan was to create a very basic iPhone app that is just a Safari service that passes some basic variables to a URL. That URL is the app built in PHP and housed on my servers, this way I can create the app very quickly without needing to outsource anything.
My question is whether apps of this nature would be accepted into the iTunes store, or would they be out-right rejected? Anyone's experiences or comments are very welcome.
Thanks
It could go either way, but mind bullet 12.3 from the App Store Review Guidelines:
12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
In my opinion, a simple UIWebView wrapper around your web site comes close to the definition of a simple web clipping. Your approval may very well hinge on your luck in drawing a sympathetic reviewer.
It really depends upon your application...These kinds of application have been approved in the past but again I am saying that it depends on many factors.
Try to test your app in every possible manner and also keep in mind the memory issues.
Best of luck!!!
Should be fine - its called a web app and there is software out there that will do just this for you.
All you need to do is to make a UIWebView and put your web app into it.
Also look at http://jqtouch.com. That gives you some idea of what you can do web-side. :)
http://www.netbiscuits.com/559
Native Hybrid Apps
Native apps can interface more deeply
with the mobile handset modules and
sensors to create an even richer
mobile user experience. Netbiscuits
provides pre-build native apps
frameworks for all major mobile
operating systems to be easily
customized for the needs of
enterprises.
Get "2in1" by combining the power of
mobile websites and native apps by
wrapping mobile websites into hybrid
apps and list them easily in all major
app stores of providers like Apple,
Nokia, Google or Samsung to open a new
mobile distribution channel. The
benefits of this approach are fast
time to market, minimized development
and maintenance efforts and maximum
mobile cross-platform technology
coverage.
Yes, it will be accepted as long as you stick with HTML, CSS, JS and Obj-C on the client side. You still need to wrap it in an iPhone app. In my experience, the best way to this is to use http://www.phonegap.com/ or a similar framework.
You'll have the option of deploying you app through iTunes or as a regular web app (you users will be able to create a link to your web app right on their springboards)
It SHOULD be accepted, granted you test test test and make it look just like a native application. Also you'll have to make sure that your server is never down, or if the application can't reach it just display an error message. You also have to keep in mind that there are a lot of iPod Touch users, and they don't have access to the internet all the time. Which means that chances are you'll get a BUNCH of 1 star reviews

What can be achieved in a native mobile application that can't be done in a HTML5 web app?

I've talked to a lot of people recently who say they are expecting to stop writing native mobile apps and start writing web apps once HTML5 gets more fully baked in mobile OSs. I just finished my first HTML5 deep dive, and I'm not yet convinced.
Will HTML5 work as a replacement development platform for native apps, or are there certain things that require targeting the native runtime?
HTML 5 is not magic. it adds a lot of long awaited functionality to HTML and to traditional web applications, but still - many things are still out of it's scope.
for example:
accessing your contact list
getting bluetooth data
making use of an OS specific function
for those (and other) functions - you would still need to write vendor specific applications.
One thing which necessitates the native app is the access to more features on particular mobile devices; it's not guaranteed that that all the features of the device is exposed via javascript interfaces to HTML5. In that case, you are forced to use whatever native APIs available.
In short, no. HTML5 provides an appropriate toolset for a large range of applications, so I see it growing popular in this arena (for portability reasons). I except there will always be application developers (and users) that prefer the native look and feel though, and there will always be scenarios in which bare-metal coding is required, or a 3D engine is more practical to utilize using system level API's.
HTML5 is a compelling technology stack though, especially when coupled with some cross-platform API management (e.g., PhoneGap).
Native applications will continue be able to use new device features first, before they are eventually supported up through to the browser so for cutting edge development, native will still be the way to go.
There is also an issue with discovery - right now users are accustomed to using apps and can find them in their devices app store. Searching for a web app seems unnatural to a typical user and that wont change any time soon. That's why a lot of apps that would seem to make more sense as a web app are still being produced as native apps.
Conclusion: Native apps will continue to be necessary, but mobile web app development will grow and may well replace more native app development as time goes on.
It will make some native apps unnecessary but not all of them. Not really much more to say about it :)

Iphone App vs. Offline Web App. Which way is the smartest?

I think about starting from scratch building a small application fullfilling two technical requirements:
should be usable on iPhone
should work offline
There are two obvious alternatives here to choose between
A real iPhone application with offline capabilities
A web app using HTML5 offline, Google Gears or similar
Having no iPhone app development experience (I don't own an iPhone), i wonder which way would be the easiest to go?
What are the learning curves for building offline HTML vs building an iPhone app?
Honestly, it depends what your app is going to do.
MobileSafari supports all the HTML5 offline stuff, so you could store data in a clientside SQL database, cache the application clientside, etc... The mobile Gmail app is probably the most notable example of that, giving you full-featured access to your Gmail even when offline. You can also use geolocation through JavaScript APIs that were added in 3.0. Web Clips let your web app share the home screen with native applications too. There is more on using web apps on the iPhone on this Stack Overflow post.
Obviously, doing a Web app will be of interest to people who like dealing with HTML, CSS, and JavaScript (and possibly whatever language is running server-side). It is possible to do really neat stuff with offline Web apps, but its performance won't be as good as that of native apps, especially on pre-3GS devices.
Developing a native application will require you to learn Objective-C (or C# as soon as Mono Touch is available to the masses) and pay a $99 fee to be allowed to test on-device and deploy to App Store. A lot more of the system is exposed to you through the various APIs, such as the camera, compass, multitouch, and so on.
Objective-C is pretty simple to pick up if you're familiar with Java; you only really need to get used to the square bracket syntax and memory management and then it's pretty straight-forward.
Then there are the hybrid systems, like PhoneGap, which expose more of the device's APIs, provided the Web app runs in a special container app. It is also crossplatform, so you could also deploy the app on Android and BlackBerry if you wanted to. This still requires you to pay the App Store fee, but if you're more familiar with Web development, this gives you the best of both worlds.
I can't tell you too much about HTML apps in general, but I can tell you that the API for the UIWebView is extremely minimal, and of course there is much less you can do than in a native iPhone application.
An HTML5 offline app would have security issues as you would have to hard code your oauth secret into code that anyone could see ( by clicking view source, or inspecting in Firebug ). You could simply use http auth, but then you get the ugly "from API" credit with every tweet sent from your app, and also that ugly http auth popup from the browser.