Ionic for production apps

@jazzfanatic I completely agree with you on the part that as a developer you should have a certain philosophy when using bleeding edge tech. I too have that philosophy and I am well aware of what I’m doing in that sense. The Ionic team is working their asses off to create a kick-ass framework while tackling all the cross platform difficulties one can encounter.

I fell in love with the great team vibe (which is still here), good looking UI and built-in AngularJS support but to be completely honest, I wouldn’t choose for Ionic for my next app project. Not until there is a stable 1.0 release at least. Until then I will follow every development that is going on with this framework and the Ionic team itself and I will be using Ionic for my own non-critical app projects / hobbies and contribute/test where I can. But when it comes to industry grade stable and usable software, in my opinion, we aren’t there yet.

At the moment of this writing, the scrolling and tapping issues keep stacking up and from using the nightly version with many well known issues fixed, I’m forced to fall back to beta1 and start hacking the pancake out of this release myself to fix the particular issues I’m facing (forms not scrolling at all, content resizing issues when Android keyboard was open, etc.). Correct me if I’m wrong but in my opinion there is too much focus on ‘new features’ instead of (cross platform) framework stability and bug fixes.

As to the ‘contractor’ part; we are indeed working for a client with this particular project. This client isn’t forcing us to do anything. We always do things our way, that’s what clients appreciate about us since ‘our way’ has a high quality standard.

1 Like

@Robin Yea, while we make no guarantees there won’t be regressions from commit to commit in master, we need to expand our physical device testing to reduce these issues. We will get there in time.

As for Android, we are going to be getting rid of defaulting to the Android WebView and switching to Chrome underneath which will help in a lot of ways (consistency, performance, stability).

The unfortunate part to a lot of this is if you don’t use Ionic, you basically have to redo all of the stuff we’ve been agonizing over for the last 9 months…and trust me, you don’t want to go there :smile:

Thanks for hanging in there as we keep working toward a solid 1.0!

2 Likes

@max The most interesting thing I’ve experienced while using the master is that things that used to be working in version A can be broken in version B and vice versa. I’d expect that you would be working ‘forwards’ e.g. improving / fixing / extending the framework instead of breaking stuff that was working before.

Of course as a developer I know that using the master can result in having broken software but this happens more often than I would expect.

As it turns out, my expectations of Ionic were probably too high when I first started using it. I assumed it would be ready for a production app while it was still (back then) in alpha state. Unfortunately my colleagues are now being proved right that I shouldn’t have used it in the first place. :frowning:

Luckily my use cases haven’t been too complicated and I have a little time left before my apps need to be released, but I’m in the same camp… I really respect the work that the team is doing and I knew it was alpha / beta software when I chose to work with it. But time is getting short for things to become really solid, which can at times be frustrating. Really really hope beta 2 or even a final 1.0 isn’t too far off.

Holding on though… the potential here is just too great. Keep up the good work guys.

@Robin while we make no guarantees there won’t be regressions from commit to commit in master, we do need to improve our physical device testing to make sure we catch issues faster. That will improve over time.

Stay tuned, we are doing a bit “issues” check to verify our tap and scroll fixes not only fix previous issues, but actually make the hybrid experience better than anything you’d get without Ionic. It might seem like we are just creating issues, but really we are trying to stabilize all of the wonkyness across iOS, Android, and soon Windows Phone, along with improving the UX of hybrid apps (through our upcoming keyboard improvements).

Oh, and we are moving to Chrome for Android instead of the old Web View, which will also improve stability, performance, and consistency going forward.

Thanks for all the help!

2 Likes

I really don’t see any real alternatives if you are doing hybrid apps using HTML/CSS skills.

The issues you mentioned also exist in Jquery Mobile, Sencha Touch, Kendo Mobile etc. They may be more matured but doesn’t mean you are not going to run into issues with older devices. I too wish the community here actually respect developer’s wishes and stop asking for Android 2.3 improvements. You are not going to make money from the 15% or so users left on these devices and they are probably gone by the time you actually release a popular app!

I really feel Angular is miles ahead of other JS frameworks, that is why I am sticking with ionic despite its flaws.

2 Likes

Hi Max,

Can you clarify what you mean by “we are moving to Chrome for Android” ? Do you mean you are going to require 4.4 or do you mean you are going to embed Chromium ?

Yep, like @hitmantb says, many issues that we are going to be fixing, are actually hybrid issues in general that plague the other frameworks today but won’t plague Ionic as much (the new keyboard and scroll stuff is really a step forwards, I’m very excited about it!).

And about 2.3…I am this ready to just 100% cut support for it. Supporting it is a waste of everyone’s time. I think we as developers need to channel some of that confidence we had years ago in hating IE 6 and refusing to target it :slight_smile:

1 Like

@PBK the idea is Chromium or Chrome would replace the core WebView for 4.0+. We are making some progress here, but don’t have anything to announce yet.

When that happens we will drop 2.3 support probably entirely.

We are currently working on two large, complex, production-state apps with Ionic. One that includes a group video chat (using WebRTC - we had to build a phonegap plugin for it), and another that includes lots of different screens with a very complex logic.

My suggestion is to keep everything modular. Learn about modular angular project structure. Use yeoman and write unit tests. If you are building multiple apps, try to write your modules as generic as possible so you can share them between apps. Test on real devices all the time! And care about performance.

For anyone having problems with Android - just use Crosswalk. It embeds chromium in your app. Adds ~18mb but makes the app work like in iOS. Supports Android 4.0+ and works with Cordova.

I don’t know why crosswalk isn’t featured in Ionic’s docs or something. It’s amazing and no one knows about it.

And seriously, who the hell cares about 2.3? Ionic should drop support for it now.

6 Likes

Thanks for the insight @alon_gubkin! Great tips.

Regarding ‘who cares about Android 2.3’… Let’s just say not everyone lives in a country where the latest and greatest smartphones are mainstream. There are a lot of countries out there where older smartphones are still very popular.

For example, I live in Curaçao. A year ago, Blackberry was still the huge market leader over here. The companies (our clients) are demanding cutting edge fancy apps (like they see with other modern companies world wide) but the market is still stuck on old devices. Result: we need to develop ‘as good as possible’ apps for older devices. That’s where Android 2.3 support is highly appreciated.

Luckily, Android is eating big chunks of marketshare form Blackberry lately. That enables us to rule out Blackberry development for new projects and even focus on Android 4.* support but it doesn’t mean Android 2.3 isn’t being used by our target audience, unfortunately.

TL;DR: There are other countries out there where the latest and greatest doesn’t have the largest market share.

2 Likes

@alon_gubkin thanks for the great insight. We do want to start using Crosswalk, can I email you with some questions about that?

And Robin, I didn’t know you lived there…let me see if I can use this as an excuse to come fly down and help you with your app :wink:

You’re more than welcome to drink a beer at the Neverwoods office @max. You can even book it as a business trip :wink: There is a direct flight with American Airlines…

Edit: crap I didn’t enter a full URL to Neverwoods. That’s fixed now.

Hi!

I must agree with @Robin. Here in eastern Europe countries people have mostly Android smartphones, like many Samsung Galaxy S2 which comes with a stock Android 2.3.4 Gingerbread, so we have to support them. We are not expecting that every fancy graphic, transition,etc feature will work, but the basic usages would be good like click(tap), some gestures, slides, proper navigation.
I know that developing to older platforms its time consuming, but some basic supports for them will make Ionic a lovely framework.

Cheers

1 Like

I’ve heard much about Crosswalk and am now also trying to integrate it with my projects. Been pushing for it quite a bit [here][1] and [here][2]. If Ionic would include it by default in the CLI or describe integration in the docs, I think it would cut down on support queries and issues on GitHub, which would in turn free up the dev team to do other things.

Only downside is I think Crosswalk support starts at Android 4.0.
https://www.scirra.com/blog/133/introducing-crosswalk-the-new-way-to-publish-to-android

Still! That would cut down supporting excentricities between Android from 2.3, 4.0, 4.0.1, 4.1, 4.2.3.5.1, 4.3 and the zillion other versions out there to just two: 4.4/Crosswalk and 2.3. A marked improvement!
[1]: Has anyone integrated an Ionic project with Crosswalk or Android ChromeView?
[2]: https://github.com/driftyco/ionic/issues/1119

@coen_warmer yes Crosswalk is Android 4.0 and up, the Android APIs appear to be the reason why.

As previously mentioned the beta is the better release to use. It’s Chrome 34, supports external debugging from chrome inspect (enough of a reason to use Crosswalk) and all the other nice modern apis, hello websockets and webworkers.

Latest Cordova plugins work fine, I’m using Camera, File, Device, Barcode Scanner, a custom plugin that accesses Bluetooth among others.

I’m using Crosswalk Cordova 5.34.104.4 on a Cordova project (upgraded to Cordova 3.4.1) that I use the Cordova CLI to build/debug. In short, BACKUP before doing anything:

  • I created a clean Crosswalk Cordova project (ARM version) for testing on a real device. If you use the ARM emulator it should work but I gave up on that a long time ago and use Genymotion which is x86 so substitute the x86 version if targeting that

  • Copied the cordova.js (v3.3) into the Android platform_www directory replacing the existing js (don’t need this step when they merge the pull request for 3.4 refactor)

  • Replace the existing CordovaLib with the Crosswalk Cordova project’s CordovaLib (xwalk lib is in this directory)

  • I updated any Manifests.xml to force them to be at least min 14 but it may work without doing this

  • Patched cordova/lib/build.js because, it won’t compile xwalk correctly with CordovaLib due to the custom_rules.xml.You can’t get rid of custom_rules.xml because the CLI needs the app apk to be located in the ant-build dir for launching/copying/etc to device/emulator

module.exports.get_apk = function() {
    if (hasCustomRules()) {
        var binDir = path.join(ROOT, 'ant-build');
    }
    else {
        var binDir = path.join(ROOT, 'bin');
    }

On the app side:

  • I had CORS issues so created a manifest.json and that resolved it
  • Crosswalk has orientation change issues and some devices (see tablets) annoyingly default to landscape, so I placed the following in the document ready code because I only support portrait (change approach as required).
  # Ensure portrait orientation https://w3c.github.io/screen-orientation/
  if window.screen?.lockOrientation?
    window.screen.lockOrientation("portrait")

Hopefully this helps someone get a start.

3 Likes

@max: Of course! maybe you could even hire me :wink:

@Robin: Actually you have completely changed my mind. This is a big reason to support older versions of Android. The problem is that the Android browser on < KitKat is the IE6 of the mobile web.

Chromium WebView doesn’t support 2.3, and therefore Crosswalk doesn’t support it too. It might be possible to solve this issue for older versions by using GeckoView instead of Chromium, the engine behind Firefox that does support 2.3. Although last time I checked GeckoView was at very early stages.

2 Likes

Great thread, discussing the big problem of Android webview. Well for those who want to try crosswalk, good way to try is to use Intel XDK. You can package your Ionic app with crosswalk without any command line interface. Simply import your Ionic app’s www folder in XDK and use “Crosswalk for Android” option under “Build” tab of XDK.

Just use Ionic to develop app and use XDK to build your app for Android.

Pros - Smooth interactions like as if you are on iOS.
Cons - App size increases hugely as chromium based webview gets added to your APK. my app was 2 MB earlier, now with crosswalk APK is 18 MB and once app gets installed on phone, it takes around 50 MB :frowning:

Regarding support for 2.3, I think its important to support it as highlighted by @Robin but at the same time I agree with @max viewpoint too that supporting 2.3 will be a waste time and effort as it just hold 14% market share and anyway its pie will further reduce in some time, so supporting a going platform does not make much sense.

Regards,
Gaurav

1 Like

Is Ionic ready yet for production apps ?

Yes!.

Damn you 20 character limit on ionic forums

2 Likes