UIWebView wrapper vs. native components - ios

I have been doing some research before beginning my first iOS app, and I was wondering - what are some advantages and disadvantages of creating a mobile web app and wrapping it in a UIWebView vs. native components and classes?
I've read about OkCupid discussing their issues with the web view and caching.
Can anyone share their thoughts on what might be the most appropriate route?

As a user, I prefer to use an app made natively for the device, rather than web app. I consider it somewhat lame when I download an app from the app store only to discover that it's simply a UIWebView. The only reason (as a developer) that you might consider doing this is because you do not have the resources needed to make a native app, yet you would still like to distribute your web app in the same way as you would a normal, native application.
In other words, if you can, don't make a web app. Using the native iOS frameworks gives you a more rich set of libraries and tools, and generally produces an app that feels more natural and works a lot more seamlessly.

Related

Need to convert a Sencha Touch + NodeJs + MongoDB app to Native apps

Based on our user feedback, we would like to convert our Hybrid app built using Sencha Touch on Node JS & MongoDb to pure Native apps for both IOS and Android. Having built a lot of logic and data, what are our most optimal choices to keep as much of backend REST API code as possible and save on time, cost and effort.
Thanks
If your API endpoints are properly detached from the rest of the app, you will only have to rewrite the native logic for iOS and Android. If everything is intertwined then the first thing you need to do is separate the API calls into their own self sustained application.
Before discarding ST be sure you are getting the best performance possible:
1.- build for production with sencha CMD.
2.- be sure you are not over-nesting components (more than needed).
3.- use container when possible instead of panels
4.- if possible avoid nested lists
5.- be sure you are not creating components over and over again when you can show / hide them.
6.- be aware of memory leaks.
7.- Smart DOM query e.g this.down('myPanel') instead of Ext.ComponentQuery.query('myPanel')
8.- Make the UI to respond while server side is processing stuff (use of masks and stuff like that)
I'm sure there are more things you can do to get the best out of the framework, research them.
I believe Sencha Touch is awesome, look for some of the demos they have and if the performance of those apps are like the one you have and you still don't like it, then ok move to native.
In good ST apps users aren't able to tell if it's hybrid or native.
UPDATE
BTW you are using something like Cordova or PhoneGap to package it right ?

Native Windows Phone app vs Jquery Mobile + PhoneGap?

I am new to mobile programming, and I want to build a mobile app to fill few forms, offline, and then sync them later, when internet access is available, with a database on an online server through a VPN connection.
At first, I thought about learning Windows8 Phone App development, but then I heard/read about Phonegap and Jquery Mobile! and I am a bit confused which one would be better to use, considering two things:
1- Which one you think would be good for my app's functionality
2- Which tool would be more beneficial on the long run (in the mobile programming world).
Any advice would be very much appreciated.
With these functionality I don't thing you don't need many mobile dependent features rather you need more web features. For your first question, answer could be that technology in which you are more comfortable. But it also depends how you want to sync your data. In background or when the app is open. If you want to sync data in background that means app is closed, you have some data to send in server, and internet access is there, then you'll need some native windows phone code. In that case if you use phonegap ultimately you will need some native code to deal with it, may be you'll need to write a plugin to communicate between phonegap and native code. And if you don't need background process, if you want to send data to server only when your app is opened,phonegap can work like a charm. It'll be easy to communicate between 2 web technology.
For your second question, ofcourse phonegap is great technology to learn to deal with cross platform. If you need to make apps not only for WP rather for all platforms then phonegap is great. Having said that it's necessary to mention phonegap has it's quirks too. Native code always has it's benefit. Phonegap can't completely overcome native code. But if you are willing to compromise a bit, then it's easy to learn phonegap,a familiar tech than all those platform dependent techs like objective-c, android etc.
(N.B. I'm not an expert, it's just my experience so far)

Can web app for ios run as smoothly as native?

Is there a framework that will allow to create web apps for iOS that will run as smoothly as native app?
I've checked demos of Sencha Touch http://www.sencha.com/products/touch on my iPad there's visible delay for touch events and for how precisely they are recognized. The feeling isn't the same as for native apps.
Is there other frameworks or technics that will allow to provide same experience as native apps?
It depends on your app. If your app is a hard-core heavy-duty 3D game, then no. If your app is primarily displaying static content ... like a web page or collection of photos, you might get close enough.
Think about what experience you want to achieve first. If you want a cross platform application and you want to avoid the stores (App Store, Google Play, BB App World), then by all means, consider a web app.
Other things to consider, how much data do you estimate the user will need store locally (HTML apps are more limited in this respect); how much functionality is lost when there is no network connection, and does this loss of functionality make the app unusable.
Like the answer by #RichardTurner, if you need the kind of performance you find in the higher end games (Infinity Blade or Modern Combat 3), then native is the way to go.
Figure what you want, then you will have better idea of what technology to use.
NO. Native apps will perform better every single time over web apps. If you want a smooth experience, go native. Also consider that some people have older model iOS devices and performance will be even more difficult to achieve on those devices in web apps.
Here are a few things to consider with a Sencha app vs a native application.
You were browsing a Sencha Touch application online and chances are it wasn't a "packaged" version so you would have to download each source file individually.
With Sencha, you can utilize Sencha CMD to package an application which essentially builds a single minified js file containing only the required components from the Sencha library and your application (smaller DOM). You can also look into a production version which takes advantage of appcache. You'll see some performance increases here.
A packaged native Touch application will contain the actual JS, CSS, etc. files as part of the applications source, so their is no downloading from external resources.
You have to consider that any HTML5 application is going to have a ~300ms touch delay, more on that here: http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

Is Blackberry WebWorks a good development choice?

This is kind of a dumb question but I've aware of classic style JDE development for Blackberry but I've never tried using WebWorks. BB website says that it's possible to build applications for both smartphones (OS 6.0+) and tablets - sounds fantastic, but what's the price?
Is here anyone using WebWorks on a daily basis and capable of describing pros and cons?
Thanks in advance
I would suggest using it if you build webOS applications before hand. It make porting to the blackberry a breeze.
Use WebWorks if you know html5, Css3 and javascript over Java and C++.
I haven't ran into any issues with the webWorks, ported two applications without running into any issues. Its your standard html5, css3 and javascript you love with blackberry APIs
WebWorks is a good development choice, particularly as it allows easy migration from earlier BB OSes to BB10. It's mostly standard web technologies (HTML5, CSS3, etc.) and the team seems focused on making it perform well (e.g. hardware accelerated WebGL graphics) while at the same time providing BlackBerry-specific APIs to make WebWork apps capable and with good UX (e.g. you can make it look like a native app).
For native apps, you should look into Cascades. This is a modern development environment with good tooling, accelerated graphics, and APIs for building snazzy apps. It's the one that will most be a "BlackBerry app".
AIR remains an option, but I would recommend WebWorks over AIR, as even Adobe is migrating from Flash to web technologies. Likewise, you can develop Android apps on BB10, but unless you are keen on Java programming, you will get more cross-platform support from WebWorks (or even AIR) so there's no particular reason to go the Android route.
WebWorks API is limited, for example it does not have socket, so you cannot port a VNC (UltaVNC, tightVNC ..) to it but you can do it with JDE.
For UI, WebWorks allowed me to write UI of acceptable quality quickly and easily, a thing that I have never succeeded with JDE.
Still on the UI side, I can make use of multi-touch (PlayBook), I don't think this one is possible with JDE.
So depending on your needs you should go either WebWorks or Native, having heard that Java may not be supported in BB10, and Air may not be future proof (Adobe favors HTML5 instead of Flash). Android appli has some lag on start up when it is run on PlayBook, some customers are sensitive to the initial even just one time slow response time.
I'm a huge proponent of Webworks. Ever since I've started using it, it quickly became the default option for my apps going forward. Especially for someone like me who is just writing a few apps on the side, I don't have the time to do it in c++.
The apps I'm writing revolve around home automation. They are client/server based from the get go.
Here's why I like it:
First and foremost, native API support. I can very easily create my own active frames, import invocation from other apps (think camera, stuff like that). I can export portions of my webworks app as an invocation card! Which means I can write say 3 unique apps (in this case home automation, lights, thermostat, security cameras). And I can very easily pull features from each app into the other. Maybe I want to turn my lights on in the living room, I can also import the camera card from my IPcam app and view the results, without having to add that code into my lights app and maintain two separate code lines.
Rapid design. Since I've been dabbling in html since I was a kid, it's now very easy for me to whip up an appealing UI in little time. Because web engines these days offer good performance in terms of graphics capability, I also can make apps that behave very fluid.
Considering the time to make something beautiful, it's hard for me to leave webworks and go for something in c++. Also the big plus is often these apps I'm making are intended for multiple devices, namely an app on my phone and being hosted on my personal website. By maintaining two slightly different css files, most of the time I need no code changes, just load a different css depending on if it's a phone or a pc. (Exactly what you'd do if you were developing a regular old website).
For that matter, I actually don't put my code on the device, I host all of my html and javascript, images etc on my server. The webworks app is just the config.xml pointing it's source to my server, and an icon. A glorified website bookmark on the homescreen, only difference is I can use native API and there's no browser bar in the app.
Also, this way I can still continue to edit the same single codeline on my server, and instantly apply changes to the in-browser app and the on-device app.
This is especially cool if you're designing an app where all of it's data is out in the "cloud", say you work for a publication and you want to write a magazine app which pulls content from your servers on the net.

Are there any limitations of Flex 4.5 mobile apps on iOS?

I've looked at a few demos from adobe that show apps built with Flex 4.5 running on iOS from simple list views to video capture. This has made me wonder if its an effective solution to build cross platform mobile apps.
For those of you who have taken Flex 4.5 mobile for a spin, what is your impression on the capability and performance on iOS. Is there anything you can't do with Flex 4.5 mobile that you couldn't with a native app? Are there any limitations?
The mobile story in Flex is quite strong, in my opinion. It is what has attracted me to the platform and what seems to be bringing life into the Flex community.
The experience for developing apps in Android and iOS is quite fantastic, actually. The velocity in which you can dev is blazing and the abstractions provided by Flex (data binding, state management, skinning, etc) give you the ability to totally rock your app.
The performance is better than I had expected. It is not as great as a native app, but it certainly gets the job done. The ability to share code and UIs between Android and iOS more than make up for it in most cases.
There are, however, limitations. For one, you are not using the native widget set. You are using the Flex widget set. This means that you do not get the native look/feel. For this reason, it is best to build apps that look like YOUR app... not a Flex app or a native app. There are lots of popular examples in the app stores that work this way... and a Flex app pretty much requires it in my opinion.
There are also a lot of APIs not available to you. Flex provides hardware abstractions for the most popular APIs (video, audio, accelerometer, positioning, webkit, etc) but platform specific APIs are still missing (contacts, calendar, system notifications, etc).
At that point, it is worth asking what your app needs to do. Does it have a lot of native interfacing? If so, Flex might not be right for you. Find the APIs you need to talk to and make sure Flex has an abstraction for you. If it is a data-centric display/edit app, then Flex is a strong fit.
Hope this helps :)

Resources