I missed the live Q & A. If anyone managed to catch it, please post here what was said.
I should let Hal summarize if for you 
I didnt find it terribly enlightening as there was still a lot of āin the futureā kind of talk and things they couldnt tell us
They did record it so maybe they will make that available ?
Ah I didnāt realise they were recording it. I assumed that they wouldnāt in case someone caught them off guard with a question.
Iāll wait patiently to see if @HalGumbert writes something down.
I think the only comment Iāve seen him make so far was on the discord
I got the impression he was disappointed (?)
there are follow on discussions on the forums about workers and man I sure ho they fix the way things are right now
https://forum.xojo.com/conversation/post/480955
Karen asks a very good q and the answer is ā¦ well ā¦ not entirely pleasing
EDIT : at this time
1 Like
Watching it now. Thereās no way workers are coming out in R1. Doesnāt look like iOS API 2.0 either 
It sure sounds like Workers are going to be VERY limited initiallyā¦ and if history is any guide, for a LONG time.
-karen
1 Like
Yeah I was surprised by Kems answer to your question - makes no sense to me that the worker couldnt also have a fair amount of the main app code compiled into it.
But without a compat flag of some kind (like the Desktop, Web, IOS, Console ones) exposed there no decent way to do that and indicate what code would even b proposed to be compiled into the worker.
At least that way I could pass data in JSON that made up some object, use that to create an instance from the data, then I can no reuse my object code for whatever it is Iām going to do
But at the moment that doesnt sound possible
Flags are one solution, but I would thing that the compiler could just include all code used by the worker subclass in the worker app, and throw errors if any code used in the worker is not usable in a console app.
But I can see how that could be an issue for code in classes and modules where some of the code is not console safe and some notā¦ The compile would need to handle that and Iām guessing it canāt. Of course that situation could just trow a compile error
1 Like
the IDE has to send the worker all the code and then the compiler could strip it out based on usage
however since a worker i a console app it probably should not be sent any thing like a window etc that is UI
I guess, like you, Iām more surprised some of this wasnt already done or thought of (apparently)
1 Like
If you donāt mind me asking, what was your reasoning behind the choice of JSON? A well constructed binary format should be faster to serialize and de-serialize.
Because naturally scheduling eats into time saved by concurrency, any time that can be saved here, will impact the overall time. At least thatās my thinking.
I saw that the workers are persistent, which is good IMHO, as it reduces launch/release delays.
not sure unpacking binary would be that much faster
it might
its really going to depend on how/if they can make it so these easy to build helpers can get access to the same code we use in the main app
not being able to leverage that code is a huge loss IMHO
they really need to solve that
1 Like
Correct me if Iām wrong but the current compiler could strip a lot of things from the code that eventually end up in our built apps (like unused framework components) to make our apps smaller but it doesnāt. Not sure Iād cross my fingers for it to do it when it comes to workersā¦
I breathed a sigh of relief at that too.
A related question, perhaps best answered by @samRowlands, do you think we will still be able to distribute apps using workers on the Mac App Store if they have bundled console apps?
1 Like
Yes.
1 Like
Why do they still show stuff that we wonāt be able to get in 2020r1? I really donāt understand the reasoning. Xojo has teased us for years with āoh, xyz is just around the cornerā. This is getting old old old.
1 Like
I basically said itās just vaporware until it ships. Been waiting around three years. When it ships all the controls demoed years ago wonāt all be there as some will come ālaterā. While Im happy about a Date Picker, thereās no sign of a Time Picker or Timestamp Picker. Literally, WTF.
Also disappointed that āEasy Database Connectivityā is further down on the list.
Making me glad I jumped into PHP. where I can apply my Xojo skillz.
2 Likes
Correct me if Iām wrong but the current compiler could strip a lot of things from the code that eventually end up in our built apps (like unused framework components) to make our apps smaller but it doesnāt. Not sure Iād cross my fingers for it to do it when it comes to workersā¦
It does this already
What it DOESNT do is trip at the level of methods
It will strip out classes & modules that are never referenced
So it definitely could do this for workers
But the IDE would have to NOT send the code for any UI elements (windows, menu bars, buttons, etc) as if you try this in a console app the compile fails VERY early on. Long before it ever gets to the point of linking and striping out unused code.
1 Like
Phew.
I suppose this isnāt an announcement of whatās coming in the next release, merely whatās been going on over the last 12 months. I agree though that itās very annoying to tease a feature that isnāt bake with their track record - it may well be 12 months before we see workers for all I know.
I learn something new everyday.
1 Like