Rollo62

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/

In some rare cases I add a "Module_Init();" function in such units, which can be called from the caller unit or initialization process, to have a little bit better manual control over the initialization order.

Here are some libraries, some were not free unfortunately https://github.com/landgraf-dev/aws-sdk-delphi https://www.tmssoftware.com/site/tmsfnccloudpack.asp# https://www.appercept.com/ https://www.esegece.com/openapi/apis/amazon-aws-sdk

For me it was quite the opposite. Ok, Claude gives a more short answer generally, while CGPT might give longer explanations in more detail. But Claude for example seems to hallucinate specific abbreviations, like this '"Holistic Supply Chain Compliance Report (HSCCR)", which I think nobody is using in the real world. Such hallucinations I had never seen with CGPT in the whole last year, it was always quite precise and spot-on. Perhaps it depends a lot for what you are going to use it mainly, in my case, it not 100% for coding.

Simulation doesnt help much with IoT Devices, unfortunalely.

OpenAI is the most capable, now also as Version ChatGPT o1

You can follow my Odysee here https://en.delphipraxis.net/topic/11463-ios-xcode-15-madda-make-delphi-debugging-again-after-01may-2024/?tab=comments#comment-90929 Not happy debugging here either, so my silent hope was 12.2. But it turns out, that Delphi 12.2 doesn'T change andything, as they told us yesterday. I'm still preparing my move to Delphi 12.2 for testing, so I still have min imal hope 🙂

https://www.youtube.com/watch?v=E73cMk856xM&list=PLwUPJvR9mZHisbPqXfMYk6JOzx_5IF_k6&index=1 https://youtu.be/E73cMk856xM?list=PLwUPJvR9mZHisbPqXfMYk6JOzx_5IF_k6

....

Perhaps it would even better to decouple this a little more, to be on the safe(r) side against timing problems on different OS and hardware. This is what I would usually do, if not really give a delay inbetween, like 50ms or so: TabControl1.SetActiveTabWithTransition(TabItem17, TTabTransition.Slide, TTabTransitionDirection.Normal); TThread.ForceQueu( nil, procedure begin FPDFControl.LoadPDF(sFile); end );

Sorry, that was the least biased answer, to such an wildly general and fully open question