html5

off.the.walls

can html 5 and css 3 be used to create mobile apps or are these different from interactive websites for mobile? only starting out and looking to get into mobile so if someone could let me know that'd be awesome

ChRoMe

off.the.walls wrote: »

can html 5 and css 3 be used to create mobile apps or are these different from interactive websites for mobile? only starting out and looking to get into mobile so if someone could let me know that'd be awesome

Yes... but there is a caveat in the sense that not all HTML5 features will be available across all mobile browsers (basically the same situation as desktop).

off.the.walls

Thats cool so what language is usually used to create mobile apps? and ios apps?

Draco

Native iOS apps are built with Objective-C.

Native Android apps can be built using Java and/Or C++.

renegade909

Check out http://phonegap.com/. I've never used it before but you can create apps using HTML, CSS and JavaScript and then it converts the code to whatever device you're creating it for, iOS, Android etc.

Graham

I'd have a look at:

PhoneGap http://www.phonegap.com
Apache Cordova http://cordova.apache.org
Sencha Touch http://sencha.com
Appcelerator Titanium http://appcelerator.com

off.the.walls

thanks for this guys

ChRoMe

Some of my colleagues have used Phonegap for commerical projects in here, and they were not impressed. Once you get into anything more complicated that a basic CRUD app, the browser can't render fast enough.

There really is no replacement for good old native code.

maxmarmalade

ChRoMe wrote: »

Some of my colleagues have used Phonegap for commerical projects in here, and they were not impressed. Once you get into anything more complicated that a basic CRUD app, the browser can't render fast enough.

There really is no replacement for good old native code.

We are currently using phonegap to help us build a HTML5 and it's quite good. The news app Pulse is an example of a HTML5 app and it's extremely fast.

ChRoMe

maxmarmalade wrote: »

We are currently using phonegap to help us build a HTML5 and it's quite good. The news app Pulse is an example of a HTML5 app and it's extremely fast.

Start nesting a lot of elements to do a complex UI and get back to me

Not to mention browser inconsistencies.

maxmarmalade

ChRoMe wrote: »

Start nesting a lot of elements to do a complex UI and get back to me

Not to mention browser inconsistencies.

But there are so many examples of HTML5 apps with complex UI's that work very nicely. We have had some problems with browser consistencies but not many, especially on newer phones. I bet you are using HTML5 apps and you don't even realise it;)

Graham

I suppose it's like any kind of development, an App can perform badly whatever it's written in.

It does appear to be easier to write a mobile App badly in HTML5 though, perhaps that shows that people are more willing to have a go at cobbling together an HTML5 app than a native App.

I would lean more towards the 'complex apps should be native' school of thought though.

ChRoMe

maxmarmalade wrote: »

But there are so many examples of HTML5 apps with complex UI's that work very nicely. We have had some problems with browser consistencies but not many, especially on newer phones. I bet you are using HTML5 apps and you don't even realise it;)

Of course, but they are not HTML5 apps masquerading as native mobile applications. Its a huge difference!

The Corinthian

Graham wrote: »

I suppose it's like any kind of development, an App can perform badly whatever it's written in.

True, but this should not be the principle reason why html5 or framework (such as PhoneGap) based apps are poorer performers.

There are two basic models for how they work:

• html5/framework codebase -A-> interpreter (VM) -B-> Native OS
• Native codebase -C-> Native OS

Straight away you should spot where a performance loss is going to happen in the former, as you've got this extra layer of processing taking place.

Another factor is how that codebase is sent to the VM (be it a browser or custom interpreter). It may be optimized at point (A) - compiled - it improve efficency, or may simply be interpreted from the original code, which is naturally less efficient.

Finally, you'll get differences between the last leg of the journey, between (B) and (C), in that the latter has been optimized by Apple, Google or whomever wrote the original OS, while a third party may produce a less efficient bridge to the native OS. This certainly was not unusual in the past; Microsoft famously kept secret certain API's that allowed them to better interact with Win32, and many third party implementations turned out to be less than optimal. Even having access to some native functionality, to begin with, can vary with many app frameworks (I came across one such case, a few years back, where Appcelerator would have fitted the bill nicely, but for the fact that in-app purchases was a requirement and this was not supported by Appcelerator at the time).

Note that some frameworks claim to compile directly to native apps, but again the above concern would still apply.

As a caveat, I did say that bad code "should not be" why an app is less efficient. However, in the real World, certain languages do lend themselves to writing bad code. In Web development PHP has long been criticized for this - not because it is necessarily bad itself, but because it's so easy to get into (compared to many other languages) that a lot of half-arsed, cut 'n paste merchants ended up cobbling together Web solutions that were as often as not, disasters.

As to the holy grail of 'write once, run on many', ChRoMe pretty much summed it up. Differences between OS's, or browsers, are such that you can quickly end up with a nightmarish labyrinth of if and switch conditionals, so as to accommodate your requirements and these differences. Most of these are UI based, but many are simply down to the different way the different OS's handle (or not) things; phone ID's being a case in point.

Maintaining such a monster can quickly become more expensive than maintaining two separate, native, codebases.

Once the initial hype and hopes of html5 and the various multi-platform frameworks died out, it left us with the now broadly accepted conventional wisdom that once your app reaches a certain level of complexity or expected requirements, that you're best going native, for both performance and human resource reasons.

maxmarmalade

Interesting read, the Sencha guys rebuilt the facebook HTML5 app and it actually performs better than the new native facebook apps http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/

jimmycrackcorm

maxmarmalade wrote: »

Interesting read, the Sencha guys rebuilt the facebook HTML5 app and it actually performs better than the new native facebook apps http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/

It's a good demo but those guys had to jump through hoops to manage an expanding dom. The sencha demo itself crawls on my browser

Theinsideman

I cannot speak to iOS but for Android I'd stay away from HTML5 and the PhoneGap, Cordova,Sencha Touch, Titanium,jQuery Mobile, Adobe Air crowd.

As a web developer I went down the HTML5 route for app development and bitterly regret the decision, I really wanted HTML5 apps to work so I could use my existing skills. In the end it was just a waste of time. I've tried most of the above. Some are pretty decent (Titanium, Air, jQuery Mobile) but the major problem is when your basic app starts to grow and needs some more bells and whistles HTML5 just cant deal things like threading performance, advanced layouts, memory management, advanced graphics (any sort of animation or 3D).

HTML5 apps are ok for testing the water but if your serious just buy the books and go native. Its quicker in the long run.

My best advice is to hit the books.

For Android my books (in order) were..

-- Head First Java - O'Reilly
-- Beginning Android - O'Reilly
-- Professional Android Application Development - Wrox

If your getting someone to build the app for you i'd be VERY careful. The responsiveness and performance of HTML5 apps in my experience are not good enough to satisfy a very demanding public.

Theinsideman

The other thing I forgot to say is that although Titanium is decent I found it so complicated to use that I honestly didn't see the point.

Graham

Theinsideman wrote: »

The other thing I forgot to say is that although Titanium is decent I found it so complicated to use that I honestly didn't see the point.

If you've any experience with javascript, Titanium would be a lot more familiar to most devs than native Android/iOS.