@david ranger
Thanks for the insult, very professional i must say… How can anybody pay attention when you are intentional burying the starter option now? Are you familiar with the legal reference bait and switch? I guess from now on… new members will think there is no starter option and thus padding your greedy pockets even more. You straight up sicken me.
Lets all take a deep breath. Corona Labs staff has families to support and bills to pay. There is nothing wrong with charging for a product. Demand / supply laws dictate who succeed and who go extinct at the end of the day. I don’t see the recent changes as driven by greed. I think CL is simply trying to adapt and evolve and perhaps making learning mistakes along the way.
I would much rather have them charge so they can get more devs / resources on board and deliver a working product. Lets all try and make this work.
I agree with ksan, lets not get mean and hasty on this thread. I think the goal to figure out what hobbyists that are pro level’s options really are. I think it would be great for Corona to offer a “Grandfather” deal where pro developers that signed up when the prices were a bit more reasonable can keep that rate. I totally understand that Corona wants to use the daily build feature as a selling point of the higher costing licenses and that makes sense. When it comes down it I think a lot of developers need the ability to get fixes for major issues in a timely manner but they have not made a ton of money at this (<200 $ / year) so the expense of the higher cost of the pro level that provides the daily builds has become too much for them.
I guess what I am trying to get at is that it seems that a user base of your platform is going to get priced out.
I appreciate David providing input and everyone else doing the same as well. We can have a civil discourse and maybe make some progress on this. If no progress is made then that may be ok too, as we may not be the target dev audience for Corona anymore.
Travis
Yea when I saw the new Corona business model I thought I would just have to be done using Corona but thankfully I am a college student at the moment and am able to get a discount for being a student. It is still expensive for a college student like me but it is doable. Once I graduate however it will be a different story, I will have to look else where to develop as a single person team making hardly any money. Like @twomack33 said, it could very well be that people like us are not the type of business Corona is looking to get anymore.
I think the latest stable release should be just that stable and daily builds should release new features. Daily builds are pretty much untested beta versions. The untested Beta version should not be the only option that works. I only develop for ios now I was going to go for the ios only option but since the price increase and no ios only option I am looking at developing my next app in native objective C its a lot more trouble initially but maybe less trouble in the long run. Time will tell.
Your explanation of what “Daily Builds” are is spot on. They are untested beta releases just like nightly builds anywhere else. What the Corona team doesn’t understand is you don’t release a stable build and then not maintain its essential core functions. But objective C is definitely the way to go, but it is going to be a real pain in the neck to get your handle on it. You will more than likely start, get pissed off, then try again and eventually just give up after cracking open the iOS SDK and CocoaTouch frameworks.
@ ksan
Simply put, what about my family? Do you honestly think what their doing is correct? If any other business ran like this, think of Wordpress, they would be dead in the water. I mean you know how much effort goes into a patch right? You create a simple file with the lines to remove and the code to replace it with. You run it and boom, its patched plan and simple. It takes about 5 minutes of your time to do this. They just are holding the patches hostage so you pay them… I don’t know how else to say it, it is blatantly obvious. And if that is not the case, then they are just terrible programers. I am not going to explain this part, but just google and read on facebook’s walled garden approach.
I doubt that. Real developers that know Objective C and are conformable with the iOS SDK would never deal with this SDK. There are quite a few issues with it that i am not going to go into beyond the basics core functions being incompatible. They want people like us, we are their bread and butter when it comes to business. I have been using Corona since it begain and to see how greedy and desperate they have gotta is straight up ridiculous. Why do you think you think so many legacy developers have left and now use gideros sdk which is free with no limitations; you pay them $149 a year to remove their load screen that is all. You essentially have the Corona Enterprise package for free with them… and as a bonus, the SDK is not bloated + physics is not iffy. It is just not at mature as Corona.
Travis - your mention of a “grandfathered” price has been in place for a while. Take a look:
David, I understand the business model and fully support the notion that you have to charge in order to sustain and grow your business. We will all prosper together once the balance is found. Meanwhile I have another problem…
Pay for service on a subscription assumes service will be provided as promised / advertised. I have been waiting for fixes to various parts of the Corona SDK with vast majority of issues stemming from Widget 2.0 library. Since the service I paid for has not worked completely as promised for most of the subscription period, I now feel some form of compensation is in order.
In other words, if I lease a car I expect it to run fine. If the car has a problem I would get the leasing company give me a repair. If they can’t repair it in time then I would expect them to at least give me a refund for the lease period where the car has been unusable or has performed less than promised.
Make sense?
ksan - You are a reasonably guy and I really appreciate that. But I have to disagree a bit here. We all wish Corona (and any other software platform) worked perfectly all the time. But it is frankly impossible. And I’m not just making excuses for us here. If you show me any other platform of this complexity that does not have bugs, I will personally refund your subscription. But that platform does not exist.
I know for a fact that people often complain about our biggest competitor because, not only do they have significant bugs, but people have to wait months (or more) for fixes. We have daily builds which make the wait much shorter (usually). But it is inevitable that we will have bugs (some very significant) and that sometimes schedules will not align to the satisfaction of everyone involved.
With widgets, we specifically made it open source for this reason. And I promise we don’t mean this as an insult. It is just one more option for developers if they *really* need a fix right away that we are not in a position to provide. Widgets is less than 1% of what Corona does, so saying that we have not delivered what you paid for is not quite fair.
In any case - I’m just trying to explain our views and what we are dealing with in a reasonable way. I often get more heat when I do this, but it’s just the way I am - I’d rather try to have a reasonable discussion than just flame people or go silent.
David
Dear David,
There is a huge difference between core functionality and additional features. A difference between blockers and minor issues. I personally believe a text field is a major component; it’s the most common form of input. Now I’m not saying you should patch all the changes that have been made in Daily Builds into your public release, as a matter of fact, I think that the public release should be kept to a minimum so that users would be tempted to subscribe.
However, here’s where I disagree with you. If your existing users had applications that were already running fine, and you discovered that there is now an issue in a major component that cripples such applications, a patch should be delivered. The application I’m releasing tomorrow is a trip budget application. Can you even imagine how this would function given the text field issue? The user would type $10, see $10 on the screen, then miraculously find that it’s been saved as $100.
This isn’t an issue that people should “wait a bit” for. In my opinion at least. Think of it this way, a new user downloads your public build, tries to simply input some text in his application and fails. How do you think he will view your SDK? Will he be recommending it?
Once again, I’m not saying merge your Daily Builds to the public release. I’m just saying that you now have a major broken component that was already working gracefully. A component that is a deciding factor for many.
Dear David,
Thank you very much for your response and open dialogue.
For the record, I’m not trying to score a quick refund. I just want issues to be fixed so we can all move forward. What you define as 1% of what Corona SDK does is 100% of the requirement for developers with business apps focus. Hence the discrepancy between CL prioritization vs. customer expectations. So you can consider my effort to be a form of lobbying for priority & attention.
Regarding your comparisons with competition… For me, your competition is Xcode & ADK. Put very directly, I am choosing Corona SDK for the dual platform delivery capability and the 10X promise… If it fails in either but especially the 10X promise then its time for me to go native. The IOS and Android native development kits are robust and issues are usually dealt with on a faster basis. Of course I don’t expect to compare the resources Apple and Google has at their disposal with the humble Corona Labs team size but this is what you’re up against in terms comparison.
I understand that currently the mobile app revenue stream is biased towards the game industry and perhaps that is driving your decisions in what makes the 99% and 1% of Corona SDK. The global business application & services revenue stream is greater than the global game industry revenue by an order of magnitude. The business app share in mobile world is growing steadily and is projected to become the way companies deliver services and do business (in conjunction with the Cloud) as we go forward. Hence, IMHO, it is rather shortsighted of CL to continue with the highly biased prioritization of what gets fixed & implemented.
While all this is somewhat related, my thoughts are perhaps taking this thread off topic. Lets continue discussing on the widget forum if you like. Thanks once again.
Regards,
Kerem
David,
Why is it that the more and more i read your replies i get the feeling you have absolutely no idea what we are talking about? Don’t get me wrong, you are a good sales and company “yes” man, but you just can’t grasp the understanding of what a “patch” is… And now you are trashing your competition over having bugs? You know what happened with CLEAR did that right? Corona is slowly becoming the CLEAR of RAD KITS. Focus on fixing your own SDK and stoping make excuses… If i had your mentality, I would be out of business in no time. Forgive me as I digressed… Which makes me wonder if you are on the development team or a customer service personal? If you are the latter, i would prefer speaking with Rob Miracle who I know he is indeed a developer and understands what a “patch” is. At least if I spoke with him, he might say that there is no way to patch the public build due to them not being two separate build platforms, but rather just a older build of the same platform. But in doing so, he would try his best to offer a work around… I am sure there is one other than forcing us to upgrade our memberships. in fact I know there is because somebody was able to fix this issue with modifying a textbox rather than textfield but i have not been able to replicate his fix. As for what this 1% vs 99% talk, it just really shows how out of touch with your developers and reality as a whole the Corona management really is. In the real world, it is 30% vs 70% and rich business apps are out pacing games (especially 2D games! ) 2 to 1.
So Rob Miracle, I know you are subscripted to this thread… Please come and help us find a workaround for this issue. And if you say there is none and nothing you can do, i will be disappointed, but at least i will get this from one of the most respected developers at Corona and one who is linked to the development team and has helped me in the past.
Jason
Please bear with me, this is going to be a very long post. Please read it all very carefully.
At this point its really hard to tell what the actual problem being reported here is. I’ve gone back to the top of the thread to try and determine exactly what problem is being reported and frankly it’s a bit hard to know what the real problem is since there seems to be variants of an issue. To obfuscate this problem some more, there were filed bug reports on the keyboard that engineering did fix post 1202 that seemed to address the reported problems. Some of it may be related to what was posted here. It seems that several people on this thread have reported that the post 1202 fixes solved their problems making it hard to know what problems still exist and which ones were solved.
So I was thinking about asking for a very clear example of what was broken so we could separate out what’s been fixed, what Apple fixed between iOS 7 beta and iOS 7 release and so on. But before I asked for that, I decided to start by taking the code by the OP at the top of the thread, built for my iPhone running 7.0.3 using 1202 and reproduce the problem. But, with the following code (I had to make the snippet whole):
local serialNumField; local function fieldHandler2( event ) print("Text entered: ".. event.target.text) if event.phase == "began" then print("begin") -- user begins editing textField elseif event.phase == "ended" then print("ended") -- textField/Box loses focus elseif event.phase == "submitted" then print("submitted") -- do something with defaulField's text native.setKeyboardFocus( nil ) elseif event.phase == "editing" then print("editing") end end serialNumField = native.newTextField(0, 0, 400, 60) serialNumField.x = display.contentCenterX serialNumField.y = display.contentCenterY serialNumField.userInput = fieldHandler2; serialNumField:addEventListener ("userInput", fieldHandler2)
I see all of the prints for the appropriate event print as expected. During the editing phase, event.target.text is one character short. But in the ended and submitted phases, the string was complete as expected. In other words, if you’re only taking the string during the editing phase will this actually hurt you. If you grab it during the “ended” or “submitted” phases like it’s intended, then it works. I also tested a pre-1202 built app on iOS 7 that did keyboard input and it worked like it supposed to so I could have another reference point. I had Brent duplicate this on iOS 7.0.2 in case Apple fixed something in 7.0.3. Unfortunately I have no way of testing 7.0 or 7.0.1.
Brent and I decided to dig further into this. Next up we took the sample App (and you should always run the sample app’s when you’re having problems) and guess what? With 1202 on iOS 7 the sample app runs perfectly. It however is not grabbing the text during the editing phase.
Brent had some code that was being problematic:
local function editInfo( event ) if event.phase == "began" then print("BEGAN") if event.phase == "ended" or event.phase == "submitted" then print("ENDED event.text", event.text) native.setKeyboardFocus( nil ) elseif event.phase == "editing" then print( "EDITING event.text", event.text ) end end
In this case, during “editing”, it was short and it was the only place he was storing the text value back to his code. (I’ve modified his code with prints to demonstrate the problem a bit better). Notice he is using event.text not event.target.text. We learned that event.text is only populated in the event table during the editing phase. Once it’s submitted, that field is no longer present and it kind of makes sense.
The event handling code is a complex beast and it’s easy to mix up things. I’m going to use the term “textField” to reference the actual text field object. The reason this gets confusing is there is:
textField.text – the actual text of the text field.
event.text – set during the editing phase which is a copy of the textField.text
event.target – which is the actual text field.
The event table changes depending on the phase in question. During the editing phase, the event table has a copy of the text being edited. When we get to the submitted phase and the ended phase, we are no longer editing the text, so there is no reason to have event.text populated because the object itself now has the edited (and post-autocorrected) text stored in it. This is why the Corona SDK sample app works, it’s using the textField’s .text attribute and not depending on the values of the event table.
Changing the code to:
local function editInfo( event ) if event.phase == "began" then print("BEGAN") if event.phase == "ended" or event.phase == "submitted" then print("ENDED event.target.text", event.target.text) native.setKeyboardFocus( nil ) elseif event.phase == "editing" then print( "EDITING event.text", event.text ) end end
by using event.target.text in the ended phase, we now get the properly filled out value at the end. Looking at our sample project for it, we only access the object directly and not the event table, so we always get the right value.
If you are using native.newTextFields directly on the screen and you only care about getting the right value, then only access event.target.text or a direct reference to the object’s .text attribute in the “ended” or “submitted” phases and you shouldn’t have a problem
If you are using the native.newTextField offscreen and are copying the text into an on screen display with display.newText() then you can consider appending event.newCharacters which should have the newly typed characters to the string and see if that helps solve it If you are doing some type of character count, then add 1.
Now I will qualify this. Our tests were with Xcode 5 not Xcode 4.6. If you’re running 1202, you can still build with 4.6 and it’s older iOS SDK’s and that may be contributing to the problem.
If you are still having problems after re-evaluating your code:
If you can using a later daily build where we have added the iOS 7 bug fixes.
Try it with Xcode 5 installed.
Make sure your accessing the target’s .text field and not the event.text field.
Try the Corona SDK sample app.
If these work arounds are not helpful, please report back with the code you are using. What you are trying to do? It might be helpful to know why you’re not using the examples from the Sample project. Report back what version of Xcode you’re running as well.
@ Rob Miracle
Once again, Rob you are the man! Thanks for taking a look at this issue and you couldn’t have put it any more elegantly. Looking at it now, i feel so stupid. I honestly had no idea event.newCharacters was even in the API… But, the issue was using the pseudo-native.newTextField; essentially an text-field located offscreen and grabbing it’s text contents. For me, appending the event.newCharacters worked like a charm. I rewrote it using a editable native.newTextBox earlier trying to do a workaround which failed, but the native.newTextField would act the same. The only change I made in the editing phase and is in the following two blocks of code. I can confirm that it now works in both the Corona Simulator and Xcode Simulator, as well as, iOS 6.1, 7.0 and 7.03 (don’t have a test device on 7.0.2 ).
Old
defaultFieldPlaceholder.text = string.sub(defaultField.text, 1 );
New
defaultFieldPlaceholder.text = string.sub(defaultField.text .. event.newCharacters, 1 );Hmmm, sounds like an apology might be in order… All that ends well! 
Thanks for posting this, was hitting my head against the wall wondering why the keyboard input on device wouldn’t work. Going to try a daily build above 1217.
Something that i feel is utter nonsense is that i had a daily build installed and let my pro run out this morning because i am just a hobbyist… and when i go to do some work, i was forced to delete the daily build and use the public release. If that isn’t a slap in the face idk what is. To revoke access to vital patches and not offer a workaround is nonsense! It is really a horrid and greedy business model forcing a subscription to remedy a MAJOR issue… If you want to charge for access to graphics 2.0 which isn’t important and add-on plugins, go ahead, but to revoke a patch to make the textfield functional is just flat out ridiculous… i am sorry but it is…
Now that i got that off my chest, what is the workaround for those of us who no longer have access to daily builds… Are we really stuck in limbo? I will look at the native.textBox as fastek2000 mentioned for now.
Update: i tried using native.textBox… it does not fix the lag that exists within the edit phase… this is rather disappointing. i guess all applications that use native fields are basically screwed till a new public release comes out. i just don’t see what you don’t release a patch or tell us a workaround for this. Having a crippled keyboard makes Corona absolutely worthless to me. I guess i will have to just remove my app from the store and call it quits. Do the right thing and just put a simple patch out!
jmarchalonis - sorry this is causing you some trouble, but unfortunately there isn’t much we can do. The issue this happened is because of a breaking change between iOS6 and iOS7, which we had no way of knowing ahead of time.
We have set processes for how we handle daily builds and public releases and we cannot change those without larger implications unfortunately. The good news is that we do provide a way to deal with things like this via daily builds, and in a way that is usually very quick. Most other platforms are not able to turn things around this quickly.
And while we would like to make daily builds available to everyone, we do have a business model we have to keep working so that we are around for the long term.
David
David, I did not know this. So when a Pro subscription runs out you can’t keep using the last daily build you had access to on your last day of Pro until the next Public Release? This is a major PITA and possibly against the law in many countries around the world. You can’t take back something that has been paid for in full. Hope you can reconsider this decision. IMHO, a Pro user should be entitled to keep using the last daily build that he/she had paid access to. That would be a fair business practice. Thanks for hearing this out.
ksan - there are 3 points to make here:
You may be forgetting we are a service and you pay in the form of a subscription. If your subscription expires, you lose access to the service. Since we now have a free tier (Starter), in this case the paid service is being able to publish apps with certain Corona builds. I don’t see this as being different from any other service/subscription out there.
Previously, when we did not have a free/Starter tier, this would have been a moot point. When your subscription expired, not only would you not have been able to build with a daily build, you would not have been able to build *at all*. Again, not different from any other service/subscription. Interestingly, now that you are able to build with a public release when your subscription expires you actually have a fallback option.
Finally, as a side note, think about the complexity of a system that would have to keep track of what the latest daily build was when anyone’s subscription expired (or whatever the last daily build was you used when your subscription expired) and had to keep giving you access to that daily build but none after that. And each person’s "last’ daily build was different. This would not be tenable. And also would not be in the spirit of a service/subscription model.
Hope you understand. We aren’t trying to screw anyone - just run a business. The fact that you can always fall back and actually publish apps for free, with a public release build that is fully updated every 2-3 months is actually a great thing in my opinion.
David