Hans♫

If you plan to buy a mac (mini), please note: the simulator only works on ARM processors. All new macs use ARM now, but if you buy an old one, be sure to avoid Intel. The first Mac Mini with M1 (arm) processor was released in 2020.

It also depends on your need to access the hardware on the computer. If you need to access microphone, camera, harddrive, audio, USB devices, etc. you have much better control with an installed app. It is the case with both desktop and mobile devices. That's the reason we release our app on Windows, MacOS, Android and iOS.

Ha, ha, I am sure you know what I mean 😉 I'm no expert in the compilers memory management and optimization. I was trying to explain why it made no difference to add [ref]. I guess that if you create a "packed" record that is smaller than a pointer then it will be passed by value.

Thats because there is no difference. As the text says, with "const" only, the compiler decides the most efficient way. For a record the most efficient way is to pass its reference, so adding [ref] makes no difference.

I think the answer is in this text from the FreeAndNil article linked above: ... [ref], which forces the compiler to pass a const parameter as a reference. Without it, the compiler can optimize passing of const parameter depending on the size of the parameter.

Ok, thats great. So let me elaborate: When you have found out what native functions are used in Objective-C to get the wanted result, then you can search the source code of Delphi for those functions. This will tell you exactly what function to call in Delphi to access the feature. Its of course nice to be able to get help here in DelphiPraxis, but its even better if you know how to find the solution on your own - and its much faster 🙂

To increase the chances for a positive response, I would recommend to first check if its possible at all with XCode and Objective-C. If it's possible there then its usually also possible in Delphi, and then you can begin figuring out how its done and eventually ask about it here.

Thank you so much 👍 We have successfully incorporated your new solution in our project (we use our own build script). It has also been tested on Play Store and that works too!

It might be a simple task for some, but at least not for me 🙂 First step of the switch is to create a Delphi interface to the new jar, and next step is to make the code work with that interface and jar. With the current solution we used the interface to play-core-1.10.0.jar, that you created and supplied in your Kastri example project. I made a quick attempt to do the same myself for asset-delivery-2.2.2.jar, using Java2OP.exe and the instructions supplied by Embarcadero - but unsuccessful. I believe this is just the first problem, out of many, to complete this switch of jar's. Probably because I have no idea what I am doing... So I won't list the error messages here to start a problem solving session. I think it is more beneficial for the Delphi community if its solved by a competent person and shared with the community - and I'll be pleased to pay for the work, even if its shared.

With the new API 34, it looks like the solution we made for install time assets, based on the Kastri example, no longer works. When installing the resulting .aab on a device (Google Pixel8) running Android 14 it throws an security exception and the Install Time asset isn't loaded: java.long.SecurityException: com.<applicationname>.android: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts As far as I see, the problem is the play-core-1.10.0.jar (February 2021) is no longer accepted. And we need to migrate to the new Play libraries (since April 2022) https://developer.android.com/reference/com/google/android/play/core/release-notes Specifically the Play Asset Delivery Library - Latest update 2.2.2 (May 2024) https://developer.android.com/reference/com/google/android/play/core/release-notes-asset_delivery Anyone having experienced the same?

@vfbb Any update on this issue? - Maybe a bug should be filed in the QP?

Yes, I can reproduce this in a blank project. You did not see it because you used gray in gray. When using white on black, then you can see it: <No Skia | Skia + Vulkan > Enlarged: <No Skia | Skia + Vulkan > This is produced with an empty app with only this code: GlobalUseSkia := true; GlobalUseSkiaRasterWhenAvailable := false; GlobalUseVulkan := true; ... procedure TForm1.PaintBox1Paint(Sender: TObject; Canvas: TCanvas); var lStroke: TStrokeBrush; lPath: TPathData; begin lStroke := TStrokeBrush.Create(TBrushKind.Solid, claWhite); lStroke.Thickness := 1.5; lPath := TPathData.Create; lPath.AddEllipse(RectF(-12, -12, 12, 12)); lPath.Translate(50,50); Canvas.Fill.Color := claBlack; Canvas.FillRect(RectF(0,0,100,100), 0, 0, [], 1); Canvas.DrawPath(lPath, 1, lStroke); lStroke.Free; lPath.Free; end;

Its a path. Our code looks like this (simplified): fStroke := TStrokeBrush.Create(TBrushKind.Solid, claSilver); fStroke.Thickness := 1.5; fPath := TPathData.Create; fPath.AddEllipse(RectF(-12, -12, 12, 12)); ... Canvas.DrawPath(fPath, 1, fStroke);

Thank you. We had the Form.Quality set to SystemDefault, which seem to do the same as setting it to HighQuality. I tried to set it to HighQuality, but did not see any difference. However, I just found out that with Skia+Vulkan, it actually draws with anti-aliasing, but in a very simple way. Here is our back button. The version to the left is with no Skia. To the right it is with Skia + Vulkan: <No skia | Skia+Vulkan> I though the Skia+Vulkan version was not anti-aliased, but when enlarging, I can see that it is: The quality of the anti-aliasing is simply lower with Skia+Vulkan (and the forms quality is set to high quality). Is there a way to change that?

Yes, it looks the same both with and without Vulkan: no anti-aliasing.