Well to be fair, I’d say that Android itself is an incoherent idiosyncrasy.
Joking aside, this is a very safe bet. iOS support was designed somewhat in a vacuum. Awareness of the needs of desktop and web was certainly present, but not so much Android. I expect getting Android to fit into what was designed for iOS will be a bit of a square peg in a round hole situation. Realistically, both mobile platforms needed to be designed at the same time, which was of course impractical.
Imagine you were designing Xojo from scratch for Mac-only. You’re vaguely aware that Windows is similar in many ways. So you design with the dock, popovers, document controller, autosave… so many platform-specific things. Now it’s time to add Windows and it has none of those things. Now what? You can’t do lowest-common-denominator with only part of the picture, and I expect that’s what happened with iOS and Android. We’ll find out some day.
They could have kept the old syntax so Im starting to wonder if the new framework was at least in part done as an extension to the name change, a further attempt to distance themselves from their BASIC roots.
In my opinion they should have embraced those roots instead: Its BASIC - but not as you know it!
If you dont believe in yourself, it becomes very difficult to be true to yourself.
[quote=381941:@Markus Winter]They could have kept the old syntax so Im starting to wonder if the new framework was at least in part done as an extension to the name change, a further attempt to distance themselves from their BASIC roots.
In my opinion they should have embraced those roots instead: Its BASIC - but not as you know it!
If you dont believe in yourself, it becomes very difficult to be true to yourself.[/quote]
There was no hint of that in any of our conversations. Technically the syntax hasnt changed, they just heavily namespaced it, and namespaces are trendy.
We have in fact nearly no project, which uses the new framework more than just a couple of times.
For us it is easier to use the old but gold classic framework instead of turning to the new framework wich, besides the lack of some features, also feels very unnatural and overcomplex.
Next is Xojo iOS. Developing a iOS app in Xojo feels like learning a new programming language. The interface designing is horrible, the graphical possibilities are like they was back in 2007 and the usecases are very limited. I’m afraid of the Android version, if they don’t improve this heavily. Why using Xojo if I need to learn a new dialect. I can also learn another cross-plattform language such as C# with Xamarin or ReactNative or something.
I think Xojo needs to refocus on what they came from and what they can better than other languages. Real crossplatform applications. Also easy-to-write webapplications. I really hope that the new webframework woun’t be such a mess like the new desktop framework.
In times where performant and professional backend and frontend developmentfor web get much easier because of React, NodeJS, Java and so on, they really need to focus on improving their classic products instead of releasing new but not ready plattform targets.
But that is precisely what ensured the success of RealBasic back in the days. I doubt the first incarnations were designed with Windows in mind. Yet, they brilliantly succeeded in abstracting the Windows platform.
I believe they completely lost it when they redesigned the language around the iOS framework, instead of abstracting the framework in favor of the Xojo language. Furthermore, they did not even bring in the most interesting features of the platform, such as background color and images for most controls, or most events, which by the way have been part of Xojo for close to two decades, such as mousedown/mouseup.
Besides the horrific layout editor which might as well not be here at all with it’s idiotic auto layout, that is one place where they should have taken example from XCode, which does not mess the layout as created by the user.
That alone defies the very concept of RAD…
I think it is time for Xojo to make it’s agiornamento, and admit Xojo iOS needs a redesign quite badly. As well as implementation of the dozens of feature requests posted since the beta version, 2 and a half years ago. Otherwise Xojo is mostly doomed in a world where Android represents over 50% of all platforms, and iOS some 12%, Windows less than 12%, and Mac with some luck around 3-5%. And that was back in 2015 !
Xojo’s future will depend on it’s ability to retain it’s existing customers, as well as gaining new ones in market become very different from what it was when Windows represented 90% of the PC market. For the moment, Xojo iOS is a lot “can do better”.
Very good point. Though to be fair, the landscape was much less volatile back then.
Autolayout is really powerful. Its basically responsive design for traditionally static content. I wish I was aware of it when designing the web framework, it absolutely should have been introduced there. However, Xojo failed to distill it into something approachable. That would probably mean giving up some of its power, but thats what Xojo does. Its impossible to know if Id have been successful in doing that for Xojo Web though.
I happen to have implemented auto layout in RubberViewsWE, mostly based on a list of constraints.
I don’t discuss the need for it on certain platforms. In the case of RubberViewsWE, it appeared necessary on mobile essentially where a simple scaling cannot manage view rotation.
Its is just as important on native mobile programs.
My beef is the ill conceived auto layout in the layout editor. Once again, XCode does not second guess the user decisions in terms of layout. If you place a control at 50 pixels from the left, XCode will not decide by himself to delete that constraints in favor of a relative to the control on the right. Unfortunately, that is what Xojo iOS does in the IDE. Worse yet, if you spend a significant amount of time building constraints and even naming them to use them in code, the IDE bulldozer will stomp over your work like an elephant in a porcelain store, if you move the control even a point. Gone the constrains decided by the user, even the named ones. This is ridiculous.
I also have a lot of grief with the way most methods have been changed. In classic, most methods are available with parentheses of with dot notation. Why was it necessary to systematically force the dot notation ? Actually, this betrays all the Xojo language syntax. Why, heaven, why ?
[quote=382020:@Hal Gumbert]It’d rock to have and Old Framework setting for the 0 or 1 based Indexes.
[/quote]
The old framework is a mixture of 0 and 1 based indexes… That setting should 'Classic Indices ’ or ‘0 based indexes’…
I wish they would give up on the new framework … IMO it’s less intuitive , more work and often slower to boot!!!
IMO if the time has been spent making the Incremental improvements under the hood and a few changes like the above to the old framework and the old IDE, we would have been a lot better off now in terms of having a product that helps us be more productive…
The decisions made for iOS development and their ripple effects IMO were truly unfortunate.
[quote=382061:@Karen Atkocius]
The old framework is a mixture of 0 and 1 based indexes… That setting should 'Classic Indices ’ or ‘0 based indexes’…[/quote]
[quote=382020:@Hal Gumbert]It’d rock to have and Old Framework setting for the 0 or 1 based Indexes.
Default would be how it is now, but if you set something like App.IndexesZeroBased = true, every 1 based index would be 0 based.
That’d help one of the main issues with the Old Framework.[/quote]
No, no, no. Imagine modules from two different authors that each expect a different setting. This would create such a mess. Most things are 0, they should all be zero. Simple as that.
51863 - FR: Introduce array.LowestIndex for increased code compatibility
[i]The old framework uses 0 or 1 based arrays, the new framework standardizes on 0 based arrays.
However if you mix code modules from developers where one uses or expects a 0 based array, the other 1 based arrays, then it becomes messy.
One easy way forward would be to introduce an array.LowestIndex property, then your code can be used across both frameworks and whatever a developer expects an array to be.
Then code would simply be
For i as integer = array.LowestIndex to array.Ubound
or even better as I never liked ubound:
For i as integer = array.LowestIndex to array.HighestIndex
It would also make it easier to adapt code with a simply find and replace.[/i]
Norman has noted that if done properly, it would not break anyones code, as one could set the lower and upper bounds in a declaration statement as in dim a(1:9). For many numerical or scientific calculations, setting a non-zero lower bound has many advantages. I hope as some point it is implemented as it would make some of my programs significantly less memory intensive.
