Cross with a platform.....
Cross Platform or Cross with a platform? It is a similar question as 2B or not 2B... Where on one hand it would be nice to have a single source that would work cross platform, it is also imperative that when used in isolation, each platform can deliver the maximum that you can get from it. It would be nice to be able to create an app that works on both iOS and Android. Which Android?? ARMv6 or ARMv7? Android 320x240, 480x640 or a Tablet? The one that has CarrierIQ spying on you or the ones that doesn't. Which dessert will it be? Cupcake, Ice-cream sandwich, Honeycomb, eclair, etc..
In the 90's and 2000's when web browsers were becoming mainstream and important, most companies were working on compatibility between the different html tags. Where IE did not have canvas and Mozilla had a canvas. Things look very much similar, the mobile platforms are in the same race, iOS and Android are the two players that are considered at the moment. Microsoft is a contender, but due to the sandboxed development environment that Microsoft insists upon, it is still not a widely accepted platform amongst developers.
So where does the issue lie? The issue is should any framework that relies on cross platform abilities severely impair the framework under the name of cross compatibility? One of my ever favourite platforms, frameworks one that I seem to have a love/hate relationship with, CoronaSDK is a very good example. I love it for the ease of use and simplicity, there is none other that can offer anything simpler. Even scratch is *slightly* complicated and tedious (plus it converts code into *java* my least favourite language)
In iOS, Apple introduced Gestures a couple of versions ago. It was as simple as defining a UIGestureRecognizer and there are a couple of recognizers available that can be used and not only can the gestures be used, one can also get the velocity, magnitude of the gesture. Which in the current touch handler method is tedious. These are some points in the framework that make the whole experience of reapid development seem like a dredge and almost feel like there is nothing wrong in using Objective-C to get this accomplished. In fact there will be more power available via objective-C than with this framework.
I am not dissing the framework, it has some really powerful features, but the inability to utilise the powerful API that is available like the MFMessageComposerViewController that can be used for composing emails and sms, the URI settings in the plist for being able to associate the app with a particular file extension, being able to tap into the UIViewAnimations for pagecurls and other FX, being able to tap into the CoreGraphics for some amazing graphic filters and rendering, is all lost and the question is "at what cost?"
It is in a way segregated with a dedicated engineer for the Android platform and a couple for iOS like Eric Wing, etc show dedication on the part of Ansca, but... as far as the user base is concerned, where majority are only after how can I make two physics bodies collide better, there are many other developers that are looking at how to use the UIKit features of Corona better.
The Android side of things will get left out, yes, they will as these then become very specific to iOS only. To achieve the cross-compatibility (if really ever required) the *emulated* UI components (which do not work for Android at this point anyways) could be used. Plus when someone works on a cross platform app, they would *not* really want the iOS theming or the Android theming, but a custom theme that would flow across the two devices to provide a single uniform look and feel.
Any framework developers, add the stuff that is easy to include, even if it available for one platform only, The line between cross-platform and making users cross because of a platform is very thin, if clients pay to implement apps on iOS, who really cases about an Android port that would not have worked anyways due to the ARMv6, ARMv7 and then simulator issues. If there was no Android option, would it change things? Maybe...maybe not... It is nice to be able to Kindle a Fire in the Nook. It is the *latest* phenomenon, but given the choice between professional projects vs games/fart apps on these devices is the difference between 10-100K vs struggling to get $0.99 from users for the game.
In the 90's and 2000's when web browsers were becoming mainstream and important, most companies were working on compatibility between the different html tags. Where IE did not have canvas and Mozilla had a canvas. Things look very much similar, the mobile platforms are in the same race, iOS and Android are the two players that are considered at the moment. Microsoft is a contender, but due to the sandboxed development environment that Microsoft insists upon, it is still not a widely accepted platform amongst developers.
So where does the issue lie? The issue is should any framework that relies on cross platform abilities severely impair the framework under the name of cross compatibility? One of my ever favourite platforms, frameworks one that I seem to have a love/hate relationship with, CoronaSDK is a very good example. I love it for the ease of use and simplicity, there is none other that can offer anything simpler. Even scratch is *slightly* complicated and tedious (plus it converts code into *java* my least favourite language)
What are the impediments?
I am working on a couple of projects that are *iOS* only and rely heavily on touches and gestures. In each one of those projects, I have ended up writing code to handle touches and then nested code to handle a substate of a touch and further on with different states. In simpler words, it is "sehr kompliziert"In iOS, Apple introduced Gestures a couple of versions ago. It was as simple as defining a UIGestureRecognizer and there are a couple of recognizers available that can be used and not only can the gestures be used, one can also get the velocity, magnitude of the gesture. Which in the current touch handler method is tedious. These are some points in the framework that make the whole experience of reapid development seem like a dredge and almost feel like there is nothing wrong in using Objective-C to get this accomplished. In fact there will be more power available via objective-C than with this framework.
I am not dissing the framework, it has some really powerful features, but the inability to utilise the powerful API that is available like the MFMessageComposerViewController that can be used for composing emails and sms, the URI settings in the plist for being able to associate the app with a particular file extension, being able to tap into the UIViewAnimations for pagecurls and other FX, being able to tap into the CoreGraphics for some amazing graphic filters and rendering, is all lost and the question is "at what cost?"
It is in a way segregated with a dedicated engineer for the Android platform and a couple for iOS like Eric Wing, etc show dedication on the part of Ansca, but... as far as the user base is concerned, where majority are only after how can I make two physics bodies collide better, there are many other developers that are looking at how to use the UIKit features of Corona better.
Suggestion
Ansca can have a UIKit based app where a simple command like application.SetModeGraphics() or application.setModeUIKit() would swap between the OpenGL and the UIKit modes, after all both are nothing but UIViews that hold other subviews. This way, they would be able to provide all the native UIKit without having to replicate the functionality. The TextBoxes, WebBrowser, etc will all sit proper. Images are nothing again but UIViews that have clipping set on, layers can be used to manipulate the UIViews. 2.5D transforms can be applied, even 3D transformation can be applied, it is so much simpler. So the graphics mode becomes like the Physics model, where the developer requires Physics, they set the mode to graphics, after all you would not really have a physics enabled textbox that will bounce off a pickerListView (unless there is a perfectly crazy reason to do so)The Android side of things will get left out, yes, they will as these then become very specific to iOS only. To achieve the cross-compatibility (if really ever required) the *emulated* UI components (which do not work for Android at this point anyways) could be used. Plus when someone works on a cross platform app, they would *not* really want the iOS theming or the Android theming, but a custom theme that would flow across the two devices to provide a single uniform look and feel.
I should be on the advisory committee of Ansca
No Thanks!! I am an Educator, a Business Owner and an Author. I am happy being my own boss and working on things that I like. I would not like to be *tied* down with the *directions* from certain others that do not have a handle on what is it that the user base requires, nor listen but impose their own bottom lines *PROFITS*. I am working on something that will help change the way we look at cross-compatibility and the last thing that I would require is to be *directed* by VC's and Corporations. I have quite a few things on my plate at this moment, but I am happy to shed light on the bottle neck areas, as I have worked hard to find a solution to overcome some of the issues, not he most elegant way but gets the job done.Parting thoughts
Matter cannot be created or destroyed, well that is true, Flash is dead, HTML5 has taken it's place. Things change from one to the other. VB6 died, the developers moved to Apple and Objective-C than then moved on to Lua and other frameworks. So nothing is forever, the only thing constant is Change. So, any framework needs to be fluid and keep including stuff, otherwise it is going to become stagnant and lose traction. CoronaSDK still remains one of my favourite options, after all I am writing a book on it and creating a framework that is going to be revolutionary (at least that's what I think ;))Any framework developers, add the stuff that is easy to include, even if it available for one platform only, The line between cross-platform and making users cross because of a platform is very thin, if clients pay to implement apps on iOS, who really cases about an Android port that would not have worked anyways due to the ARMv6, ARMv7 and then simulator issues. If there was no Android option, would it change things? Maybe...maybe not... It is nice to be able to Kindle a Fire in the Nook. It is the *latest* phenomenon, but given the choice between professional projects vs games/fart apps on these devices is the difference between 10-100K vs struggling to get $0.99 from users for the game.
Again 100% Agreement with your words. It's always a pleasure to read you thoughts and views. Keep it going ... cheers Mark
ReplyDelete