Rollo62

512GB HD If possible, choose a decent SSD, its worth it, even with a little cost-up.

As far as i know, Android x86 is not supported. You can check the current Plattform Status, i cannot check the dokwiki right now.

Right, but its the cheapest way to start M1+ development and even reasonable local AI expermiments ( Llama3 8B runs on M2+ not so bad, much cheaper than Nvidia GPU ). You can purchase an older, refurbished x86 machine maybe cheaper, but then you are stucked on x86, as fas as I can say will Apple hardly kill development any time they want.

Why not? If there is a change that he wants to create CrossPlattform Apps, this will be a good choice. With Parallels Desktop, it runs Windows, and as far as I know Delphi runs nicely on an M1 MacMini. I only use MacMini for XYCode purposes, so never tried to install Windows + Delphi there. It depends, depends, depends, on what you need.

So you would say Apple M3, M4 is not performant enough against Intel? You're maybe right in the top 5 positions, but there is also the parameter "Price". All in all, I would say ARM has the strong ability to overtake all parameters in the near future, while Intel struggels a bit at the moment.

My 5 ct: Either CISC Intel/AMD manage the complete U-turn to achieve CPU/GPU/NPU at lowest power consumption with highest performance at best economic cost, or RISC will win the race in the long run. Microsoft on ARM just shows that not everything has to be locked to x86, but also Android/iOS clearly show where the performance can be with ARM. For me, the question is not if, but only when the ‘ARM singularity’ will happen. If you believe in the CISC U-turn, then maybe it won't happen, but what magic wand would Intel/AMD have against Qualcom, Apple M1, Samsung, NVIDIA, TSMC and so on? You have to bury your head very, very deep in the sand to believe in x86's sole dominance.

https://docwiki.embarcadero.com/Libraries/Athens/en/System.SysUtils.DeleteFile

This is pretty much overwhelming. I'm afraid there is already a point here where users are shocked by the functionality and need a gentle way to climb the learning curve. In my opinion, it is always best to have many examples covering different levels of difficulty to understand the whole concept behind it piece-by-piece. If there is a clear usage concept behind it, how could you explain it in the docs, maybe step by step? Maybe a user needs a mix of Delphi and HTML/JS knowledge to understand most of it, how can these lessons be broken down into small, digestible chunks?

My update/upgrade process tends to be more and more complicated every year. This is much more enhanced right now: https://en.delphipraxis.net/topic/1336-fmx-crossplatform-best-practices-upgrading-1031-to-1032/?tab=comments#comment-11214 In short I would say, to be stable in FMX cross-platform: - Use VM, backup VM - Clean VM, remove any part of IDE (means also cleanup certain folders after uninstall, to remove any missing items), Interbase, SDK's, JavaJRE, ... - Clean install IDE - Check & set paths - Check & set environment variables - Setup IDE, but mainly keep original settings as-is - Install used components & experts - Add SDKs in SdkManager & Update local cache - Create empty projects, with default settings, to check for any changes in .dproj, Android.template.xml, iOS.plist, etc. - Duplicate any projects .dproj into new version folder (! so not overwriting the former version) - Open .dproj w/ IDE and compare for changes and compare with new, empty project, for added or changed items - Open UnitTest, check for failures - Open main libraries, install & test - Open project 1, Android update libraries, test ....

What about // Key Value TDictionary<Integer,string> with Integer Key as Hash from the original string? This will allow you to handle and operate with key's and only retrieve the real, original strings whenever necessary.

Hi there, I had again alonger session, making me headaches with mobile development. Android 12-14+ should currently be affected, I was able to prove this on various devices. The problem: With normal IoT applications, there is the option of using the ‘neverForLocation’ flag to bypass the annoying location query. So far, so good, this works with the normal BLE modules. However, there are products that appear as IoT with a normal, general serial interface ( Characteristiocs Write / Read / Notify ), but in which obviously a beacon chip is installed internally, which outputs a beacon / iBeacon identifier. The special beacon function is not used at all, but is only present in the ‘Manufacturer specific data’ of the chip. The device can be addressed normally via the characteristics and it works as it should. However, if the ‘neverForLocation’ flag is used in the manifest, these IoT devices are suddenly no longer listed in DeviceDiscovery. This makes sense, of course, because a beacon is a location-based device. It is noted here under the Bluetooth definitions: The solution: Doesn't seem to exist. # Either remove the ‘neverForLocation’ flag, then it works, or # Do not use a BLE module that is pre-programmed for Beacon/iBeacon. You can identify the modules with e.g. the nRF Connect app in the list as ‘Device XYZ (iBeacon)’, you can click on them and display further data with ‘more’: ‘Company: Apple, Inc. 0x04’ and ‘Type: Beacon: 0x02’. The LightBlue app shows ‘Device XYZ’ in the list, if this is clicked, then further data is shown. Among other things, the ‘Manufacturer specific data: ’Apple, Inc. (0x4c): 0x0215FDA5....’ This identifier 0x4C02 therefore seems to be decisive for the categorisation as an iBeacon. Are there maybe any other possible solutions, to use iBeacon, but still get listed in a normal DeviceDiscovery? If not, then at least I hope my description might others stepping into the same trap.

Not followed here exactly, but I would always recommend to try to check exactly the same path: if TFile.Exists(JStringToString(PackageName)) then begin TFile.Delete(TPath.GetHomePath + PathDelim + 'myDatabase.s3db'); maybe like this, if both "exists" are relevant if TFile.Exists(JStringToString(PackageName)) then begin if TFile.Exists(TPath.GetHomePath + PathDelim + 'myDatabase.s3db') then begin TFile.Delete(TPath.GetHomePath + PathDelim + 'myDatabase.s3db'); end; ...

Now I stop having too many bad thoughts about the whole Tiobe-System, thank you, its all right again and I start liking it

Perhaps using threads might help, to keep animations flowing. But to be honest, I really would rather skip the whole SplashScreen idea at all, especially with animations. Even using threads might get into nightmares, not worth the efford at all, for example splash screens might stay invisible, behind other processes etc. From my experience, splash screens are a call for problems only. It might confuse, en-nerve your users, waiting for something usable showing up. My preferred strategy, if that is possible ( not always can be done like this ), show the main entry page as soon as possible in a greyed out manner maybe plus "loading ..." label, and lazy-load the rest of the app afterwards. This gives a much better, responsible user experience IMHO, which is not interruppted or cluttered by splash-screens, which always felt to be too long.

Yes, that seems a good choice, but maybe you can clarify a few questions, which would be important. In some place they declare something, in other places they stay a little more vage, so it would be great to know if everything is supported as expected. # Is this product based on or related to Indy, or just cooperates with Indy, or is completely different, standalone and not-compatible? # Are all platforms natively and fully supported (in other places they descibe this not so clear)? As stated here: https://www.devart.com/sbridge/compatibility.html Supported Target Platforms Windows 32-bit and 64-bit macOS 64-bit and ARM (macOS Apple M1) Linux 32-bit (only in Lazarus and Free Pascal) and 64-bit iOS 64-bit iOS Simulator ARM 64-bit Android 32-bit and 64-bit # Are any pre-compiled static or dynamic binary libraries or SDKs needed, are they included or are sources included to compile them externally? Or is everything pure pascal source? # How is SSL ( OpenSSL ) supported, as binary library, or pascal unit?

Like said, maybe you even need more decoupling, by a timer. Perhaps Android needs a while interally to build and save a PDF in the background, if PdfView kicks in too soon, that could maybe lead to odd behaviours.

Maybe this has also to be considered https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#FireDAC_SQLite_Version_Update https://blogs.embarcadero.com/new-firedac-driver-for-sqlite-see/ https://www.youtube.com/watch?v=hhzkxjYKv-g When using encryption, you seemed to be locked in into an older version from 2020, if I understand this right. Either you use the paid EE, or the outdated FDE.

Yes, I checked that, its a very heavy and mighty DB that needs a lot of maintainance attention, IMHO. It can do much more, what I ever will need probably. I do like the more light weight DB, which are more easy to handle and with a less steep learning curve.

I would not use any of those for a local app, that doesn't really hardly requires any of the big ones. The locical steps for me would be 1. Sqlite, 2. Firebird Embedded or Server, 3. only if that is not good enough something bigger. Mysql (or better MariaDB) would be the next logical step (3.) for me, PostgreSQL is quite heavy weight, but I have not much experience with it, perhaps its capable for doing huge stuff. SQL Server binds you more to the Microsoft environment, if that is no issue for you. I was forces to use SQL Anywhere once and I was no big fan of that either. In the end, all SQL DB should work fine, at the SQL level, then maybe the small differences appear more important. Like drivers, like OS and general support, like portability, like certain SQL specialities (e.g. full text searc h), and so on. Generally I tend to stay with the most basic SQL sets anyway, which would allow me to switch easily between DBs anyway. What I can say is that Sqlite is perfect for local DB under all OS, thats the usual choice. Firebird server works also rock solid, even when not eagerly maintained, this really astound me how this runs untouched over many years. Interbase IBToGo is maybe a good choice for cross-platform too.

Sqlite can be used in large, production-ready sites, you could have a look what Pieter Levels does with Sqlite, PHP, JQuery only, like back to the roots. https://news.ycombinator.com/item?id=23359023 https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.youtube.com/watch%3Fv%3DB-_P0d1el2k&ved=2ahUKEwjJxILl-PuIAxXFSPEDHTKKOr8QtwJ6BAgKEAI&usg=AOvVaw0ESb4TJ_wTRTzhSmsFX7ot

Maybe that can give some ideas, although for Win and VCL. https://stackoverflow.com/questions/38273974/delphi-components-and-screen-readers Perhaps this can be implemented in similar ways on Android too? But I doubt it will be already well prepared under FMX, habe not checked recently. Edit: Maybe you can check, if this might work for you ( untested ) : But I doubt that the Delphi handle works as expected. uses System.SysUtils, FMX.Types, FMX.Controls, FMX.Platform, FMX.Platform.Android, Androidapi.JNI.GraphicsContentViewText, Androidapi.Helpers, Androidapi.JNI.Widget; ... procedure SetControlAccessibilityDescription(AControl: TControl; const ADescription: string); var NativeView: JView; begin NativeView := WindowHandleToPlatform(AControl.Handle).View; if NativeView <> nil then begin NativeView.setContentDescription(StringToJString(ADescription)); end else begin raise Exception.Create('Das View-Objekt konnte nicht abgerufen werden.'); end; end; ... // Application for Label SetControlAccessibilityDescription(Label1, 'Das ist eine Beschriftung für den Namen'); ... // Application for Edit SetControlAccessibilityDescription(Edit1, 'Bitte geben Sie Ihren Namen ein'); ... // Application for Checkbox SetControlAccessibilityDescription(CheckBox1, 'Ich akzeptiere die Nutzungsbedingungen'); ... // Application for Switch SetControlAccessibilityDescription(Switch1, 'Benachrichtigungen ein- oder ausschalten');

But this would run fine too. procedure Test; begin Abort; end; It should be good enough to use fully qualified names only in cases of ambiguity, IMHO. The compiler shows such cases. But in the uses clause I always use fully qualified names.

Maybe these lists are intersting too, although not 1:1 what you're asking for: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List https://en.wikipedia.org/wiki/History_of_Delphi_(software)

Usually I try to use fully qualified namespaces only, in the unit and uses definitions. Still I can see that many code may use "partly" or "mixed" qualified namespaces, like this: unit MyCompany.Libs.MyUnit1； uses System.Classes, // Fully qualified name. SysUtils, // Generic name. MyCompany.Libs.Unit2, // Fully qualified name. UnitX; // Generic name. Are there any insights how this behaves, will the resolver of namespaces work on each single name separately and make a separate decision, or will the whole "uses" switched into a different, generic mode? The fully qualified name should be the most performant, and the total generic name should be the least performant, IMHO. What about a mixture of that, is it exactly according to the number of generic name count in those uses, or does it behave worse than that, more like if all where generic names?

Some more details on CmonLib TInitialize here too https://en.delphipraxis.net/topic/11986-best-way-to-set-early-global-variables-in-a-project-before-build-time/