Rollo62

As said, its not FMX related, but gives you a lot of info about memory usage, performance, power consumprtion, hardware, network status etc. It has several tools that can be configured in a custom way. Instruments is a kind of separate tool in XCode, so not much problems to use it, it can connect to running or start new processes.

Profiling is a bit tricky, I think there is no real integrated version for FMX yet. But you could try to use the Macos XCode Instrument tools, they show a lot of details for any running apps, but I havent used them any more in the last few years. I think it should be more powerful and useful even. https://gist.github.com/loderunner/36724cc9ee8db66db305

I'm not sure what exactly you are looking for, especially for FMX. A Macos "performance monitor", like a rudimentary "Windows Task-Manager", is called ACtivity Monitor under Macos. This has nothing special for FMX of course.

Ok, here is something to play around with natural spline interpolation vs. other kinds. https://tools.timodenk.com/cubic-spline-interpolation Maybe that has enough gamification factor to fulfil the high expectations here.

So you need to fit all datapoints, but want to avoid large overshootings, then this paper is maybe also interesting for you. https://towardsdatascience.com/numerical-interpolation-natural-cubic-spline-52c1157b98ac

Android: There are quite old infos from Brian Long, maybe too much has changed meanwhile. http://www.blong.com/articles/delphixe7nfc/nfc.htm Android iOS: Maybe WinSoft ? https://winsoft.sk/infclib.htm https://blogs.embarcadero.com/powerful-core-nfc-api-library-for-delphi-firemonkey-on-ios-by-winsoft/ And maybe you find something in Dave's great Kastri Library too https://github.com/DelphiWorlds/Kastri/blob/master/Demos/NFC/MainFrm.pas

Sorry, its probably too late. I had read it as: ... I dont have any issues IOS - Developer/Deployment certificate with Provisioning profile.

Done. But the personal questions had gone way beyond of good taste, IMHO.

For iOS distribution you MUST have a developer account, a provision certificate, etc. etc. etc., the whole Apple "Security by bureaucracy" flash ... https://docwiki.embarcadero.com/RADStudio/Sydney/en/IOS_Mobile_Application_Development I'm afraid there is no way around it.

Haven't checked the sources: I would assume that the SubscribeToMessage() is called twice, with using the same event handler. That should not be allowed, from the EListError error above. So you could try to move this line to a position where it is only called once per lifetime of the app, during initialization ( in TScreenOrientationMonitor.Create for example, if that exists in the source ).

Maybe adding 'android.permission.BLUETOOTH_ADMIN'; makes any difference for you. Not sure how Pairing and Bonding differ in detail, and can be used under Delphi. Do you have any simple example code of what you want to achieve in Java (Android) / Objective-C (iOS) ? Maybe its possible to add and implement that in Delphi too In the code above you don't do anything "bonding special", I would say. https://medium.com/@martijn.van.welie/making-android-ble-work-part-4-72a0b85cb442 https://www.kynetics.com/docs/2018/BLE_Pairing_and_bonding/

Hi there, I'm playing around with the platform behaviours, and I found some strange behaviour when adding them to both 32-Bit and 64.Bit. (1) 32-Bit node: While it is possible to add the library to 32-Bit, ... <== dw-kastri-base-2.0.0.jar was added (2) 64-Bit node: it seems impossible to add the same library to the 64-Bit node: ... <== dw-kastri-base-2.0.0.jar cannot be added Although it seems pretty much possible to add different libraries under the same name ( see work-runtime-2.1.0.dex.jar or others of the default libraries ). In case (2) under 64-Bit I don't get any error or message or something, it simply didn't appear in the list above. It seems to work when I add under 32-Bit only, also under 64-Bit (at least I don't see any errors here), but it doesn't work when I add it under 64-Bit node only. Then it seems not be available in the 32-Bit node. It seems to compile, run and work anyhow, see enclosed demo, but I'm unsure if this by lucky accident ony. Maybe you have some idea what could be going wrong here ?. T457_TestAndLib_001.zip Running under Delphi D11.1 Patch 1

Yes, sorry for that. I am currently chasing some strange behaviours I see on some older Android systems maybe connected with Android-32 CPU. Thats why I just try to look into all possible corners to find a reason, but I have no clear reproducable error right now.

For what platform ? From my setup here: Under Android64, debugging is broken in more complex projects, already since >= 10.4 or so, simply starts veeery slow, shows blackscreen and stops. Under Android32, debugging is still fine and fluid. But I haven't seen such D33566 yet. My recommendationm for any Internal error is, to completely clean all compiled, temporary stuff, and build the project new. That resolved the internal errors in 99.9% in my cases, which leads to my opinion that internal errors are causes mostly by mainy failing processes, leaving DCU or other files in a ghost state.

@Dave Nottage Thanks, that's interesting. Unfortunately it doesn't give me a clue howto workaround these issues really in a reliable way ( currently I'm not dealing with service, but wanted to know howto handle the .jar in the right way ). I considered a "brute-force" copy and paste the same library into the 32/64 Bit structures, but I had to realize that this is only one structure under a general entry "<ItemGroup>", which has no platform specific versions. <ItemGroup> <DelphiCompile Include="$(MainSource)"> <MainSource>MainSource</MainSource> </DelphiCompile> <DCCReference Include="Unit1.pas"> <Form>Form1</Form> <FormType>fmx</FormType> </DCCReference> <JavaReference Include="..\..\..\Kastri\Src\Lib\dw-kastri-base-2.0.0.jar"> <Disabled/> </JavaReference> <BuildConfiguration Include="Base"> <Key>Base</Key> </BuildConfiguration> <BuildConfiguration Include="Debug"> <Key>Cfg_1</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> <BuildConfiguration Include="Release"> <Key>Cfg_2</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> </ItemGroup> That would explain why there is a "There can only be one" behaviour for the .jars. I slightly assume it doen't really matter if the library is in the 32- or 64-Bit tree, as long as it is there it will be taken for both. Howto ensure that it is taken for both, is there a secret Delphi switch ? Strange is that there were are separate library trees for the standard libraries, for 32- and 64-Bits, just as it should be: <PropertyGroup Condition="'$(Base_Android)'!=''"> //<== 32-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;FmxTeeUI;bindcompfmx;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;dbrtl;FireDACDBXDriver;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 32-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> <PropertyGroup Condition="'$(Base_Android64)'!=''"> //<== 64-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;PkS4_Core_Rx1111;FmxTeeUI;bindcompfmx;hclcore_xe11;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;htmleditcore_xe11;htmledit_xe11;dbrtl;FireDACDBXDriver;htmlcomp_xe11;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 64-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> Just looking at the "annotation-1.2.0.dex.jar" entry, there were two places where it is included. While for the external libraries, see above, Delphi allows only one place for all architectures, strange. Still I'm unsure if this one will be enough for compilation of Android-32 and -64, how could I check if a library is binded into the package ? I can find the reference, I assume, inside the classes.dex, but not sure if it always gets there . Will there be any useful error message, if the reference would be missing, either in 32- or 64-Bit or both ? This error hopefully pops by linker failures. When I would ever need to handle separate 32- and 64-Bit Jars, I'm afraid there is no option in Delphi to do that right now, maybe by adding a wrapper JAR only, handling that externally.

@Minh Hoang The error 96/05/2022 10:20:30 is clearly not a valid date. But this format also might lead to the consideration if you are using the appropriate TFormatSettings for the conversion itself. Since "/ :" separators are used in US mainly, other countries might use different formats, for example in Germany the usual format is "dd.mm.yyyy hh:nn:ss". I think in asian countries you also might have the ". :" separators , which may lead to similar errors when not taking care about them. Suddenly a program running well in your country might crash in another country.

Why not upload via PAServer ? Have you tried to delete all apps with same name, or BundleId before ? It seems that you have an existing app, maybe due to Apple Configurator, thats why it cannot be re-loaded by PAServer ( a rough guess ).

Good point, but IMHO Skia is just in the early phase of rocketing launch into many projects. I would assume this may stay quite some time very active, the more people get aware of this nice library. Edit: References References References

Yes, thats true, but also my biggest concern. Google is lightyears ahead, and Embarcadero needs to follow Google, Apple, Microsoft, and whatsnot. This is clearly an unfair game 🙂 Thanks, I was not aware of that fact. That make is much more easy to just move to Skia, without too much rewrite of existing code. This makes is more easy to join and to use and improve it, you should make this fact more clear since this could ease the decisions. If it only would concern sourcecode, I would be relaxed, but since Skia also involved external libraries as a binary base, there is a lot more risk of using it. Easily it might break iOS, Macos, Android and even Windows, when running out of sync in new IDE, XCode, SDK versions or OS versions. Again, very good to know about the simple Skia on/off switch behaviour, so that I still can check FMX and Skia behaviour in parallel. You could not advertise this fact big enough

Thanks for the insights, this is what I expected too. There was a TScene "demo" from Eugene which pointed maybe in the same direction, this library I checked out some years ago, but never implemented into my current apps yet because the advantage was not so big for me. Maybe that could be more relevant with Skia now, or is this already obsolete technology ? If Skia is able to perform so well and stable, I will give it a try soon, probably beyond just testing. My biggest concern is if such system is resilient and production stable now, or rather might break in the next OS or IDE updates. I see you'r updating very eager, and it seems well supported, so thats a very good sign. FMX is not really stable for me, and tend to behave different in every version. If Skia is an approach to make FMX more stable, I'm jumping on that train very likely, but if Skia is adding another dimension of new failure modes, I will probably will make more tests.

@vfbb Great, getting better with every build Could you please clarify some basic internals, since I haven't looked into this too much ? FMX has the drawback that it repaints the whole screen, even when only a small fraction of the screen has changed. How is the screen painting handled in Skia controls ? Is the control handled by Skia external library, or does it still behave like the original FMX ? Maybe Skia completely replaced the FMX rendering engine, and is optimized after that for the whole FMX controls, or the Skia rendering engine is used for their controls only, which leads to optimized drawing performance only for these controls, or Skia can not optimize the general FMX behaviour, but it can optimize within FMX's limits.

Have you tried this player, using VLC ? Worked fine for me in an older project, have not checked that with current IDE's. https://prog.olsztyn.pl/paslibvlc/

Bittesehr, you're welcome

Ok, in that case maybe this can be helpful, but its not a complete Delphi solution yet, you have to look into the sources.

Why ? If you want to igore a key you could abort operation, and also do other oprtation. Do you want to determine where the key is sended from, to do differentiate operations depending on sended from hardware or virtual keyboard ?