A new year and another XDC coming up which gives us opportunity to reflect on where we are and where we are going with Xojo. If you are like me Xojo is your favorite programming tool to use and I rely on it daily to build great experiences for customers. However, that is not to say that it is not without fault or room for improvement.
I wanted to take some time to discuss my top wishes for 2018 from Xojo, Inc.
gotta say… I could do without all 4 of those items if push came to shove
#1 = I am firmly convinced that the “new framework” was a design fail from the start, and was not “required” for iOS (my opinion) #2 - no use, as I don’t do console apps, but I realize that others do… #3 -perhaps may be a benefit, yet to been seen. but nothing that “excites” me #4 - Android? perhaps get iOS out of beta first? there are dozens of missing controls, hundreds of missing attributes, too heavy a dependance on 3rd party declares and workarounds… As I’ve said before… for the current level, it should be free, not a premimum price… I think Michel used the term “Fisher Price”
[quote=370418:@Dave S]gotta say… I could do without all 4 of those items if push came to shove
#1 = I am firmly convinced that the “new framework” was a design fail from the start, and was not “required” for iOS (my opinion) #2 - no use, as I don’t do console apps, but I realize that others do… #3 -perhaps may be a benefit, yet to been seen. but nothing that “excites” me #4 - Android? perhaps get iOS out of beta first? there are dozens of missing controls, hundreds of missing attributes, too heavy a dependance on 3rd party declares and workarounds… As I’ve said before… for the current level, it should be free, not a premimum price… I think Michel used the term “Fisher Price” :)[/quote]
#1 Well we discussed that at length before on this forum and we know how that went… I will say I do not necessarily agree or disagree. However, the way it has been handled since then is very poor.
#3 Interops is mostly exciting because declares are rough and so necessary on iOS and likely Android. That being said we have not even seen code snippet of what that might look like. I am going in with high expectations.
#4 I do not disagree that iOS is still essentially beta and I kinda touch on that. Nevertheless we need to be able target Android to be taken serious as a cross platform provider.
[quote=370424:@Dave S]Not “we”, but Xojo, Inc. … and to be taken serious, yes Android needs to be there… but iOS needs to come out of the toybox
my biggest complaint (well one of them)… Declares should be the EXCEPTION, not the rule[/quote]
Good catch - I meant provider. It is hard to solicit for mobile projects when I can’t provide Android with the same code base. So we end up having to use Xamarin or something else.
I would love async io. I do not believe pre-emptive threading will happen anytime soon. Perhaps the new framework is designed to be thread safe. If not then it probably will never happen.
Interops might be interesting. But I’d rather have Christian figure out this stuff.
Just say no to the new framework.
I’m currently working on my fourth helper app with the fifth on the horizon. All of them totally different. I can’t see how Xojo is supposed to help here.
Xojo for iOS was a one-man job, and as I understand it they let him go after they had a shipping product even though it wasnt the finished article it should have been.
#1 I agree that the two frameworks need to be unified, it’s going to be painful which ever way they do it, but they do need to it sooner than later.
#2 I totally agree with this and I think I filed some feedback reports years ago about a mechanism design that would make the console application invisible to the developer, look just like a thread in the IDE, but in reality it creates a console application.
#3 These sound very interesting and while it probably means I have to replace a lot of existing code, I do hope that they help with things like handling IAP and dealing with API which returns on a non main thread.
Helper apps usually involve data sharing so that probably means you are sharing classes and code between the main app and helper app projects. It would be great if a Xojo project could support multiple app types as you could then store everything under one roof. I would also like to see some holes plugged when using external classes and source code management.
My gut feeling is that Xojo are completely ignoring the ability to have real threading which is a shame as it limits what you can create and makes other languages more attractive. I imagine this could be a bigger issue under iOS and the forthcoming Android where I imagine helper apps are a no go.
I believe Mars was contracted to create a MVP which he did - let go? I don’t think so.
The concept of MVP (Minimum Viable Product) is used in all industries. Would you wait until your product was feature complete before shipping? You’d go broke first! The Wright bro’s should have waited until they could fly a 747 before demonstrating flight (Richard Pearse did it first BTW).
The 4 release per year target that Xojo have allows us to have access to features & improvements that we would otherwise wait years to get while they “perfect” the product.
I think our (make that your) expectations are somewhat more than realistic. How could we expect iOS projects to reflect the same depth of features as Desktop with over 15 years of incremental improvements?
As for the complaining about the new vs classic framework.
We could already see an issue arising for example we have textfield (for desktop projects) we also have webtextfield (for web projects) we could also have had iOStextfield and androidtextfield. It is so ■■■■■■■ obvious that a new way of dealing with this was required. Xojo have bitten the bullet and are moving forward in a very logical ( & clever) manner.
I can also see down the track that there might be a linux framework & perhaps a windows framework to go alongside the existing MACos framework (currently called classic). None of which would be possible without refactoring the system.
I will be looking at the applications from other commentators which are feature complete in version 1 and therefore will never require upgrading and obviously won’t have an upgrade fee
I believe so too Phillip. But it’s sad news since the corporative threading we have now doesn’t bring mutch and added the fact that xojo-database plugins are not threadsave and so intervals of timers cannot always be trusted drives us to the need for helper apps.
20 years ago, with the good old VB6, I was happy with this solution, but we should have had expect a more mature platform nowadays.
Some more items for the list : #5 Enhancements to the debugger
The current debugger is useful but limited comparing to other dev. tools. It lacks several features.
- being able to search for variables (and/or filter them and show the locations)
- display variable content with tooltip while debugging
- watchpoints (variable values or expressions) and conditional breakpoints
- show timer/other special constructs in the debug window
- list of all defined breakpoints
- being able to move the execution point
- one time breakpoint
etc.
#6 Some modern language constructs
Slices for arrays, strings
“Conventional” arrays for faster processing
String interpolation
#7 Code optimisation
#2 Helper apps : I would greatly like to have a way (but not be forced to) to keep helper apps in the same project as the main app.
Perhaps a special module kind could be reserved for this. The build system could then generate the helper binary automatically and place it where it fits.
A simple API would allow to spawn/instantiate a helper, control it (suspend, resume, kill). Communication should be done through channels. A list of all instantiated helpers should be kept. Also being able to clone helpers easily keeping or changing the destination channels, killing them would be great.
[quote=370488:@Wayne Golding]As for the complaining about the new vs classic framework.
We could already see an issue arising for example we have textfield (for desktop projects) we also have webtextfield (for web projects) we could also have had iOStextfield and androidtextfield. It is so !@#$% obvious that a new way of dealing with this was required. Xojo have bitten the bullet and are moving forward in a very logical ( & clever) manner.
[/quote]
Controls obviously need to be different on very different platforms such as desktop vs web vs mobile… but that does not mean the new framework as conceived was needed…
The problem IMO with the new framework is that it is too picky and more “computer sciencey” making it less approachable and less RAD than the old, and so more work and less “fun”. I’m not saying the old framework is perfect… It certainly has plenty of warts…
But the new framework overall feels like it has a design philosophy that is different in ways far beyond just dealing with edge cases and inconsistencies in the old one…
To me it feels like it has a different user base as it’s target audience than the old one, regardless of if that was intended or not by Xojo inc …
Anyway those are just my feelings/impressions and I know Xojo Inc will likely not turn back…
[quote=370533:@Karen Atkocius]The problem IMO with the new framework is that it is too picky and more “computer sciencey” making it less approachable and less RAD than the old, and so more work and less “fun”. I’m not saying the old framework is perfect… It certainly has plenty of warts…
But the new framework overall feels like it has a design philosophy that is different in ways far beyond just dealing with edge cases and inconsistencies in the old one… [/quote]
Completely agree.
I think you are right.
For me Xojo like Apple has lost its soul. Apples aim under Steve Job was excellence at every level - now its making shareholders happy. Xojo wanted to make object-oriented programming easy. The new seems to go into a different direction, and as for example Sam and Phillip pointed out Xojo could do a lot more to automate using multiple cores. For the moment both are still the best choice for many situations though.
