Recommendations for new framework?

The new framework is a work in progress. No qualms with that. But it raises a question as this type of information is missing so far:

Which parts would you recommend for use over the old framework and why?

Equally, which parts would you not recommend, and why?

Xojo.Net.HTTPSocket should replace HTTPSocket and HTTPSecureSocket in my book.

Xojo.Core.Date is an improvement but lacks the nice to haves that make working with dates actually pleasurable.

Xojo.Crypto.* is essentially a copy of classic Crypto albeit with Text where appropriate.

Xojo.Core.Dictionary is useful for JSON if you are prepared for String -> Text hassles through the rest of the classic framework when trying to use JSON.

Xojo.Core.MemoryBlock is supposedly faster but I don’t know that as fact for myself. It lacks the most useful helper which is automatic conversion from Text that classic MemoryBlock has for String making getting data in/out a real chore and likely nullifies any performance improvement.

Xojo.Introspection.* is good but offers little over classic Introspection. I think it might expose some additional internal details but I’d have to compare/contrast. Perhaps it is identical.

Xojo.IO.* is the same as classic except where more limited such as SpecialFolder.* where it has not evolved away from iOS.

Xojo.Math.* is just some of the classic global math methods namespaced.

Xojo.Net.TCPSocket is good and I have used it as a super for some clients but it does not support listening nor is there a ServerSocket equivalent.

Xojo.Threading.* is just copy of classic.


So to answer your question the only ones of real substantial benefit are Xojo.Net.HTTPSocket, Xojo.Core.Dictionary, and maybe Xojo.Core.Date.

We live in a globally connected and interdependent world now. The classic Date class has no understanding of Time Zones, daylight savings, etc. When these things matter it’s easy to write code that would get you into trouble without even realizing it until it’s too late.

Same with the IO stuff. The classic framework doesn’t require you to be clear about which encoding to use. In the new framework it’s required so you don’t end up with encoding-related misbehavior in your app at runtime.

All the changes we have and are making in the new framework are to reduce problems we have seen time and time again on this forum and via tech support. Some may seem subtle or even minor but they are still improvements.

Having said that, yes it’s incomplete. As more becomes available, it will be more useful. And I sympathize with having to deal with strings versus text and other places where you must operate on the border between the old and the new. That can be a hassle and I can’t wait for more of the new framework APIs to be available.

[quote=359249:@Markus Winter]The new framework is a work in progress. No qualms with that. But it raises a question as this type of information is missing so far:

Which parts would you recommend for use over the old framework and why?

Equally, which parts would you not recommend, and why?[/quote]

A reasonable, well-thoughtout question. Thank you, Markus.

Xojo.Core.MemoryBlock is a real improvement with functions that make copying data among them faster and easier. Converting to/from Text to the new MemoryBlock directly does not make sense since, unlike String, Text is list of code points, not a bucket of bytes. What I would like to see is a direct conversion to/from String and to/from the classic MemoryBlock.

Overall, there seems to be a wall between the classic and new frameworks that makes it harder to transition. I’d like that wall to come down a bit.

Text is a conceptual improvement. I wish it were named something else like Unicode, but the only real downside right now is how slow it is to use on Windows/Linux (I think that’s still the case but haven’t tested of late). Once that’s fixed, I expect to use it a lot more.

The last time I tested, Xojo.Core.Dictionary was slower than the classic version so I have avoided it.

The new Introspection lets you get TypeInfo on intrinsic types (String, Double, etc.), a great improvement over the classic.

Finally, the new framework has standardized function names and zero-based indexes, also a huge improvement.

You will get a riot on your hands from people who cannot wrap their heads around asynchronous :wink:

Certainly Auto Conversion of string (when it has an encoding) to Text would help, as would having having things like SQLDate and SQLDateTime on the new date class…

In general making the new framework classes and have as many of the feature of the old as makes sense would help…

IMO in general the old framework strikes a “better” balance between safety and convenience than the new one for a RAD environment. I wish something could be done about that…

And of course performance/speed matters. For a specific app for a specific defined use case, speed optimization is often that not important… but for Xojo as platform it matters more, Because it can be used for anything, general speed optimization is more important than for any specific app.

  • Karen

This is already there. Just request a date with a Nil locale.

I ran into something like this yesterday where I needed just a time, not a date and and a time. Paul showed me how to do that and realized that we didn’t have an example of that in the documentation so he’s adding one.

Is an extra line of code not worth the knowledge that your code will function properly? Seems like things such as DateInterval and having to providing an encoding when data is going in and out of your app are worth the little additional effort to make sure you won’t have runtime problems.

We chose Text as a name because it’s the best representation of what the type is. Yes it’s unicode behind the scenes but that’s an implementation detail. String IHMO has always been a horrible name. It’s something you have to learn because as someone new to programming it makes no sense at all. When I was learning C and it was explained to me that a string is really and array of characters (a string of characters), it made more sense but again it just seemed like unnecessary obfuscation.

You could easily convince me of that but for the existing use of “Text” in controls declared as String. It’s within that context that I would have preferred a different name.

However, this is a minor objection, hardly worth discussion at all.

We are trying to move away from that in the new Desktop framework. Text is sometimes descriptive but something like Contents is better. The contents of a control might not always be text but it will always be Contents. :slight_smile: That means that if you know a control has contents you can guess what the property is called rather than having to think about what type of contents it has.

I like Value

@Geoff Perlman

Term ‘Cross platform’ - for iOS, MacOS, Windows, Linux and RPI

  • Cross platform support for standard data encoding engines such as Base64, UU, Hex and etc. since current ones are not cross platform and they not working as it should. I already submitted feedback and no reply at all. Even example which is coming as part of Xojo examples not working well on iOS for example.

  • Cross platform support for data compression (zip, zlib, lzv) in memory and as file;

  • Better handling of text data type conversion when text encoding is in use;

  • Cross platform - adding support for X509 certificates (allow to create, use, do administration and etc.);

  • Cross platform - adding support for OpenPGP as encryption and as any e-mail support interfaces;

  • Cross platform - adding support for S/MIME;

  • Cross platform - adding support for symmetric encryptions such as AES 128/192/256/512, Camellia, CAST-128/256, IDEA, RC2/RC5/RC6, SEED, ARIA Skipjack, TEA, XTEA, Twofish, SERPENT, SC2000, Clefia. Also support for wide range of modes such as ECB, CBC, PCBC, CFB, OFB, CTR, XTS.

  • Cross platform supoort which allows working with PowerShell script side by side with Xojo from Xojo code like you can use shell now via Xojo;

and so on…

[don’t have much time to write full list…]

Actually, I think that is what we have settled on.

We don’t usually reply to cases (feature request or bug report) unless we need more information. So don’t take a lack of reply as meaning anything other than we understood what you were asking for.

@Geoff Perlman

Regarding to encoding example at least I expected to work :slight_smile:
Even after I play a bit around and ask some people I found solution but partial since there is a issue in implementation. That is why I wrote above things which shouldn’t happen.

Keep in mind that examples which comes with Xojo should represent best of Xojo and that if everything I set from working condition should work like swiss clock!

I would like to support you guys and would like Xojo to forward but also I understand that everything is on your end not on ours.

This frankly and friendly and hope you don’t mind on this.

Not everything is on their end as we, as programmers, can implement some of that stuff ourselves.

For example, my M_Crypto project already implements AES and Blowfish with ECB and CBC modes.

If you find any example that doesn’t work, please report it using Feedback.