Fair enough Atanas.
Rob
Rob, all that Corona Labs had to do was to do what Atanas has done to fulfill those feature requests. No one asked for a full blown keyboard implementation with spell check etc. We all understand the difficulties of the native vs non-native. Not trying to undermine the amount of work Atanas has put in. It is huge but still if a one person could do it so could Corona Labs… Thankfully Atanas felt this was something he could tackle and results speak for themselves. I for one am very happy with what he was able to create and will be forever grateful. Consider that feature request closed!
Rob,
Can you tell me what this sentence means:
This has to happen for Window’s support.
I can’t tell what you are saying…will you guys eventually tackle openGL text fields or not?
And if I was to submit a feature request for nested tableView rows, based on your guess about where it would fall on the list, would it likely get done within a few months?
Thanks,
Dewey
Take a look. Hope this helps for now : http://forums.coronalabs.com/topic/43124-collapsable-tableview-demo/
Sorry wrong thread
Dewey, let me first clear up the textField vs. Windows thing. Corona SDK is an OpenGL based product. On iOS, Mac OS-X, and Android the operating systems let you mix native objects and OpenGL in the same window. The native objects draw on top. On Windows, Microsoft wants people to use their DirectX graphics language/APIs. In an DirectX world, you can mix native and DirectX like you can on other OS’s, but Microsoft does not permit it with their implementation of OpenGL.
So our choice is to either build a text field/keyboard in OpenGL which would take the entire engineering team years to do right or have MSFT patch their OS’s to allow it which is very unlikely to happen. I don’t know enough about the Windows 8 Phone project we are working on to know how this will be solved, but it will not work back in win32 binaries that run on Windows XP, Vista, 7, 8 etc. So while I don’t like to use the term never, it’s very unlikely to happen.
When I said “this has to happen for Windows support”, **this** means “the entire engineering team working on it full time for over a year”.
Now for your tableView issue…
While entering a feature request is a required step to get engineering to consider this, there is a work around. The biggest issue with tableViews right now is that it’s really hard to change the height of the tableRow after it’s created. What I would recommend is to think a bit more abstractly about the problem. Since we can’t hide/show invisible rows and we can’t resize them, I would recommend (if the tableView doesn’t have hundreds of rows) that when you want to expand a row, that you could delete all of the rows and rebuild the tableView with the expanded rows in place. This should draw fast enough that it should be smooth.
Rob
Hmmm, yesterday you were advocating that we should submit a feature request for this need :
And now, after I posted a working code sample doing exactly what you “suggest” below suddenly a tableView feature implementation is very hard and therefore unlikely…
So if we took your advice yesterday and posted a feature request and started waiting patiently where would we be today, tomorrow and three months later?
For the record, your second response posted above is much prefered to the first. Tell us what can happen using CL resources and what we should possibly tackle ourselves and let us deal with it. We’re all adults. Giving us the blanket “If you want to see it happen file a feature request” response knowing full well its not going to happen is simply a dis-service.
I think I am reaching the age where I might need to stop believing in Miracles
The feature request system works. I can think of a dozen things off of the top of my head that we’ve added from the list like:
Facebook social sharing
Access to the iTunes music library
Access to contacts
The pasteboard access
Being able to zip/unzip files.
Amazon IAP
iAds
AdMob,
Support for Ouya
Support for Gamestick
Self masking TableViews and ScrollViews
Ability to view PDFs
GameCenter multi-player support
Google Play Game support
Windows 8 (In progress)
Google IAP v3 (In progress)
All of these and more were pulled from the feedback site. I unfortunately don’t have a list of all of them since they are removed once complete.
Now for a full reality check on this. Yes, some things get put on there that are very unlikely to happen and there are various reasons. The native.newTextField for Windows is the poster child for that. Other things that may not happen include things that only one person wants. Unless it’s a really cool feature, it’s probably not worth engineering time to address a feature for one person. This is why we used to try and track +1’s, but went to the Feedback sites voting system. Now we can measure popularity of a request. Lots of votes, the better the chance it will get implement. The fewer votes, the less chance it has.
Of course there are other factors that come into play in deciding what we work on. Popularity of a request is just one factor. Does it make business sense? Are there competing projects going on? Do we have bandwidth to work on a task? How much engineering resources does it take?
At the end of the day, we are a business and we have to base our work on what will grow the business and if something will take a team of engineers six months to do that benefits 5 people, it’s not going to happen. If an engineer can knock something out in a short period of time that benefits the whole community, then it will happen. Anything in between becomes a “Depends”.
There is one certainty, if it’s not put into feedback, it’s chances of being considered is far less than if it is.
Now as Perry pointed out, there isn’t a need for an API to get the information we are now putting out since you can do it on your own, but if you want that in a single API, then it will need to be a feature request. Now I do apologize because I guess we had added those extra calls and I didn’t realize that’s what we were outputting. In that case, feature requests that you can already do, probably will be very low priority items (unless lots of people want it). If you enter a request like this, then we would reply to it to say “You can do it this way”. The feedback system works.
The high vote items that we have not done are there because they don’t make business sense for us to do based on the engineering resources to do them. It’s that simple.
If Brent and I know for certain, it’s not going to happen, we won’t ask you to post it. If there is a chance it might happen, the only way it will is if its there and it gets votes.
Rob, I think you got the threads mixed up. My comments above were regarding your “Enter a feature request” response to the Collapsable / Nested tableviews need discussed above. In any case, thanks for your continued input and support. I respect your views and the decision making rights that lie with Corona Labs leadership. I may not always understand or agree but thats ilfe.
In any case, this thread is about the ongoing issues we have with the widgets. We are fast approaching the 1st year anniversary of the infamous “Widget 2.0 is here! Bam!” post by Walter. https://coronalabs.com/blog/2013/02/22/widget-2-0-is-here-bam/
Back in 2/22/13, 2.0 was released with the following remarks :
“To tell you the truth, we look at the Widget 1.0 code and feel embarrassed by it”
“The most important thing we did was decide to start from scratch, which was critical in building a stable, rock-solid foundation.”
Funny things is how Widgets 1.0 replaced the earlier attempt called UI library or something like that, memory is fading on this. So in a nutshell this has been a multi-year journey (3+?) trying to get the UI capabilities right and the list of bugs that have to be addressed is still significant and keeps growing rather than shrinking.
So if Widgets 1.0 code embarrassed Corona Labs, then the current state of Widget 2.0 bugs list should have a similar if not stronger effect. It has been more than a year since this framework was introduced in the Daily Builds and we are fast approaching the February 22 public release anniversary. So let this be a public call for response…
Walter , we know the engineering capability exists within Corona Labs to make all this embarrassment go away. Please make the right resource shift, put the people who can fix this on a 6 week mandate. We have been patiently waiting now for almost a year for Widgets 2.0 to get stable.
Why not make that “Bam” come true before its 1st anniversary?
Here’s a list of what we managed to capture on my humble list as of today:
I am sure the internal bug tracking system has more but for starters if all these are ticked off before the anniversary I think we’ll all be happy. No need to be embarrassed anymore. Just make it right please. Thank you for listening.
Rob,
Its all about the point of view. You stated yours (Corona’s official?) and I respect that, but I would like to state mine as a paying customer of your product so we can both appreciate our respective positions.
We are business owners and also need to make our business decisions and most of all, we need to release apps in order to make money. Our business is not to find bugs, submit bugs, fix bugs, enter feature requests etc. related to the tools we use - we can not make money from that.
In my case, I got into Corona 2 months ago based on the advertisement on your main page for developing business apps with Corona (little did I realize the business app sample didn’t have an entry field or that native.newTextFields will stand out like a sore thumb on top of all my overlays). There were a couple other gaming SDKs similar to Corona, but only you claimed the support for business apps that I needed. And I liked the forums too 
Since then, I spent ~20% of my time on my little app and the rest ~80% fixing bugs in widgets or implementing missing features. Not a good business situation. Yet looking at your list of implemented feature requests, the only one that relates to the current thread is the fix for the tableView, scrollView masks which is certainly needed, but a little thin. Had I patiently waited for the fixes or missing features, my app would be nowhere and I would have probably long forgotten about my investment in Corona’s SDK.
I fully agree with Kerem that you guys have to staff up the widgets/business apps team and take it to a better level - in addition to his list, a nice first step would be to include the fixes that we are submitting from the community in a timely manner and regularly upload the latest widgets code to github. A “thank you” from time to time would be appreciated too
As a side note, I don’t understand how anyone could have entered the Windows Phone native.newTextField into the request tracking system, since this is not released? However if you really can’t provide any text entry mechanism for Windows, I strongly suggest you remove the business apps support from your web site.
Thanks
Atanas
P.S. You should be happy to have customers like Kerem who care about the product and raise their voice, the alternative is customers who silently move onto another product.
I really like Corona, this forum and the people at the company…and I’m in the same boat as Kerem and atanas…I purchased Corona 3 years ago because of it’s stated support for business apps. The only reason I’ve not been screaming more loudly, is that 2.5 years ago, I started a separate (non-mobile) company with some friends and had to put my app on hold during that period. Upon my recent return, I’ve been surprised that widgets is still so under-supported by the company…lets either add proper support for “business apps”, or stop claiming it as a selling point.
Either response is ok with me, but in support of you continuing to develop a business-app developer/customer following, I recently heard a lecture by Richard Garriott, founder of Origin games. He said (roughly): “the indie game business is about to get A LOT HARDER and more competitive because the large studios can up-the-ante on game sophistication and quality way faster than the indie guys can”
You guys need to make your own business decision, and it’s only fair that you let your customers/partners in on that decision.
With respect and kindness!
Dewey
Kerem,
Keep objective please. The list is shrinking, and it is being actively worked on. Bare in mind that we have to do more things at the same time, it’s the nature of having to maintain a game platform with business bindings. But we actively work towards fixing all the remaining issues. So while respectfully understanding all the pain under the Widget 2.0 hood, i think the actions we took towards the ending of last year ( two widget fixes batches ) and the fact that a third batch is on the way, do clearly show the perspective we have on the widgets.
Thanks,
Alex
@kerem: Also double check your list. There are some items in there that have been solved.
Thanks
Alex
Picking up on Atanas post and joining the discussion from the side lines… :rolleyes:
I was one of the customers who moved on, but not silently. I insisted on a refund and moved off to other products. This was after only a very short time of using Corona. I could see the business risk of working with daily builds and even latest shipped public release due to the tremendous state of flux the product is continually existing in.
Yet here I am back!
Well the reason I am back is that the product and [most] facilities are very easy to use and get up and running. I have decided to stay ‘back-level’ [XP stage in windows analogy] to ensure that my apps are stable and I get something that works continuously.
I have many many years of IT computing experience (50yrs to be precise) and this product is one of the easiest to get up and running development services [mobile apps] that I have found. You can even doit for free. Most parts are excellent to use and get things running [forget the hype of apps in a few hours-most are not worth using, but business apps need more time as they have to be precise and faultless , if a game fails, then it is almost a ‘so what’ [waits for big games companies to throws rocks], a bad name is created but with business apps your are probably getting close to more legal issues-ok games included B)]
Having said that however, if you look back as Atanas has said, there is far far too many ‘ongoing changes’ far far to many good working things being changed for change sake (look in Graphics 2. e.g reference points as an example) but now at least compatibility options are appearing.
For what its worth , my view is that Corona staff are working hard but have lost sight of the impact their work/changes are having on existing customers. The staff are too heads down on new and exciting demands. I feel there is a ‘msoft’ attitude to let the customer test this approach to builds and releases. I have stepped back from ‘trying’ new things and stepped back from reporting problems-because only to be told to ‘submit a bug report’- even when the bugs are clearly regression problems with most simple Corona examples and obvious very little regression testing being done-just testing the new stuff I suspect…
Having recognised this, I am sticking with Corona-using back burner levels- and only going current release when I am sure I have everything working on old levels first. Then I know that the new release will entail code change due to deprecation[but why change RGB colour parameter? Why remove referencepoints why change setTextFillcolor etc etc].
There should be a team/management in Corona justifying keeping the existing customers happy, justifying keeping things that work, as well as the other business management team justifying how to address the new requirements. If the latter wins then your customer base may shrink, but certainly will change, moving from one set of customers to another, and hence the need for continual product changes… and continual development cost trying to keep ahead. Ok a lot of developers like ‘new things’ but don’t forget there are probably more that make up your business base that hate deprecation and change for change sake…
Alec
@Alex, your work and efforts are the bright spot, however clearly insufficient and the messages here are addressed to your higher ups. While the widgets are fairly buggy and need critical fixes, they also need improvements to make them workable in a business app. Speaking of objectivity, I can be objective about the state of widgets 2.0, but I dont think anyone will like that Thanks, Atanas
@alec, finally someone older than me here Sending you a PM, would love to keep in touch and hear from your experience Atanas
Thanks for the interest. Now I do feel my age, having replied to your PM with details… :unsure:
@Alex, Please don’t take this thread the wrong way. I appreciate all the hard work and attention you and your colleagues provide. We just need and wish for more of it. Having to wait for a year for stability is simply not acceptable.
I fully agree with Dewey, Atanas, Alec (much respect!). Not much more I can add without repetition. Thanks for your support.
When I call “object:reloadData()” it states “Attempt to call method ‘reloadData’ (a nil value)” even though I am able to call other functions (like object:deleteRow() or :insertRow()) Why might this be?