List of open Widget 2.0 bugs & promised features...

Solar2D Widgets
#541

Hi Guys,

Back here after a few months away and now back getting ready to publish. But have found my app, which works like lightning{fast and slick}  and friends have suggested I get it in the app store needs to be built on Graphics 2.0 … Oh dear!

I have just been using the Starter system back level to build and test. I would like some advise of moving from back-level to the latest public release or to a daily build licence BASIC. 

My experience of going to Graphics 2 on the latest public built is, well, totally un-usable and certainly not publishable due to really reeeeeally slow tableview response {2-10 secs, some time 15 secs now, when it took millisecs on back level} . Also compatibilty mode=1 does not fully work, and tableview scrolling is clunky.problem could be masses of warning messages about reference points (can these be turned off?}

I have made a forum entry at

http://forums.coronalabs.com/topic/47435-can-i-publish-to-app-store-on-back-level-corona-sdk-etc/?p=246484

Thanks for any comments/suggestions.

I cannot publish now as these problems look like a lot of work to even get close to what was a great and usable app…

#542

Corona widgets are not the most stable critters; I’ve posted about this before.

That said, I’m using TableViews with the latest daily build with ~200 items and have had good performance on actual devices. Once you get to ~1000+ items there’s a noticeable lag time (perhaps 500ms-1000ms) when building the TableView, so I would avoid that if possible. This is using Graphics 2.0 *not* in compatibility mode.

I suggest you try converting a few screens of your app to native Graphics 2.0 and see if that solves the performance problem. It’s not as painful as you might think.

#543

I have found the cause of my performance problem-far far too many warnings. These did not occur in earlier builds-there was a bug in my code referencing a nil object in setreference. Corrected and messages gone, so very fast again now.

My table lists are very small -max 52 entries, but many many different scenes/views [over 60 combinations can be chosen].

I also overcome the tableview problem when deleteall is done and new entries added the tableview then starts centre screen.

Due to my short lists it is just as fast to re-buld from new and everything displays correctly.

So I am hanging in on to compatibility mode at the moement.

My final funny is on one tableview it will not show all 12 entries, only the first 10 that fill the window. Thereon you cannot scroll up.

If I model a iPhone 5 all 12 entries can be seen because it is taller… so the code is working.

So this tableview now is a problem. it is acting as if it is locked. If I code a scrollto 12 it works by showing entry 12 until you scroll back manually, then it stays locked showing the first ten entries.

Thanks for the advice. Once I clear these I am almost ready to publish again-I hope…

#544

These are exactly the issues we are experiencing as well which make the picker wheels unusable for us. We have a critical update that we absolutely MUST get out asap but this little annoyance among some other things are holding us back from submitting it. Would be nice to see a fix for this ASAP.

By the way curious, are you using graphicsCompatibility mode 1 as well? Or is this an issue with both graphics versions?

Edit: Attached a video of our pickerWheel as well just to demonstrate how much it currently works.

#545

Sorry to hear you are still having these problems. One question. I noticed the videos are from Simulator. Do you also see similar issues on device builds? Please try without G1 compatibility mode and see if the issues go away. I see nothing like this in the pickerWheel implementation now but I don’t use G1 compatibility mode. Maybe thats the key to the remaining issues. Good luck! 

#546

Yeah tried them both on the device and the simulator but getting the issues on both. Suspecting it to be a G1.0 compatibility issue but afaik G1.0 isn’t deprecated yet? So you’d hope it to work properly on both

#547

The main issue is that there is very little resource allocated to dealing with these bugs. As far as I know, and I might be wrong, its just one person who is also responsible for other parts of Corona SDK so we’re getting a fraction of an FTE time on these issues. Solid progress is made and for that I am very thankful but as you are finding out, we are far from being totally out of this mess yet.

My hunch and again, I might be totally wrong is that the widgets are not stress tested in G1 compatibility mode simply because there aren’t that many people using G1 compatibility and the widgets.This possibly results in having some bugs persist while they are fixed in G2. Again, just a hunch of course. 

The more people are affected and make a noise about these issues the more likely the issue is to get attention. Look at @guruk’s video for example. It has been downloaded a total of 10 times and I think 2 of those downloads was me… What he demonstrates there is pretty serious. I totally agree with him in that it is unusable in the state that he demonstrates the widget. I don’t see that behavior in my app but he does. Unless followed up with a bug report with code etc it is unlikely CL engineers will be able to duplicate it and fix it either.

So in a nutshell, we need bug reports, sample code and visibility, lots of visibility. 

#548

Hey guys,

Please file a bug and paste back the number. Even if on g1 compat, it sounds like a serious issue and will be treated accordingly.

Thanks in advance,
alex

#549

Hey Alex, 

Thanks much for being here for us even on your Sunday. Your support is most appreciated.

Regards,

Kerem

#550

Very much so! Will go ahead and file one as soon as I get home.

Thanks again//

#551

hi… yes i also use G1 compatibility mode…

also again im on travel and less time… feel free to add my video to the Bug List.

I guess there u see very clear the problem…

and yes… stress it out to test with G1 Mode

Thanks

Greets

Chris

#552

Have filed a bug report about it now with this id: #33674. Thanks again for the swift response Alex.

#553

Withdraw my last comment-I can’t publish yet as I have found categories are moving to far right and cannot fully scroll to last entries in tableviews. Can scroll but last few rows are hidden…

Known problems I suspect… recoding to direct interface without compatibility to see if there is a difference.

#554

I need to scale the pickerwheel to display on a 640x960 screen (yes I know this is NOT officially supported but I’m stuck and have no good alternative)   I’ve been putting it off as long as possible, but now I need to start working on it…

Can I solicit tips & code-change-steps from any of you who are more familiar with the widget code than I am…

How best should I tackle this task?

Thx

Dewey

#555

Seconded. It will register the center of the scrollView’s contents at the top edge of the scrollView.

#556

No changes unless we nag a bit so nag nag :slight_smile: Been 15 days - any news on the widget fix?

#557

Hey Skatan,

Yea, it got fix a few daily builds ago. The release notes did not contain it, thus the confusion.

Thanks,

alex

#558

Ah sorry and awesome! Hadn’t updated since the last comment. Thanks! :slight_smile:

#559

Hey there!

I posted an issue a while ago, and was wondering if it may be a bug, or if I misunderstood how ScrollView works.

Could somebody check ?

http://forums.coronalabs.com/topic/48280-preventing-white-borders-to-appear-on-a-scrollview/

Thanks a lot,

Ben

#560

Heads-up! More widget fixes in todays daily build!!! Thanks much Alex!!! Keep it going.