Rollo62

A lot of those ratios are scales of a kind of base ratio. I get screenshots from the devices to native resolution e.g. 1242x2208 somehow, and then re-scale the other variants from this base usually. Its getting more difficult since iPhone X, but you can still prepare a lot of variants from one screenshot. For example with a resize tool like IrfanView, which allows to keep resizing images with fixed aspect ratio, you can see that resizing came close tho the magic number (like 2209), and when you then remove the fixed aspect checkbox to be able to enter the desired number directily in the edit field (like 2208). Please check enclosed Excel file, where I found that e.g. the magic numbers 1242 and 2048 play a special role. I can re-scale the original base pictures to most of the needed aspect ratios (which may differ a few bits) w/o much distortion. So I must confess I'm not an designer, and I cannot see any issues with the bare eye (I'm sure that some designer will find some flaws), so I don't care much about this "invisible" distortion of the image.. But when I upload such artwork this is rarely rejected by Apple, so maybe also there somebody took a fast look at it, no special AI algorithm. For production I prepared some batch files for the processing, but I always wanted to put this whole image generation into a small tool, also for Android. iOS_Dimensions2.xls

@Dave Nottage Yes, it seems to work permanently in background only when I set both modes, but I do only use it as bluetooth-central. Otherwise it could be killed within 10 minutes. The iOS documentation tells me that background app can be killed anyway, no matter how many modes are set, if the phone needs resources (so that doen't make me feel much secure in this area), although my app is not safety critical. What I assume is that defining the bluetooth-peripherial seems to trigger the strange behaviour, which I haven't seen before. Theoretical there should be nothing wrong defining a background mode that I don't use, but this rejects maybe some more customers from the app. Anyhow, I have to do still more tests, but next week I'm on holiday, so won't be able too in short time. I would be happy to see more developers with BLE running in foreground or background in general, so far I have seen ' only little feedback in these topics (to be fair I see also little feedback in Xamarin and other products forums). There could be a solution to completely rework and rewrite the BT stack, but it still makes most sense to me to use the existing BT system, also because it shall work well on all platforms.

I use screenshots from physical devices, and some form-factors I scale to what is needed. Although this is not the way that is recommended, I got no rejections so far. Important is that the aspect ratio stays the same, doesn'T get blurry and looks like on a real device. Only for tablets this doesn't work out (to skale a phone to tablet), so you must look for the right base screenshots for phones and tablets. Maybe this helps to find the right aspect ratios.

Good luck for you too

https://community.idera.com/developer-tools/b/blog/posts/additional-information-for-the-android-32-bit-extension This proposal is still processing for me, at least Google didn't directly said NO. Currently the cases were pushed from 1st operator to technical team, waiting for their answer. I hope that I will hear some positive results, to move on with my work.

Sorry, I missed to put this in <irony> tags. Of coarse this is a nogo for Beacon apps, same as for BeaconFence. Isn't there a big field of applications (if not the largest field) for beacons using the background mode ? These changes were for Beacons, but not directly for normal Bluetooth LE apps. You mean keeping background mode like this I wouldn't need the location update, and the BLE accessories is the " bluetooth-peripheral" flag, right ? So do you mean here to use location updates to keep BLE alive in background ? Keeping alive already does the " bluetooth-peripheral" flag for me, but with some side-effects. Or with an ability to clear internal BT buffers after disconnected devices. A better solution would be to use " bluetooth-central" only, in background mode, hopefully w/o any side effects. But this I didn'T get to work w/o the " bluetooth-peripheral" flag.

That would be great. This is something I assume that is done internally by TMS WebCore, but from my understanding what I asked them, this is a internal WebBrowser, not opened for the normal use, but seems only for internal processing. So that answer took me away from testing and purchasing this product,, but a reliable bridge between Delphi and browser with all modern JS features is a big thing IMHO, and could even take over some parts of the growing node.js ecosystem a little bit.

@Dave Nottage Thanks for sharing, did you also get it working with the mobile frameworks ?

@Dave Nottage Well, is that line of yours an advertisement for BeaconFence ? I were lucky to use Bluetooth in foreground up to now, but it should be possible with the background modes. Why else did Embarcadero added them ? Is there any way to get background modes working as expected? I could already do background receive/transmit data, start Tts, place a local notification, etc. when the app was in foreground and the phone is just switched off (to black screen). But when the app is set to background before switching off (black screen), this might not work all the time. At at least I would say foreground works very stable in my library (which took a long way), the only problem now is the missing ability to reconnect at once, only 2nd power up of the IoT devices does the job. There seems to be something strangely blocked in the BT system, I have to investigate in the FMX code. Generally BT worked for me after long tests and finetuning, and one of the biggest issues from day one was the disconnection of IoT devices. While connection went more or less nicely, the disconnection may end in all kinds of strange behaviours, which I think has to do with the mixing of internal BT threads and Delphi threads, to avoid UI blocking. What helped me there was to completely destroy (free) the TBluetoothLEDevice variable, to get disconnection stable. Especially disconneting is still a very fragile process, and I'm happy it works halfway stable so far.

Hi all, as described here, I found a solution to the crash problem when using bluetooth background modes. Unfortunately this puts new issues on the table. Short recap: I use these background modes ( of coaarse all under latest 10.3.2 and current XCode/iOS versions). Actually I would need only bluetooth-central, since I want to receive data from a connected device. Once the connection is lost, I don't need to re-connect. Which works, but only for a short time (2- 10 min), then iOS seems to kill this app, even if peramently (1x per sec.) data is received. So I searched for solutions and found some in the web to add bluetooth-peripheral, so this mode will allow permanent app connection and streaming data, and even discovering devices and re-connect (untested). To get this running, I need to add these permission keys But the purpose of this bluetooth-peripheral background mode is, that the Phone will act as a peripheral, which I don't really need here. The drawback of this is, that I receive a new privacy permission request message, strangely when I disconnect a previous connected device, not earlier. (2.) Issue: unintended permission request call This message seemed to be related to the BluetoothLE.ClearServices; call, which I was calling to cleanup. This call seems to be used only when using as peripheral, not cleaning the services in central mode. Anyway, removing this call disabled the permission request. So far ,so good, 2 issues fixed. (3) issue: after disconnection, the device cannot be re-discovered again in the first attempt When I disconnect an IoT device (shut off), andwait until app has completely disconnected, and switch it on again. Strangely the device is not found any longer. It can be discovered again, when I does this power cycle twice (shut off the IoT device and power up again), then its discovered as usual. Of coarse I search for missing variables in my code, but I found the reasonf for this behaviour is the following: 1. time power up the IoT device 1. time connection: OnDiscoverLEDevice is called and the ADevice.DeviceName contains the name of the IoT device, as it should All OK, the IoT device is connected 1. time power off the IoT device, until fully disconnected in the app 2. time power up the IoT device 2. time connection: OnDiscoverLEDevice is called and the ADevice.DeviceName IS EMPTY STRING "", this causes the problem here 2. time power off the IoT device 3. time power up the IoT device 3. time connection: OnDiscoverLEDevice is called and the ADevice.DeviceName contains the name of the IoT device, al OK again, as in 1. start So the device is only able to re-connect when its two times powered up. I already tried to reset the BluetoothDeviceLE, the BluetoothAdapter, the BluetoothManager somehow, but without success. Also waiting a long time (30 min) before power up doesn't reset. When I connect another IoT device instead, it works, so it looks as if only the last device cannot simply be reconnected. Question: I'm still searching howto solve issue (3), to at re-connect every power up, maybe you have some clues howto get this running ? Some other open questions: How can I get rid of the bluetooth-peripheral mode at all ? - To be able to use bluetooth-central only, but with ability to receive data from a connected device in background mode. - To be able to use bluetooth-central only, but with the ability to discover and connect devices in background mode.

I've tried the follwing to reset the internal devices data FBluetoothLE1.CurrentManager.AllDiscoveredDevices.Clear; FBluetoothLE1.CurrentManager.LastDiscoveredDevices.Clear; FBluetoothLE1.CurrentManager.ForceRefreshCachedDevices := True; None of this works to solve issue (3). It looks as if this is something deep inside the iOS framework, which probably could be reset there somehow with some magic method. I'm further testing and searching solutions, but I hope for some help from the community.

So far I have better perfomance on iOS, no matter 10.3.1 or 10.3.2, compared to Android, which is still behind. But I couldn't really notice any big difference between the 10.3.1 and 10.3.2, also when using approximately same datarate as your, with storing into Sqlite, showing Chart, showing each data point on the screen. Ok, usually the datarates are lower, about 1 / sec., but I can also process the fastest channels and IoT devices with 0.25 sec. w/o stucking. The data comes in via Bluetooth LE, into a threaded ringbuffer, then getting processed chunk by chunk in a dedicated analyser, abnd the result is put into a special TMessage and sended to any subscriber in my app (which can up to 4-5 subscribers at a time (Sqlite table storage, Preview display, Chart view, debug logging, text to speech, etc.). I must confess that I have already made larger structural changes between 10.3.1 and .2, because of improving Android system mainly, so from these improvements iOS also gains a lot. But my early tests in a 1:1 same configuration for both IDE verisons showed no big, noticeable differences.

Not sure if this is related, I asked a similar question before. In my case its not only about the IDE upgrade, but also about howto port projects best from one to the other version. I found especially re-creating new projects and resetting them manually with every setting, the best and most reliable way for me to get projects updated. Since new versions might have new features and settings especially in FMX (like info.plist, entitlements, version info, etc.), the IDE does not always make the right choice when opening old projects into new IDE.

There is also a consideration about which JDK to install. In the last version(s) I only used the standard setup from Embarcadero, which works fine for me, and ensures that all EMBT libs are compatible to the JDK, NDK, SDK, and is less hassle. In the past I also had to use AndroidStudio, to get certain fixes, but I think the current versions were a lot more stable now.

Probably you have old and new units in the search path. Maybe you check your search paths and cleanup a little. I usually also clean all compiled project *.DCU, and re-build them all, which helps to avoid such strange linking error.

@Daniel I already made such proposal of a "CanIUse" page for Delphi and the most important 3rd party components. Maybe thats worth to think about, and to add in DelphiPraxis ? I would vote for this

It was not a new warning, aside the already known ones, but in my case it took much longer to process until it appears in the PlayStore (about some hours now). Usually when I published an app, I could see immediately a note "its available in the play store now", but this time not. Probably this was only because of bad timing of my update 31.07. (one day before the 01.08. break), I haven't checked whats happening now, after 01.08., but I soon will check that (if it takes any longer with the confirmation letter from Google).

Yes, that is true. I didn't made any benchmarks, but regarding compile-time my gut feeling tells me that Macos64 right now compiles significantly slower than Macos32. So I hope that this is only an effect of the initial version, and that optimization as well as compile-speed will be enhanced to normal in the next update(s).

I was trying to prepare new versions until yesterday, so I had hope that until 31.07.19 app still were processing normally. Unfortunately it seems not the case for me, at least for some apps I got a note. In parallel I asked for the Delphi extensions of various apps, but I got no direct, automatic "email received" message from Google, which is somewhat strange. Instead I received only a very simple "be patient" site after filling out the form. Does anybody else have this experience, and how long should I wait until Googles reply (3 days, 4 days, ...) ? I'm afraid they are a little bit busy now, checking a lot of extensions. Would be good to know how long this process might need, and how many pitfalls it might have, please share if you have some tipps and experiences. Edit: Oh, sorry. I just doublechecked, the app seems online in the store, although yesterday it didn't proceed as normally. The "processing" seems to take much longer as usual (seems to getting a little closer to Apple procedures now )

@Dave Nottage Well thanks, perfect tip again. I was alrerady diving deep in other tasked, but I just doublechecked this. There was a well hidden reference in OSX-specific code (typical copy-paste problem ) This reference was nicely separated in its own OSX unit uses {$IF Defined(IOS)} Sys.Power.WakeLock.Impl.iOS {$ELSEIF Defined(ANDROID)} Sys.Power.WakeLock.Impl.Android {$ELSEIF Defined(MSWINDOWS)} Sys.Power.WakeLock.Impl.Win {$ELSEIF Defined(MACOS)} Sys.Power.WakeLock.Impl.OSX {$ELSE} {$MESSAGE Error 'IWakeLock not supported on this platform'} {$ENDIF} ; but unfortunately the hidden reference resides in a region unit Sys.Power.WakeLock.Impl.OSX; .... {$REGION 'Windows helper functions'} function SetThreadExecutionState(esFlags: EXECUTION_STATE): EXECUTION_STATE; stdcall; external 'kernel32.dll'; {$ENDREGION} So this was hardly visible, if region was not expanded. Anyway, it was just this line, never used in the unit at all. Thats a good reason why I tend to avoid regions usually, and here I had one of the few places where I still used it by accident. I wonder why this never got any message/warning/hint/ under Macos32 ? Maybe Macos can make use of Windows kernel32.dll somehow Thanks for pointing me in the right direction. App is running now normally under Macos64 ( w/o any changes), even with the dirty Spring4D fix, and more important for me with Bluetooth LE support running at same code under Macos32/64 Bit (which was my biggest worry for me). Looks very good, need more time to test, but so far all is running out of the box. At compiletime I still get a warning: So maybe one day I find where this reference is, but for now I will check and test the more important parts. @Fritzew Thanks for the info, then I will be able re-test all my Spring4D related code soon. Since I already postponed this to the latest possible moment, and just started with the first project.

Not that it helps you here, but I try to separate code into separate units, as much as possible. So that I can bind the right routines like here: {$DEFINE ___USE_VERSION1} {$DEFINE _X_USE_VERSION2} {$DEFINE ___USE_VERSION3} uses ... {$IF DEFINED _X_USE_VERSION1} Feature.Version1 {$ELSEIF DEFINED _X_USE_VERSION2} Feature.Version2 {$ELSEIF DEFINED _X_USE_VERSION3} Feature.Version3 {$ENDIF} Which makes matters much more clear and readable. And YES: I also would like to see if I'm in the active part of an IFDEF, good feature. Wouldn't like to see it as comment, but as a kind of comment with slightly different color (maybe darker green), that would be OK for me.

I agree to what was said before, but maybe this and this info helps for additional tests.

Dear all, I'm still intensively testing all my projects under Rx10.3.2, and I reach now the following error in my Macos test machine: This happens when trying to load and debug an app on Macos, I already could debug other apps successfully in same setup. PAServer loads some files, but then stops with above message. The only difference is that I upgraded this project as described here, while other projects still just opened from 10.3.1 .dproj versions. Anyway, this app is running well on Android, iOS still to be tested. Compiling possible on all platforms without errors. The error message leads to some kind of linking error, missing file for sqlite3 distribution. In the web I found some solutions, like "upgrade OS" or "add missing libs", but hard to say whats missing in my setup ... My current setup is - RadStudio 10.3.2 Enterprise, running in VM under Win10 - iMac 2017 - Macos 10.12.6 Sierra ! Please don't recommend to upgrade the iMac to latest OS, since I use this specific iMac hardware to debug Bluetooth LE fastly, and this is the last OS version running BLE without problems for me. So usually all libs should be included in the deployment automatically, but mayxbe the libs used are too modern to be running on older OS. So either I could doengrade my libSqlite3, or I upgrade my iMac somehow. Maybe there is somebody who could help me out of this ugly situation ? Edit: I've used SDK 10.14 before, and now tried again with the SDK 10.14 Updated from the iMac, with same error message.

Hello @Dave Nottage, thank you very much for the clarification, I already thought into that direction. From where did you get that note about the "featured file" ? Since I was a little concerned about from where to pick the right build that doesn't crash somewhere else, but those thoughts turns out to be a no-brainer: Its available under Bds\Studio\20.0\binosx or binosx64. Again Delphi brings everything needed for the job with it Thanks much your help, so I can further focus on porting and testing now.

Do you know this nice tutorial from Craig Chapman ?